Posts


# The Assumption Stack: Rank Your Riskiest Product Bets

> The **assumption stack** is a framework for visualizing your product as a tower of dependent assumptions — "target users exist" at the foundation, "problem is painful enough" above it, "solution solves the problem" above that, and so on up to "unit economics work at scale." If any assumption is false, everything above it collapses. The framework makes these bets explicit, scores them by risk (Impact x Uncertainty), and tests them in dependency order so foundational failures are caught before downstream investment.

Every product decision is a bet.

"Users will want this." That's a bet. "They'll pay $X for it." Another bet. "We can build it in 6 weeks." Bet. "It'll work at scale." Bet.

Most products fail not because the team was incompetent, but because they bet wrong—and didn't know it until they'd already lost.

**The Assumption Stack is a framework for identifying your bets, ranking them by risk, and systematically testing them before they can kill you.**

## What Is the Assumption Stack?

Think of your product as a tower of assumptions, each one stacked on top of others:

```
┌─────────────────────────────────┐
│  Unit economics work at scale   │  ← Only matters if below is true
├─────────────────────────────────┤
│  Users will pay $X/month        │  ← Only matters if below is true
├─────────────────────────────────┤
│  Solution solves the problem    │  ← Only matters if below is true
├─────────────────────────────────┤
│  Problem is painful enough      │  ← Only matters if below is true
├─────────────────────────────────┤
│  Target users actually exist    │  ← Foundation
└─────────────────────────────────┘
```

If any assumption in the stack is false, everything above it collapses.

The Assumption Stack framework helps you:
1. Make these assumptions explicit
2. Identify which are most likely to be wrong
3. Test them in the right order

## Building Your Assumption Stack

### Step 1: List Every Assumption

Start by brainstorming every assumption your product depends on. Be exhaustive. Common categories:

**User Assumptions**
- Target users exist in sufficient numbers
- They experience the problem I think they do
- The problem is painful enough to motivate action
- They're actively looking for solutions
- They have budget for solutions

**Problem Assumptions**
- Current solutions are inadequate
- The problem is frequent enough to matter
- Users recognize they have this problem
- The problem is urgent, not just important

**Solution Assumptions**
- Our solution addresses the core problem
- Users can figure out how to use it
- It's significantly better than alternatives
- The benefits are obvious quickly

**Business Model Assumptions**
- Users will pay our target price
- CAC will be lower than LTV
- We can reach our target users affordably
- Word of mouth will help with growth

**Technical Assumptions**
- We can build this with our team
- It will perform acceptably
- It will scale when needed
- We can maintain it long-term

**Market Assumptions**
- Timing is right
- No dominant incumbent will crush us
- Regulations won't block us
- Market is large enough

Aim for 20-50 assumptions. More is better at this stage.

### Step 2: Score Each Assumption

For each assumption, rate on three dimensions:

**Impact (1-5):** If this is wrong, how bad is it?
- 5 = Product/company fails
- 3 = Major pivot required
- 1 = Minor adjustment needed

**Uncertainty (1-5):** How confident are we this is true?
- 5 = Complete guess
- 3 = Some evidence but not conclusive
- 1 = Very confident, strong evidence

**Testability (1-5):** How easily can we test this?
- 5 = Can test this week cheaply
- 3 = Moderate effort/time/cost
- 1 = Very difficult to test

**Risk Score = Impact × Uncertainty**

**Priority Score = Risk Score × Testability**

High priority = high risk AND easy to test. These are your quick wins.

### Step 3: Order the Stack

Arrange your assumptions in dependency order. Ask: "If this assumption is false, which other assumptions become irrelevant?"

For example, if "users experience this problem" is false, then "users will pay for a solution" doesn't matter.

Test foundational assumptions first.

### Step 4: Design Tests

For each top-priority assumption, design the cheapest, fastest test:

| Assumption | Test | Cost | Time | Success Criteria |
|------------|------|------|------|------------------|
| Users have this problem weekly | 10 user interviews | $0 | 3 days | 7+ confirm |
| Will pay $20/month | Painted door test | $200 ads | 1 week | 3%+ CTR |
| Can build in 4 weeks | Technical spike | $0 | 3 days | Proof of concept |

### Step 5: Execute in Order

Run tests sequentially for dependent assumptions, parallel for independent ones.

**Stop if a foundational assumption fails.** Don't test pricing if you haven't validated the problem.

## Assumption Stack in Practice

### Example: B2B Meeting Scheduler

