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


# The Pre-Mortem Framework for Product Validation

Most product teams run post-mortems after something fails. By then, you've already burned months of development time, depleted runway, and demoralized your team.

**What if you could run that analysis before you build?**

> A **product pre-mortem** is a structured risk analysis technique where you imagine your product has already failed and work backward to identify why. Based on psychologist Gary Klein's research, prospective hindsight — imagining a future event has already happened — increases the ability to identify reasons for outcomes by 30%. Applied to product development, it surfaces the assumptions you're not questioning, the competitors you're underestimating, and the user behaviors you're wishfully assuming.

That's the pre-mortem framework—a structured approach to identifying why your product might fail, before you've invested anything.

## What Is a Pre-Mortem?

A pre-mortem flips the traditional post-mortem on its head. Instead of asking "what went wrong?" after launch, you ask "what could go wrong?" before you start.

The concept comes from psychologist Gary Klein, who found that **prospective hindsight**—imagining a future event has already happened—increases the ability to identify reasons for outcomes by 30%.

Applied to product development:

1. **Assume your product failed spectacularly**
2. **List every reason why it might have failed**
3. **Prioritize risks by likelihood and impact**
4. **Design experiments to test your riskiest assumptions**

## Why Pre-Mortems Beat Traditional Validation

Traditional validation methods have a fundamental flaw: **confirmation bias**.

When you ask customers "would you use this?", they say yes to be polite. When you survey the market, you find data that supports your hypothesis. When you build an MVP, you've already committed emotionally.

Pre-mortems work differently because they:

- **Invite dissent**: Asking "why will this fail?" gives permission to voice concerns
- **Surface hidden assumptions**: Forces you to articulate what you're taking for granted
- **Prioritize ruthlessly**: Not all risks are equal—pre-mortems help you focus on what matters
- **Create testable hypotheses**: Each risk becomes an experiment you can run

## The 5-Step Pre-Mortem Process

### Step 1: Define the Failure State

Start by vividly imagining failure. Not a mediocre outcome—catastrophic failure.

> "It's 12 months from now. Our product launched, and it's a disaster. We have almost no users, we're out of money, and we're shutting down."

Write this down. Make it specific to your product.

### Step 2: Generate Failure Reasons

Now brainstorm: **Why did we fail?**

Don't filter. Don't debate. Just generate. Common categories include:

- **Market risks**: No one wanted this. The market was too small. Timing was wrong.
- **Product risks**: It didn't solve the problem. It was too hard to use. Key feature was missing.
- **Technical risks**: We couldn't build it. It didn't scale. Security breach killed trust.
- **Business model risks**: Couldn't charge enough. CAC exceeded LTV. Wrong pricing model.
- **Competitive risks**: Incumbent crushed us. Better-funded startup beat us to market.
- **Team risks**: Key person left. Couldn't hire the skills we needed. Founder conflict.

Aim for 15-30 distinct failure reasons.

### Step 3: Cluster and Prioritize

Group related failures and score each cluster on:

- **Likelihood** (1-5): How probable is this failure mode?
- **Impact** (1-5): If it happens, how bad is it?
- **Uncertainty** (1-5): How much do we really know about this?

Multiply to get a risk score. Focus on your top 5-7 risks.

### Step 4: Identify Assumptions

For each top risk, ask: **What would have to be true for this NOT to happen?**

These are your critical assumptions. For example:

- Risk: "No one wanted this"
- Assumptions: 
  - Target users experience this pain weekly
  - Current solutions are inadequate
  - Users would pay $X/month for a better solution

### Step 5: Design Experiments

For each critical assumption, design the cheapest, fastest experiment to test it:

| Assumption | Experiment | Success Criteria | Time |
|------------|------------|------------------|------|
| Users experience pain weekly | Interview 10 target users | 7+ confirm pain point | 1 week |
| Would pay $X/month | Landing page with pricing | 3%+ click "Buy Now" | 2 weeks |
| Current solutions inadequate | Competitive analysis | Gap identified | 3 days |

