Assumption mapping: find the beliefs that can kill your product before you build it

You’ve got a promising product idea, a roadmap that makes sense, and a team ready to build. But here’s the uncomfortable truth: your entire plan is built on a stack of assumptions you haven’t validated. Assumption mapping is the discipline of making those hidden beliefs visible, then systematically testing the ones that could sink your product before you’ve written a line of code.

Most product failures don’t happen because teams built the wrong thing poorly. They happen because teams built the wrong thing well—executing flawlessly on an idea that was fundamentally flawed from the start. Assumption mapping helps you find those flaws while they’re still cheap to fix.

What counts as an assumption in product development

An assumption is anything you believe to be true but haven’t yet proven with evidence. In product work, assumptions hide everywhere:

• Desirability assumptions: Users want this. They’ll pay for it. They’ll switch from their current solution.
• Viability assumptions: We can make money doing this. The unit economics work. We can acquire customers profitably.
• Feasibility assumptions: We can build this with our current team and technology. We can build it in the timeframe we’ve committed to.
• Usability assumptions: Users will understand how to use this. They’ll complete the key workflows without help.

Teresa Torres, author of Continuous Discovery Habits, calls these “opportunity assumptions”—the beliefs that must be true for an opportunity to be worth pursuing. The problem is that product teams often treat these beliefs as facts, skipping straight to solution design.

Consider a real example: Quibi raised $1.75 billion betting that people wanted premium, short-form video content designed for mobile viewing during commutes and waiting rooms. Every assumption in that thesis—that people wanted premium short content, that they’d pay $5-8/month for it, that mobile-first viewing was underserved—turned out to be wrong or significantly overstated. Better assumption mapping might not have saved Quibi, but it would have surfaced these risks before billions were spent.

The two axes: importance versus evidence

Not all assumptions deserve the same attention. The core of assumption mapping is plotting your beliefs on two dimensions:

Importance (Y-axis): How critical is this assumption to your product’s success? If this assumption is wrong, does it slightly reduce value, or does it completely invalidate your entire approach? High-importance assumptions are “load-bearing”—your product collapses without them.

Evidence (X-axis): How confident are you that this assumption is true, based on actual data? A belief backed by user research, market data, or successful experiments sits on the high-evidence end. A gut feeling or untested hypothesis sits on the low-evidence end.

This creates four quadrants:

1. High importance, low evidence (top-left): These are your “leap of faith” assumptions—the critical beliefs you’re betting on without proof. Test these first.
2. High importance, high evidence (top-right): These are validated fundamentals. Monitor them but don’t over-invest in re-testing.
3. Low importance, low evidence (bottom-left): These are distractions. Don’t waste time validating assumptions that don’t matter much either way.
4. Low importance, high evidence (bottom-right): These are nice-to-knows. You’ve got the data, but it doesn’t move the needle on your core bet.

The magic happens in the top-left quadrant. These are the assumptions that could kill your product, and you have no evidence they’re true. This is where your discovery efforts should focus.

How to run an assumption mapping session

A good assumption mapping session takes 60-90 minutes and involves your core product trio (PM, designer, tech lead) plus any key stakeholders. Here’s a step-by-step process:

Step 1: Frame the opportunity or solution (5 minutes)

Start by clearly stating what you’re evaluating. This could be a new product idea, a feature, or even a strategic bet. Write it on a whiteboard or shared document where everyone can see it. Be specific: “We believe that offering a freemium tier will increase our paid conversion rate by 20%” is better than “freemium might help growth.”

Step 2: Generate assumptions individually (10 minutes)

Give everyone sticky notes (physical or digital via Miro/FigJam) and ask them to write down every assumption embedded in this opportunity. One assumption per sticky. Push the team to surface assumptions across all four categories: desirability, viability, feasibility, and usability.

Prompt questions that help:

• What must be true about our users for this to work?
• What must be true about the market?
• What are we assuming about our ability to build this?
• What are we assuming about our business model?
• What are we assuming users will do that they’ve never done before?

