What Would Have to Be True
When a team debates whether an option is right, it becomes a clash of opinions and the loudest advocate tends to win. This skill flips the question: instead of “is this a good idea?”, ask “what would have to be true for this to be the best choice?” That turns a position into explicit conditions, which can be rated for confidence and tested. It depersonalizes disagreement (we are not debating who is right, we are listing conditions and checking them) and separates what would have to be true from what is true. The output is an assumption ledger that ends by naming the one or two conditions worth testing before committing.
When to Use
Section titled “When to Use”- Evaluating a consequential strategic bet or a specific option.
- A disagreement has hardened into competing opinions with no way to resolve it.
- A choice rests on optimistic or unstated assumptions.
- Often after options exist and before a final decision; pairs with a decision-comparison skill and with premortem.
When NOT to Use
Section titled “When NOT to Use”- Trivial or fully reversible decisions where the ceremony is not worth it.
- To generate options (use an ideation skill) or to choose among several at once (use a decision-comparison skill).
- As a substitute for actually testing the conditions; listing them is not validating them.
Instructions
Section titled “Instructions”When asked what would have to be true, follow these steps:
- State the option or claim under examination in one sentence (the thing whose conditions you will surface).
- Enumerate the conditions. List the things that would have to be true for this to be the best choice. Push for the load-bearing and risky ones, not the easy, agreeable ones. Cover demand, economics, execution, competitive response, and stakeholder conditions.
- Mark which are load-bearing. For each, note why the choice fails if it is false.
- Rate current confidence. High / medium / low, with a reason. Be honest where you do not know.
- Say how each could be tested. A cheap test, a signal, or the data that would confirm or kill it.
- Name the killer conditions. Identify the one or two conditions that are both most load-bearing and least certain. These should be tested before committing.
- Emit the assumption ledger per
references/TEMPLATE.md.
Output Format
Section titled “Output Format”Use the template in references/TEMPLATE.md. The deliverable is the ledger ending in the killer conditions, not prose.
Quality Checklist
Section titled “Quality Checklist”Before finalizing, verify:
- Conditions are framed as “would have to be true,” not asserted as already true.
- The risky, load-bearing conditions are present, not just easy ones.
- Each condition has a confidence level and a way to test it.
- One or two killer conditions (load-bearing and uncertain) are named.
- The output is the ledger artifact, not prose.
- No overclaiming: this structures and tests the bet, it does not prove it (see
evidence/dossier.md).
Evidence
Section titled “Evidence”Tier P. A widely adopted strategy method from Lafley and Martin’s Playing to Win (2013): reverse-engineer an option into the conditions under which it would be best, then test the ones you are least sure of. It has strong practitioner traction and sound hypothesis discipline, but no controlled evidence of improved outcomes, and the evidence is transferred from human strategy practice, not AI-validated. Full grading: evidence/dossier.md.
Examples
Section titled “Examples”See references/EXAMPLE.md for a completed assumption ledger.
Deep dive: worked example
Section titled “Deep dive: worked example”A full worked run (the shared Northwind scenario)
Assumption Ledger - Worked Example
Section titled “Assumption Ledger - Worked Example”A completed run of think-what-would-have-to-be-true, on the shared Northwind scenario. This is the quality bar a generated ledger should meet.
Northwind is a B2B SaaS weighing a self-serve free-tier launch. Here the skill tests the option “launch a free tier” by surfacing what would have to be true for it to be the best growth move.
Option or claim under examination
Section titled “Option or claim under examination”- The choice: Launching a self-serve free tier is the best way to hit Northwind’s Q3 growth target.
Conditions that would have to be true
Section titled “Conditions that would have to be true”| # | Condition that must hold | Why it is load-bearing | Confidence | How to test it |
|---|---|---|---|---|
| 1 | Free-to-paid conversion among ICP-fit free users is high enough to cover the free tier’s cost | If conversion is too low, the free tier is pure cost and does not produce paid growth | low | Cohort analysis of current self-serve conversion; a small gated pilot measuring ICP-fit free-to-paid |
| 2 | The free tier attracts ICP-fit users, not mostly tire-kickers | Growth in non-ICP signups does not convert and inflates cost | low | Light qualification at signup; measure firmographic fit of free cohort in a pilot |
| 3 | The free tier does not materially cannibalize paid plans | Downgrades would offset or exceed new growth | medium | Limited rollout; monitor downgrade rate and trial-to-free vs trial-to-paid |
| 4 | Support and infrastructure cost per free user stays within budget | Cost overrun breaks unit economics regardless of growth | medium | Cost model + a usage-capped pilot with a cost-per-free-user ceiling |
| 5 | Sales cooperates (comp and lead-routing realigned before launch) | Reps steering away from free suppresses the whole motion | medium | Written rules of engagement and sign-off from sales leadership |
| 6 | No cheaper path hits the Q3 target with less irreversible commitment | If a cheaper option exists, the free tier is not the best choice | low | Quick comparison against 2-3 alternatives (funnel fix, outbound, partnerships) |
Killer conditions (test these before committing)
Section titled “Killer conditions (test these before committing)”- Condition 1 (ICP-fit conversion economics) - confidence low - cheapest test: a gated pilot to ~100 ICP-fit free users measuring conversion and cost. If it fails, the free tier produces cost without paid growth and the whole case collapses.
- Condition 6 (no cheaper path) - confidence low - cheapest test: a one-day comparison of alternatives. If a funnel fix or outbound hits the target cheaper, the free tier is not the best choice even if it works.
Note: the value is forcing conditions 1 and 6 into the open. The original proposal asserted growth; this ledger shows the bet rests on two low-confidence conditions that a small pilot and a one-day comparison could de-risk before committing engineering to a one-way door. From here, run think-premortem on the chosen plan.
Grounding: the full evidence dossier
Section titled “Grounding: the full evidence dossier”What the research does and does not show, with graded sources
Evidence Dossier: What Would Have to Be True
Section titled “Evidence Dossier: What Would Have to Be True”Single source of truth for the
what-would-have-to-be-trueskill. The SKILL.md, sidecar, and evals derive from this. If a claim is not here, it does not belong in the skill.
| Skill | thinking-framework-skills.what-would-have-to-be-true (installable name think-what-would-have-to-be-true) |
| Family | decision-and-option-evaluation |
| Evidence tier | P (practitioner; respected strategy method) |
| Confidence | High that it improves the quality of a strategy conversation; no controlled outcome evidence |
| Status | draft (authored 2026-05-31 from the discovery corpus) |
1. The mechanism (what actually does the work)
Section titled “1. The mechanism (what actually does the work)”When a team debates whether an option is right, the conversation becomes a clash of opinions and the loudest advocate often wins. WWHTBT flips it: instead of asking “is this a good idea?”, ask “what would have to be true for this to be the best choice?” That converts a position into a set of explicit conditions. The conditions can then be assessed for current confidence and, crucially, the few that are both load-bearing and uncertain can be tested before committing. The work is done by (a) depersonalizing disagreement (we are not debating who is right, we are listing conditions and checking them) and (b) separating what would have to be true from what is true, which exposes the assumptions a choice silently rests on.
2. Lineage
Section titled “2. Lineage”- Roger Martin and A.G. Lafley, Playing to Win (2013), and Martin’s related HBR strategy work, introduce “what would have to be true” as a reverse-engineering test for strategic options: rather than defend a favorite, articulate the conditions under which each option would be the best one, then test the conditions you are least sure of.
No trademark on the phrase. Named descriptively; lineage cited.
3. What the evidence shows, and what it does NOT show
Section titled “3. What the evidence shows, and what it does NOT show”Supported (as practice): it is a widely adopted strategy method with strong practitioner traction, and it has a sound logical basis (converting claims to testable conditions is good hypothesis discipline).
NOT shown: there is no controlled study that WWHTBT improves decision outcomes or accuracy. Its value is in structuring the conversation and surfacing assumptions; do not claim a measured effect on results.
4. Transferred-evidence flag
Section titled “4. Transferred-evidence flag”Evidence is from human strategy practice, not AI-augmented use. Transferred, not AI-validated. The AI value: a model will happily argue for or against an option; forcing it to enumerate the conditions that would have to hold, and to flag the riskiest, is a direct counter to confident advocacy, and the ledger is testable and inspectable.
5. When it works / when it fails
Section titled “5. When it works / when it fails”Works best when: evaluating a consequential strategic bet or option; a disagreement has become a clash of opinions; a choice rests on optimistic or unstated assumptions.
Fails or misleads when (poor-fit / anti-patterns):
- Trivial or fully reversible decisions where the ceremony is not worth it.
- Listing conditions but never prioritizing or testing them (the central failure mode).
- Generating agreeable, easy-to-meet conditions instead of the load-bearing risky ones.
- Confusing “would have to be true” (a condition to test) with “is true” (already verified).
- It tests a given option or claim; it does not generate options (use ideation) or choose among several (use a decision-comparison skill, though it pairs well with one).
6. Output artifact
Section titled “6. Output artifact”An assumption ledger: each condition that would have to hold, why it is load-bearing, current confidence (high/medium/low), how it could be tested, and a test priority. It ends by naming the one or two “killer” conditions that are both most load-bearing and least certain, which should be tested before committing.
7. Sources
Section titled “7. Sources”- Lafley, A. G., & Martin, R. L. (2013). Playing to Win: How Strategy Really Works.
- Martin, R. L. - HBR strategy writing on reverse-engineering options and testing the assumptions you are least sure of.
Verification status: the attribution to Lafley & Martin / Playing to Win is well-attested. Treat all effectiveness as practitioner-reported; do not attach a quantified outcome claim in any public-facing text.