A founder wanted to build an AI meeting scheduler for sales teams.

**Initial Assumption Stack:**

| Assumption | Impact | Uncertainty | Testable | Priority |
|------------|--------|-------------|----------|----------|
| Sales reps spend 5+ hrs/week scheduling | 5 | 4 | 5 | 100 |
| Current tools (Calendly) aren't enough | 4 | 4 | 4 | 64 |
| AI can schedule better than rules-based | 3 | 3 | 3 | 27 |
| Sales managers will approve new tools | 4 | 4 | 4 | 64 |
| Will pay $30/user/month | 5 | 4 | 4 | 80 |
| Can integrate with major CRMs | 4 | 2 | 5 | 40 |

**Top priority to test:** "Sales reps spend 5+ hrs/week scheduling"

**Test:** Interviewed 15 sales reps at target companies

**Result:** Average was 2 hours/week. Only 2 of 15 said it was a major pain point. Most said, "Calendly is fine."

**Decision:** Killed the idea before writing any code. Saved months of development.

**Lesson:** The foundational assumption was wrong. Everything built on it would have failed.

### Example: Creator Analytics Dashboard

Another founder building analytics for YouTube creators.

**Assumption Stack (excerpted):**

| Assumption | Impact | Uncertainty | Priority |
|------------|--------|-------------|----------|
| Creators check analytics daily | 4 | 3 | 60 |
| YouTube Studio is insufficient | 4 | 4 | 64 |
| Creators will pay $15/mo | 5 | 4 | 80 |
| Can get YouTube API access | 5 | 2 | 40 |

**Tests Run:**
1. "Check analytics daily" → User interviews → TRUE (8/10 daily users)
2. "YouTube Studio insufficient" → Survey → PARTIALLY TRUE (specific gaps identified)
3. "Will pay $15/mo" → Painted door → FALSE (1.2% CTR at $15, 4.8% at $5)

**Outcome:** Pivoted pricing to $5/mo with annual plans. Also narrowed focus to the specific gaps users complained about. Launched successfully.

## Common Mistakes with Assumption Stacks

### 1. Testing the Easy Assumptions First

It's tempting to start with what's comfortable. "Can we build this?" is less scary than "Will anyone pay for this?"

**Fix:** Force yourself to test the riskiest, most foundational assumptions first. Technical validation can come later.

### 2. Treating All Assumptions as Equal

"Users will love the dark mode" is not the same risk as "Users will pay us money."

**Fix:** Always score by impact. Low-impact assumptions can be tested later or skipped.

### 3. Not Killing Bad Ideas

You've found a false assumption. But you're attached to the idea. So you rationalize.

**Fix:** Set kill criteria before you test. "If fewer than 6 of 10 users confirm this problem, we stop." Then follow through.

### 4. Analysis Paralysis

You've listed 100 assumptions. Now you're overwhelmed.

**Fix:** You don't need to test everything. Focus on the top 5-7 by priority score. That usually covers 80% of your risk.

### 5. Testing Assumptions in the Wrong Order

Spending weeks validating that you can scale to 1M users when you haven't validated that 100 users want this.

**Fix:** Dependency order matters. Test foundational assumptions before downstream ones.

## The Assumption Stack Template

Here's a simple template to get started:

```
PRODUCT: _______________
DATE: _______________

ASSUMPTIONS (in dependency order):

1. [Foundation] _____________________
   Impact: __ Uncertainty: __ Testable: __ Priority: __
   Test: _____________________
   Success criteria: _____________________
   Result: _____________________

2. [If #1 is true] _____________________
   Impact: __ Uncertainty: __ Testable: __ Priority: __
   Test: _____________________
   Success criteria: _____________________
   Result: _____________________

[Continue for top 5-7 assumptions]

DECISION: Continue / Pivot / Kill
RATIONALE: _____________________
```

## Start Stacking Today

Your product is already a stack of assumptions. The only question is whether you make them explicit and test them, or leave them implicit and hope.

1. **This week:** List your top 10 assumptions
2. **Score them:** Impact × Uncertainty = Risk
3. **Pick the top 3:** Start testing immediately
4. **Be honest:** If an assumption fails, act on it

The founders who win aren't the ones who guess right. They're the ones who test their guesses systematically.

---

## FAQ

**Q: What is the assumption stack framework?**

The assumption stack visualizes your product as a tower of dependent assumptions. If any is false, everything above collapses. It makes bets explicit, scores them by Impact x Uncertainty, and tests them in dependency order.

