Founders: Turn Assumption Mapping Workshops Into Decision Journals

Assumption mapping is a short-term exercise that surfaces your riskiest, testable beliefs so you can run the right experiments first. Any product manager or founder can run one in 30 to 90 minutes with a whiteboard and the right people in the room. Schedule the session now, before the next roadmap commitment gets made on a hunch.

TL;DR:

• Assumption mapping prioritizes high-importance, low-evidence beliefs to focus testing efforts on real risks and avoid wasted resources.
• The process should be capped at roughly 40 assumptions, with testing aligned to assumption type, such as interviews for desirability or prototypes for feasibility.
• High-importance, low-evidence assumptions must have clear tests designed within a two-week window, with pre-defined metrics and success criteria.
• Keeping a decision journal that records confidence levels, hypotheses, and results helps teams improve calibration and learning from failed or successful tests.
• Common pitfalls include overlong lists, testing unriskiest assumptions first, and loosely defined success metrics, which can be fixed with procedural discipline.

What Is Assumption Mapping?

Assumption mapping is a team exercise where you make your desirability, feasibility, and viability hypotheses explicit, then rank them by how important they are and how much evidence backs them up. The method traces back to Lean UX and Design Sprint practice, where teams needed a fast way to separate “we know this” from “we’re guessing.” Strategyzer frames it as a workshop where hidden assumptions get written down and prioritized instead of debated in circles.

Teams generally pick one of two framings:

• List-by-type: Sort assumptions into desirability, feasibility, viability, and sometimes adaptability, then discuss each bucket separately.
• Importance × Evidence 2x2: Plot every assumption on a grid where one axis measures how much the idea depends on it and the other measures how much proof you already have.

Use list-by-type when the team is new to the exercise and needs structure. Use the 2x2 once the group is comfortable debating placement, since that visual forces the harder conversation about what you actually don’t know.

Why Assumption Mapping Matters

Most failed launches don’t fail because the build was bad. They fail because a belief nobody tested turned out to be wrong, and the team only found out after shipping. That’s the trap Annie Duke calls resulting: judging a decision by its outcome instead of the quality of reasoning behind it, which teaches you the wrong lesson every time a lucky guess pays off.

Assumption mapping exists to catch this before money and months get spent. Foundational work on assumptional analysis by Mason and Mitroff argued that hidden, unexamined beliefs are what trigger organizational crises, not the beliefs teams actually debate out loud. Running the exercise regularly turns it into more than a one-off planning tool. Strategyzer notes it works as a governance ritual too, building shared situational awareness across a team instead of letting each function optimize in isolation.

What you walk away with:

• A ranked list of assumptions, not a vague sense of risk.
• Fewer wasted builds, because experiments target the unknowns that actually threaten the plan.
• A shared reference the whole team agreed to, not one person’s opinion.

What Are the Types of Assumptions You Should Map?

Three categories cover most of what threatens a product bet. A fourth, adaptability, matters once you’re operating in a market that shifts fast enough to break your plan on its own.

1. Desirability asks whether anyone actually wants this. Example: “We believe freelance designers will pay for automated client invoicing.” Example: “We believe users will return weekly without a push notification.”
2. Feasibility asks whether you can build and deliver it. Example: “We believe our team can process a large volume of image uploads per hour on current infrastructure.” Example: “We believe our support team can handle onboarding without a hire.”
3. Viability asks whether it makes business sense. Example: “We believe customers will pay a premium price each month rather than a lower price.” Example: “We believe this feature reduces churn enough to justify its build cost.”
4. Adaptability asks whether the plan survives a shifting market. Example: “We believe our pricing model still works if a competitor undercuts us by 30%.”

Turn each belief into a short “We believe that…” statement rather than a paragraph of hedges. Strategyzer’s guidance is blunt about this: a concise hypothesis format gets you testing faster than endlessly wordsmithing the statement.

Pro Tip: Color-code sticky notes by type, yellow for desirability, blue for feasibility, green for viability, before the session starts. It saves 10 minutes of sorting arguments and lets people scan the board by category at a glance.

How Do You Run an Assumption-Mapping Workshop?

Preparation checklist: Define the scope in one sentence (a feature, a pricing change, a new market), invite five to eight people who touch the decision from different angles (design, engineering, sales, support), and bring a whiteboard or Miro board with a 2x2 already drawn: Importance on one axis, Evidence on the other.

Run the session in three steps.

1. Identify. Give everyone five minutes of silent brainstorming to write one assumption per sticky note, phrased as “We believe…” Silent generation first avoids groupthink, since the loudest voice in the room otherwise sets the agenda before quieter people finish thinking.
2. Map and prioritize. One at a time, have each person place their notes on the grid and briefly justify the placement. Expect disagreement here. Connected Places Catapult recommends running this as a group exercise specifically because the debate over placement surfaces disagreements that would otherwise stay hidden until launch. Sessions typically run 30 to 90 minutes depending on scope.
3. Design tests for the top-right quadrant — a crucial step described in detail in How to Validate a Startup Idea Before You Build Anything — to ensure your assumptions get the right early validation. Anything high-importance and low-evidence gets a test and an owner before the meeting ends. Google’s Design Sprint Kit calls this the important-but-unknown quadrant and treats it as the entire point of the exercise: the map itself matters less than the conversation that produces it.

