defi-naly

lean-startup

0
0
# Install this skill:
npx skills add defi-naly/skillbank --skill "lean-startup"

Install specific skill from multi-skill repository

# Description

Eric Ries's methodology for building products through validated learning and rapid iteration.

# SKILL.md


name: lean-startup
description: "Eric Ries's methodology for building products through validated learning and rapid iteration."

dimensions:
domain: [product-development, entrepreneurship, innovation, management]
phase: [idea-validation, mvp-building, growth, pivot-decision]
problem_type: [product-market-fit, hypothesis-testing, metrics, iteration]

contexts:
- situation: "have a product idea"
use_when: "need to validate before building; design experiments and MVPs"
- situation: "built something but no traction"
use_when: "deciding whether to pivot or persevere"
- situation: "measuring product success"
use_when: "distinguishing vanity metrics from actionable metrics"
- situation: "planning product roadmap"
use_when: "prioritizing experiments over features"
- situation: "startup is growing"
use_when: "choosing and optimizing engine of growth"

combines_with:
- zero-to-one # what to build (lean = how to validate it)
- founders-at-work # pattern recognition from successful pivots
- playing-to-win # strategy after finding product-market fit
- thinking-fast-and-slow # avoiding confirmation bias in experiments

contrast_with:
- skill: zero-to-one
distinction: "Lean Startup is PROCESS for validation; Zero to One is VISION for what's worth building"
- skill: playing-to-win
distinction: "Lean Startup is for uncertainty/discovery; Playing to Win is for established strategy execution"


The Lean Startup Framework

Core Philosophy

A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.

The fundamental problem: We build things nobody wants. Traditional planning fails because we can't predict the future in uncertain environments.

The solution: Treat every product decision as a hypothesis to be tested, not a feature to be built.

The Build-Measure-Learn Loop

        IDEAS
           │
           ▼
    ┌─────────────┐
    │    BUILD    │ ◄── Minimize time through the loop
    └─────────────┘
           │
           ▼
        PRODUCT
           │
           ▼
    ┌─────────────┐
    │   MEASURE   │ ◄── Actionable metrics, not vanity metrics
    └─────────────┘
           │
           ▼
         DATA
           │
           ▼
    ┌─────────────┐
    │    LEARN    │ ◄── Validated learning = progress
    └─────────────┘
           │
           ▼
        IDEAS

Goal: Minimize TOTAL time through the loop. Speed of learning determines success, not speed of building.

Validated Learning

The unit of progress for a startup is validated learning—demonstrated through empirical data that you've discovered something true about your customers.

Validated learning is:
- Backed by empirical data from real customers
- Demonstrated, not just believed
- Useful for building a sustainable business

Questions to answer:
1. Do customers recognize they have the problem?
2. If there was a solution, would they buy it?
3. Would they buy it from us?
4. Can we build a solution?

Minimum Viable Product (MVP)

The MVP is the version of the product that enables a full turn of the Build-Measure-Learn loop with minimum effort and minimum development time.

MVP Types

Type Description Best For
Landing Page Describe product, measure signups Testing demand
Video MVP Demo the concept (Dropbox style) Complex products
Concierge Manual delivery of automated service Testing value prop
Wizard of Oz Appears automated, humans behind scenes Testing UX
Piecemeal Existing tools stitched together Testing workflow
Single Feature One feature, done well Testing core value

MVP Rules

  1. Remove any feature that doesn't contribute to learning
  2. Ship faster than you're comfortable with
  3. Quality only matters where it affects learning
  4. If it doesn't have customers, it's not an MVP—it's a prototype

Common mistake: Building too much. If you're not embarrassed by v1, you launched too late.

Pivot or Persevere

A pivot is a structured course correction designed to test a new fundamental hypothesis about the product, strategy, or engine of growth.

When to Pivot

Signs you need to pivot:
- Experiments show diminishing effectiveness
- Product development becomes less productive
- General feeling that things should be further along

The pivot meeting: Regular meetings (monthly/quarterly) to ask:
- Are we making sufficient progress toward our vision?
- Is our hypothesis validated or invalidated?

Types of Pivots

Pivot Description Example
Zoom-in Single feature becomes whole product Flickr (gaming → photos)
Zoom-out Whole product becomes single feature
Customer Segment Same product, different customers
Customer Need Same customers, different problem
Platform Application → Platform or reverse
Business Architecture High margin/low volume ↔ low margin/high volume
Value Capture Change monetization model
Engine of Growth Viral ↔ Sticky ↔ Paid
Channel Change distribution mechanism
Technology Same solution, different tech

A pivot is NOT:
- Random change
- Giving up
- Starting over
- Just a "tweak"

