When should we run an assumption mapping workshop?

Run it at the start of any initiative where the team is about to commit 4+ weeks of engineering effort. It is especially useful after a [product vision workshop](/templates/product-vision-workshop-template) when the team has aligned on direction but has not yet validated the underlying assumptions. It is also valuable when the team inherits a project from another team and needs to pressure-test the original hypotheses.

How many assumptions should we surface?

Aim for 15-25 total across the four categories. Fewer than 10 means the team is not thinking critically enough. More than 30 means the scope is too broad for one session. If you hit 30+, narrow the initiative scope or split into two sessions for different aspects of the initiative.

What if the team disagrees about where to plot an assumption?

Disagreement about placement is the point. If one person thinks an assumption has strong evidence and another thinks it is a guess, that disagreement reveals an information gap. Ask the person who rated it "high evidence" to share their data. If they cannot, the assumption moves left on the evidence axis. Use the [Product Discovery Handbook](/discovery-guide) for research methods that can fill evidence gaps.

What types of experiments work for testing assumptions?

Match the experiment type to the assumption category. Desirability assumptions: fake door tests, landing pages, user interviews, surveys. Viability assumptions: pricing page tests, willingness-to-pay interviews, financial modeling. Feasibility assumptions: technical spikes, proof-of-concept builds. Usability assumptions: prototype tests, first-click tests, unmoderated usability sessions. The fastest experiments take 1-2 days (fake door, data analysis). The slowest take 2-3 weeks (interview series, prototype builds).

What do we do if an experiment invalidates a riskiest assumption?

This is the best possible outcome. You saved weeks or months of building the wrong thing. Three options: (1) Pivot the approach to avoid the invalidated assumption. (2) Reduce scope to a version that does not depend on the assumption. (3) Kill the initiative and redirect resources. The PM should present the experiment results to stakeholders with a recommendation. Use the [RICE Calculator](/tools/rice-calculator) to re-score the initiative given the new information. ---

Assumption Mapping Workshop Template

What This Template Is For

Every product decision rests on assumptions. "Users will pay for this feature." "Our API can handle 10x current load." "Customers prefer self-serve onboarding over guided setup." Most teams never articulate these assumptions explicitly. They build for months, launch, and then discover that a foundational assumption was wrong.

An assumption mapping workshop forces the team to surface, categorize, and prioritize the assumptions behind a product decision. The output is a 2x2 matrix that plots each assumption by how critical it is (if wrong, does the project fail?) and how much evidence supports it (do we know this is true, or are we guessing?). The riskiest assumptions (high impact, low evidence) become candidates for testing before the team commits to building.

This template is designed for a 90-minute session. Use it at the start of any new initiative, after a product vision workshop, or whenever the team is about to commit significant resources to a bet. The Product Discovery Handbook covers the broader discovery process, and the Riskiest Assumption Test (RAT) glossary entry explains the underlying concept. For teams that want to validate market-level assumptions, the TAM Calculator can test sizing assumptions with data.

How to Use This Template

Frame the decision. Before the workshop, write a clear statement of the product decision, initiative, or bet the team is evaluating. Assumptions are meaningless without context.
Invite 4-6 people. Include PM, design, engineering, and at least one person close to customers. Keep the group small enough for real discussion.
Block 90 minutes. The exercises are designed to fit tightly. If you have less time, cut Exercise 3 (experiment design) and do it as a follow-up.
Follow the three exercises in order. Surfacing assumptions (Exercise 1) must happen before plotting them on the matrix (Exercise 2). Experiment design (Exercise 3) only makes sense after you know which assumptions are riskiest.
Be honest about what you do not know. The value of this exercise is admitting uncertainty, not performing confidence.

The Template

Workshop Setup

Field	Details
Initiative / Bet	[The product decision being evaluated]
Decision Statement	[One sentence: "We believe that if we build X, then Y will happen, resulting in Z"]
Date	[Date]
Facilitator	[Name]
Participants	[Names and roles]

Agenda

Time	Activity	Output
0:00 - 0:05	Opening: review the decision statement and ground rules	Shared context
0:05 - 0:30	Exercise 1: Assumption Brainstorm	Full list of assumptions across 4 categories
0:30 - 0:55	Exercise 2: Plot the 2x2 Matrix	Assumptions mapped by impact and evidence
0:55 - 1:05	Break
1:05 - 1:25	Exercise 3: Design Experiments	Experiment cards for top 2-3 riskiest assumptions
1:25 - 1:30	Wrap-up: owners and deadlines	Action items

Exercise 1: Assumption Brainstorm (25 min)

Goal: Surface every assumption the team is making about this initiative. Organize by category.

☐ Give each participant 5 minutes of silent writing. Each assumption goes on a separate sticky note or card
☐ Share and cluster into the four categories below
☐ Do not evaluate or debate assumptions yet. The goal is volume and honesty
☐ Aim for 15-25 assumptions total

Category: Desirability (Do users want this?)

☐ [Assumption: e.g., "Users will switch from their current tool to ours"]
☐ [Assumption]
☐ [Assumption]
☐ [Assumption]

Category: Viability (Does the business model work?)

☐ [Assumption: e.g., "Users will pay $29/month for this feature"]
☐ [Assumption]
☐ [Assumption]

Category: Feasibility (Can we build this?)

☐ [Assumption: e.g., "Our API can handle 50K concurrent connections"]
☐ [Assumption]
☐ [Assumption]

Category: Usability (Can users figure it out?)

