返回技能列表

lean-startup

wondelai
更新于 Yesterday
2 次查看
1,096
121
1,096
在 GitHub 上查看
testingdesign

关于

This skill helps developers apply Lean Startup principles to design MVPs, run validated learning experiments, and make data-driven pivot-or-persevere decisions. It guides users through the Build-Measure-Learn loop, focusing on innovation accounting and actionable metrics over vanity metrics. Use it when scoping an MVP, testing assumptions, or evaluating product direction based on real progress.

快速安装

Claude Code

推荐
主要方式
npx skills add wondelai/skills -a claude-code
插件命令备选方式
/plugin add https://github.com/wondelai/skills
Git 克隆备选方式
git clone https://github.com/wondelai/skills.git ~/.claude/skills/lean-startup

在 Claude Code 中复制并粘贴此命令以安装该技能

技能文档

Lean Startup Methodology

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:

  1. What do we want to learn? (hypothesis to test)
  2. How will we know if we learned it? (metrics)
  3. 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:

LevelEvidenceStrength
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:

TypeWhat It IsWhen to UseExample
ConciergeManual service pretending to be automatedTest if solution is valuableFood on the Table (manual meal planning)
Wizard of OzFake automation, manual backendTest if automation is neededZappos (no inventory, bought shoes retail)
Smoke testLanding page + signup, no productTest demand before buildingDropbox video (explained concept, measured signups)
Single featureOne core feature onlyTest which feature is most valuableTwitter (just status updates)
PiecemealCombine existing toolsTest workflow before custom buildGroupon (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:

  1. Identify your business model's critical assumptions
  2. Prioritize by risk (which failure would be fatal?)
  3. Test the riskiest assumption first

Common leap-of-faith assumptions:

Assumption TypeQuestionTest Method
Value hypothesisDo customers care about this problem?Smoke test, concierge MVP
Growth hypothesisHow will customers discover us?Channel tests, referral experiments
Retention hypothesisWill customers come back?Cohort analysis, engagement metrics
Monetization hypothesisWill 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.

VanityWhy It's BadActionable Alternative
Total signupsAlways goes up, no context% signup → active (conversion rate)
Page viewsDoesn't indicate valueTime on page, bounce rate
Total usersIncludes inactive/churnedActive users (DAU, WAU, MAU)
DownloadsDoesn't mean usageDAU/downloads (activation rate)
RevenueWithout contextRevenue per cohort, LTV/CAC

Three characteristics of actionable metrics:

  1. Actionable: Clear cause-and-effect (can reproduce)
  2. Accessible: Simple, understandable by everyone
  3. 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 TypeWhat ChangesExample
Zoom-in pivotSingle feature becomes the whole productInstagram (photo filters from Burbn check-in app)
Zoom-out pivotProduct becomes a single featureFlickr (photo-sharing from Game Neverending)
Customer segmentSame problem, different customerGroupon (activism platform → local deals)
Customer needSame customer, different problemPotbelly Sandwich (antique store → sandwiches)
PlatformApp → Platform or Platform → AppYouTube (dating site → video platform)
Business architectureHigh margin, low volume ↔ Low margin, high volumeSalesforce (software → SaaS)
Value captureMonetization model changeAndroid (paid → free + app revenue)
Engine of growthViral, sticky, or paid growth modelFacebook (viral within colleges → paid advertising)
ChannelHow you reach customersSalesforce (direct sales → self-service)
TechnologyDifferent technology, same solutionApple (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.

3. Paid Engine of Growth

Mechanism: Spend money to acquire customers

Formula: LTV (Lifetime Value) > CAC (Customer Acquisition Cost)

Focus: Unit economics that allow reinvestment

Metrics:

  • CAC (cost per acquisition)
  • LTV (average revenue per customer)
  • LTV/CAC ratio (target: > 3x)
  • Payback period (how long to recoup CAC)

Examples: E-commerce, traditional businesses

Strategy: 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:

  1. A problem occurs (bug, outage, customer complaint)
  2. Ask "Why did this happen?" → Answer
  3. Ask "Why?" about that answer → Second answer
  4. Repeat 5 times until you reach the root cause
  5. Make proportional investments at each level

Example:

Problem: Website went down

  1. Why? Server ran out of memory
  2. Why? Memory leak in new feature
  3. Why? Code wasn't reviewed for memory management
  4. Why? No code review process for infrastructure changes
  5. 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 BatchSmall Batch
Build entire product, then launchLaunch landing page, then build
Release quarterlyRelease weekly or daily
Plan 12-month roadmapPlan 6-week cycles
Big bang rewriteIncremental 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

  1. Smoke test: Landing page + email list (validate demand)
  2. Concierge MVP: Manually deliver service to 10 customers (validate value)
  3. Single-feature MVP: Build one core workflow (validate engagement)
  4. Measure: Retention, NPS, feature usage
  5. Pivot or scale: Based on cohort data

Corporate Innovation

  1. Innovation accounting: Separate metrics from core business
  2. Protected teams: Shield from quarterly revenue pressure
  3. Metered funding: Unlock funding based on validated learning milestones
  4. Internal entrepreneurship: Treat team as startup within company

Product Features

  1. Feature flags: Deploy behind flag, test with small cohort
  2. A/B test: Measure impact on core metrics
  3. Kill, iterate, or scale: Based on data

See: references/applications.md for context-specific guides.

Common Mistakes

MistakeWhy It FailsFix
Building too muchWaste before validationTest with smoke test or concierge first
Asking customersPeople don't know/mispredictObserve behavior, not opinions
Vanity metricsFeel-good numbers, no decisionsTrack cohorts, conversion, retention
No hypothesisCan't learn if you don't predictWrite hypothesis before each experiment
Pivot too slowWaste runwaySet clear pivot criteria upfront
Skip innovation accountingCan't tell if you're improvingEstablish baseline, measure tuning efforts

Quick Diagnostic

Audit any product development plan:

QuestionIf NoAction
What's the riskiest assumption?You're building on shaky groundMap leap-of-faith assumptions
How will you test it?You're guessingDesign MVP to test assumption
What metric will validate/invalidate?You won't learnDefine actionable metrics
Can you test with less than this?You're over-buildingShrink MVP further
What will you do if the experiment fails?No pivot criteriaDefine 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

Further Reading

This skill is based on Eric Ries' Lean Startup methodology. For the complete framework, research, and case studies:

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.

GitHub 仓库

wondelai/skills
路径: lean-startup
0
agent-skillsai-skillsclaude-codeclaude-code-marketplaceclaude-code-pluginclaude-code-skills

相关推荐技能

content-collections

Content Collections 是一个 TypeScript 优先的构建工具,可将本地 Markdown/MDX 文件转换为类型安全的数据集合。它专为构建博客、文档站和内容密集型 Vite+React 应用而设计,提供基于 Zod 的自动模式验证。该工具涵盖从 Vite 插件配置、MDX 编译到生产环境部署的完整工作流。

查看技能

polymarket

这个Claude Skill为开发者提供完整的Polymarket预测市场开发支持,涵盖API调用、交易执行和市场数据分析。关键特性包括实时WebSocket数据流,可监控实时交易、订单和市场动态。开发者可用它构建预测市场应用、实施交易策略并集成实时市场预测功能。

查看技能

creating-opencode-plugins

该Skill帮助开发者创建OpenCode插件,用于接入命令、文件、LSP等25+种事件。它提供了插件结构、事件API规范和JavaScript/TypeScript实现模式,适合需要拦截操作、扩展功能或自定义事件处理的场景。开发者可通过它快速构建响应式模块来增强OpenCode AI助手的能力。

查看技能

sglang

SGLang是一个专为LLM设计的高性能推理框架,特别适用于需要结构化输出的场景。它通过RadixAttention前缀缓存技术,在处理JSON、正则表达式、工具调用等具有重复前缀的复杂工作流时,能实现极速生成。如果你正在构建智能体或多轮对话系统,并追求远超vLLM的推理性能,SGLang是理想选择。

查看技能