Lean Startup

Framework

IRON LAW: Validate Before You Build

Every product decision is a hypothesis. The most expensive way to test
a hypothesis is to build the full product. The cheapest is to test the
riskiest assumption FIRST with the minimum possible effort.

"Build it and they will come" is not a strategy — it's a prayer.

Build-Measure-Learn Loop

1. Build: Create the smallest possible thing that tests your riskiest assumption (MVP)
2. Measure: Collect data on whether the assumption holds (actionable metrics, not vanity metrics)
3. Learn: Did the data validate or invalidate the assumption?
   • Validated → double down, test next assumption
   • Invalidated → pivot (change strategy) or persevere (refine execution)

MVP Types (Ordered by Effort)

MVP Type	Effort	What It Tests
Landing page	Hours	"Do people want this?" (signup conversion)
Explainer video	Days	"Do people understand and desire this?"
Concierge	Days	"Can we deliver value manually?" (do it by hand for 10 customers)
Wizard of Oz	Weeks	"Does the full experience work?" (fake the backend, real frontend)
Single-feature	Weeks	"Does this core feature solve the problem?"
Functional prototype	Months	"Can we build this and do users adopt it?"

Vanity Metrics vs Actionable Metrics

Vanity (avoid)	Actionable (use)
Total signups	Activation rate (% who complete onboarding)
Page views	Conversion rate (% who take desired action)
Downloads	Retention (% who return after 7/30 days)
Total revenue	Revenue per user, LTV:CAC

Pivot Triggers

Consider pivoting when:

• Metrics flat after 2-3 iteration cycles
• Customer feedback consistently requests something different than what you're building
• Unit economics don't improve with scale
• The team's enthusiasm has shifted to a different problem

Pivot Types

Pivot	What Changes
Customer segment	Same product, different target
Problem	Same customer, different problem to solve
Solution	Same problem, different approach
Channel	Same product, different distribution method
Revenue model	Same product, different pricing/business model
Platform	Single product → platform (or vice versa)

Output Format

# Lean Startup Plan: {Product/Idea}

## Riskiest Assumption
{The one thing that must be true for this to work}

## MVP Design
- Type: {landing page / concierge / etc.}
- What it tests: {specific assumption}
- Build time: {hours/days/weeks}
- Success metric: {specific threshold}

## Build-Measure-Learn Plan
| Cycle | Build | Measure | Learn |
|-------|-------|---------|-------|
| 1 | {MVP} | {metric + threshold} | Validate/Pivot? |
| 2 | {iteration} | {metric} | ... |

## Pivot/Persevere Criteria
- Persevere if: {specific metric threshold met}
- Pivot if: {specific metric threshold not met after N cycles}

Gotchas

• MVP ≠ crappy product: Minimum Viable Product is the minimum needed to LEARN, not the minimum you can get away with shipping. Quality still matters where it affects the test.
• "Build" doesn't always mean code: A landing page, a spreadsheet, a manual service — anything that tests the assumption counts.
• Pivot is not failure: Pivoting means you learned something valuable. The failure is not pivoting when the data says you should.
• Lean Startup is for uncertainty: If you're building a well-understood product in a known market, waterfall may be fine. Lean Startup is for when you don't know what to build or for whom.

References

• For experiment design templates, see references/experiment-templates.md