Step 3: Share and cluster (15 minutes)

Have each person share their assumptions. Group similar ones together. You’ll likely end up with 15-30 distinct assumptions. Don’t debate whether assumptions are valid at this stage—just capture them.

Step 4: Draw your 2×2 and place assumptions (20 minutes)

Create a large 2×2 grid with “Importance” on the Y-axis and “Evidence” on the X-axis. As a group, discuss and place each assumption on the grid. This is where healthy debate happens—team members often disagree about how much evidence they actually have or how critical an assumption really is.

A tip from Marty Cagan’s team at SVPG: ask “If we learned tomorrow that this assumption was wrong, would we still pursue this opportunity?” If the answer is “absolutely not,” it’s a high-importance assumption.

Step 5: Prioritize your testing backlog (15 minutes)

Focus on the top-left quadrant. Rank these assumptions by asking: “Which assumption, if proven wrong, would most change our direction?” These become your testing priorities. Aim to identify 2-4 assumptions to test in your next discovery cycle.

Connecting assumption maps to experiment design

Assumption mapping is only half the job. The real value comes from designing experiments that efficiently test your riskiest assumptions. [INTERNAL_LINK: experiment design]

For each high-priority assumption, ask:

• What’s the cheapest way to test this? Can you validate it with a conversation, a prototype, a landing page, or a concierge MVP?
• What would we need to see to believe this assumption is true? Define your success criteria before you run the test.
• What would convince us to abandon this direction? Equally important—define what failure looks like.

Airbnb famously tested their core assumption—”strangers will pay to stay in other strangers’ homes”—by photographing apartments and posting them on Craigslist before building any platform. The experiment was crude, but it directly tested their highest-risk assumption with minimal investment.

Match your experiment fidelity to your assumption’s risk level. A high-stakes assumption about user willingness to pay might warrant a fake-door test or a Wizard-of-Oz prototype. A lower-stakes assumption about navigation preferences might be testable with a quick usability study.

How to prioritize which assumptions to test first

When you’ve got multiple high-importance, low-evidence assumptions (you usually will), use these criteria to sequence your testing:

1. Dependency: Some assumptions depend on others. If assumption A is “users have this problem” and assumption B is “users will pay to solve this problem,” you need to validate A before B matters. Test upstream assumptions first.
2. Speed to learn: If two assumptions are equally risky, test the one you can validate faster. A user interview takes days; a market analysis might take weeks.
3. Cost of being wrong: Some wrong assumptions lead to wasted weeks; others lead to wasted years. Prioritize assumptions where the cost of being wrong is highest.
4. Reversibility: If you can easily course-correct after launch, the assumption is less urgent to test upfront. If a wrong bet locks you into an architecture or market position, test before committing.

Lenny Rachitsky’s research on product development speed suggests that the best teams run 2-3 assumption tests per week during discovery phases. This isn’t about being sloppy—it’s about designing lean experiments that generate learning quickly.

Making assumption mapping a habit

The teams that get the most value from assumption mapping don’t treat it as a one-time workshop. They build it into their regular rhythm:

• Before roadmap planning: Map assumptions behind any major initiative before committing to it
• At kickoff: Identify the riskiest assumptions before starting design or development work
• During retrospectives: Review which assumptions proved wrong and what that cost you
• When pivoting: Use assumption mapping to evaluate new directions with the same rigor

Intercom’s product team reportedly runs assumption mapping at the start of every major project, treating it as essential as writing a product brief. The discipline has helped them avoid building features that looked promising on paper but rested on shaky foundations.

Your next step: pick one idea currently on your roadmap and spend 30 minutes listing every assumption it rests on. Plot them on the importance-evidence grid. You’ll likely find at least one “leap of faith” assumption you’ve been treating as fact—and that’s exactly where your next discovery sprint should focus.

Frequently asked questions