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.*


product risk analysis

The Assumption Stack: Rank Your Riskiest Product Bets