charlieviettq 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
- Build: Create the smallest possible thing that tests your riskiest assumption (MVP)
- Measure: Collect data on whether the assumption holds (actionable metrics, not vanity metrics)
- 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