Assumption mapping

Assumption mapping helps a team decide what it needs to learn before making a larger commitment. Start with the beliefs an idea depends on, separate what is known from what is merely plausible, and identify the uncertainty that matters most to the next decision. The useful output is a small set of questions with owners and a plan for gathering evidence.

Imagine a team proposing a shared equipment-booking service. The interface looks straightforward, the presentation is convincing, and everyone can picture the finished product. But the proposal depends on several different things: people must need the service, equipment records must be reliable, and somebody must handle damaged or missing items. A polished screen answers none of those questions on its own.

What the method does

David J. Bland describes an approach that places assumptions according to their importance and supporting evidence. His account covers demand, delivery, financial and adaptability questions. The immediate attention goes to consequential beliefs with little support. This guide draws on Bland’s explanation of assumptions mapping, while using an original agenda and example.

That is a prioritization exercise, not a calculation of risk. A note’s position does not provide the probability that an idea will fail. Nor does agreement around the board establish that a belief is true. The map makes the team’s current reasoning available for challenge.

Use it after you have enough understanding of a problem to describe a possible response, but before the response becomes difficult to change. If the underlying problem is still unclear, return to discovery and problem framing.

Start with a decision, not a wall of notes

Write down the decision the exercise should inform. “Should we fund a two-week prototype?” is more workable than “Is this a good idea?” The first question has a scope, a time horizon and a commitment that evidence could change.

For the booking service, the next decision might be whether to test a reservation process with one department. It is not yet whether to replace the organization’s entire asset-management system. That distinction keeps the discussion from collecting every uncertainty the organization has ever faced.

Invite people who understand different parts of the proposed service: someone who uses equipment, someone who maintains it, a person responsible for the records, and whoever can authorize the next step. Four to seven participants is a manageable starting choice for the agenda below, not a research-backed group-size rule.

Before the meeting, assemble what already exists: relevant observations, incident records, technical constraints and previous tests. Note where the material came from and when it was collected. A statement such as “users asked for this” needs the underlying conversation and context, not just a quotation in a slide deck.

Make a shared document available alongside any physical board. People should be able to contribute without reading small handwriting, identifying colors, or interrupting a fast discussion.

A sixty-minute working session

This is a suggested agenda. Shorten the scope or arrange a second discussion if access needs or complicated evidence require more time.

First ten minutes: describe the proposal

Ask one person to explain the idea without selling it. Capture the intended users, the problem, what would change for them, and the decision being considered. Let others correct the description.

Then ask participants to write, privately, what they would need to know before supporting that decision. Starting individually gives you material to compare before the first confident speaker defines the whole discussion.

Next fifteen minutes: turn concerns into separate statements

“People won’t use it” is too broad. For the booking service, distinguish whether staff can find an available item, whether they can reserve it, and whether the collection process fits their working day. Those are different questions.

Tendayi Viki’s guidance on formulating hypotheses emphasizes statements that can be checked, specify what is meant, and do not bundle several propositions together. You do not need to perfect every sentence immediately. Refine the statements that survive prioritization.

Keep requests separate from assumptions. “Add a calendar” proposes a feature. “Staff need to see availability across the coming week before choosing an item” describes a belief that could support several designs.

Next fifteen minutes: compare consequence and evidence

For each statement, ask two separate questions: what happens to the proposal if this is wrong, and what relevant evidence do we have? Use relative placement rather than pretending that a score of four is objectively twice a score of two.

A particularly important distinction is between missing evidence and evidence against the idea. Both deserve attention, but they call for different conversations. Where something already contradicts a belief, record that contradiction rather than putting the note in a vague “uncertain” pile.

A CLOSER LOOK

Which uncertainty could change the next decision?

1. 01
   Consequential, little supportChoose a focused investigation before making a larger commitment.
2. 02
   Consequential, relevant supportCheck how far the evidence applies to this proposal and setting.
3. 03
   Less consequential for nowRecord it and revisit it if the decision or scope changes.

Evidence against a belief is not the same as no evidence.

If people disagree, capture the reasons beside the statement. One person may be thinking about occasional users while another is thinking about a specialist team. That is often a scope problem to resolve, not a vote to win.