**Q: How do you prioritize which assumptions to test first?**

Score by impact (how bad if wrong), uncertainty (how confident you are), and testability (how easily tested). Priority = Risk x Testability. Test foundational assumptions before downstream ones — don't test pricing if you haven't validated the problem.

**Q: What are the most common assumption testing mistakes?**

Testing easy assumptions first, treating all assumptions as equal, not killing bad ideas when disproven, analysis paralysis from too many assumptions, and testing in the wrong order.

---

*Want help identifying your riskiest assumptions? [Try Cutline](/start) for AI-powered assumption analysis and risk assessment.*


The Assumption Stack: Rank Your Riskiest Product Bets


# Pre-Mortem Template: The 30-Minute Product Risk Assessment

> A **pre-mortem template** is a structured 30-minute exercise where you imagine your product has failed catastrophically and work backward through five risk categories — demand, product, channel, business model, and competitive — to identify why. Each category produces scored risks and testable assumptions. The output: your top 3 kill-or-fix risks, explicit kill criteria, and a go/no-go decision backed by structured analysis rather than optimism.

A post-mortem asks: "Why did this fail?"

A **pre-mortem** asks: "Why *will* this fail?"—before you've built anything.

It's the single most effective technique for catching product risks early. Here's a complete template to run one in 30 minutes.

## Why Pre-Mortems Work

Traditional planning is optimistic. You imagine success and work backward.

Pre-mortems are deliberately pessimistic. You imagine failure and ask what caused it.

This mental shift surfaces risks your optimistic brain suppresses:
- The assumption you're not questioning
- The competitor you're underestimating
- The user behavior you're wishfully assuming
- The technical debt you're ignoring

Research by psychologist Gary Klein found that pre-mortems increase the ability to identify reasons for future outcomes by **30%**.

## The 30-Minute Pre-Mortem Template

### Setup (2 minutes)

**Prompt:** "Imagine it's 12 months from now. Your product has failed completely. It's dead. Users left. Revenue is zero. The project is shut down."

Write down: *"[Product name] failed because..."*

Now you'll fill in the "because."

---

### Part 1: Demand Risks (8 minutes)

These are risks that no one wants what you're building.

**Questions to answer:**

1. **What problem are you solving?**
   - Write it in one sentence
   - Is this a vitamin (nice to have) or painkiller (must have)?

2. **Who has this problem?**
   - Be specific: not "businesses" but "B2B SaaS founders with 10-50 employees"
   - How many of them exist?

3. **How are they solving it today?**
   - If "nothing," that's a red flag (maybe it's not a real problem)
   - If "competitor X," why would they switch?

4. **What's your evidence of demand?**
   - Interviews conducted: ___
   - Waitlist signups: ___
   - LOIs or pre-orders: ___
   - If blank, this is your #1 risk

**Template output:**

| Risk | Likelihood (1-5) | Impact (1-5) | Evidence |
|------|------------------|--------------|----------|
| Target users don't have this problem | | | |
| Problem isn't painful enough to pay for | | | |
| Existing solutions are good enough | | | |
| Market is too small | | | |

---

### Part 2: Product Risks (8 minutes)

These are risks that your solution doesn't actually solve the problem.

**Questions to answer:**

1. **What's your core value proposition?**
   - In one sentence, why is your solution better?
   - Is this a 10x improvement or incremental?

2. **What must be true for your product to work?**
   - List 3-5 critical assumptions
   - Which have you validated?

3. **What's the simplest version that delivers value?**
   - Can you describe a 1-week MVP?
   - If not, you might be overbuilding

4. **What will users complain about?**
   - Every product has weaknesses
   - What are yours?

**Template output:**

| Assumption | Confidence (1-5) | Validated? | Test to Run |
|------------|------------------|------------|-------------|
| Users will understand the value prop | | | |
| Core feature works as expected | | | |
| Users will complete onboarding | | | |
| Users will return after first use | | | |

---

### Part 3: Channel Risks (6 minutes)

These are risks that you can't reach your target users.

**Questions to answer:**

1. **How will users find you?**
   - Primary channel: ___
   - Do you have experience with this channel?

2. **What's your expected CAC?**
   - If you don't know, estimate
   - Is this sustainable given your price point?

3. **What's your unfair advantage in distribution?**
   - Existing audience?
   - Partnerships?
   - SEO moat?
   - If "none," distribution is a major risk

**Template output:**

| Channel | Expected CAC | Confidence | Backup Plan |
|---------|--------------|------------|-------------|
| | | | |

