A team can agree on a product idea while disagreeing about why it will work. One person assumes customers already feel the problem. Another assumes buyers will pay to solve it. A third assumes the necessary data is easy to obtain. Until those assumptions are visible, a polished roadmap can conceal three different bets.
An assumption mapping workshop helps you choose which uncertainty to investigate first. Find a claim that could change your investment decision, then design a test that helps you decide whether to proceed.
Separate importance from evidence
On an assumption map, importance means how much the idea depends on a claim being true. Evidence means what you actually know about that claim. These are different judgments. A strongly held opinion is not strong evidence, and an easy-to-test detail is not automatically important.
Strategyzer's assumption mapping approach plots importance against evidence to identify critical, poorly supported hypotheses. Use that distinction to structure a discussion, not to assign scientific precision to sticky-note positions.
Draw importance from low to high vertically and supporting evidence from weak to strong horizontally. Label both ends. Your first candidates usually sit in the high-importance, weak-evidence area. A different axis orientation is fine, provided everyone reads it the same way.
Start with a decision, not a blank brainstorming prompt
Write the decision at the top of the board: “Should we build a customer-facing reporting portal this quarter?” Add what is at stake and when the decision must be made. Otherwise people may list interesting uncertainties that do not affect the decision in front of them.
If the team has already chosen a feature without clarifying the customer need, a worked opportunity solution tree shows how to separate the desired outcome, unmet needs, possible solutions and tests.
Bring the people who understand customer behavior, delivery constraints, and commercial consequences. Give them a short description of the idea and the evidence already available. If you have a business model canvas, use its blocks to prompt questions about customers, channels, costs, and partners. The canvas is an input, not evidence that the model works.
Ask participants to write independently before discussing. Each note should contain one claim and, underneath it, the reason someone currently believes it. This makes a support ticket, an interview quotation, and an executive's intuition visibly different inputs.
Rewrite vague assumptions into testable claims
“Customers want better reports” is too broad to test. Better reports could mean faster loading, clearer charts, fewer emails, or exportable data. A more useful claim is: “Account managers at small agencies need to send clients a project-status summary every week, and preparing that summary is a recurring source of manual work.”
Strategyzer describes useful hypotheses as testable, precise, and discrete. In practice, name the people, the situation, and the behavior you expect. Split claims that combine demand, willingness to pay, and delivery feasibility. Evidence for one does not establish the others.
Use negative questions as well: what would make this claim false? If the only acceptable outcome is agreement, you are writing a sales argument rather than a hypothesis.
Example: should an agency build a client portal?
Imagine a small agency considering a reporting portal for its clients. In this hypothetical example, the team has a few client conversations, samples of current reports, and no live portal.
| Assumption | Importance | Evidence available | Next question |
|---|---|---|---|
| Clients struggle to find the latest project status | High | Several support emails, but no observation of clients' workflow | What do clients do when they need an update? |
| Clients will sign in to a separate portal regularly | High | Internal preference only | Will clients use a small pilot without reminders? |
| Existing project data can produce reliable summaries | High | A sample export with missing fields | Which fields require manual repair? |
| A custom dashboard theme is necessary | Low for a pilot | One requested color change | Does the theme prevent clients completing the task? |
| Account managers will stop sending duplicate reports | High | No operating agreement | What obligations still require an email report? |
The portal-login assumption is an obvious test candidate, but data reliability also matters: enthusiastic clients will not rescue inaccurate reports. The team chooses a small pilot that can examine actual use while manually checking the data. It postpones the theme discussion because that decision can wait without committing the team to a costly path.
Discuss evidence quality without false precision
For each note, ask where the evidence came from, which users it represents, and what alternative explanation fits it. “A customer asked for a dashboard” might mean they want fewer status meetings, not another place to log in. Five comments from one account are not five independent accounts.
Keep evidence links or short excerpts next to the relevant claim. The customer feedback synthesis guide can help organize repeated observations without treating repetition as proof of market demand.
Do not resolve every disagreement by averaging votes. If support sees a recurring problem and sales has never heard it, identify whether they serve different customer groups. Place two notes on the map if the claims refer to different segments. The disagreement may be the most useful thing the workshop reveals.
Choose a test that can change the decision
Turn the selected assumption into a short test card: claim, participants or data, activity, observation, decision rule, and owner. Choose the rule before seeing the result. This does not make a small study conclusive; it prevents the team from changing the definition of success to suit a preferred answer.
For the agency's portal pilot, invite clients through their usual contact to a small portal that requires sign-in and contains a reviewed weekly status page. Observe whether they return without repeated reminders and whether they still request the same information by email. Ask about their reasons afterward. A publicly accessible page could test the information's usefulness, but it would leave willingness to sign in unresolved. Do not count opening a link once as adoption, and do not interpret silence as satisfaction.
Run a separate technical check on data completeness. A manually prepared pilot can teach you about usefulness, but it cannot show that automated reporting will be reliable or inexpensive. Name that remaining uncertainty rather than smuggling it into a positive result.
Use the result to change the plan
Keep the original claim and add the observation below it. Then decide whether to proceed, revise the idea, gather different evidence, or stop. “Inconclusive” is a valid result when participation was too limited or the test did not recreate the relevant situation.
For example, if clients prefer a concise email and rarely revisit a portal, the agency might test a better email summary instead of adding portal features. If clients use the portal but staff spend too long correcting data, the next investment may belong in data quality. These are different decisions, even though both began with the same product idea.
Open Boardmix and draw the matrix with importance increasing upward and evidence increasing to the right. For the agency example, place “Clients return without reminders” near the high-importance, weak-evidence corner. Keep “Existing data produces reliable summaries” nearby as a separate claim. Beside the matrix, add a pilot card with the activity, observation, decision rule, and owner; record results below it rather than moving a note to “strong evidence” after a single positive comment. For a broader session, use the product discovery workshop guide.
