Extract and classify every assumption before committing — test high-importance, high-vulnerability first
Before committing resources to a plan, extract every assumption it depends on and classify each by importance (would the plan fail if this is wrong?) and vulnerability (how likely is this to be wrong?), then test assumptions marked both high-importance and high-vulnerability first.
Why This Is a Rule
Every plan rests on assumptions, and most plans fail at the assumptions rather than the execution. The team that builds a flawless product on the assumption that "customers want this" fails when the assumption turns out to be wrong. Testing assumptions before committing resources prevents the most expensive category of failure: well-executed plans built on false premises.
The two-dimensional classification (importance × vulnerability) solves the prioritization problem. Not all assumptions are worth testing — some are low-importance (the plan survives if they're wrong) or low-vulnerability (they're almost certainly correct). Testing every assumption is impractical. The 2×2 matrix focuses your limited testing budget on the quadrant that matters: assumptions that would kill the plan if wrong AND are plausibly wrong. These are your "killer assumptions" — test them first.
The extraction step itself is valuable even without testing. Most assumptions are invisible until you deliberately enumerate them. The act of writing "this plan assumes..." surfaces dependencies that were operating without scrutiny.
When This Fires
- Before committing budget, time, or team resources to a project plan
- Before launching a product, feature, or initiative
- When a plan "feels solid" but hasn't been stress-tested
- During any planning session where the next step is "go build it"
Common Failure Mode
Testing the easy assumptions instead of the dangerous ones. Low-importance, low-vulnerability assumptions are comfortable to verify ("yes, the API supports JSON") while high-importance, high-vulnerability assumptions are uncomfortable to confront ("do customers actually want this?"). The matrix forces you to sequence by risk rather than by comfort.
The Protocol
Before committing resources: (1) List every assumption the plan depends on — aim for 10+. (2) For each, rate importance (H/L): "Would the plan fail if this is wrong?" (3) For each, rate vulnerability (H/L): "How likely is this to be wrong?" (4) Sort into a 2×2 matrix. (5) Test all High-Importance / High-Vulnerability assumptions before committing resources. If any fail, redesign the plan. The remaining quadrants can be tested during execution.
Source Lessons
Externalize your assumptions
Assumptions you never write down are assumptions you never question. Every plan, decision, and belief rests on invisible premises — and the invisible ones are the ones that destroy you.
Compound ideas hide dependencies
An idea that looks like one thing is often several things fused together, each carrying unstated assumptions that silently constrain what you can do with it.