Assumption Mapping

What Is Assumption Mapping?

Assumption mapping is a team exercise for identifying the beliefs a product idea depends on and ranking them by how important they are and how much evidence supports them. The assumptions that are both critical and least supported get tested first.

David Bland, co-author of Testing Business Ideas, developed this approach through work with product teams, building on earlier risk-mapping practices.

How Assumption Mapping Works

The exercise usually has three steps. Teams can also include adaptability assumptions: whether the idea can survive changes in its environment.

1. Surface the assumptions. The team writes down everything that must be true for the idea to succeed, grouped into three categories borrowed from design thinking:

   • Desirability: do customers want this? For example, "small agencies are frustrated enough by late invoices to switch tools."
   • Viability: should we do this as a business? For example, "customers will pay at least our target price."
   • Feasibility: can we deliver it? For example, "we can integrate with the main accounting platforms."

2. Map them. Each assumption is placed on a 2x2 grid. One axis runs from unimportant to important: how much the idea depends on it. The other runs from "have evidence" to "no evidence."

3. Choose what to test. The quadrant with important assumptions and little evidence holds the riskiest bets, and those become the focus of the next experiments. Important assumptions with strong evidence can be accepted for now. Unimportant ones can wait.

Each assumption chosen for testing is then turned into a clear hypothesis with a success measure and tested with a small product experiment, such as interviews, a landing page, or a prototype.

Why Assumption Mapping Matters

Every idea rests on assumptions, but most are never written down. When they stay hidden, teams test what is easy instead of what is risky, or skip testing altogether. Assumption mapping makes the beliefs explicit and gives the team a shared, defensible reason for testing one thing before another.

It also prevents spending money too early. The exercise helps the team clarify what must be true before committing more capital. Testing the riskiest assumptions first means a fatal flaw shows up after a week of interviews rather than after months of development.

Because the exercise is collaborative, it brings disagreement to the surface. An engineer may rate a feasibility assumption as far riskier than a product manager expects, and that conversation is valuable in itself. Mapping is a core step in product discovery and is often repeated as evidence builds up. For how tested assumptions turn into data-backed requirements, see SaaS idea validation loops from customer discovery to PRDs.

Assumption Mapping Example

The following example is hypothetical.

A team plans a marketplace that connects homeowners with local handypeople for small repairs. Their mapping session surfaces assumptions including:

• Homeowners struggle to find someone for small jobs (important, some evidence from interviews).
• Handypeople will accept a platform fee on each job (important, no evidence).
• We can verify a handyperson's identity cheaply (important, little evidence).
• Homeowners want in-app chat (less important, no evidence).

The fee assumption lands in the riskiest corner. Before building anything, the team calls local handypeople and offers to send them paid jobs in exchange for a fee. Their responses provide an initial signal about willingness to accept the fee; actual completed jobs and repeat participation provide stronger evidence. The chat feature can wait.

From Mapping to an Assumption Register

A map helps the team choose what to test now. An assumption register keeps those beliefs visible as work continues. After the session, record each critical assumption with an owner, its current evidence, the next test, and a review date. The register is an ongoing record, rather than another name for the initial ranking exercise.

Link the test result back to the assumption and update its confidence when new validation evidence arrives. Keep the distinction between “we observed this” and “we believe this means that.” A positive interview does not permanently remove a risk. Revisit important assumptions when the target segment, pricing, technology, or market changes; remap them if their importance or evidence has shifted.