"What Would Have to Be True?": Turning Optimism Into Testable Conditions

"What would have to be true?" is Roger Martin's reverse-engineering test for strategy: instead of arguing whether an option is right, you list every condition that would need to hold for it to be right. Each condition becomes testable and assignable, which turns an unwinnable argument over conclusions into a shared, checkable list.

Quick answer: Stop debating "is this the right call?" — nobody wins that argument. Ask instead, "what would have to be true for this option to be right?" List every condition, mark each one testable or assumed, and go check the one you're least sure about and most exposed to.

The Reverse-Engineering Question That Ends Circular Debates

Roger Martin's test flips a strategy argument backward: instead of defending a conclusion, you name the conditions that would have to hold in the world for that conclusion to be the correct one. Two people can disagree forever about whether an option is "right." They can usually agree, quickly, on a testable list of what it depends on.

"The reason you would say this is a good choice is that you believe X, Y, and Z to be true. Are they?" — the shape of Martin's question, applied to any contested strategic call.

Martin developed this idea across decades advising CEOs, first as a strategy consultant and later as dean of the Rotman School of Management. With former Procter & Gamble CEO A.G. Lafley, he wrote Playing to Win, which treats a strategy not as a plan but as a set of choices — where to play, how to win — each one a hypothesis rather than a fact.

His reframe is deceptively simple. A strategic choice is not "true" or "false" on its own; it's a bet that pays off only if certain background conditions hold. So instead of asking whether the bet is smart, you ask what has to be true about customers, costs, competitors, or capability for it to pay off.

That single move does two things a conclusion-first argument never does:

• It converts opinions ("I think we should go enterprise") into falsifiable claims ("enterprise buyers will pay 4x our current ACV for this workflow").
• It separates the parts of the debate that are actually about evidence from the parts that are really about risk appetite or incentives.

This is the same underlying instinct behind the broader discipline of adversarial thinking for product managers: you don't wait for the market, the board, or a competitor to find the weak point in your logic. You go looking for it yourself, on paper, while it's still cheap to be wrong.

Why Teams Argue Conclusions Instead of Assumptions

Most product debates get stuck at the conclusion layer because that's the only layer anyone can see; the assumptions underneath stay silent, so the same argument repeats every quarter with no new information surfacing. Naming the hidden layer is what actually moves a debate forward.

Organizational-behavior researcher Chris Argyris, working out of Harvard Business School, described this pattern with a model called the ladder of inference. People select a slice of available data, add meaning to it based on their own experience, form assumptions, jump to conclusions, and then defend those conclusions as if they were the data itself.

Two colleagues can climb entirely different ladders from the same set of facts — and never notice they diverged three rungs down.

That's why "I disagree" meetings go in circles. Nobody is debating the data — they're each defending a conclusion built on assumptions the other person never got to see, let alone challenge. Roger Martin's question is, functionally, a way of forcing everyone back down their own ladder to the rung where the actual disagreement lives.

Three symptoms usually mean a team is stuck arguing conclusions instead of conditions:

1. The same debate resurfaces in consecutive meetings with no new evidence introduced, just louder restatements of each side's position.
2. Confidence is used as evidence. "I'm sure this will work" substitutes for a testable reason it would work.
3. Disagreement tracks seniority or team affiliation more than it tracks any specific claim about customers, costs, or capability.

None of this means the conclusions people hold are wrong. It means nobody has yet separated the part of the disagreement that's checkable from the part that's just appetite for risk.

Running the Individual Version: From Opinion to a List of Conditions

To run Martin's test on your own recommendation, write down every condition that would have to be true for it to be the right call, then sort that list by how confident you are and how much damage being wrong would do. The condition with low confidence and high exposure is where your real risk lives — and where you should look next.

The process is short enough to run solo in twenty minutes, before you take a recommendation into a room:

1. State the option plainly. "We should build the enterprise SSO integration next quarter" — not a vague direction, an actual, falsifiable decision.
2. List every condition it depends on. What has to be true about the customer, the cost, the competitor, the team, and the timing for this to be the right call?
3. Tag each condition as known (you have real evidence), believed (you're fairly sure but haven't tested it), or hoped (you want it to be true and haven't checked).
4. Rank by confidence × exposure. A hoped condition that the whole plan rests on outranks a known condition every time — even if the known one feels more urgent to discuss.
5. Design the cheapest test for the top-ranked condition, not the whole list at once.

The table below shows how the same recommendation reads differently once you separate the conclusion from the conditions underneath it:

Notice what happened: the disagreement about whether "enterprise" is the right call didn't get resolved by more debate. It got broken into three separate, ownable questions, at least one of which someone can probably answer this week using jobs-to-be-done research already sitting in a CRM or a support queue.

The Group Version: Every Faction Names Its Own Conditions

When a room is split between two or three options, have each faction write down what would have to be true for their preferred option to be the right one — not why the other side is wrong. This reframes a debate between people into a comparison between conditions, which is far easier to resolve without anyone losing face.

The mechanics matter more than they look:

• Each faction writes independently, in silence, before any cross-talk — the same principle behind a well-run four critics pre-mortem panel, where forcing individual answers first prevents the loudest voice from anchoring everyone else's list.
• No faction is allowed to write conditions about the other option. Attacking someone else's assumptions is round two; naming your own comes first.
• Conditions get pooled into one shared table, so overlaps and contradictions become visible to everyone at once, instead of living in separate camps' heads.

A worked version, for a team split between two roadmap bets:

Laid out this way, the fight over which roadmap is "right" quietly becomes a fight over which two untested conditions — sales-cycle length, or self-funding expansion revenue — are cheaper and faster to check. That's a solvable disagreement. "Which team's instinct do we trust more?" never was.

It also tends to surface where a faction is really debating feasibility (call in a skeptical-engineer critique on the SSO timeline) versus where they're really debating unit economics (call in a revenue-hawk critique on that support-cost assumption). Naming the condition tells you which specialist should test it.

A Worked Strategy Example: Two Roadmaps, One Shared List

Applying the full test to a real-shaped strategic choice makes the mechanics concrete: list the conditions each option depends on, rank them by confidence and exposure, and let the cheapest test — not the loudest voice — decide what gets checked first. Here is how that plays out for the enterprise-versus-SMB choice above.

Strategist Richard Rumelt, in Good Strategy/Bad Strategy, makes a related point: he argues that most documents labeled "strategy" are really just restated ambitions — a target revenue number, not a diagnosis of the actual obstacle standing between you and it. A "what would have to be true" list is one way to force the diagnosis back in: you can't write a testable condition without first naming the specific obstacle it's meant to clear.

Applying the ranking step from the individual version to the pooled group table above:

1. Rank every condition across both factions by confidence × exposure, ignoring which team proposed it.
2. The lowest-confidence, highest-exposure condition wins the next two weeks of attention — in this case, whether SMB expansion revenue can genuinely self-fund the roadmap, since the whole product-led bet collapses if it can't.
3. Design the cheapest real test: a cohort-level revenue model using the last two quarters of expansion data, not a fresh forecast built on hope.
4. Set a re-check date, not an indefinite "monitor it" — an untested condition with no return date quietly becomes a belief again.

Decision researcher Annie Duke, in Thinking in Bets, calls the failure mode this guards against "resulting" — judging a decision by whether it worked out, rather than by whether the process behind it was sound given what was knowable at the time. A condition you tested and got wrong, on a fair test, was still a good decision. An untested "hoped" condition that happened to pay off wasn't.

Oxford researcher Bent Flyvbjerg's studies of infrastructure megaprojects — cited by Daniel Kahneman as a textbook planning-fallacy case — found rail projects overrunning budget by roughly 45 percent on average, and roads by around 20 percent.

That gap exists because planners tested feasibility against hope, not against a reference class of comparable projects that actually shipped — the same discipline gap a "what would have to be true" list is meant to close before the money is committed, not after.

If the enterprise bet is the one that survives this ranking, a natural next step is validating the buying and adoption conditions with a customer journey map for the enterprise security-review stage specifically — the point in the funnel where "buyers will pay for SSO" either holds up against a real evaluation process or quietly doesn't.

Turning Conditions Into Owned, Tracked Assumptions

A list of conditions is only as useful as the discipline that keeps it alive after the meeting ends; without an owner and a status, "what would have to be true" decays into forgotten notes exactly like any other unresolved action item. The fix is treating each condition as a tracked object, not a bullet in a slide that nobody reopens.

This is the part of the exercise most teams skip, not because it's hard, but because there's no natural home for a list of "beliefs we're checking." A shared doc gets stale. A Slack thread scrolls away. Six months later, nobody remembers which conditions were ever actually resolved.

What tracking a condition properly requires is small but rarely happens by default:

• An owner — one name, not "the team."
• A status — known, believed, hoped, or resolved, not just "noted."
• A re-check date — so an assumption has to be actively re-confirmed, not just quietly assumed to still hold.

In Prodinja, the conditions you surface from a "what would have to be true?" session can be logged as Assumption entries in Journals — including by voice, right after the meeting where they surfaced — and then pulled into a Situation, so each one carries exactly that: an owner, a status, and a date, instead of dissolving back into "I thought we agreed on that."

That's the honest version of what a tool can do here: it gives the list somewhere to live and someone accountable for each line, so the next time the enterprise-versus-SMB debate resurfaces, the room can check what was actually resolved instead of restarting the argument from opinion.

Key Takeaways

• Argue conditions, not conclusions. "Is this right?" is unwinnable; "what would have to be true for it to be right?" produces a checkable list.
• Tag every condition as known, believed, or hoped — confidence level determines what needs testing, not how confidently it was stated in the room.
• Rank by confidence × exposure, not by urgency or seniority — the untested condition the whole plan depends on outranks the one that's merely loud.
• Run the group version by having each faction name its own conditions first, silently, before anyone is allowed to attack the other side's assumptions.
• Assign a specialist to the condition type: feasibility conditions to an engineering-minded critic, unit-economics conditions to a finance-minded one.
• Give conditions an owner and a re-check date — an assumption nobody is accountable for quietly turns back into an unexamined belief within a quarter.