The Assumption Stack
The most dangerous thing an entrepreneur can do is build something for six months before testing their core assumptions. And yet most teams do exactly this — they mistake construction for progress, confusing the act of building with the act of learning.
The Lean Startup methodology begins with a different premise: your new venture is not a business yet. It is a portfolio of unproven assumptions. Every line of code you write, every feature you design, and every hire you make is a bet that specific assumptions about your customer, your market, and your technology are correct. The question is not whether you have assumptions — you do, many of them. The question is whether you make them explicit before you bet the company on them.
In Lesson 4, you selected an idea and ran a pressure test. Each objection in that test corresponds to one or more hidden assumptions. Now you make every assumption explicit, score it by risk, and design the cheapest possible test for each.
Why Assumptions Kill Ventures
Research on venture failure is unambiguous: the most common cause of failure is not bad execution — it is building something customers do not want or will not pay for. Both of these are assumption failures. The team assumed that customers had a particular problem with sufficient severity; they assumed customers would pay a particular price; they assumed their technical approach would achieve sufficient accuracy. None of these were tested before six months of construction.
The assumption map is the antidote. It does not prevent you from being wrong — it ensures you discover you are wrong before you have spent six months building the answer to the wrong question.
| Without an Assumption Map | With an Assumption Map |
|---|---|
| Bets are implicit and untracked | Bets are explicit and systematically tested |
| Discover wrong assumptions after 6 months of build | Discover wrong assumptions in week 1-2 via conversation |
| Pivot feels like failure | Pivot is a data-driven direction adjustment |
| MVP scope bloats (features for untested bets) | MVP is scoped to test only the most critical assumptions |
The Five Assumption Categories
The /hypothesis skill uses five categories to ensure completeness. Starting with all five prevents the most common failure mode: teams that map only product assumptions and miss business model or customer assumptions.
Customer assumptions — who they are, what they want, how they behave
- The customer segment you identified is real and reachable
- They have the pain you think they have, with the severity you think
- They are actively trying to solve this problem (not just mildly aware of it)
- They have the authority and budget to buy a solution
Problem assumptions — is the problem worth solving?
- The problem is frequent enough to justify a dedicated solution
- Current solutions are genuinely inadequate (not just sub-optimal)
- Customers are willing to change their behaviour to solve it
Solution assumptions — does your approach work?
- Your solution technically works as designed
- Customers can and will use it (adoption)
- It solves the problem at the quality level customers need
Business model assumptions — can you make money?
- Customers will pay your assumed price
- You can acquire customers at your assumed cost
- Customers will stay (churn assumption is survivable)
- Your gross margin is achievable
Technical assumptions — can you build it?
- The core technology works at the required accuracy and scale
- You can build it with the team you have in the time you have
Target 20-30 assumptions. If you have fewer than 15, you are not thinking hard enough. The goal is to surface the bets before they surface themselves as failures.
Three-Tier Risk Scoring
Every assumption has a different consequence if it is wrong. The three-tier system forces you to distinguish between assumptions that would end the venture (TIER 1), significantly change the product (TIER 2), and require optimisation (TIER 3).
The Risk Scoring Rule
Ask one question for every assumption: "If I discovered this was wrong tomorrow, would I change direction?"
- YES → TIER 1 (Existential): pivot required if wrong
- MAYBE / SIGNIFICANTLY → TIER 2 (Serious): product changes significantly
- PROBABLY NOT / OPTIMISE → TIER 3 (Important): optimisation required
TIER 1 assumptions are specifically those where being wrong means: (a) no revenue, (b) cannot build the product as designed, or (c) cannot acquire customers at a viable cost. These must be tested before the MVP is built.
Evidence Quality: ASSUMED → ANECDOTAL → VALIDATED
Each assumption carries an evidence quality score that reflects how much you actually know:
- ASSUMED: No external evidence. You believe this is true based on reasoning, intuition, or analogy.
- ANECDOTAL: Some external evidence, but not systematic. A few customer conversations, one industry report, or your own experience suggests this is true.
- VALIDATED: Systematic behavioural evidence. Customers paid for it OR used it repeatedly without prompting. "They said they would use it" is not VALIDATED — it is ANECDOTAL at best.
The assumption map makes the gap between confidence and evidence visible. Most teams discover they feel highly confident about assumptions that are actually ASSUMED — they have never directly tested the claim with a customer.
The Minimum Viable Test (MVT) Hierarchy
The goal is to validate each assumption at the lowest possible cost. The MVT hierarchy defines five levels, ordered from cheapest to most expensive:
| Level | Method | Cost | Use When |
|---|---|---|---|
| 1 | Conversation: ask customers directly | 30 minutes | Testing beliefs and intent |
| 2 | Landing page / waitlist | 1 day | Testing market interest at scale |
| 3 | Concierge MVP: do the job manually for customers | Days/weeks | Testing value proposition before automation |
| 4 | Wizard of Oz: customer-facing front-end; manual back-end | Weeks | Testing UX and adoption without full build |
| 5 | Functional MVP: minimum end-to-end product | Months | Testing technical performance and business model |
Rule: Go to Level 5 only if Levels 1-4 cannot test the assumption.
Most TIER 1 assumptions can be tested at Level 1 or 2. The question "would you sign an LOI for $500/month before we build?" is Level 1. It takes 30 minutes and costs nothing. Most teams build a product instead. This is how six months of development produces learnings that a 30-minute conversation would have revealed.
The AP Automation Assumption Map
Worked example. Using the selected idea from Lesson 4 — WhatsApp approval workflow SaaS for mid-market CFOs at $500/month — you build the full assumption map:
/hypothesis
Build a complete assumption map for my AP automation SaaS startup.
Venture: AP automation for mid-market companies
Target customer: CFO, $5M–$50M revenue
Solution hypothesis: A SaaS platform that digitises invoice receipt,
AI-powered PO matching, WhatsApp-integrated approval workflows,
and real-time AP dashboard. $500/month.
For each assumption, score:
- Risk tier (TIER 1/2/3) — if wrong, does the company fail/pivot/optimise?
- Evidence quality (ASSUMED/ANECDOTAL/VALIDATED)
- Cheapest test — minimum viable test level and specific test design
- Test cost: time + money estimate
Sample assumption map:
ASSUMPTION MAP
Venture: AP Automation SaaS | Stage: Pre-MVP
════════════════════════════════════════════════════════════
TIER 1 — EXISTENTIAL ASSUMPTIONS (if wrong, pivot required)
A-001: CFOs will pay $500/month for this solution
Risk: 🔴 HIGH | Evidence: ASSUMED
Why existential: The entire business model depends on this price point.
If real willingness-to-pay is $150/month, the unit economics collapse.
Cheapest test: Ask 5 pilot prospects: "If this existed today, would you
sign a letter of intent at $500/month before we build?"
Get signed LOIs — not verbal commitments.
Time: 2 weeks | Cost: $0
A-002: AI-powered PO matching can achieve >90% accuracy on
local invoice formats (mixed formats, languages, handwriting)
Risk: 🔴 HIGH | Evidence: ASSUMED
Why existential: Core product claim. If accuracy is 70%, the product
creates more manual work than it eliminates.
Cheapest test: Build a 2-week technical spike with 500 real invoices
from 3 pilot customers. Measure accuracy. Make pivot/continue decision.
Time: 2 weeks | Cost: Developer time only
A-003: CFOs have authority to purchase this without CEO sign-off
Risk: 🔴 HIGH | Evidence: ANECDOTAL (mixed: 5/10 interviews unclear)
Why existential: Determines sales cycle length and deal economics.
If CFO needs CEO approval, CAC doubles and sales cycle triples.
Cheapest test: In the next 5 discovery conversations, ask explicitly:
"If this existed today at $500/month, could you approve the purchase
yourself, or would it need sign-off?"
Time: 1 week | Cost: $0
TIER 2 — SERIOUS ASSUMPTIONS (if wrong, product changes significantly)
A-004: WhatsApp integration is technically feasible via WhatsApp
Business API at acceptable cost per message
Risk: 🟡 MEDIUM-HIGH | Evidence: ASSUMED
Test: Proof-of-concept: 1 developer, 1 week. Send one test invoice
approval via WhatsApp Business API. Confirm cost per message is within
unit economics (target: <$0.05 per approval).
Time: 1 week | Cost: Developer time only
A-005: Finance teams will actually use the system (adoption)
Risk: 🟡 MEDIUM-HIGH | Evidence: ASSUMED
Test: In pilot: track percentage of invoices processed through the
system in Week 1, 2, and 4. Target: >70% by Week 4. Below this
threshold, investigate before scaling.
Time: 4 weeks (pilot) | Cost: $0 additional
A-006: ERP integration is not a barrier to purchase
Risk: 🟡 MEDIUM | Evidence: ANECDOTAL
Test: Ask next 5 prospects: "What ERP do you use? How important is
real-time sync with the ERP to sign up?" If >60% require ERP
integration on Day 1, reprioritise roadmap.
Time: 1 week | Cost: $0
TIER 3 — IMPORTANT ASSUMPTIONS (if wrong, optimisation required)
A-007: Customer acquisition cost via LinkedIn outreach is <$5,000
A-008: Customer success can be managed by 1 person for first 50 customers
A-009: 12-month average contract length (annual churn < 8%)
A-010: Net Promoter Score > 40 at 90 days (customers will refer others)
TEST PRIORITY ORDER:
Week 1-2: A-001 (price) + A-003 (buying authority) — zero-cost conversations
Week 3-4: A-002 (AI accuracy) — technical spike with real invoice data
Week 5-6: A-004 (WhatsApp integration) — technical proof-of-concept
Month 3+: A-005, A-006, A-007 — validated during pilot
════════════════════════════════════════════════════════════
Notice the test priority: the two TIER 1 assumptions that cost nothing to test (A-001 and A-003) come first. The technical spike (A-002) comes second — it costs developer time but not product build time. The pilot-validated assumptions come last. This sequence means that if A-001 (price) fails in Week 1, you have spent two hours on conversations, not two months on code.
After building the assumption map, most teams discover a pattern: their highest-confidence assumptions are also their most critical assumptions — and yet the evidence quality is ASSUMED. This gap between confidence and evidence is the most important output of the exercise. Confidence without evidence is just a well-articulated guess.
Inside an existing organisation, TIER 1 assumptions have a different shape. They often include: "The innovation committee will approve this for a pilot" (organisational authority), "The IT department will allow this integration with existing systems" (technical gatekeeping), and "The target internal users will actually adopt this rather than continuing with the current process" (change management). Test these assumptions before building — an internal sponsor conversation is as cheap as an external customer conversation.
Exercise: Hypothesis Stress-Test (Part 1)
Type: Lean Startup — Hypothesis Time: 40 minutes Goal: Build a 20+ assumption map for your selected idea from Lesson 4 and design a 4-week validation plan
From Exercise 1 (Lesson 4), you have: a selected idea with a two-paragraph rationale and a pressure test with 5 objections. Each objection contains at least one hidden assumption — start your map from there.
Step 1 — Assumption brainstorm (10 minutes).
Using the 5 categories (Customer, Problem, Solution, Business Model, Technical), list every assumption embedded in your selected idea. Start with the pressure test objections from Lesson 4 — each one is a TIER 1 or TIER 2 assumption. Then expand to all five categories.
Target: 20-30 assumptions. If you have fewer than 15, you are not thinking hard enough.
Step 2 — Risk scoring and test design (20 minutes).
/hypothesis
Build a complete assumption map for my venture.
Venture: [Your idea in 2-3 sentences]
Target customer: [Specific — role, company size, context]
Assumptions: [Paste your list]
For each assumption:
- Tier: TIER 1 (existential), TIER 2 (serious), or TIER 3 (important)
Rule: "If I discovered this was wrong tomorrow, would I change direction?"
YES = TIER 1 | MAYBE/SIGNIFICANTLY = TIER 2 | PROBABLY NOT = TIER 3
- Evidence quality: ASSUMED / ANECDOTAL / VALIDATED
- Cheapest test: what is the minimum viable test (conversation, landing
page, concierge, wizard-of-oz, or functional MVP)?
- Test cost: time + money estimate
Step 3 — Test prioritisation and 4-week validation plan (10 minutes).
/hypothesis
My top 5 highest-risk assumptions (from the map above) are:
[List A-001 through A-005 with their descriptions]
Design a 4-week validation plan:
- Week 1: cheapest tests only — what can I test in conversations this week?
- Week 2: next cheapest — what can I build or prototype quickly?
- Weeks 3-4: what requires building a small proof-of-concept?
- Pivot criteria: what result in each week would trigger a pivot conversation?
Deliverable: Full assumption map (20+ assumptions) with tier classifications and evidence quality scores, plus a 4-week validation plan. Save this — it is the direct input to Lesson 6 (MVP scoping) and the exercises in Lesson 7 (Build-Measure-Learn).
Your assumption map drives everything in Lessons 6 and 7. The MVP you scope in Lesson 6 exists to test your TIER 1 assumptions. The pilot results you analyse in Lesson 7 will update the status of each assumption from ASSUMED to VALIDATED or INVALIDATED. Keep this in your Cowork session.
Try With AI
Use these prompts in Cowork or your preferred AI assistant.
Reproduce — Run the chapter's worked example:
/hypothesis
Build a complete assumption map for an AP automation SaaS startup.
Venture: SaaS platform for mid-market AP automation
Target customer: CFO, $5M–$50M revenue company
Solution hypothesis: Invoice ingestion via email + WhatsApp,
AI-powered PO matching, WhatsApp approval workflow, real-time AP
dashboard. $500/month subscription.
For each assumption:
- Tier (TIER 1/2/3) with rationale
- Evidence quality (ASSUMED/ANECDOTAL/VALIDATED)
- Cheapest test + cost estimate
Also produce a test priority order (which assumptions to test first
and why).
What you are learning: Notice how many TIER 1 assumptions can be tested in a 30-minute conversation (zero cost). The test priority order reveals that most teams should be having conversations, not writing code, in weeks 1 and 2.
Adapt — Build an assumption map for a different venture type:
/hypothesis
Build a complete assumption map for the following venture.
Venture: A platform that connects freelance graphic designers with
small business owners who need brand identity work
Target customer: Small business owner, under 10 employees,
recently launched or rebranding, no design knowledge
Solution hypothesis: Subscription model — $99/month for unlimited
revision rounds with a dedicated designer. Designer earns 70%.
For each assumption: Tier + evidence quality + cheapest test.
Produce the 4-week validation plan.
What you are learning: Notice how the assumption map changes shape for a two-sided marketplace versus a SaaS product. There are now two sets of TIER 1 assumptions — one for the buyer side and one for the supply side. A marketplace must validate both simultaneously.
Apply — Build your own assumption map:
/hypothesis
Build a complete assumption map for my venture.
Venture: [Your selected idea from Lesson 4, in 2-3 sentences]
Target customer: [Specific role and context]
My top 5 pressure-test objections from Lesson 4 are:
1. [Objection 1]
2. [Objection 2]
3. [Objection 3]
4. [Objection 4]
5. [Objection 5]
Start with these as TIER 1/2 candidates. Then generate additional
assumptions across all 5 categories to reach 20+ total.
Score each and produce a 4-week validation plan.
What you are learning: The objections from your Lesson 4 pressure test are not abstract risks — they are specific assumptions you can test cheaply. Mapping them formally surfaces the test design and cost, which often reveals that the "scariest" risks can be tested for free in a single afternoon.
Flashcards Study Aid
Continue to Lesson 6: MVP — The Minimum That Validates →