Watch for one recurring failure: teams drift toward testing what’s easy or already well-evidenced instead of what’s actually risky. A good facilitator prompt is simple: “What would have to be true for this to fail badly, and do we actually know that yet?”

Templates and Worked Examples for Assumption Mapping

A usable 2x2 template needs two labeled axes: Importance (how much the plan depends on this being true) running vertically, and Evidence (how much proof you already have) running horizontally. The top-left quadrant, important and unproven, gets tested first. Everything else waits.

Pair the map with a short experiment card for each high-priority assumption:

• Hypothesis: the “We believe…” statement
• Metric: the single number that proves or disproves it
• Owner: one name, not a team
• Duration: a fixed window, typically one to two weeks
• Stop criteria: the result that kills the idea

Matching test method to assumption type isn’t optional. Maze’s guidance on assumption maps is specific: interviews for desirability, smoke tests or prototypes for feasibility, pricing experiments for viability, and desk research for market-level adaptability questions.

Turning Assumption Maps Into Bets You Can Learn From

A map tells you what to test. It doesn’t tell you how confident you actually were once the result comes in, and that gap is where most teams lose the learning value of the exercise entirely.

Treat each high-priority assumption from the map as a bet, the way Betlog structures decisions: write down a confidence percentage before running the test, not a vague “I think so.” Pre-commit the metric and the exact result that kills the idea, before you see any data that might bias the call.

• Record confidence as a probability, not a feeling.
• Set the kill/continue threshold before the test runs, not after.
• Hold a short post-mortem that separates what you got right from what you got lucky on.

A recorded decision journal practice, capturing confidence, acceptance criteria, and expected metrics before the test runs, improves learning quality and cuts down on the motivated reasoning that creeps in once you already know how things turned out.

Calibration means your confidence numbers should roughly match your actual hit rate over many bets, not run consistently low.*

What Facilitators Get Wrong About Assumption Mapping

The three mistakes I see most often: lists that balloon past 40 sticky notes with no cutoff, teams that gravitate toward testing whatever’s cheapest instead of what’s riskiest, and success metrics defined so loosely that any result can be spun as a win. The fix for each is procedural, not motivational: cap the identify phase at a fixed number of notes per person, force the group to justify anything placed outside the important-but-unknown quadrant before testing it, and write the kill criteria down before the test starts, not after you see the number.

One team I’ve seen described anonymously spent six weeks building a feature nobody asked for because their “desirability” assumption never made it onto a board. A 45 minute mapping session the week before would have surfaced it as the highest-risk unknown in the room.

— Cesar

Put Your Assumption Map Into a Decision Record

A mapping session gives you a ranked list of risky beliefs and a plan to test them. What most teams lose within a month is the record of what they actually believed going in, at what confidence, and what result was supposed to change their mind. Some decision journal tools capture each assumption as a bet, with a hypothesis, a confidence percentage, the trade-offs you accepted, and the metric that decides the outcome, before you run the test.

When the experiment closes, an honest verdict—won, killed, or inconclusive—and a post-mortem that separates skill from luck can help prevent teams from quietly crediting wins to genius and losses to bad timing. Over enough bets, that record shows whether your 70%-confidence calls are actually landing 70% of the time. Take the assumptions off your workshop wall and start a free trial to turn this session’s map into your team’s first tracked bet.

Sources

• How assumptions mapping can focus your teams on running experiments that matter
• Assumption maps in product development: How to identify, map, and test assumptions
• Assumptions Mapping - Design Sprint Kit (Google)

FAQ

What Is Assumption Mapping?

Assumption mapping is a team exercise that makes your desirability, feasibility, and viability beliefs explicit, then ranks them by importance and available evidence so you know which ones to test first.

What Happens During an Assumption Mapping Exercise?

A facilitator leads the team through generating assumptions individually, placing them on an Importance × Evidence grid as a group, and designing tests for anything that’s high-importance and low-evidence, usually in a session lasting 30 to 90 minutes.

What Are the Three Main Types of Assumptions?

The three core types are desirability (whether people want it), feasibility (whether you can build and deliver it), and viability (whether it makes business sense); some teams add adaptability for how the plan holds up against market shifts.

What Are Examples of Assumptions Worth Mapping?

Examples include “We believe customers will pay $49 a month for this feature” (viability), “We believe our team can process 10,000 uploads per hour” (feasibility), and “We believe freelancers will return weekly without a reminder” (desirability).

How Long Should an Assumption Mapping Session Take?

Most sessions run 30 to 90 minutes depending on the scope of the decision, with shorter 10 to 30 minute versions used for narrow, low-stakes questions.