☐ [Assumption: e.g., "Users will complete onboarding without live support"]
☐ [Assumption]
☐ [Assumption]

Exercise 2: Plot the 2x2 Matrix (25 min)

Goal: Map each assumption on the impact-evidence matrix. The top-right quadrant (high impact, low evidence) contains your riskiest assumptions.

☐ Draw a 2x2 matrix on a whiteboard or digital board
☐ X-axis: Evidence (left = "We are guessing" / right = "We have data")
☐ Y-axis: Impact (bottom = "If wrong, we adjust" / top = "If wrong, the project fails")
☐ Place each assumption from Exercise 1 on the matrix. Discuss placement as a group
☐ Circle the top 2-3 assumptions in the "Leap of Faith" quadrant

                    HIGH IMPACT
                         |
     LEAP OF FAITH       |    VALIDATED
     (Test these first)   |    (Keep monitoring)
                         |
  LOW EVIDENCE --------- + --------- HIGH EVIDENCE
                         |
     NOT WORTH TESTING   |    KNOWN AND LOW RISK
     (Accept the risk)   |    (Move on)
                         |
                    LOW IMPACT

Assumption Placement:

Assumption	Impact (1-5)	Evidence (1-5)	Quadrant
[Assumption 1]	Leap of Faith / Validated / Not Worth Testing / Known
[Assumption 2]
[Assumption 3]
[Assumption 4]
[Assumption 5]
[Assumption 6]

Riskiest Assumptions (Leap of Faith quadrant):

[Assumption]
[Assumption]
[Assumption]

Exercise 3: Design Experiments (20 min)

Goal: For each riskiest assumption, design a quick experiment to test it before committing to build.

☐ For each riskiest assumption, fill out an experiment card
☐ Experiments should be completable in 1-2 weeks, not 1-2 months
☐ Define a clear success metric and a threshold for "validated" vs "invalidated"

Experiment Card 1:

Field	Details
Assumption	[The riskiest assumption]
Experiment type	[Fake door test / Landing page / Concierge MVP / User interview / Prototype test / Data analysis]
What we will do	[Specific steps]
Success metric	[What we measure]
Validation threshold	[e.g., "At least 15% of visitors click the CTA"]
Timeline	[Days or weeks]
Owner	[Name]

Experiment Card 2:

Field	Details
Assumption	[Second riskiest assumption]
Experiment type	[Type]
What we will do	[Steps]
Success metric	[Metric]
Validation threshold	[Threshold]
Timeline	[Timeline]
Owner	[Name]

Experiment Card 3:

Field	Details
Assumption	[Third riskiest assumption]
Experiment type	[Type]
What we will do	[Steps]
Success metric	[Metric]
Validation threshold	[Threshold]
Timeline	[Timeline]
Owner	[Name]

Action Items

Action	Owner	Deadline
Run experiment for riskiest assumption	[Name]	[Date]
Run experiment for second riskiest assumption	[Name]	[Date]
Share assumption map with stakeholders	[Name]	[Date]
Schedule follow-up to review experiment results	[Name]	[Date]

Filled Example: PayFlow Instant Payments Launch

Workshop Setup

Field	Details
Initiative	Launch instant peer-to-peer payments for PayFlow mobile app
Decision Statement	We believe that if we add instant P2P payments, then users will increase weekly active usage by 30% and transaction volume by 50%, resulting in $2M additional annual revenue from interchange fees.
Facilitator	Mei Chen (Senior PM)
Participants	Mei (PM), Dave (Eng Lead), Kira (Design), Sam (Compliance), Leah (Data Analyst)

Assumptions (Selected)

Assumption	Impact (1-5)	Evidence (1-5)	Quadrant
Users will use P2P payments weekly (not just once)	5	2	Leap of Faith
We can process payments in under 5 seconds	4	3	Leap of Faith
Users trust us enough to link their bank account	5	1	Leap of Faith
Regulatory approval will take less than 3 months	4	4	Validated
Users prefer our P2P over Venmo/Zelle	3	1	Not Worth Testing
The interchange fee model covers infrastructure costs	4	4	Validated

Riskiest Assumptions and Experiments

Experiment 1: Trust and Bank Linking

Field	Details
Assumption	Users trust PayFlow enough to link their bank account
Experiment	Fake door test: add a "Link Bank Account" CTA to the existing app. Measure click-through and completion rate
Success metric	Click-through rate on the CTA
Threshold	At least 8% of monthly active users click. At least 40% of clickers complete the mock flow
Timeline	1 week (feature flag, no actual bank integration)
Owner	Kira (Design) + Dave (Eng)

Experiment 2: Weekly Usage Frequency

Field	Details
Assumption	Users will use P2P payments weekly, not just once
Experiment	10 user interviews with target users who currently use Venmo/Zelle. Ask about frequency, triggers, and switching willingness
Success metric	Proportion who report weekly P2P usage and would try a new provider
Threshold	At least 6 of 10 users report weekly usage and express willingness
Timeline	2 weeks
Owner	Mei (PM)

Key Takeaways

Every product initiative rests on assumptions. Making them explicit is the first step to managing risk
The 2x2 matrix (impact vs evidence) identifies which assumptions are worth testing and which are safe to accept
Test the riskiest assumptions (high impact, low evidence) before committing to build
Experiments should take 1-2 weeks, not months. If your experiment takes a month, you are building, not testing
An invalidated assumption is not a failure. It is the discovery process working as designed

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use

Assumption Mapping Workshop Template