Assumption mapping: find the riskiest assumption before you build
Run this method in IdeaHone
Creates a space with the entities and scoring criteria of this method, ready for your next session.
A team spends three months building, launches, and learns in week one that customers never had the problem. Nobody had checked. Assumption mapping is the hour you spend before the budget is approved: list what must be true for the concept to work, find the assumption that is both important and unproven, and test that one first, cheaply.
The assumptions everyone nods at
Every concept rests on assumptions, most of them unspoken. The dangerous ones are not the ones the team argues about; they are the ones everyone nods at without having checked.
It helps to sort them into three kinds:
- Desirability. Do customers want this? Do they have the problem, and does it hurt enough to change their behaviour?
- Feasibility. Can we build and run it with the people, technology and processes we have?
- Viability. Does it pay? Does the margin cover the cost, and will it still be worth it in a year?
Teams over-test feasibility because engineers can answer it from their desk. Concepts die more often on desirability.
How to run it
Plan 60 to 90 minutes with the five to eight people who will build or fund the concept.
- Write the concept in one line. On the wall: who it is for, what it does, what changes for them. No agreement on the line, no mapping.
- Write assumptions silently. Everyone alone, one per card, in the form "We believe that ...". Aim for 20 to 40 across the group.
- Cluster and remove duplicates. Read every card out loud, group near-identical ones, keep the sharpest wording.
- Place each on a 2 by 2. Importance: if this is wrong, does the idea die? Evidence: do we know this or do we think it? Ask "what is the source?" whenever someone says "we know".
- Read the top right. Important and no evidence: that quadrant is your risky list. Everything else can wait.
- Pick the one riskiest. Not three, one. If the group argues, ask which one, if wrong, makes the others irrelevant.
- Design the cheapest test that could prove it wrong in two weeks. A landing page, a paper prototype, a manual version of the service, ten interviews. It must be able to fail.
- Set the kill criterion. Before the test starts, write down the number below which you stop. Agreeing on it afterwards never works.
- Record the rest with their quadrant. Every assumption, its quadrant, who placed it and why, in the decision log. Evidence moves cards, so revisit the map after each test.
The four quadrants
| Quadrant | What it means | What to do |
|---|---|---|
| Important, no evidence | The idea depends on it, nobody has checked | Test first, with a kill criterion |
| Important, evidence | The idea depends on it, you have data | Note the source, move on |
| Not important, no evidence | Nice to know, not decisive | Park it, revisit after the first test |
| Not important, evidence | Known and harmless | Ignore it |
Worked example: the refill station
A retail chain wants a refill station for cleaning products in one store. Five of the team's assumptions:
- Customers bring their own bottles. Important: without it there is no refill. Evidence: a survey where people said they like sustainability, so none. Top right.
- Store staff can refill in under a minute. Important for queues and labour cost. Evidence: a supplier demo. Note the source.
- Hygiene rules allow it. Important: a no ends the idea. Evidence: a colleague "thinks so". Top right too, but one call to the authority settles it, so call this week instead of testing.
- Margin per refill covers the station. Important, and the finance model exists.
- The second store behaves like the first. Not important yet. No evidence. Parked.
The riskiest: customers bring bottles. The test: two weeks, one station, a hand-written sign, staff count bottles. Kill criterion: fewer than 30 refills in week one and the concept goes back to the drawing board.
Phrase assumptions so that they can be false. "Customers like sustainability" cannot fail. "At least 30 of 100 customers bring a bottle in week one" can, and that is what makes it testable.
The sponsor's favourite assumption tends to land in "we have evidence" without any. Ask for the source every time, for every card, so that it is never personal.
When the map never leads to a real test
- Testing the easy assumption instead of the risky one. Feasibility is comfortable because the team controls the answer. If the test cannot kill the idea, it is not the first test.
- Tests that cannot fail. "We will show it to customers and see what they say" produces polite nods. Set a number before you start.
- 40 assumptions and no decision. The map is not the output. The output is one test, one owner, one date, one kill criterion. If the group cannot choose, run a decision workshop.
- Mapping once and never revisiting. A map that lives as a photo on someone's phone is dead. Keep it where the team sees it, with the evidence noted; tools like IdeaHone keep assumptions as items in the same space as the concept.
Score and prioritise ideas with your team
IdeaHone scores ideas against your criteria, shows them on a matrix and keeps the reasons, so the decision is clear and traceable.
What is assumption mapping?
A workshop method in which a team writes down what must be true for a concept to work, places each assumption on a grid of importance and evidence, and tests the most important unproven one first, before building or budgeting.
What are the three types of assumptions?
Desirability (do customers want it), feasibility (can we build and run it) and viability (does it pay). Teams tend to over-test feasibility and under-test desirability.
How do you test a risky assumption cheaply?
Design the smallest experiment that could prove it wrong within two weeks: a landing page, a manual version of the service, a paper prototype or ten interviews. Set the kill criterion before you start.
