Skip to content
Nerdy beta

Assumption Mapping

Add to Space
 Product Discovery

Every product idea is a stack of assumptions pretending to be facts. Assumption mapping forces the team to name them, sort them, and figure out which ones to test first.

Overview

Assumption mapping is a collaborative exercise where a cross-functional team generates assumptions about their product idea, then plots them on a 2x2 grid: importance (vertical) vs. evidence (horizontal). The upper-right quadrant — important assumptions with no evidence — is where the risk lives. Those are the ones worth testing before you build anything.

The technique feeds on everything the team has built so far: story maps, user journeys, impact and outcome models, personas, business models, and competitive research all contribute assumptions worth examining. Each assumption is color-coded by risk category — viability (green), desirability (red), and feasibility (blue) — so the team can see whether their blind spots cluster in one area.

The output is a prioritized list of assumptions to validate through experiments. The format is simple: “We believe that…” followed by a testable claim. From there, the team designs experiments to gather evidence, starting with the cheapest tests for the riskiest assumptions.

How to Run It

  1. Form a cross-functional group (3 product/UX, 3 engineering works well)
  2. Draw the 2x2 grid: Important/Not Important on the Y-axis, Have Evidence/No Evidence on the X-axis
  3. Individually generate as many assumptions as possible in a few minutes — one per sticky note, phrased as “We believe that…”
  4. Come together and place assumptions on the grid as a group
  5. Use different colors for viability, desirability, and feasibility assumptions
  6. Circle the upper-right quadrant: important, no evidence. These are your candidates for experimentation

Traps

  • One-shot maps. Assumption maps should be living artifacts, revisited as you learn. A map you build once and never update is just a workshop exercise.
  • Too many assumptions. An overloaded map loses its power to prioritize. Focus on the assumptions that would kill the idea if wrong.
  • Declaring validation too soon. One positive signal is not validation. Be honest about what you actually know vs. what you hope.
  • Lack of diverse POVs. If only product people are in the room, you’ll miss feasibility and viability assumptions. Engineering and business perspectives matter.

Resources

  • David J. Bland and Alex Osterwalder, “Testing Business Ideas” (Wiley, 2019) — the canonical reference for assumption-driven experimentation
  • Product Experiments — what you do after you identify risky assumptions
  • Opportunity Solution Trees — another tool for structuring the space between outcomes and solutions
  • Framing — the upstream practice that produces the problem statement an assumption map tests