How to build an assumption map for product discovery

Most assumption maps die on a Tuesday. A product trio meets, draws a 2x2, fills it with sticky notes, agrees the leap-of-faith beliefs are terrifying, and then goes back to Jira. Six weeks later the feature is half-built, the map is a screenshot in a Slack thread nobody re-opens, and the assumption that would have killed the project (usually the desirability one) is discovered by the launch funnel instead of by a test that would have cost the team a week.

This is a working guide on how to run assumption mapping so the map actually changes what the team ships. What the framework is, why most maps get filed, the six-step build, the tests that follow, and the operational cadence that keeps the map from decaying into wall decoration. It sits inside the voice user research guide and pairs with the playbooks on continuous discovery interviews and concept testing.

What assumption mapping is

Assumption mapping is a team exercise from David Bland and Alexander Osterwalder's Testing Business Ideas (Wiley, 2019) in which every belief a product idea rests on is written down, sorted by type (desirability, viability, feasibility), and plotted on a 2x2 of importance against evidence. The goal is not to feel rigorous. The goal is to isolate the small number of leap-of-faith assumptions that would kill the idea if wrong, and to spend the next two weeks testing those specifically. Bland's canonical short write-up lives on Strategyzer's library.

The framework has four moving parts. Desirability asks whether the market wants the thing at all: will the target participant recognise the problem, prefer this solution to what they use today, and change their behaviour to adopt it. Viability asks whether the business will work: pricing, unit economics, distribution, retention. Feasibility asks whether the team can actually build and operate it at the fidelity the promise implies. A fourth category, adaptability, gets added in some later Strategyzer material and covers whether the idea can survive a changing environment.

The map itself is drawn on a 2x2. The x-axis is evidence: from "we have data" on the left to "we're guessing" on the right. The y-axis is importance: from "won't kill us if wrong" at the bottom to "kills the idea if wrong" at the top. The top-right quadrant, high importance and low evidence, is where the leap-of-faith assumptions live. That is the only quadrant the team is allowed to work on this week.

Assumption mapping sits between two better-known artifacts in the product-discovery stack. Upstream, an opportunity solution tree surfaces the customer opportunities the team could address. Assumption mapping picks the candidate solution and enumerates what would have to be true for it to land. Downstream, concept testing is one of the tests the map calls for. Skipping the map produces concept tests that measure the wrong thing.

Why most assumption maps get filed and forgotten

Three failure modes recur across teams whose maps went stale in the first month. They are structural, not motivational, and they cluster together more often than not.

The map lists opinions, not assumptions

The first failure is grammar. Teams write bullet points that read like feature descriptions ("users want a mobile app", "the pricing should be usage-based") and file them as assumptions. Feature descriptions are not testable. An assumption is written in the form "we believe [specific outcome] because [reason]" and it names a claim that could be shown to be false. "We believe that first-time users will invite a teammate within the first session because they told us in interviews that they onboard alongside a colleague" is an assumption. "Team onboarding is important" is a slogan.

The fix is a rewrite pass after the brainstorm. Every sticky is rephrased into "we believe X because Y". If the sticky can't be rewritten into that shape, the sticky is either a fact (move it left on the evidence axis with the source noted) or a feature idea (move it off the map into the solution backlog).

The team plots by feeling, not by evidence

The second failure is the axis pass. Once the assumptions are on the wall, teams often place them into quadrants based on how nervous each assumption makes them feel, not on how much evidence they actually have or how bad the failure would be. The result is a map skewed toward the founder's pet worries and blind to the assumptions everyone assumes are safe.

The fix is a facilitator with a single question at each sticky: "what data would move this leftward, and do we have any of it?" If the answer is "a research note from 2023", the note gets pulled up and re-read on the spot. Half the time the note doesn't say what the team remembers it saying, and the sticky slides right into the leap-of-faith quadrant where it belongs.

The map has no cadence behind it

