How to Approach Assumption Mapping Systematically

A roadmap can look precise while resting on a sentence nobody has examined.

“Customers need a shared dashboard.”

Perhaps they do. The same idea could also depend on customers noticing the problem often enough, trusting the data, changing an existing workflow, and paying for the improvement.

The feature is visible. The beliefs supporting it are not.

Assumption mapping makes those beliefs discussable. Its purpose is not to remove uncertainty or cover a wall in sticky notes. It is to decide what the team needs to learn before making the next expensive commitment.

Start with the commitment, not the canvas

An assumption map becomes useful when it is attached to a decision.

Are you deciding whether to interview customers, build a prototype, fund an engineering spike, or place an initiative on the roadmap? Each commitment demands a different level of evidence.

Write the decision at the top of the map:

What do we need to believe before we responsibly make this commitment?

This question gives the exercise a boundary. Without it, teams tend to list every uncertainty they can imagine. The result feels thorough but does not identify the work that should happen next.

For a large roadmap investment, commercial viability may be critical. Before a prototype test, the immediate question may be whether people understand the interaction.

The map should be as wide as the decision requires, and no wider.

Write assumptions so they can be challenged

“Customers value simplicity” is too vague to test. It does not define the customer, the behaviour, the alternative, or the meaning of value.

A more useful assumption is:

Operations managers who prepare a weekly report will replace their spreadsheet when the product produces a reviewable draft from existing data.

It may still be wrong, but the team can now challenge it. Do those managers own the report? Is weekly preparation painful? Is the spreadsheet the real alternative? What makes a draft reviewable?

Good assumptions usually name:

• a specific actor;
• a situation or trigger;
• an expected behaviour or outcome;
• a condition that matters to the decision.

Avoid hiding several beliefs inside one sentence. “Users will understand, adopt, and pay for it” is at least three assumptions with different evidence needs.

When a statement sounds like a fact, ask what evidence currently supports it. Confidence, repetition, and seniority are not evidence.

Look across four kinds of product risk

Teams often map only desirability: do people want the idea? A product can be desirable and still fail because people cannot use it, the team cannot deliver it, or the business cannot sustain it.

The four big risks described by Silicon Valley Product Group offer useful prompts:

Value

Will people choose or use the product? Is the problem important enough to change behaviour? Does the proposed response create a meaningful improvement over the status quo?

Usability

Can the intended users understand and use it in their real context? What knowledge, access, device, or assistance does the experience assume?

Feasibility

Can the team build, operate, secure, and support it with the available technology, data, skills, and time?

Business viability

Can the organisation sell, fund, govern, and legally operate it? Does it fit the business model, brand, policy, and channel?

These categories are prompts, not four boxes that require equal numbers of notes. Their value is in exposing risks that one discipline might otherwise miss.

Invite product, design, engineering, research, commercial, operational, and policy perspectives when they are relevant. Different roles see different parts of the same bet.

Rank importance against evidence

David J. Bland’s assumptions-mapping approach compares how important a belief is with how much evidence supports it.

That distinction matters. An assumption can be uncertain but harmless. Another can feel familiar while controlling the whole investment.

Use two questions:

1. Importance: If this is wrong, does the current idea or commitment still make sense?
2. Evidence: What have we observed that directly supports the belief?

Do not turn the axes into false precision. “Evidence: 7.3” says less than “three recent workflow observations, all from existing power users.” Describe the evidence so people can inspect its relevance and limits.

Pay attention to the beliefs that are both important and weakly supported. They deserve action first.

This is the same discipline used in Research-Driven Opportunity Sizing: an explicit assumption is more useful than an impressive number with no traceable basis.

Find the assumption that controls the next move

The highest-risk note is not automatically the next thing to test.

Some assumptions depend on others. There is little value in testing the visual design of a dashboard if the team has no evidence that the underlying reporting problem matters.

Ask:

• Which belief could make the rest of the idea irrelevant?
• Which uncertainty blocks the next decision?
• Which evidence could change our direction soonest?
• Which test is proportionate to the commitment we are considering?

This creates an evidence sequence. Test problem and behaviour before polishing a solution. Test a technical unknown before promising a date. Test purchasing constraints before projecting revenue.

Assumption mapping is therefore a form of prioritisation. It determines the order in which uncertainty should be reduced.

Design the smallest credible test

