01 / UNDERSTAND
What is Assumption Mapping?
Assumption mapping makes the beliefs behind a proposal visible and prioritises them by consequence and evidence. It helps a team decide which uncertainty deserves an experiment before effort is spent building the whole solution.
Why use Assumption Mapping?
A promising concept can rest on beliefs about desirability, viability, feasibility or usability. Writing those beliefs as specific claims makes disagreement inspectable. Mapping risk against current evidence helps a team choose a useful next test instead of treating confidence in a meeting as proof.
When to use it
USE IT WHEN
A concept depends on several unverified beliefs.
A team needs to choose between research, prototyping or delivery work.
A decision is blocked because people disagree about what must be true.
When to choose another method
Use Impact / Effort Matrix when comparing solution work rather than uncertainty.
Use User Interviews when the main need is to understand people’s context and language.
Use Usability Testing when a working interaction is available and task performance is the question.
What you’ll need
Bring one decision, a shared description of the proposal and the people who own its risks. Gather existing evidence, separate observation from interpretation and agree what counts as enough evidence for the next decision. Do not force every assumption into a single score.
What an assumption map needs
Keep the elements that help answer your question and support a decision.
What choice the assumptions should inform.
Beliefs written so they could be supported or disproved.
The consequence if wrong and the evidence available now.
Desirability, viability, feasibility or usability, when useful.
The smallest credible way to learn.
Who acts and what new evidence changes the plan.
02 / PUT IT INTO PRACTICE
How to map assumptions
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Name the decision
State what the team is deciding and by when.
Decide whether to offer flexible rescheduling during course booking.
02
List the beliefs
Write one claim per card with a subject and observable outcome.
People with a booking will choose a paid flexible option when the conditions are clear.
03
Classify carefully
Use types to expose blind spots, not to create a decorative taxonomy.
Separate demand for the option from the operational ability to honour it.
04
Assess consequence
Ask what happens if the claim is wrong.
A false demand assumption wastes build effort; a false capacity assumption creates service failures.
05
Check evidence
Record what is observed, reported, inferred or unknown.
Existing support messages suggest confusion, but do not prove willingness to pay.
06
Design the next test
Choose a small experiment with a decision rule and owner.
Prototype the offer, recruit people with recent bookings and record the reasons for choosing or rejecting it.
Example: testing flexible rescheduling
Illustrative scenario, not research findings. A course platform is considering a paid option that lets a learner move a booking once. The team lists claims about demand, acceptable price, staff capacity and the clarity of the conditions. They mark the demand claim as consequential but weakly evidenced, while the operational rule is consequential and partly documented.
The next test is a prototype offer shown after booking. The team records questions, choices and reasons, then checks the operational handoff with staff. The output is a decision about what to investigate next, not a forecast of sales.
A hypothetical choice can reveal how someone interprets the offer. It does not establish willingness to pay. Before estimating demand, plan an appropriate behavioural test involving a real commitment.
03 / BELOW THE SURFACE
Below the surface: evidence changes priority, not just confidence
The map should influence the next action. Keep consequence, available evidence and dependencies visible.
01 / CONSEQUENCE
What fails if this is wrong?
Trace the effect on the proposal and its dependencies.
02 / EVIDENCE
What has actually been observed?
Separate behaviour, reports and team confidence.
03 / DECISION
What result changes the plan?
Set the decision rule before running the experiment.
A map is useful when it changes the next action. A high consequence, low evidence assumption deserves attention, but a low consequence claim can still block a dependency. Revisit the map when the proposal changes, because one new constraint can move another belief to the front. Keep confidence separate from evidence: a team can feel certain and still have little that is observable. State the decision rule before running the experiment so the result cannot be reinterpreted after the fact.
Assumption Mapping working canvas
Use page one for the question and practical record, and page two for the review and next decision. The two page PDF has 7 editable text fields. Open it in a PDF reader that supports forms and save a working copy.
Practical tips
Write claims that name a behaviour, condition or observable result.
Keep assumptions atomic so one experiment can teach something specific.
Pair every high risk assumption with an owner and a trigger.
Common mistakes
Ranking ideas by intuition alone.
Calling a stakeholder opinion evidence of behaviour.
Choosing an experiment without saying what decision it will inform.
What you’ll get
A prioritised set of assumptions, a visible evidence gap and a next experiment tied to a decision.