The third failure is operational. A map without a weekly review is a snapshot of one afternoon's belief. New evidence arrives at the pace the team is talking to customers, and if that pace is zero, the map cannot be updated because nothing new is coming in. Teams draw a beautiful map, run one experiment, and then the interview cadence collapses under launch pressure and the map ages out silently. The same cadence problem sinks the opportunity solution tree; the fix in both cases is the same. Weekly customer input, async where possible, tightly enough scoped that the trio can review it in an hour on a Wednesday.

How to build an assumption map, step by step

Six steps. The order is opinionated. Steps one through three are what make the plotting pass in step four worth doing, and step six is what keeps the map from becoming a screenshot in a Slack thread.

01 · Frame the idea in one sentence

Before any sticky notes, the trio writes one sentence describing the idea being tested. Not a feature list, not a positioning statement, not a pitch. One sentence in the form: for [specific participant] who has [problem], we will build [solution] so that [behavioural change].

If the sentence takes more than one attempt, the idea is not yet crisp enough to be mapped. Sit with it for another twenty minutes. An assumption map for a fuzzy idea produces fuzzy assumptions and a map full of things everyone can agree with, which is the map that gets filed.

Three examples of well-framed idea sentences:

• For product managers running weekly research, we will let them share one link that captures voice, text, choice, or rating so they get five participant answers before the next standup.
• For SMB owners on our free tier, we will introduce usage-based pricing at 10x the free ceiling so ~15 percent convert without the current annual-plan sticker shock.
• For internal engineering leads, we will surface a per-service latency budget so on-call teams triage regressions before customer support tickets arrive.

Each sentence names a participant, a problem, a solution, and a target behavioural change. That framing is what the assumptions will hang off.

02 · Extract every assumption the idea depends on

The trio and any invited stakeholders brainstorm every belief the sentence rests on. Timebox this to fifteen minutes. Volume matters more than quality; the sorting pass is next.

The prompts that generate the most useful stickies:

• What would have to be true about the participant for this to work?
• What would have to be true about the current behaviour we're replacing?
• What would have to be true about the offer, the price, the channel, and the timing?
• What would have to be true about the team, the tech, the data, and the ops?
• What are we assuming that we haven't said out loud?

The fifth prompt is the one that surfaces the assumptions the team is embarrassed about. Encourage those specifically. Founders' unspoken beliefs about a segment ("SMB owners will pay for tools they use daily") are almost always in the leap-of-faith quadrant and almost never on the first sticky wave.

The internal-testing angle earns its keep here. A study link shared inside the company (engineering, support, sales, finance) captures the assumptions the trio's colleagues carry but wouldn't say in the meeting. Share the link the day before the workshop and use their responses to seed the fifth prompt.

03 · Sort assumptions into desirability, viability, feasibility

Split the wall into three vertical columns and move each sticky into one:

• Desirability. Will the target participant want this, prefer it to their current solution, and change behaviour to use it. The classic case: users said they wanted the thing in an interview but will not click the button when it exists.
• Viability. Will the business work. Pricing, willingness to pay, retention, unit economics, distribution, regulatory. This is the column most product-led teams under-populate because it feels like Finance's job. It is not.
• Feasibility. Can the team actually build and operate it. Technical risk, data availability, latency budgets, ops load, third-party dependencies.

A sticky that fits two categories usually needs to be split into two stickies. "Users will pay $29/month" is really two assumptions: users see enough value to pay something (desirability) and $29 is the correct number (viability). Splitting them lets the team test each one with the cheapest test that applies.

"I said I'd probably use it in the survey but honestly I never remember to check that kind of dashboard. If it lived inside the tool I already open every morning I'd use it. Where you're proposing to put it, I won't."

Answers like that one usually reset three stickies at once. The participant told the team the desirability assumption ("users will change tools to check the dashboard") is wrong, and the correction ("integrate into the existing morning surface") is a whole different feasibility bet. That is the map earning its keep.

04 · Plot on the importance vs. evidence matrix

