Assumption Mapping: Find What Must Be True Before You Commit
An assumption map turns invisible beliefs into a test queue, starting with claims that are both important and uncertain.
How assumption mapping works
Write the proposed solution or explanation, list what must be true for it to work, and separate facts from beliefs. Rank each assumption by consequence if wrong and strength of current evidence. Test the high-consequence, weak-evidence assumptions first with the smallest observation or experiment that can change the decision.
Write down what must be true for a plan to work. Test the beliefs that are both important and uncertain before spending more time or money.
Key relationships
- An assumption connects a proposed action to an expected result.
- Importance measures how much the plan depends on that belief.
- Uncertainty shows how little strong evidence supports the belief.
Prioritize beliefs by decision risk, not by convenience
Suppose a team proposes a self-service scheduling tool. The plan depends on several beliefs, but they should not all receive equal research time. Importance describes how badly the plan fails if a belief is false. Evidence strength describes how much trustworthy support exists now.
| Assumption | Importance | Evidence now | Next test |
|---|---|---|---|
| Customers can identify the correct appointment type | High | Weak | Observe a prototype task with representative users |
| Available slots are accurate across systems | High | Medium | Compare a synchronized pilot against source calendars |
| Reminder wording is understood | Medium | Weak | Run a comprehension test before building automation |
| The new color palette is preferred | Low | Weak | Defer unless it affects comprehension or access |
The first assumption belongs at the front of the test queue because the product fails at its core task if users choose the wrong service. The palette preference is uncertain but not yet decision-critical. Testing it first would create activity without protecting the plan.
Turn a belief into a testable record
- State the belief as a claim that can be false.
- Name the commitment that depends on it.
- Describe evidence that would increase or reduce confidence.
- Choose a review date and owner for the next decision.
Extract assumptions from a proposal
Take each verb and outcome in the proposal and ask what must be true. If the plan says customers will use a self-service form, assumptions may concern awareness, access, motivation, comprehension, trust, and whether the form can resolve the common cases.
Include system assumptions, not only user behavior. Capacity, permissions, data quality, handoffs, timing, and incentives often determine whether an otherwise attractive idea can operate.
Separate facts, estimates, and beliefs
A fact has a traceable observation within a relevant time and population. An estimate uses a stated method and uncertainty. A belief is plausible but not yet supported enough for the decision. The labels describe evidence, not confidence or seniority.
Record the source and date beside facts. A verified pattern from last year may become an assumption after a process, market, or audience changes.
Build the importance and evidence map
Score consequence if wrong using a small anchored scale. A high score might mean the solution cannot deliver its main outcome or creates unacceptable harm. Score evidence strength separately based on directness, recency, sample coverage, and measurement quality.
The priority region contains important assumptions with weak evidence. Important, well-supported claims should be monitored. Low-impact claims rarely deserve an expensive test even when uncertain.
Design a decision-changing test
State what result would support, weaken, or retire the proposal before collecting data. A test that cannot change the decision is theatre. Prefer behavioral evidence and operational traces over opinions when the assumption concerns actual use or system performance.
Match test fidelity to risk. A paper walkthrough may reveal comprehension problems. A limited pilot may be needed for workflow capacity. A safety-critical assumption may require formal validation before any live exposure.
Maintain the map through delivery
An assumption map is not a kickoff artifact. Update evidence, confidence, owner, and next review point as the solution changes. When a high-priority assumption fails, revisit dependent decisions rather than editing only the failed line.
Archive retired assumptions with the evidence that resolved them. The history explains why the team chose its path and stops old claims from quietly returning in later versions.
Use the map to sequence investment
Place tests before commitments they can inform. A comprehension test belongs before interface development, while a capacity pilot belongs before a broad operational rollout. If a contract or build decision will make learning expensive, move the relevant assumption test earlier even when another test would be easier to run.
Track the cost of being wrong as well as the cost of testing. A low-probability claim with irreversible harm can deserve earlier validation than a more uncertain claim whose failure is cheap and reversible. This keeps the map tied to decisions rather than curiosity.
Turn a risky assumption into a test
Once the critical assumption is visible, use hypothesis-driven problem solving to design evidence that can change the decision.
If the appropriate method is still unclear, compare the options with the problem-solving method selector.
Practice replacing an assumed preference with a physical constraint in the elevator resident lateral-thinking riddle.