Signal is not the ability to read data. Every PM reads data. Signal is the ability to read *conflicting* data — and still move.
That distinction matters more than it sounds. The skill isn't pattern recognition in a clean spreadsheet. It's knowing which evidence to weight when you have a retention chart pointing one way, a support queue pointing another, and a qualitative research session that contradicts both. It's the capacity to hold three genuinely conflicting reads at once and still arrive at a decision — not because the conflict resolved cleanly, but because you developed a read on which signal was real and which was noise.
The wrong take beginners have: they think Signal is about gathering more data until the picture clears. It rarely does. In the situations that matter — a product at an inflection point, a roadmap call under resource constraint, a bet-the-year feature decision — the picture never fully clears. The data will be incomplete. The evidence will point both ways. The org will be watching. Signal is the judgment to read through that fog and call it anyway.
The harder wrong take: Signal is just confidence. It isn't. Over-confident PMs move fast on thin evidence. What Signal measures is specifically the quality of the read — whether you knew which piece of evidence deserved the most weight, and whether that reasoning was sound after the fact.
The reason it's in Acuity — the skill of discernment and judgment under ambiguity — is that Signal requires the PM to hold two things simultaneously: genuine openness to what the evidence is saying, and the discipline to rank that evidence rather than treat it as equal votes. Both without losing either. That's a rare move.
citation
PL Standard v3.1 · Acuity · Signal
Markdown form: [PL Standard v3.1 · Acuity · Signal](https://pragmaticleaders.io/framework/competencies/signal)
the four levels
Anchored at every rung. The blockquote at each level is panel-authored and pulled live from the rubric — edit anchors via the panel tooling and they appear here.
L1Developing
flags contradictions only after a teammate names them, then defers to whoever spoke last instead of weighing the evidence.
you'll see this when…
The PM reports the loudest, most recent signal as the headline — a single furious customer complaint becomes "users hate this feature," a spike in one-day metrics becomes "we've cracked retention"
Evidence is presented without any weighting — a 3-person user interview and a 300-person survey get equal billing in the recommendation
When signals conflict, the PM defers to whoever has the most authority in the room rather than which signal is most structurally reliable
common failure mode: Chasing the loudest signal. Volume of noise gets mistaken for strength of evidence, so the roadmap tilts toward whoever complained last.
L2Competent
sorts conflicting signals on familiar problems and names a lead interpretation; stalls or seeks input when evidence patterns fall outside past experience.
you'll see this when…
The PM distinguishes between qualitative and quantitative evidence and names why each has a role — "the NPS drop tells us something's wrong; the session recordings are telling us what"
Conflicting signals are acknowledged rather than suppressed — the PM will say "we have a contradiction here" and hold it openly instead of resolving it by cherry-picking
Evidence weighting is plausible but shallow — they'll correctly flag that a one-week cohort's behavior shouldn't override a six-month trend, but can't articulate *why* the structural reliability differs
common failure mode: Acknowledging conflicting evidence without ranking it — good epistemic hygiene, but no move. The PM surfaces the contradiction clearly and then waits for someone else to resolve it.
L3Proficient
spots conflicting signals as noise before others flag them, then names the specific failure mode that would invalidate the leading interpretation.
you'll see this when…
The PM applies a consistent mental model for ranking evidence — "behavioral data over stated preference, longitudinal over cross-sectional, cohort-controlled over aggregate" — and does it instinctively, not from a checklist
They catch the quiet signal others dismiss: three of your most engaged users going silent is noticed and treated as material, even if the aggregate metrics haven't moved yet
When a decision gets made on weak signal, they name the bet explicitly — "we're acting on thin evidence here; here's what we expect to see in 30 days that will confirm or refute it"
common failure mode: The survey trap. Self-reported preferences get treated as behavioral evidence. "Users said they would pay for this" gets used as a proxy for "users will pay for this." It's not the same signal. One is stated intent; the other is proof. Proficient PMs know the difference, but the trap still catches them under deadline pressure.
L4Expert
reframes which signals matter before others form the question, then calls the decision — setting the standard the team uses on the next hard call.
you'll see this when…
The PM reads second-order signals — not just what users are doing, but what the pattern of what they're doing implies about what they need and won't articulate
They develop a prior for their own environment: they know, from experience, which signal types in this product, this customer segment, this stage tend to be leading indicators versus lagging noise
Evidence synthesis is causal, not correlational — the PM can articulate *why* one metric moves before another in their system, not just that it does
common failure mode: Over-discounting. The L4 trap is becoming so calibrated to noise that you start dismissing real signal because it comes through a channel you've learned to distrust. "Users always say they want more control — ignore it" becomes a filter that misses the moment when they actually do. Expert pattern-matching can become expert blindness. The antidote is deliberate naivety: periodically ask what you would think about this evidence if you had no priors at all.
how to develop it
The most leveraged move is training yourself to slow down at the moment you receive evidence. Most PMs don't have a bad read — they have a fast read. They receive a data point and immediately pattern-match it against what they expect. Signal lives in the gap between receiving evidence and acting on it.
Read. [Data interpretation](/manual/core-skills/analytics/data-interpretation) is the technical foundation — the traps (Simpson's paradox, survivorship bias, composition shifts) that make dashboards lie. [Metrics and KPIs](/manual/core-skills/analytics/metrics-and-kpis) for the structural reasoning about which metrics are leading vs lagging. [Diagnosing metric drops](/manual/core-skills/analytics/diagnosing-metric-drops) for how to hold competing hypotheses about the same signal.
Practice. Any scenario where you're handed contradictory inputs and asked to make a call. Look for briefs that put qualitative and quantitative evidence in tension — your job isn't to resolve the contradiction, it's to decide which side of it to act on and why. The Practice section at [/practice](/practice) includes decision-under-ambiguity scenarios where the signal deliberately points both ways.
Write. In your next Brief, build a section called "what the evidence says vs what I'm reading from it." Explicitly name the gap between the raw data and your interpretation of it. If there's no gap, you haven't done the work yet.
Coach yourself. After a decision, ask: *which signal was I most confident in, and was I right?* Not just whether the outcome was good — that's survivorship bias. The specific question is whether the signal you weighted most heavily turned out to be the reliable one. Build that log over time.
how to spot it in others
In a planning review, they volunteer what the evidence *doesn't* say as well as what it does — "this tells us about retention in the first 30 days; we have nothing reliable on 90-day behavior yet"
They name the signal hierarchy when evidence conflicts rather than presenting both sides as equal: "I'm weighting the behavioral data over the survey responses because…"
When they update a view based on new evidence, they can say exactly what changed and why — not "I saw some more data" but "the cohort analysis shifted my read on churn attribution because it controlled for the acquisition channel confound"
In post-mortems, they distinguish between a bad decision and a decision made on the best available evidence that turned out wrong — they know the difference, and they're honest about which one it was
They're comfortable holding a view before the data is clean: "we don't have enough to be certain, but the best read I can make today is X, and here's what I'd need to see to change it"
three failure modes we see often
The survey trap. Self-reported preference gets treated as behavioral signal. "73% of users said they'd pay for a premium tier" goes into the deck as evidence that users will pay for a premium tier. Stated intent and revealed behavior are not the same signal. Stated intent is useful as a directional indicator; it becomes dangerous when it's treated as proof. The reason this happens is that surveys are cheap to run and produce clean, quotable numbers — which makes them disproportionately influential relative to their reliability.
The cohort fallacy. One cohort's extreme experience gets elevated to company strategy. A power user segment's demands reshape the roadmap. A single bad-churn cohort drives a retention overhaul. The cohort's signal may be real — but without controlling for whether that cohort is representative or an outlier, you're potentially remaking the product for an edge case. The cohort fallacy is especially pernicious because power users are vocal and leadership tends to take their meetings. Volume of engagement gets mistaken for representativeness.
The dashboard freeze. Waiting for clean data when the situation calls for a read now. A metric is ambiguous. The cause could be A, B, or C. The natural instinct is to hold the decision until the analysis is done. Sometimes that's right. Often — especially in fast-moving environments — the cost of waiting exceeds the cost of deciding on imperfect evidence. The dashboard freeze is Signal failure of a particular kind: the PM can read evidence but can't tolerate acting on uncertain evidence. Real Signal includes knowing when to call it with 60% confidence rather than waiting for 90%.
Both involve reading evidence, but Reframe is specifically about recognizing when the *question* being asked is wrong. Signal is about reading the evidence correctly once you have the right question. They compose: you need Reframe to make sure you're looking at the right signal, and Signal to read it accurately. But a PM can have strong Signal and poor Reframe — they read the evidence in front of them sharply, without ever questioning whether they're looking at the right thing.
Bet is downstream of Signal. Signal is the read; Bet is what you do with it under resource constraint. A PM can have strong Signal and poor Bet — they know what the evidence says, but they size investments poorly under uncertainty. In practice they work together: you rarely have a clean signal that makes the bet obvious, so Signal and Bet happen simultaneously. But in scoring they're distinct — one is the quality of the read, the other is the quality of the commitment.
Taste is about judging quality you didn't make — outputs, work products, AI-generated artifacts. Signal is about reading evidence from the world. The surface similarity: both require discernment. The distinction: Taste is evaluative (is this good?), Signal is epistemic (what is this telling me?). A PM with strong Signal reads data sharply. A PM with strong Taste reads a design or a draft sharply. Different inputs, different judgment muscle.
what good looks like in the wild
A PM at a mid-stage SaaS company was staring at a feature with 19% adoption — roughly average for their toolkit. The feature had been shipping for eight months. On every call with the success team, customers were positive about it. The NPS cohort that used it was higher than average. Every visible signal said "this is fine."
She killed it.
The signal she was weighting wasn't the adoption rate, which was ambiguous. It wasn't the qualitative feedback, which was warm but shallow — customers weren't saying they needed it, they were saying they liked it when they remembered it existed. The signal she was reading was the cohort of six power users who had been heavy users in months one and two and then quietly stopped. Six users, out of thousands. Not a number that would show up on any dashboard.
She reached out to them directly. Three replied. The pattern was consistent: the feature had solved the problem they'd had when they first noticed it, but as their workflow matured, it created friction in a different part of the process. They'd found a workaround. They weren't angry. They'd just quietly stopped.
Her read: the feature solved an early-stage problem that graduated users didn't have. Keeping it had ongoing maintenance cost and — more importantly — it was a surface that distracted new users from the core workflow they needed to build. It was polite noise masquerading as signal.
She pitched the kill to leadership with the six-user cohort at the center of the evidence, named the adoption rate as ambiguous rather than positive, and got the decision made. Twelve months later, the team had rebuilt the underlying use case into the core workflow in a way that didn't require a separate feature at all — and the metric that had been stuck for a year moved.
The hardest part of that call wasn't finding the signal. It was resisting the louder signals — the NPS lift, the positive customer quotes, the adoption rate that wasn't alarming — that were technically true but not the ones that deserved the most weight.