Draw the 2x2. X-axis is evidence, running left ("we have data") to right ("we're guessing"). Y-axis is importance, running bottom ("won't kill the idea if wrong") to top ("kills the idea if wrong"). Move each sticky onto the grid.

Two rules for the plotting pass. First, importance is judged against the specific behavioural change in the framing sentence, not against how uncomfortable the assumption feels in general. Second, evidence has to be named. If a sticky is placed left of centre, the facilitator asks for the source; if the source is "a hallway conversation last quarter", the sticky slides back right.

The top-right quadrant is the leap-of-faith zone. Aim for three to seven stickies there. Fewer than three usually means the team is under-plotting importance to avoid the anxiety; more than seven means the idea is not yet crisp enough or the team is treating every sticky as high-importance.

05 · Design the smallest test for each leap-of-faith assumption

For every sticky in the top-right, name one test that would produce evidence to move it leftward. The right test depends on the column:

• Desirability tests. Concept briefs, fake-door click tests, unmoderated prototype reactions, customer discovery interviews that probe the current workaround. The most common desirability failure ("participant said yes in the interview, ignored the button in production") is the reason the Mom Test discipline exists.
• Viability tests. Price sensitivity meters (van Westendorp), pre-order pages with a real credit-card capture, letter-of-intent signals from named customers, competitive-pricing checks against comparable products, tier-uptake modelling from analog products in the trio's own funnel.
• Feasibility tests. Technical spikes, latency prototypes, third-party API rate-limit checks, data-availability audits, ops-load estimates. Feasibility tests are the cheapest to design and the ones product teams over-index on. Do them last unless the answer would kill everything else.

The test itself has one rule: it has to be able to fail. A "test" that only produces positive signal (an interview asking "would you like this?" with no willingness-to-pay anchor) is a validation ritual, not a test. Ask what would falsify the assumption before you design the test; if you can't answer, the test isn't ready.

For any test that involves talking to participants, probing depth matters. Shallow probing (at most one clarifier) works for demand-signal capture where you need the willingness-to-pay number and nothing else. Medium probing works for desirability-reaction tests where the first answer is polite and the second answer is where the actual reasoning lives. Expert probing works for the qualitative fit test where the participant's current workaround is under-described on the first pass and the honest comparison to the concept only emerges after several turns. The longer piece on probing depth as a per-question setting is in how AI follow-up questions work in user research.

Every test gets one owner, one deadline (inside two weeks), and one falsification criterion written into the map next to the sticky.

06 · Run the tests weekly and prune the map

The map is not a workshop artifact. It is a working artifact reviewed at a standing weekly slot, where the trio does three things: file new evidence against the running tests, move stickies leftward when the evidence lands, and prune the ones that got invalidated. A test that invalidates an assumption is not a failure; it is the map paying for itself.

The evidence pipeline is where most teams' cadence collapses under launch pressure. A live customer interview costs four calendars and an hour; a study link shared with a small cohort captures the same signal on the participant's time and folds into the standing weekly review without adding meeting load. Put the study link in the surfaces where the target participant already is: in-product feedback moments, the pricing page or docs for outbound-led SaaS, post-onboarding activation checkpoints, or the cancellation flow when the leap-of-faith assumption is about churn drivers. The pipeline is the same as the one used for continuous discovery interviews; the assumption map is what tells you which questions to ask this week.

Prune ruthlessly. A sticky that's been invalidated is no longer an assumption; it's a data point that belongs in the team's discovery log, not on the wall. The map should shrink in the top-right quadrant as the weeks go by, not grow. If it isn't shrinking, either the tests aren't running or the tests can't fail.

When an assumption map isn't the right tool

Three cases where the map adds ceremony without adding signal.

A build the team is going to do regardless. Regulatory features, platform migrations, security remediations, and partner-driven integrations are not discovery work. Drawing a map for them produces stickies nobody will test because the decision has already been made. Use a roadmap and a Gantt chart. Reserve the map for the surface where the outcome is genuinely uncertain.