---

### Part 4: Business Model Risks (6 minutes)

These are risks that the math doesn't work.

**Questions to answer:**

1. **What will you charge?**
   - Price point: ___
   - How did you decide this?

2. **What does it cost to serve one user?**
   - Infrastructure: ___
   - Support: ___
   - AI/API costs: ___

3. **What's your target LTV:CAC ratio?**
   - Below 3:1 is usually unsustainable
   - Have you modeled this?

4. **When do you break even?**
   - Runway: ___
   - Required users/revenue: ___

**Template output:**

| Metric | Assumption | Validated? | Kill Threshold |
|--------|------------|------------|----------------|
| Price point | | | |
| Conversion rate | | | |
| Churn rate | | | |
| CAC | | | |

---

### Part 5: Competitive Risks (5 minutes)

These are risks that someone else wins instead.

**Questions to answer:**

1. **Who are your direct competitors?**
   - List top 3
   - What do they do better than you?

2. **Who could enter this market?**
   - Big tech risk?
   - Well-funded startup risk?

3. **What's your moat?**
   - Network effects?
   - Data advantage?
   - Brand?
   - If "none," you're in a race

**Template output:**

| Competitor | Their Advantage | Your Advantage | Threat Level |
|------------|-----------------|----------------|--------------|
| | | | |

---

### Synthesis (5 minutes)

**Step 1: Rank your risks**

Review everything you wrote. Pick the **top 3 risks** that could kill your product.

1. _______________
2. _______________
3. _______________

**Step 2: Define kill criteria**

For each top risk, define what would make you stop:

| Risk | Kill Criterion | How to Test |
|------|----------------|-------------|
| Risk 1 | If ___, we stop | |
| Risk 2 | If ___, we pivot | |
| Risk 3 | If ___, we pause | |

**Step 3: Make a decision**

Based on your pre-mortem:

- [ ] **GO** - Risks are manageable, proceed with validation plan
- [ ] **CONDITIONAL GO** - Proceed only if [specific test] passes
- [ ] **PAUSE** - Need more information before deciding
- [ ] **NO GO** - Risks are too high, kill or pivot

---

## Pre-Mortem Output Example

Here's what a completed pre-mortem looks like:

**Product:** AI-powered expense tracking for freelancers

**Top 3 Risks:**
1. Freelancers don't track expenses (behavior change required)
2. Market is too small (&lt; 1M potential users)
3. Competitors offer expense tracking as a feature, not a product

**Kill Criteria:**
1. If &lt; 5% of surveyed freelancers say they'd pay, stop
2. If TAM &lt; $10M, pivot to adjacent market
3. If 3+ competitors launch similar features in 6 months, differentiate or stop

**Decision:** CONDITIONAL GO - Run demand survey first

---

## Running This With AI

You can run this template manually, or use [Cutline's AI-powered pre-mortem](/pre-mortem) to:

- **Auto-generate risks** based on your product description
- **Score assumptions** by likelihood and impact
- **Get persona feedback** from simulated target users
- **Generate experiment plans** for each risk
- **Export a shareable report** for stakeholders

The AI pre-mortem takes 10 minutes instead of 30, and catches risks you might miss.

---

## When to Run a Pre-Mortem

- **Before starting a new product** - Catch fatal flaws early
- **Before major features** - Validate assumptions before building
- **Before fundraising** - Know your risks before investors ask
- **Quarterly** - Revisit as your product evolves

---

## Download the Template

Want a copy of this template? The full pre-mortem framework is built into Cutline.

[Run a Free Pre-Mortem →](/start)

---

---

## FAQ

**Q: How long does a pre-mortem take?**

A manual pre-mortem takes 30 minutes: setup (2 min), demand risks (8 min), product risks (8 min), channel risks (6 min), business model and competitive risks (11 min), synthesis (5 min). AI-assisted takes about 10 minutes.

**Q: What are the five parts of a pre-mortem template?**

Demand risks (does anyone want this), product risks (does the solution work), channel risks (can you reach users), business model risks (does the math work), and competitive risks (will someone else win).

**Q: When should you run a pre-mortem?**

Before new products, before major features, before fundraising, and quarterly as your product evolves.

---

*Pre-mortems don't predict the future. They prepare you for it. The best founders know what could kill them—and build anyway, with eyes open.*


product risk assessment

The Assumption Stack: Rank Your Riskiest Product Bets

Pre-Mortem Template: The 30-Minute Product Risk Assessment