A pivot IS:
- Strategic hypothesis change
- Keeping one foot planted (vision)
- Structured experimentation

Innovation Accounting

Traditional accounting doesn't work for startups. You need metrics that prove you're learning and building a sustainable business.

Three Learning Milestones

  1. Establish the baseline: Build MVP, measure current state
  2. Tune the engine: Experiments to improve metrics toward ideal
  3. Pivot or persevere: If metrics not improving, pivot

Actionable vs Vanity Metrics

Vanity Metrics Actionable Metrics
Total users Active users
Page views Conversion rate
Downloads Retention rate
"Hits" Revenue per user
Press mentions Customer acquisition cost
Features shipped Lifetime value

Test for actionable metrics:
- Can it change behavior?
- Is it accessible and understandable?
- Is it auditable (can we verify it's true)?

Cohort Analysis

Don't look at cumulative totals. Track cohorts (groups of users by time period) to see if metrics are actually improving.

         Signup │ Week 1 │ Week 2 │ Week 3 │ Week 4
         ───────┼────────┼────────┼────────┼────────
Jan cohort  100 │   40%  │   25%  │   20%  │   18%
Feb cohort  150 │   45%  │   30%  │   25%  │   22%  ◄── Are we improving?
Mar cohort  200 │   50%  │   35%  │   28%  │   ???

A/B Testing

Every feature is a hypothesis. Test it.

Rules:
- Test one variable at a time
- Ensure statistical significance
- Pre-define success criteria
- Don't peek early and declare victory

Engines of Growth

How startups achieve sustainable growth. Each requires different metrics and strategies.

1. Sticky Engine

Growth through retention. New customers exceed churned customers.

Growth Rate = New Customer Rate - Churn Rate

Focus on:
- Reducing churn
- Increasing engagement
- Building habits
- Switching costs

2. Viral Engine

Growth through customers recruiting more customers.

Viral Coefficient = Invites × Conversion Rate

If viral coefficient > 1, exponential growth. If < 1, growth stalls.

Focus on:
- Making sharing natural
- Reducing friction in referral
- Incentivizing both referrer and referred

3. Paid Engine

Growth through paid customer acquisition.

Sustainable if: Customer Lifetime Value > Customer Acquisition Cost

Focus on:
- Increasing LTV (upsells, retention, price)
- Decreasing CAC (better targeting, conversion)
- Optimizing channels

Small Batches

Work in the smallest batches possible.

Benefits:
- Problems detected earlier
- Less wasted work when pivoting
- Faster learning cycles
- Reduced risk

Example: Instead of spending 6 months building, spend 2 weeks on MVP, learn, iterate.

The Five Whys

Root cause analysis for problems. Ask "Why?" five times.

Problem: Customers are churning
Why? → They don't use the product after signup
Why? → They don't understand how to use it
Why? → Onboarding is confusing
Why? → We added features without updating onboarding
Why? → No process to update onboarding with new features

Fix the root cause, not the symptom.

Rule: Make proportional investment. Small problem = small fix. Big problem = big fix.

Lean Startup in Practice

Before Building Anything

  1. State your hypothesis explicitly
  2. "We believe [customer segment] has [problem]"
  3. "We believe [solution] will solve [problem]"
  4. "We'll know we're right when we see [metric]"

  5. Define your riskiest assumption

  6. What must be true for this to work?
  7. What's the biggest unknown?

  8. Design the minimum experiment to test it

  9. What's the fastest way to learn?
  10. What can we NOT build?

During Development

  • Track actionable metrics, not vanity metrics
  • Run experiments, not just build features
  • Use cohort analysis to measure true progress
  • Have regular pivot-or-persevere meetings

Decision Framework

┌─────────────────────────────────────────────────────┐
│              Is this a leap-of-faith assumption?     │
└─────────────────────────────────────────────────────┘
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
             YES                      NO
              │                       │
              ▼                       ▼
     Design experiment          Just build it
     to test assumption         (low risk)
              │
              ▼
     Build smallest possible MVP
              │
              ▼
     Measure with actionable metrics
              │
              ▼
     Learn: Was hypothesis validated?
              │
         ┌────┴────┐
         ▼         ▼
        YES        NO
         │         │
         ▼         ▼
     Continue    Pivot

Key Mantras

Mantra Meaning
"Get out of the building" Talk to customers, don't guess
"Build to learn, not to scale" MVP purpose is learning
"Fail fast" Quick small failures beat slow big ones
"Optimize for learning" Speed of learning = competitive advantage
"Revenue is vanity, profit is sanity, cash is king" But learning precedes all

# Supported AI Coding Agents

This skill is compatible with the SKILL.md standard and works with all major AI coding agents:

Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.