Spotting and fixing the wrong question before solving it.
what we mean by this
Most PM failures are not execution failures. They are framing failures. The team shipped the thing they set out to ship — on time, on spec, with beautiful engineering — and it didn't matter, because the thing they set out to ship was the answer to the wrong question.
Reframe is the competency that catches that before it happens. It's the ability to look at the question in your hands — the one you received from a brief, a stakeholder, a planning doc, a quarterly OKR — and ask: is this actually the question we need to answer?
This is not the same as analysis. Signal tells you how to read conflicting evidence once you've agreed what question you're answering. Bet tells you how to size the investment once you've decided what you're pursuing. Reframe is upstream of both. If the question is wrong, sharp signal-reading and careful bet-sizing are just more efficiently-executed wrong answers.
Where beginners go wrong: they think reframing is something you do to other people's questions. You push back on a stakeholder's framing. You redirect a brief. You tell the team the spec misframes the problem. That's useful — but it's not the hardest part. The hardest part is catching a bad frame in your own thinking, before you've spoken it aloud, before you've written it into the doc, before you've organized a team around it. That's not feedback. That's judgment. And it's rarer.
The other trap is confusing reframe with endless deferral. A PM who never commits to a problem statement because "there might be a better frame" is not exercising judgment — they're avoiding it. Reframe is a decision move, not an escape hatch. At its best, it produces a sharper, more committed answer to the right question. At its worst, it becomes a way to stay upstream of every decision indefinitely.
citation
PL Standard v3.1 · Acuity · Reframe
Markdown form: [PL Standard v3.1 · Acuity · Reframe](https://pragmaticleaders.io/framework/competencies/reframe)
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
accepts the problem as stated and solves it; questions the framing only after a manager or peer explicitly flags that the brief is wrong.
you'll see this when…
A PM receives a stakeholder request ("we need faster export") and immediately starts scoping the export optimization — without asking why users want fast export or whether the underlying problem is actually about export speed.
A planning doc opens with a feature request labeled as a problem ("build X for Y") and nobody in the room pushes back on the framing.
Post-launch, when the feature delivers on all its metrics but the underlying user behavior hasn't changed, the PM is genuinely surprised — because they never asked whether improving the metric would move the behavior.
common failure mode: The solution-shaped problem — the problem statement is written after the solution is already decided, back-justifying the feature already in flight.
L2Competent
catches misframed problems in familiar territory; raises the reframe only after someone else signals doubt on high-stakes or unfamiliar work.
you'll see this when…
A PM surfaces the right question in review ("wait, are we sure export speed is actually the bottleneck?") after seeing conflicting qualitative signals — but wouldn't have raised it without the data prompt.
They push back on a stakeholder frame when it's clearly misaligned, but struggle to hold the reframe when the stakeholder pushes back.
They distinguish between a symptom ("users are churning") and a cause ("users churn because they can't complete setup in one session"), but the cause they land on is still framed in stakeholder terms rather than customer behavior.
common failure mode: The stakeholder echo — the problem gets reframed, but only into the stakeholder's language, not the customer's. The surface of the question changes; the underlying orientation doesn't.
L3Proficient
catches misframed problems before work begins, redirects the team to the right question, and documents the reframe so others learn the pattern.
you'll see this when…
A PM opens a planning session by naming the current frame explicitly: "we've been treating this as a speed problem — I want to check whether it's actually a setup completion problem before we commit resources."
They identify the moment a problem statement hardened into accepted truth — and can name specifically when and why the frame stopped being interrogated.
They distinguish between a frame that is wrong and one that is incomplete, and they scope the reframe accordingly — not blowing up the whole charter, just anchoring on a sharper version of the question.
common failure mode: The consensus frame — the frame everyone agrees on because nobody was willing to break the silence and push. Proficient PMs catch their own bad frames, but still sometimes confuse "everyone agrees with this" for "this is correct."
L4Expert
reframes the problem before the room commits to the wrong one — and the team adopts that framing as the new starting point.
you'll see this when…
A PM designs the planning process so that the problem statement is explicitly contested before solution work begins — not once, not as a formality, but as a structural gate.
They can identify, and name aloud, when they are rationalizing a frame they've already invested in versus genuinely testing it.
They teach the team to reframe — not by explaining the concept, but by modeling it in real decisions, so the team develops the instinct themselves.
common failure mode: Reframing as procrastination — the expert PM's fluency with alternative frames becomes a way to avoid committing. There is always a better question possible. At L4, the failure mode is not accepting bad frames — it's refusing to commit to any frame, because that commitment feels like premature closure. The move is knowing when the frame is good enough to act on, and acting.
how to develop it
The highest-leverage move is practicing it on your own work, not on someone else's. Take the last PRD you wrote or problem brief you accepted. Write the problem statement in three words or fewer. Now ask: whose problem is this? How did this version of the question get chosen? Is there a version of the question that, if answered, would make this one irrelevant? That 15-minute exercise will reveal more about your reframe instinct than any workshop.
Read. Start with /manual/core-skills/discovery/problem-definition — the anatomy of a bad problem statement is the most direct mirror for reframe failure modes. Then /manual/core-skills/discovery/jobs-to-be-done — JTBD is, mechanically, a reframe instrument: it forces you to ask what job the customer is hiring the product to do, rather than accepting the feature-first frame.
Practice. Any scenario where the brief arrives pre-framed and the evidence contradicts it — "right answer wrong reason" and "metric win, hidden regression" practice scenarios both exercise the instinct. The constraint: you must name the frame explicitly before questioning it. Unnamed frames can't be fixed.
Write. Use the Brief prompt with a product you know well, then write two competing problem statements before you write a single word of solution. Force yourself to choose between them and articulate why. The choice is the judgment.
Coach yourself. After any planning session, write one sentence: "The question we agreed to answer was ___. The question I'm not sure we tested is ___." If the second sentence is blank, you probably stopped interrogating too early.
how to spot it in others
In planning: do they accept the framing in the doc, or do they ask "how did we get to this question?" before moving to solution?
In design reviews: when the design clearly solves a problem, can they name the problem first — and is that problem the right one, or the one that made the solution easiest to specify?
In post-mortems: when something didn't work, do they go back to the problem statement, or do they stay at the execution layer? ("We shipped it wrong" vs. "we were solving the wrong thing")
In discovery readouts: when research reveals customer behavior that doesn't fit the current frame, do they stretch the frame to accommodate the data, or revise the frame to match what the data is actually saying?
In 1:1s: when they tell you what they're working on, can they state the underlying customer problem in one sentence — not the feature, the problem — and can they say how they know that's the right problem to be solving?
three failure modes we see often
The solution-shaped problem. The problem statement is written after the solution has already been decided. It's grammatically correct, emotionally compelling, and completely backwards — written to justify a feature that's already in flight, not to find the feature worth building. It's the most common reframe failure because it's the hardest to see in your own work. The tell: if the problem statement could only lead to one solution, it's probably not a problem statement.
The stakeholder echo. The PM successfully questions the original brief — but lands on a reframe that still uses the stakeholder's language, the stakeholder's categories, the stakeholder's theory of the customer. The question changes shape but not orientation. "We need to improve export" becomes "we need to improve export speed" instead of "customers need to move data out of the product to complete a workflow we don't control." The difference is the difference between an interface problem and an integration problem. Getting there requires going to customer behavior directly, not through the stakeholder's interpretation of it.
The frame that hardened when nobody was looking. Some problem statements are never decided — they accumulate. A customer complaint, a support ticket, a data point in a QBR, a throwaway line in an executive slide, and suddenly it's in the planning doc as the unexamined frame everyone builds from. Nobody chose it. Nobody tested it. It just survived long enough to seem authoritative. This is the reframe failure that scale makes worse: the larger the organization, the more planning docs repeat earlier planning docs, and the harder it is to find the moment when the question was actually set.
Signal and Reframe both involve evidence and judgment, but they operate on different objects. Signal asks: given the question in front of us, what does the evidence say? Reframe asks: is this the right question? You need Signal to execute a Reframe well — misreading the evidence will give you a bad reframe — but they are distinct moves. A PM can be excellent at Signal and poor at Reframe: they read conflicting evidence accurately and conclude the wrong thing because they never questioned the question.
Bet is downstream of Reframe. Once you've landed on the right question, Bet tells you how much to invest in answering it. The adjacency creates a failure mode: a PM with strong Bet instincts will sometimes skip the reframe in order to size the investment. They move efficiently toward a commitment on the wrong question. Strong Bet plus weak Reframe is how teams ship well-scoped things that don't matter.
what good looks like in the wild
A B2C product team was spending a quarter trying to speed up their export feature. Customer research had flagged it as a pain point: the export took 20–30 seconds, customers mentioned it in interviews, the support queue had tickets about it. The roadmap item was export performance — and it was well-scoped, engineering had a clear path, and the PM had a clean metric: reduce export time to under 5 seconds.
The PM ran the sprint kickoff and did something that took 20 minutes and changed the quarter. She pulled the support tickets herself — not the summary, the raw text — and read 40 of them in sequence. Not the ones that mentioned export speed. The ones where export appeared at all.
What she found: 60% of the tickets that mentioned export weren't about speed. They were about not being able to find the export option, or not understanding what format to export in, or starting the export and then abandoning it because they weren't sure the output would be what they needed. The 20-second wait time appeared in a minority of tickets. Speed was the complaint that was easiest to articulate, not the complaint that was most common.
The reframe: the problem wasn't that export was slow. The problem was that customers weren't confident enough in the export to start it in the first place. The 20-second wait felt painful precisely because users weren't sure it was going to give them what they wanted.
The fix wasn't a performance optimization. It was a one-sentence description of the export format, shown before the export began, and a progress indicator with an estimated completion time. Three days of engineering. The abandonment rate on the export flow dropped 40%. Customers stopped writing tickets about "slow export" — not because it got faster, but because they stopped abandoning mid-export in frustration.
“
The PM didn't invent a new process or run a discovery sprint. She read the source material instead of the summary. That's what reframe looks like — not clever, not contrarian. Just the discipline to go back to the question before committing to the answer.