Run experiments in parallel. Kill ideas fast.

## Pre-Mortem in Practice: A Real Example

A founder came to us with an idea: "AI-powered meal planning for busy parents."

Traditional validation would have them build an MVP and test it. Instead, we ran a pre-mortem:

**Top Failure Reasons Identified:**
1. Parents don't plan meals—they wing it
2. Too much friction to input preferences
3. AI suggestions feel generic
4. Grocery integration doesn't work with their store
5. Spouse/partner doesn't adopt it

**Critical Assumptions Tested:**
- "Parents want to plan meals" → Interviewed 15 parents. Only 3 actually planned meals. Most relied on 10-15 rotation recipes.
- "AI suggestions would feel personalized" → Showed mock suggestions. Users said "I could get this from Pinterest."

**Outcome:** Pivoted from meal planning to "dinner rescue"—a just-in-time suggestion for what to make with ingredients you already have. Completely different product, much stronger market signal.

Total time spent: 2 weeks and $0 in development costs.

## Common Pre-Mortem Mistakes

### 1. Being Too Optimistic
If your failure reasons are all "competition might be tough," you're not digging deep enough. Push for uncomfortable truths.

### 2. Not Testing Assumptions
Identifying risks without running experiments is just anxiety. The point is to learn, not to worry.

### 3. Testing the Wrong Things
Don't test "will users like it?" Test "will users pay for it?" and "will they come back?"

### 4. Ignoring the Results
If experiments show your core assumption is false, don't rationalize. Kill the idea or pivot dramatically.

## Tools for Running Pre-Mortems

You can run a pre-mortem with sticky notes and a whiteboard. Or you can use tools designed for structured product validation:

- **[Cutline](/pre-mortem)**: AI-powered pre-mortem analysis that generates risks, personas, and experiments based on your product brief
- **Notion/Miro**: Manual templates for collaborative pre-mortems
- **Spreadsheets**: Simple but effective for solo founders

The tool matters less than the discipline of actually doing it.

## Start Your Pre-Mortem Today

Every week you spend building the wrong thing is a week you can't get back.

Before your next feature, your next product, your next startup—run a pre-mortem. Assume it failed. Figure out why. Test those assumptions.

The best founders don't avoid failure by being lucky. They avoid it by failing on paper first.

---

## FAQ

**Q: What is a product pre-mortem?**

A product pre-mortem is a structured risk analysis where you imagine your product has already failed and work backward to identify why. Based on Gary Klein's research, prospective hindsight increases the ability to identify reasons for outcomes by 30%.

**Q: How is a pre-mortem different from a post-mortem?**

A post-mortem asks "what went wrong?" after failure has already happened. A pre-mortem asks "what could go wrong?" before you build, when you can still change direction cheaply. Pre-mortems surface risks your optimistic planning brain suppresses.

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

Run a pre-mortem before starting a new product, before major features, before fundraising, and quarterly as your product evolves. It takes 30 minutes manually or 10 minutes with AI assistance.

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

The five steps are: (1) define the failure state by imagining catastrophic failure, (2) generate failure reasons across market, product, technical, business, and competitive categories, (3) cluster and prioritize by likelihood, impact, and uncertainty, (4) identify critical assumptions underlying each risk, and (5) design the cheapest experiments to test each assumption.

---

## Run Your Pre-Mortem with Cutline

**Free Product Validation:** [Test your product idea with AI-powered pre-mortem analysis →](https://thecutline.ai/validate)

Cutline automatically generates:
- Failure scenarios across 6 risk categories
- AI personas to test your assumptions
- Prioritized experiments with success criteria
- Security, scalability, and compliance constraints

**Related Resources:**
- [SOC 2 Compliance for AI Apps](https://thecutline.ai/soc-2-compliance-for-ai-apps) — Validate compliance early
- [Free Code Security Vibe Check](https://thecutline.ai/scan) — Find vulnerabilities before launch