Final twenty minutes: choose a learning task

Choose one or two questions that could change the next decision. For each, name the observation needed, a suitable way to obtain it, an owner and a review date. Also record what would make the team stop, revise the idea, or seek stronger evidence.

The GOV.UK guidance on the alpha phase provides a useful example of keeping prototypes focused on major uncertainties instead of building a whole service. That principle can apply to a workflow rehearsal or a technical check as well as a screen prototype.

Do not finish with “research this further.” Finish with a task somebody can actually arrange. If nobody can obtain the evidence within the available time, make that constraint part of the decision.

Hypothetical example: the reservation that cannot be kept

Return to the equipment-booking proposal. The team initially plans to test whether people understand a new booking screen. During the discussion, the equipment coordinator points out that the inventory is updated only after returned items have been inspected.

This changes the question. The team has been treating “an item appears as available” as equivalent to “an item can be collected.” The proposed service might make a clear promise that the current operating process cannot keep.

Instead of immediately building the screen, the team chooses a bounded rehearsal. For a set of ordinary reservation requests, the coordinator will compare the recorded availability with the item’s actual condition and location. The exercise uses appropriate existing records and does not promise equipment to anyone. The team agrees who can inspect those records and how to avoid exposing personal information.

A CLOSER LOOK

From an attractive screen to an operational question.

1. 01
   BeliefAn item shown as available can actually be collected.
2. 02
   CheckCompare availability records with condition and location for a bounded set of requests.
3. 03
   DecisionRevise the updating process or add a confirmation step if the records do not match.

This check does not establish demand or financial viability.

The review has several possible outcomes. If records and reality differ, the service may need a confirmation step or a different updating process. If they agree, that supports this narrow operational assumption for the cases examined; it does not establish that people want the service or that it will be economical.

Nothing has been “validated” in the example: it describes a proposed investigation, not its results. The point is that the most useful next task changed when somebody with operational knowledge joined the conversation.

Match the evidence to the question

A friendly interview, a working prototype and a reliable cost record answer different questions. Before choosing a method, write down what the resulting evidence would actually allow you to say.

An interview can help explain how someone currently handles a task and what creates difficulty. It cannot, by itself, establish how frequently an entire market will buy something. A usability session can reveal trouble completing a task with a prototype; it does not demonstrate that the service will be adopted under everyday pressures.

The GOV.UK research-planning guide connects research questions with participant groups and suitable activities. Follow that logic rather than choosing an experiment because it is convenient. Include people whose circumstances could expose a weakness, not only the colleagues most enthusiastic about the idea.

For the booking service, checking records addresses operational reliability. Observing a realistic collection task addresses another uncertainty. Estimating support costs needs a different evidence trail again. Do not combine all three into a single positive label.

Keep a short record of the result, its scope and the next decision. “Three experienced coordinators could complete the rehearsal” is a different statement from “all employees can use the service.” Even when early findings are encouraging, the remaining distance between a rehearsal and ordinary use should stay visible.

Where maps become misleading

The exercise is least useful when it becomes a ceremony around a decision already made. If the sponsor will approve the idea regardless of the evidence, be honest about which details are still open to change.

Watch for a few other failure modes:

• Everything is critical. Return to the next commitment and ask which uncertainty could change it.
• Confidence stands in for evidence. Ask what was observed, by whom, and in what circumstances.
• The board fills with solutions. Separate suggested features from the beliefs they depend on.
• A small test settles a broad claim. State the limits of the participants, setting and task.
• Nobody revisits the map. Schedule a review alongside the work the evidence will influence.

For decisions involving substantial potential harm, a lightweight workshop cannot substitute for appropriate specialist assessment. Do not expose people to a risky live service simply to make a test feel realistic.

Leave with a useful next step

Save the original statements, the evidence considered, any unresolved disagreement, and the learning tasks people accepted. Review the map when new findings arrive or the proposal changes.

If the exercise reveals uncertainty about the group’s working conditions rather than the idea itself, continue with assessing change readiness. If you need to examine several ways a planned pilot could break down, a premortem offers a complementary conversation. Both should lead back to a decision, not another permanent wall of notes.