PivotBuddy

Unlock This Playbook

Create a free account to access execution playbooks

9 Comprehensive Playbooks
Access to Free-Tier AI Tools
Save Progress & Bookmarks
Create Free Account
Chapter 2 of 9

Chapter 2: Unpacking Assumptions - The Topography of Risk

Desirability, Viability, Feasibility: User Story & Impact Mapping.

Playbook Chapters
What You'll Learn Learn the three types of product risk, how to run Assumption Mapping workshops, and how to keep your MVP focused on results.

Every Business is Built on Assumptions

Behind every successful product is a set of validated assumptions. Behind every failed startup is a set of assumptions that were never tested—or tested too late. This chapter gives you a framework to find, sort, and rank every assumption in your business.

The Core Insight

Your business plan isn't a set of facts—it's a collection of beliefs. The faster you can distinguish between what you know and what you assume, the faster you'll learn what actually works.

The Triad of Product Risk

Product risks fall into three categories. A successful product must pass all three tests—miss any one, and your startup fails:

Desirability

"Do they want this?"

This is where most startups fail. Key questions:

  • Is the problem real and frequent?
  • Is it painful enough to seek a solution?
  • Do they want YOUR solution specifically?

Viability

"Should we do this?"

Even desirable products can be bad businesses. Key questions:

  • Can we acquire customers profitably?
  • Will they pay what we need to charge?
  • Is the market large enough?

Feasibility

"Can we do this?"

Technical and operational constraints. Key questions:

  • Do we have the technology?
  • Is it legal and compliant?
  • Can we handle operations at scale?
Where to Start?

Test Desirability first. Most founders start with Feasibility ("Can we build it?") because it's comfortable. But building something nobody wants is the #1 startup killer. Always validate demand before engineering.

Bug #1: Testing the Wrong Assumptions

Not all assumptions are created equal. Many founders waste months validating assumptions that don't actually matter.

The Bug

"We validated that we can build the technology, so we're good to go."

Technical feasibility is often the LEAST risky assumption. Proving you can build something tells you nothing about whether anyone will buy it.

The Fix

Use the Assumption Mapping Matrix.

Plot all assumptions on a 2x2 grid of Importance vs. Evidence. Focus exclusively on assumptions that are CRITICAL but UNPROVEN—the "Kill Zone."

The Assumption Mapping Workshop

Run this workshop with your team to systematically identify and prioritize what you don't know.

Workshop Setup

Participants:Founders + key team members (3-6 people ideal)
Duration:2-3 hours
Materials:Whiteboard, sticky notes, Sharpies, or digital tool like Miro
Output:Prioritized list of assumptions with experiment plans

Step 1: Extraction (30-45 minutes)

Brainstorm every assumption underlying your business. Use these prompts to extract hidden beliefs:

Desirability Assumptions
  • "Our target customer experiences [problem] regularly"
  • "This problem is painful enough to pay for a solution"
  • "Our solution actually solves the problem"
  • "Customers will switch from their current solution"
  • "Users will understand how to use our product"
Viability Assumptions
  • "Customers will pay $X for this"
  • "We can acquire customers for less than $Y"
  • "Our target market size is at least $Z"
  • "Customers will stay for at least N months"
  • "We can reach customers through [channel]"
Feasibility Assumptions
  • "We can build this with [technology]"
  • "We can hire the talent we need"
  • "This is legally permissible in our markets"
  • "We can deliver within [timeframe]"
  • "Partners/suppliers will work with us"
Team & Market Assumptions
  • "We have the right team composition"
  • "The market timing is right"
  • "Competitors won't respond quickly"
  • "Key stakeholders will support this"
  • "Regulations won't change"
Common Extraction Mistakes
  • Too abstract: "People want to save time" is too vague. Be specific: "Accountants spend 5+ hours/week on manual data entry."
  • Missing implicit assumptions: "Users have smartphones" might be obvious in the US but risky in rural emerging markets.
  • Skipping "obvious" ones: Your most dangerous assumptions often feel so obvious you don't question them.

Step 2: Mapping (30-45 minutes)

Plot each assumption on a 2x2 matrix:

The Assumption Mapping Matrix

X-Axis: Evidence Level

  • Low Evidence (Left): Gut feeling, no data
  • High Evidence (Right): Customer interviews, data, market research

Y-Axis: Business Impact

  • High Impact (Top): If wrong, the business fails
  • Low Impact (Bottom): If wrong, we can adapt
Low Evidence High Evidence
High Impact KILL ZONE
Test immediately		 VALIDATED
Monitor & maintain
Low Impact NICE TO KNOW
Test if time permits		 SAFE ZONE
Ignore for now

Step 3: Prioritize the Kill Zone (30 minutes)

For assumptions in the Kill Zone (high impact, low evidence), prioritize using this formula:

Prioritization Formula

Priority Score = Impact × Uncertainty × Speed of Testing

  • Impact (1-10): How catastrophic if wrong?
  • Uncertainty (1-10): How little do we know?
  • Speed (1-10): How quickly can we test it? (higher = faster)

Test the highest-scoring assumptions first.

Step 4: Design Experiments (45 minutes)

For each priority assumption, define an experiment using this template:

Experiment Design Template