A tiny UX polish inside a proven surface. Copy tweaks on a working page, a stress-test on an existing form, an accessibility pass on a shipped flow. These are experiments the team should just run. Mapping them is method-worship. A useful heuristic: if the whole assumption map would be one column and one row (all desirability, all low importance), you don't need a map. You need to ship the tweak and read the metric.

A pre-PMF pivot with no target participant yet. An assumption map presumes the team has a specific participant to test against. Before a stable participant definition exists, the map is a room full of stickies about a made-up person. The right tool at that stage is closer to jobs to be done interviews with people who switched from a workaround, or customer discovery interviews to first surface who the target participant even is. Draw the map once the participant definition holds up across five or six conversations.

FAQ

What is assumption mapping in product management?

Assumption mapping is a workshop technique in which a product team writes down every belief a new idea depends on, sorts those beliefs into desirability, viability, and feasibility categories, and plots each one on a 2x2 of importance against evidence. The goal is to isolate the "leap-of-faith" assumptions in the top-right quadrant (high importance, low evidence) and design the smallest possible tests that could falsify them. It comes from David Bland and Alexander Osterwalder's book Testing Business Ideas (Wiley, 2019) and is now standard practice in evidence-based product discovery.

How does an assumption map differ from an opportunity solution tree?

An opportunity solution tree connects a measurable outcome to customer opportunities to candidate solutions; it is the artifact the team uses to decide which solution to bet on. An assumption map picks up after that bet is chosen and enumerates the beliefs the solution depends on. The tree answers "should we build this over that?" and the map answers "what would have to be true for this to work?" Teams that use both run the tree at the outcome level (weekly, across the whole surface) and run assumption mapping once per solution the tree elevates to a candidate.

What are desirability, viability, and feasibility assumptions?

Desirability assumptions are beliefs about whether the target participant will actually want, adopt, and change behaviour for the solution. Viability assumptions are beliefs about whether the business will work: pricing, unit economics, retention, distribution. Feasibility assumptions are beliefs about whether the team can build and operate it. Bland and Osterwalder later add adaptability (whether the idea can survive a changing environment) as a fourth category. Most product teams over-test feasibility because engineering is in the room and under-test desirability, which is where most ideas actually fail.

How many assumptions should be on an assumption map?

Roughly 15 to 30 in total, with three to seven of them ending up in the leap-of-faith quadrant (top-right, high importance, low evidence). Fewer than 15 usually means the team is under-brainstorming; more than 40 usually means the sticky pass has stopped being about assumptions and started being about feature ideas. The critical count is the leap-of-faith one: a map with zero leap-of-faith stickies is a map that plotted by feeling, not by evidence, and a map with more than ten is a signal the idea itself is not yet crisp enough to test.

When should you run assumption mapping?

Run it once you have a candidate solution the team is seriously considering building and before the sprint that would build it. Too early (before the idea sentence is crisp) and the map is full of vague assumptions nobody can test. Too late (mid-build) and the tests can't influence the roadmap because the code already exists. The sweet spot is the moment a solution graduates from the opportunity solution tree into a candidate the team wants to spend two weeks investigating. Re-run the map any time the solution shape changes materially, and prune it weekly as evidence lands.

---

An assumption map is only useful if the team commits to two things: writing every belief in "we believe X because Y" form so it can be shown to be false, and running the tests that would falsify the leap-of-faith stickies before the code that assumes them is written. The workshop is one afternoon; the practice is the weekly review that follows. Talkful is built for the evidence pipeline behind that practice. A study link goes out to the target participant on their own surface, they answer in voice, text, choice, or rating, an AI interviewer probes the polite first answers into the honest second ones with per-question depth control, and a synthesis engine streams themes and quotes back so the trio can move stickies leftward at the standing weekly review. The broader voice user research guide covers how the practice sits alongside continuous discovery and the opportunity solution tree that hangs above it.