Assumption Mapping

---

Origins

Assumption Mapping was popularized by David Bland and Alexander Osterwalder in Testing Business Ideas¹, building on earlier work by Tom Gilb, the Lean Startup community, and the Lean UX practice of explicit hypothesis-building. The technique addresses a problem visible across product work: teams invest in plans built on assumptions they have not examined, then act surprised when reality disagrees with one.

The premise is simple. Every plan rests on assumptions. The team can't validate all of them — there are too many — but it can pick the ones whose failure would matter most and where the team has the least evidence, and test those first.

The Two Axes

Assumption Mapping plots assumptions on a 2×2 grid:

• X-axis: Evidence. From no evidence (unknown) on the left to strong evidence (validated) on the right.
• Y-axis: Importance. From low impact if wrong (doesn't matter much) at the bottom to high impact if wrong (would derail the work) at the top.

The four quadrants tell the team where to focus:

• Top-left: high importance, no evidence. Leap of faith assumptions. These are the bets that will sink or float the work. Test these first.
• Top-right: high importance, strong evidence. Known and supported. Move on; this is settled.
• Bottom-left: low importance, no evidence. Acknowledge and move on. Not worth investigating; not worth worrying about.
• Bottom-right: low importance, strong evidence. Trivially settled. No further work.

The top-left quadrant is the whole point. Teams that systematically attack their leap-of-faith assumptions before building waste far less effort on the wrong things than teams that don't.

Running an Assumption Mapping Workshop

1. Frame the scope (5–10 min)

What initiative or decision are we mapping assumptions for? A feature, a product, a strategy. Specificity matters — "our roadmap" is too broad, "the SMB pricing tier we're proposing" is workable.

2. Generate assumptions (20–30 min)

Silent generation. Each participant writes assumptions on sticky notes, one per note. Prompts that help:

• What about users are we assuming?
• What about the market are we assuming?
• What about technical feasibility?
• What about business viability?
• What about adoption and behavior?

3. Cluster (10 min)

Group similar assumptions. Often clusters reveal that the team is making the same assumption five different ways, which is itself useful information.

4. Place on the matrix (20 min)

For each cluster or note, the team discusses and places it on the grid. Where is the evidence (or lack)? How important would it be if this assumption turned out to be wrong?

This is the conversation that produces the value. Two people will often disagree about evidence ("we have data on this!" "what data, exactly?") or importance ("this is critical!" "really, why?"). The disagreement surfaces the assumption underneath.

5. Identify the top 3-5 leap-of-faith assumptions (10 min)

From the top-left quadrant, pick the 3-5 highest. These are the ones the team will design experiments for.

6. Design experiments (15–20 min)

For each top assumption, sketch how the team will test it. Customer interviews? A prototype test? A fake door? An A/B test? The output is a small set of experiments with owners and timelines.

What Makes the Practice Work

• Diverse perspectives in the room: an engineer surfaces technical assumptions; a designer surfaces user behavior assumptions; a PM surfaces market assumptions. A single-discipline room maps only one quadrant of its own assumptions.
• Honest evidence assessment: "we know" should mean "we have data showing." Aspirational confidence belongs on the no-evidence side of the line.
• Importance grounded in consequence: "if this assumption is wrong, what happens?" Real consequence is what makes something important, not the team's emotional attachment to it.
• Follow-through on top quadrant: the experiments designed at the end need to actually run, or the workshop produced awareness without learning.

Common Pitfalls

• Wishful evidence claims: assumptions placed in the high-evidence column based on "we feel pretty good about this" rather than data. Either it's evidence or it isn't.
• Everything important: every assumption rated high importance, defeating the prioritization. Force ranking helps.
• Missing categories of assumption: a team thinks technically and misses market assumptions. The prompts list (users, market, technical, business, behavior) is there for a reason.
• Map without experiments: assumptions identified and ranked, but no plan to test the riskiest ones. The artifact becomes wall decoration.
• One-time exercise: mapped at project kickoff, never revisited. Assumptions shift as work progresses; remap when major decisions are coming up.

Coaching Tips

Insist on Evidence Honesty

"We feel confident" is not evidence. Push the team to defend evidence claims with actual data points before placing assumptions on the right.

Force-Rank the Top Quadrant

When the top-left quadrant has 30 items, the team has surfaced fear, not focus. Force a ranking down to the riskiest 3–5.

Get All Disciplines in the Room

An engineering-only room maps technical assumptions; a product-only room maps market assumptions. Cross-functional input is required for a complete map.

Pair with Experiments

The mapping is a means to experiments. End the workshop with specific experiment plans, owners, and timelines — not just a populated grid.

Track Movement Over Time

Assumptions migrate as evidence comes in. Photograph the initial map, then revisit it after experiments — the movement is itself a useful artifact.

Watch for the Sacred

Some assumptions feel too important to question. Those are the most valuable to map. If the team resists naming an assumption, that resistance is data.

Summary

Assumption Mapping is one of the highest-leverage exercises a team can run before investing significant effort. The map itself is a forty-minute artifact; the savings from running the experiments it identifies are often months. The practice's strength is that it forces the team to name what it doesn't yet know, which most teams resist doing.

The practice fails the same way most discovery practices fail: when the team produces the artifact but doesn't act on it. The top-left quadrant has to feed real experiments, the experiments have to produce real evidence, and the team has to be willing to change direction when the evidence says they should. With those conditions, the technique pays for itself many times over.

Back to Experience & Story Mapping