Assumption:[What we believe to be true]
Experiment Type:[Interview / Landing Page / Fake Door / Concierge]
Sample Size:[How many people/interactions]
Success Metric:[What we'll measure]
Pass Threshold:[The number that means "validated"]
Deadline:[When we'll have results]

Bug #2: Building Features Without Outcomes

Many teams build features because they seem like good ideas—without connecting them to measurable business outcomes.

The Bug

"Let's add dark mode—users will love it."

Features that don't connect to business outcomes create bloat, delay launch, and waste engineering time. "Users might like it" isn't a strategy.

The Fix

Use Impact Mapping.

Every feature must connect to a behavior change that helps a business goal. No link = no build.

Impact Mapping: Why Before What

Impact Mapping connects what you build to business goals in four steps:

The Impact Map Structure

GOAL ACTORS IMPACTS DELIVERABLES
LevelQuestionExample
GoalWhy are we doing this?Increase revenue by 30%
ActorsWho can help or hinder?Event organizers, attendees, sponsors
ImpactsHow should their behavior change?Organizers create events more frequently
DeliverablesWhat can we build to cause this?Mobile admin app, event templates
The Feature Justification Test

Before adding any feature to your backlog, answer: "What behavioral change will this cause, and how does that impact our goal?" If you can't answer clearly, the feature doesn't belong in your MVP.

User Story Mapping: End-to-End Completeness

Impact Mapping asks why. User Story Mapping asks what—making sure your MVP covers the full journey, not just one piece.

User Story Map Structure

Arrange stories in a grid that represents the user's journey:

Discover Sign Up Onboard Core Action Share
View landing page Create account Complete profile Create first item Invite teammate
Watch demo video OAuth login Tutorial flow Edit item Share via link
Read testimonials SSO integration Import data Bulk actions Export report

The MVP Line: Draw a horizontal line. Everything above is your MVP—the minimum stories needed to complete the full journey. Green row = MVP. Yellow row = Next release.

Common Story Mapping Mistake

Building 100% of "Sign Up" but 0% of "Core Action." A user can create an account beautifully—but then has nothing to do. Story Mapping makes these gaps visible before you build.

Your Assumption Unpacking Checklist

Before Moving to Build

Desirability validated: You have evidence that customers want this specific solution
Viability tested: You've validated willingness to pay at your target price
Kill Zone cleared: All high-impact, low-evidence assumptions have experiments
Impact map created: Every feature links to a behavioral change and business goal
Story map drawn: Your MVP is end-to-end complete, not deep in one area

Key Takeaways

Remember These Truths
  1. Test Desirability first. Most startups fail because no one wants the product—not because they couldn't build it.
  2. Find the Kill Zone. Focus exclusively on assumptions that are high-impact and low-evidence.
  3. Link features to outcomes. Use Impact Mapping to justify every feature with a behavioral change and business goal.
  4. Ensure end-to-end completeness. Use Story Mapping to avoid building deep in one area while leaving critical gaps.
  5. Run the workshop. Assumption mapping isn't a solo activity—diverse perspectives catch hidden assumptions.

Now that you can systematically unpack and prioritize assumptions, let's explore the specific techniques for validating them without writing code.

Run Your Assumption Workshop with AI

Our AI-powered tools help you extract, prioritize, and design experiments for your business assumptions systematically.

Fit Analyzer Problem-Solution Fit Jobs to Be Done

Ready to Build Your MVP?

LeanPivot.ai provides 50+ AI-powered tools to help you design, build, and launch your minimum viable product.

Start Free Today
Works Cited & Recommended Reading
RAT vs MVP Philosophy
  • 1. Ries, E. (2011). The Lean Startup. Crown Business.
  • 2. "Why RAT (Riskiest Assumption Test) beats MVP every time." LinkedIn
  • 3. "Pretotyping: The Art of Innovation." Pretotyping.org
  • 6. "Continuous Discovery: Product Trio." Product Talk
  • 7. "MVP Fidelity Spectrum Guide." SVPG
Minimum Lovable Product
  • 8. Olsen, D. (2015). The Lean Product Playbook. Wiley.
  • 9. "From MVP to MLP: Why 'Viable' Is No Longer Enough." First Round Review
  • 10. "Minimum Lovable Product framework." Amplitude Blog
Hypothesis-Driven Development
Assumption Mapping
  • 15. Bland, D. & Osterwalder, A. (2019). Testing Business Ideas. Wiley.
  • 16. "Risk vs. Knowledge Matrix." Miro Templates
  • 17. "Identifying Riskiest Assumptions." Intercom Blog
User Story & Impact Mapping
  • 20. Patton, J. (2014). User Story Mapping. O'Reilly Media.
  • 21. Adzic, G. (2012). Impact Mapping. Provoking Thoughts.
  • 22. "Jobs-to-Be-Done Story Framework." JTBD.info
  • 23. "The INVEST Criteria for User Stories." Agile Alliance
  • 24. "North Star Metric Framework." Amplitude
  • 25. "Opportunity Solution Trees." Product Talk
  • 26. Torres, T. (2021). Continuous Discovery Habits. Product Talk LLC.
Pretotyping Techniques
Prioritization Frameworks
Build vs Buy & No-Code
Metrics & Analytics
Launch Operations & Analysis

This playbook synthesizes methodologies from Lean Startup, Design Thinking, Jobs-to-Be-Done, Pretotyping, and modern product management practices. References are provided for deeper exploration of each topic.