A systematic approach to building startups and launching new products that shortens development cycles and rapidly discovers if a business model is viable.
Core Principle
Entrepreneurship is a form of management.
Success doesn't require a perfect plan or brilliant insight—it requires a systematic process for testing assumptions, learning from customers, and iterating rapidly.
The foundation:
Most startups fail not because they couldn't build what they planned, but because they built the wrong thing. The Lean Startup methodology applies scientific experimentation to eliminate waste and accelerate validated learning.
Scoring
Goal: 10/10.
When reviewing or creating product development plans, experiments, or metrics, rate them 0-10 based on adherence to Lean Startup principles. A 10/10 means full application of Build-Measure-Learn, validated learning, and evidence-based decisions; lower scores indicate waterfall thinking or waste. Always provide the current score and specific improvements needed to reach 10/10.
The Build-Measure-Learn Loop
The fundamental cycle of Lean Startup:
IDEAS
↓
BUILD → Product
↓
MEASURE → Data
↓
LEARN → Knowledge
↓
(back to IDEAS)
Critical insight:
The loop is actually backward. Start with what you want to learn, determine metrics that will inform that learning, then build the minimum product to collect those metrics.
Reverse planning:
What do we want to learn?
(hypothesis to test)
How will we know if we learned it?
(metrics)
What's the minimum we can build?
(MVP)
Goal:
Minimize total time through the loop.
See:
references/build-measure-learn.md
for detailed loop execution.
Validated Learning
Definition:
Learning what customers really want through validated experiments, not opinion or anecdotes.
Validated learning is not:
Building features customers request (they don't know what they want)
Achieving vanity metrics (downloads, signups without engagement)
Doing surveys or focus groups (people lie/mispredict behavior)
Validated learning is:
Testing hypotheses with real behavior
Measuring what customers
do
, not what they
say
Running experiments that could falsify your assumptions
Learning = when your predictions were wrong
The Validation Ladder:
Level
Evidence
Strength
1
"I think customers want this"
Weakest (opinion)
2
"Customers said they want this"
Weak (stated preference)
3
"Customers signed up for early access"
Medium (low commitment)
4
"Customers paid a deposit"
Strong (real commitment)
5
"Customers are actively using it"
Strongest (revealed preference)
Target:
Level 4-5 before building at scale.
Minimum Viable Product (MVP)
Definition:
The version of a new product that allows a team to collect the maximum amount of validated learning with the least effort.
MVP is not:
A prototype (not about proving technical feasibility)
A beta version (not about quality or features)
A minimum marketable product (it might be embarrassing)
MVP is:
A learning vehicle
The smallest experiment to test a hypothesis
Often much smaller than you think
MVP Types:
Type
What It Is
When to Use
Example
Concierge
Manual service pretending to be automated
Test if solution is valuable
Food on the Table (manual meal planning)
Wizard of Oz
Fake automation, manual backend
Test if automation is needed
Zappos (no inventory, bought shoes retail)
Smoke test
Landing page + signup, no product
Test demand before building
Dropbox video (explained concept, measured signups)
Single feature
One core feature only
Test which feature is most valuable
Twitter (just status updates)
Piecemeal
Combine existing tools
Test workflow before custom build
Groupon (WordPress + email)
MVP Design Questions:
What's the riskiest assumption to test first?
What's the minimum to test that assumption?
How do we measure if the assumption was validated?
Common mistakes:
Building too much (overestimate MVP size)
Optimizing for scale prematurely
Confusing quality with learning (MVP can be low quality)
Skipping the experiment (building without hypothesis)
See:
references/mvp-design.md
for MVP types and design patterns.
Leap-of-Faith Assumptions
Definition:
The assumptions that, if wrong, will cause your business to fail.
Process:
Identify your business model's critical assumptions
Prioritize by risk
(which failure would be fatal?)
Test the riskiest assumption first
Common leap-of-faith assumptions:
Assumption Type
Question
Test Method
Value hypothesis
Do customers care about this problem?
Smoke test, concierge MVP
Growth hypothesis
How will customers discover us?
Channel tests, referral experiments
Retention hypothesis
Will customers come back?
Cohort analysis, engagement metrics
Monetization hypothesis
Will customers pay?
Pre-orders, pricing tests
Example: Dropbox
Leap-of-faith:
"People will download and use a file sync tool"
Test:
Explainer video showing product (before building full version)
Metric:
Beta signup list grew from 5,000 to 75,000 overnight
Learning:
Validated demand before building scale infrastructure
Anti-pattern:
Testing assumptions in order of ease rather than risk.
See:
references/assumptions.md
for assumption mapping frameworks.
Innovation Accounting
Definition:
Measuring progress when traditional accounting doesn't apply.
The problem with traditional metrics:
Revenue (startups start at $0)
Customers (startups start at 0)
Vanity metrics (look good but don't drive decisions)
Innovation accounting framework:
1. Establish the Baseline
Question:
Where are we today?
Measure current reality, even if it's zero or embarrassing.
Metrics to establish:
Conversion funnel (signup → active → retained → paying)
Engagement (DAU/MAU, session length, features used)
Economics (CAC, LTV, churn rate)
Goal:
Know your starting point precisely.
2. Tune the Engine
Question:
What can we improve to move toward our goal?
Run experiments to improve baseline metrics.
Examples:
A/B test pricing ($9/mo vs. $19/mo)
Test onboarding flows (% who complete setup)
Experiment with channels (SEO vs. paid vs. referral)
Goal:
Systematically improve metrics through validated learning.
3. Pivot or Persevere
Question:
Are we making sufficient progress, or do we need to change strategy?
Based on data, decide whether to continue or pivot.
Criteria:
Are metrics moving in the right direction?
Is the rate of improvement acceptable?
Are we learning what we expected?
Goal:
Make evidence-based strategic decisions.
See:
references/innovation-accounting.md
for metric frameworks and dashboards.
Actionable vs. Vanity Metrics
Vanity metrics:
Make you feel good but don't change behavior.
Actionable metrics:
Drive decisions and clarify cause and effect.
Vanity
Why It's Bad
Actionable Alternative
Total signups
Always goes up, no context
% signup → active
(conversion rate)
Page views
Doesn't indicate value
Time on page
,
bounce rate
Total users
Includes inactive/churned
Active users
(DAU, WAU, MAU)
Downloads
Doesn't mean usage
DAU/downloads
(activation rate)
Revenue
Without context
Revenue per cohort
,
LTV/CAC
Three characteristics of actionable metrics:
Actionable:
Clear cause-and-effect (can reproduce)
Accessible:
Simple, understandable by everyone
Auditable:
Can check the underlying data (not a black box)
Example:
Vanity:
"We have 100,000 users!"
Actionable:
"Users from channel X have 2x retention vs. channel Y. Let's double down on X."
Cohort analysis:
Group users by signup date and track behavior over time. Reveals if product is actually improving.
See:
references/metrics.md
for metric selection and tracking.
Pivot or Persevere
Pivot:
A structured course correction designed to test a new hypothesis about the product, strategy, or engine of growth.
When to pivot:
Experiments consistently fail to validate hypotheses
Metrics are flat despite multiple iterations
Customer feedback contradicts your vision
Progress is too slow given runway
When to persevere:
Metrics are improving (even if slowly)
Clear learning is happening
Adjustments are moving in right direction
Pivot Types:
Pivot Type
What Changes
Example
Zoom-in pivot
Single feature becomes the whole product
Instagram (photo filters from Burbn check-in app)
Zoom-out pivot
Product becomes a single feature
Flickr (photo-sharing from Game Neverending)
Customer segment
Same problem, different customer
Groupon (activism platform → local deals)
Customer need
Same customer, different problem
Potbelly Sandwich (antique store → sandwiches)
Platform
App → Platform or Platform → App
YouTube (dating site → video platform)
Business architecture
High margin, low volume ↔ Low margin, high volume
Salesforce (software → SaaS)
Value capture
Monetization model change
Android (paid → free + app revenue)
Engine of growth
Viral, sticky, or paid growth model
Facebook (viral within colleges → paid advertising)
Channel
How you reach customers
Salesforce (direct sales → self-service)
Technology
Different technology, same solution
Apple (Intel → ARM chips)
Pivot cadence:
Many successful startups pivot 1-5 times before finding product-market fit.
Anti-pattern:
"Pivot" without validating that the new direction solves the core problem.
See:
references/pivots.md
for pivot decision frameworks and case studies.
The Three Engines of Growth
Growth engine:
How your startup acquires and retains customers sustainably.
Choose one engine to focus on:
1. Sticky Engine of Growth
Mechanism:
High retention, low churn
Formula:
Growth rate = New customer acquisition rate - Churn rate
Focus:
Keep customers coming back
Metrics:
Churn rate (% who stop using per month)
Retention cohorts (% still active after 30/60/90 days)
Engagement (DAU/MAU ratio)
Examples:
SaaS, subscription services, social networks
Strategy:
Improve product until churn rate is low enough that natural growth exceeds churn.
2. Viral Engine of Growth
Mechanism:
Customers bring other customers
Formula:
Viral coefficient = (% who invite) × (invites sent) × (% who join)
Focus:
Viral coefficient > 1.0 = exponential growth
Metrics:
Viral coefficient (invites → signups)
Viral cycle time (how long until referred user invites others)
Referral source attribution
Examples:
Dropbox, Hotmail, WhatsApp
Strategy:
Build virality into the product. Must be > 1.0 to be self-sustaining.
Optimize until each customer generates enough profit to acquire more customers.
Warning:
Don't use multiple engines simultaneously. Pick one, optimize it, then consider adding others.
See:
references/growth-engines.md
for engine selection and optimization.
The Five Whys
Purpose:
Root cause analysis to prevent problems from recurring.
Process:
A problem occurs (bug, outage, customer complaint)
Ask "Why did this happen?" → Answer
Ask "Why?" about that answer → Second answer
Repeat 5 times until you reach the root cause
Make proportional investments at each level
Example:
Problem:
Website went down
Why?
Server ran out of memory
Why?
Memory leak in new feature
Why?
Code wasn't reviewed for memory management
Why?
No code review process for infrastructure changes
Why?
Team is moving too fast to create processes
Proportional investments:
Fix the immediate bug (level 1)
Add memory monitoring (level 2)
Implement code review (level 3-4)
Slow down to build quality processes (level 5)
Anti-pattern:
Stop at level 1 (just fix the symptom).
See:
references/five-whys.md
for facilitation guides.
Small Batches
Principle:
Work in small batches to accelerate learning and reduce waste.
Why small batches win:
Faster feedback loops
Easier to pivot
Less waste when you're wrong
Faster time to market
Examples:
Large Batch
Small Batch
Build entire product, then launch
Launch landing page, then build
Release quarterly
Release weekly or daily
Plan 12-month roadmap
Plan 6-week cycles
Big bang rewrite
Incremental refactoring
Continuous deployment:
The ultimate small batch = deploy every code commit.
Benefits:
Bugs are caught immediately
Learning happens continuously
Reduced risk per deployment
See:
references/small-batches.md
for implementation patterns.
Lean Startup Applied
For different contexts:
SaaS Startup
Smoke test:
Landing page + email list (validate demand)
Concierge MVP:
Manually deliver service to 10 customers (validate value)
Single-feature MVP:
Build one core workflow (validate engagement)
Measure:
Retention, NPS, feature usage
Pivot or scale:
Based on cohort data
Corporate Innovation
Innovation accounting:
Separate metrics from core business
Protected teams:
Shield from quarterly revenue pressure
Metered funding:
Unlock funding based on validated learning milestones
Internal entrepreneurship:
Treat team as startup within company
Product Features
Feature flags:
Deploy behind flag, test with small cohort
A/B test:
Measure impact on core metrics
Kill, iterate, or scale:
Based on data
See:
references/applications.md
for context-specific guides.
Common Mistakes
Mistake
Why It Fails
Fix
Building too much
Waste before validation
Test with smoke test or concierge first
Asking customers
People don't know/mispredict
Observe behavior, not opinions
Vanity metrics
Feel-good numbers, no decisions
Track cohorts, conversion, retention
No hypothesis
Can't learn if you don't predict
Write hypothesis before each experiment
Pivot too slow
Waste runway
Set clear pivot criteria upfront
Skip innovation accounting
Can't tell if you're improving
Establish baseline, measure tuning efforts
Quick Diagnostic
Audit any product development plan:
Question
If No
Action
What's the riskiest assumption?
You're building on shaky ground
Map leap-of-faith assumptions
How will you test it?
You're guessing
Design MVP to test assumption
What metric will validate/invalidate?
You won't learn
Define actionable metrics
Can you test with less than this?
You're over-building
Shrink MVP further
What will you do if the experiment fails?
No pivot criteria
Define pivot triggers upfront
The Lean Startup Applied: From Idea to Scale
Phase 1: Problem/Solution Fit
Goal:
Validate the problem exists and customers care
Method:
Customer discovery, smoke tests, concierge MVP
Metric:
Customers willing to pay or commit
Phase 2: Product/Market Fit
Goal:
Build something people want
Method:
Build MVP, iterate based on usage data
Metric:
High retention, organic growth, strong engagement
Phase 3: Scale
Goal:
Grow efficiently
Method:
Optimize growth engine, improve unit economics
Metric:
Sustainable, profitable growth
Anti-pattern:
Skipping Phase 1-2 and jumping straight to scale.
Reference Files
build-measure-learn.md
Detailed loop execution, reverse planning
mvp-design.md
MVP types, design patterns, sizing
assumptions.md
Leap-of-faith assumption mapping
innovation-accounting.md
Metric frameworks, dashboards
metrics.md
Actionable vs. vanity, cohort analysis, metric selection
pivots.md
Pivot types, decision frameworks, case studies
growth-engines.md
Sticky, viral, paid engines in depth
five-whys.md
Root cause analysis, facilitation guides
small-batches.md
Batch size reduction, continuous deployment
applications.md
SaaS, corporate innovation, features
case-studies.md
Dropbox, IMVU, Zappos, Groupon, and failures
Further Reading
This skill is based on Eric Ries' Lean Startup methodology. For the complete framework, research, and case studies:
"The Lean Startup"
by Eric Ries
"The Startup Way"
by Eric Ries (applying Lean Startup to established companies)
About the Author
Eric Ries
is an entrepreneur and author best known for developing the Lean Startup methodology. He was co-founder and CTO of IMVU, where he pioneered continuous deployment and customer development practices that became the foundation of Lean Startup.
The Lean Startup
has been translated into over 30 languages and has influenced startup culture worldwide. Ries is also the creator of the Long-Term Stock Exchange (LTSE), a new stock exchange designed for companies focused on long-term value creation.