The smallest test is not the quickest activity. It is the least expensive way to produce evidence credible enough for the decision.

A survey may be quick but weak for understanding a workflow. A production experiment may be excessive when a prototype can reveal whether people understand the concept.

Match the method to the question:

Assumption	Useful evidence might include
A problem occurs in a specific context	Interviews, observation, support evidence, workflow data
People understand a proposed interaction	Moderated prototype sessions, usability testing
A technical approach can meet a constraint	Spike, benchmark, architecture review
A channel can reach qualified buyers	Small channel test, sales evidence, procurement research
A change improves behaviour	Instrumented experiment or careful before-and-after analysis

The GOV.UK guidance on research planning starts with research questions before choosing methods.

That order prevents a familiar tool from defining the evidence.

Before running a test, record:

• what you expect to observe;
• what would weaken the assumption;
• whose behaviour counts as relevant;
• how the result will change the decision.

If no plausible outcome would change the plan, the activity is validation theatre.

A hypothetical mapping session

Imagine a B2B workflow product considering automatic weekly summaries. This example is invented to demonstrate the method.

The team is deciding whether to fund a production-quality beta. It lists several beliefs:

• team leads currently spend meaningful time compiling updates;
• existing reports fail because information is scattered, not because nobody reads them;
• recipients trust a generated summary when evidence is traceable;
• the available data is complete enough to create a useful draft;
• customers will permit the required data processing;
• a summary can improve decisions without creating notification noise.

The team initially wants to test the email design. The map reveals a more fundamental belief: recipients may not act on weekly summaries at all.

They review current reporting behaviour and observe a small set of relevant teams. They learn that the report matters, but only before a specific planning meeting. A generic Friday email would arrive at the wrong moment.

That evidence does not “validate the feature.” It changes the idea. The next test becomes a manually prepared, traceable brief delivered before the meeting.

The map has done its job because it changed the order of investment.

Keep the map alive

An assumption map is a decision record, not workshop debris.

Update it when research changes the evidence, engineering exposes a constraint, the market moves, or the proposed commitment grows. Retire beliefs that no longer affect a decision and add new ones that emerge.

Useful moments to revisit it include:

• opportunity and solution reviews;
• roadmap and funding decisions;
• experiment readouts;
• design or architecture changes;
• launch and post-launch reviews.

Link important assumptions to the evidence that supports them. A short note such as “five interviews” is not enough; record who was studied, in which context, and what was actually observed.

For the next step from belief to evidence, use Research-Driven Hypothesis Testing.

Where assumption mapping becomes theatre

The team maps features, not beliefs. Notes say “dashboard” and “notifications” instead of what must be true for those solutions to work.

Everything is high risk. Without a specific commitment, people cannot distinguish foundational uncertainty from general curiosity.

Votes replace evidence. Dot voting shows what the room worries about. It does not establish what is true.

Tests can only confirm the idea. Leading questions and friendly samples generate reassurance, not learning.

The map never changes a plan. If every result supports the original roadmap, the team is documenting decisions after the fact.

Ownership is vague. Assumptions remain visible but nobody is responsible for gathering evidence or returning with a decision.

The cure is simple: connect every important assumption to an owner, an evidence action, and a decision date.

A practical workshop

For one active product bet:

1. State the next commitment and its deadline.
2. Ask each relevant discipline what must be true for that commitment to make sense.
3. Rewrite broad statements into separate, challengeable assumptions.
4. Group them across value, usability, feasibility, and viability.
5. Compare importance with the strength and relevance of existing evidence.
6. Identify dependencies between the most important beliefs.
7. Choose the uncertainty that controls the next move.
8. Design a proportionate test and define how the result will affect the decision.
9. Assign an owner and return date.
10. Update the map when the evidence arrives.

The output is not a full picture of reality. It is a better next move.

Sources

• How Assumptions Mapping Can Focus Your Teams on Running Experiments That Matter — Strategyzer
• The Four Big Risks — Silicon Valley Product Group
• Plan user research for your service — GOV.UK Service Manual

Read next

Research-Driven Hypothesis Testing shows how to turn the selected assumption into a testable claim and choose evidence that can genuinely change the decision.

Strategic Bets: Commit in Stages Without Hiding the Risk applies assumption exposure to staged investment decisions where uncertainty cannot be removed upfront.