lean-startup
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseLean 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.
目标：10/10。 在评审或制定产品开发计划、实验或指标时，根据对精益创业原则的遵循程度，从0到10分进行评分。10分意味着完全应用了Build-Measure-Learn循环、验证性学习和基于证据的决策；较低的分数则表示存在瀑布式思维或资源浪费。评分时需给出当前分数，以及达到10分所需的具体改进措施。
The Build-Measure-Learn Loop
Build-Measure-Learn循环
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.
精益创业的核心循环：
想法
↓
构建 → 产品
↓
衡量 → 数据
↓
学习 → 知识
↓
（回到想法）关键洞见： 这个循环实际上是反向的。先明确你想要学习的内容，确定能够为学习提供信息的指标，然后构建最小可行产品来收集这些指标数据。
反向规划步骤：
- 我们想要学习什么？（需要测试的假设）
- 如何判断我们是否学到了？（对应的指标）
- 我们可以构建的最小版本是什么？（MVP）
目标： 尽可能缩短整个循环的时间。
详情请见：references/build-measure-learn.md
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.
定义： 通过经过验证的实验来了解客户的真实需求，而非依赖观点或轶事。
验证性学习不是：
- 构建客户要求的功能（他们往往不知道自己真正想要什么）
- 达成虚荣指标（如下载量、注册量但无实际参与度）
- 做调查或焦点小组（人们可能会说谎或错误预测自己的行为）
验证性学习是：
- 用真实行为测试假设
- 衡量客户的实际行动，而非他们的口头表述
- 开展可能推翻你假设的实验
- 学习意味着你的预测被证明是错误的
验证阶梯：
| 层级 | 证据 | 可信度 |
|---|---|---|
| 1 | “我认为客户想要这个” | 最弱（主观观点） |
| 2 | “客户说他们想要这个” | 较弱（口头偏好） |
| 3 | “客户注册了早期访问权限” | 中等（低承诺） |
| 4 | “客户支付了定金” | 较强（真实承诺） |
| 5 | “客户正在积极使用产品” | 最强（实际偏好） |
目标： 在大规模构建之前达到4-5级可信度。
Minimum Viable Product (MVP)
最小可行产品（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.
定义： 新产品的一个版本，能够让团队用最少的精力收集最多的验证性学习信息。
MVP不是：
- 原型（不是为了证明技术可行性）
- Beta版本（不是为了质量或功能完整性）
- 最小可市场化产品（可能看起来很简陋）
MVP是：
- 一种学习工具
- 测试假设的最小实验
- 通常比你想象的要小得多
MVP类型：
| 类型 | 定义 | 使用场景 | 示例 |
|---|---|---|---|
| 礼宾式MVP | 伪装成自动化服务的人工服务 | 测试解决方案是否有价值 | Food on the Table（人工制定餐食计划） |
| 绿野仙踪式MVP | 虚假的自动化，后端由人工操作 | 测试是否需要自动化 | Zappos（无库存，从零售商处采购鞋子） |
| 烟雾测试MVP | 仅包含着陆页和注册功能，无实际产品 | 在构建前测试需求 | Dropbox视频（解释产品概念，衡量注册量） |
| 单功能MVP | 仅包含一个核心功能 | 测试哪个功能最有价值 | Twitter（仅支持状态更新） |
| 拼凑式MVP | 组合现有工具 | 在定制开发前测试工作流程 | Groupon（WordPress+邮件） |
MVP设计问题：
- 最具风险的假设是什么，需要先测试？
- 测试该假设的最小投入是什么？
- 如何衡量假设是否得到验证？
常见误区：
- 构建过多功能（高估MVP的规模）
- 过早优化可扩展性
- 将质量与学习混淆（MVP可以是低质量的）
- 跳过实验环节（无假设就直接构建）
详情请见：references/mvp-design.md
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.
定义： 如果这些假设被证明是错误的，你的业务就会失败。
流程：
- 识别商业模式的关键假设
- 按风险优先级排序（哪个假设失败会导致业务崩盘？）
- 先测试风险最高的假设
常见的信仰跳跃式假设：
| 假设类型 | 问题 | 测试方法 |
|---|---|---|
| 价值假设 | 客户是否关心这个问题？ | 烟雾测试、礼宾式MVP |
| 增长假设 | 客户如何发现我们？ | 渠道测试、推荐实验 |
| 留存假设 | 客户会回头使用产品吗？ | 群组分析、参与度指标 |
| 变现假设 | 客户愿意付费吗？ | 预售、定价测试 |
示例：Dropbox
- 信仰跳跃式假设： “人们会下载并使用文件同步工具”
- 测试方法： 发布解释产品概念的视频（在构建完整版本之前）
- 指标： Beta版注册列表一夜之间从5000人增长到75000人
- 学习成果： 在构建规模化基础设施之前验证了需求
反模式： 按难易程度而非风险优先级测试假设。
详情请见：references/assumptions.md
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:
定义： 在传统会计方法不适用的情况下衡量进展。
传统指标的问题：
- 收入（创业公司初始收入为0）
- 客户数量（创业公司初始客户为0）
- 虚荣指标（看起来不错，但无法指导决策）
创新会计框架：
1. Establish the Baseline
1. 建立基准
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.
问题： 我们当前处于什么状态？
衡量当前的实际情况，即使数据为0或看起来很糟糕。
需要建立的指标：
- 转化漏斗（注册→活跃→留存→付费）
- 参与度（日活/月活、会话时长、功能使用情况）
- 经济指标（客户获取成本CAC、客户生命周期价值LTV、流失率）
目标： 精准了解你的起点。
2. Tune the Engine
2. 优化引擎
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.
问题： 我们可以改进什么来接近目标？
开展实验以优化基准指标。
示例：
- A/B测试定价（9美元/月 vs 19美元/月）
- 测试引导流程（完成设置的用户比例）
- 渠道实验（SEO vs 付费广告 vs 推荐）
目标： 通过验证性学习系统性地改进指标。
3. Pivot or Persevere
3. 转型或坚持
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.
问题： 我们是否在取得足够的进展，还是需要改变策略？
基于数据决定是继续当前方向还是转型。
判断标准：
- 指标是否在朝着正确的方向发展？
- 改进的速度是否可接受？
- 我们是否获得了预期的学习成果？
目标： 做出基于证据的战略决策。
详情请见：references/innovation-accounting.md
Actionable vs. Vanity Metrics
可行动指标 vs 虚荣指标
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.
虚荣指标： 让你感觉良好，但无法指导行为改变。
可行动指标： 能够驱动决策，明确因果关系。
| 虚荣指标 | 问题所在 | 可替代的可行动指标 |
|---|---|---|
| 总注册量 | 只会增长，没有上下文 | 注册→活跃转化率 |
| 页面浏览量 | 无法体现价值 | 页面停留时间、跳出率 |
| 总用户数 | 包含不活跃/流失用户 | 活跃用户数（日活、周活、月活） |
| 下载量 | 不代表实际使用 | 日活/下载量（激活率） |
| 总收入 | 缺乏上下文 | 群组收入、LTV/CAC比值 |
可行动指标的三个特征：
- 可行动性： 明确的因果关系（可重复验证）
- 可理解性： 简单易懂，全员能掌握
- 可审计性： 可核查底层数据（不是黑箱）
示例：
- 虚荣表述： “我们有10万用户！”
- 可行动表述： “来自渠道X的用户留存率是渠道Y的2倍。我们应该加大对渠道X的投入。”
群组分析： 按注册日期对用户分组，跟踪他们随时间的行为变化。能揭示产品是否真的在改进。
详情请见：references/metrics.md
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.
转型： 一种结构化的方向调整，旨在测试关于产品、策略或增长引擎的新假设。
何时转型：
- 实验持续无法验证假设
- 经过多次迭代后指标仍停滞不前
- 客户反馈与你的愿景矛盾
- 相对于可用资金，进展过于缓慢
何时坚持：
- 指标正在改善（即使速度缓慢）
- 明确的学习成果正在产生
- 调整措施朝着正确的方向发展
转型类型：
| 转型类型 | 变更内容 | 示例 |
|---|---|---|
| 聚焦转型 | 单个功能成为整个产品 | Instagram（从Burbn签到应用中剥离出滤镜功能） |
| 拓展转型 | 产品成为更大产品的一个功能 | Flickr（从Game Neverending游戏中剥离出照片分享功能） |
| 客户群体转型 | 解决相同问题，但面向不同客户 | Groupon（从激进主义平台转型为本地优惠平台） |
| 客户需求转型 | 面向相同客户，但解决不同问题 | Potbelly Sandwich（从古董店转型为三明治店） |
| 平台转型 | 应用→平台 或 平台→应用 | YouTube（从约会网站转型为视频平台） |
| 业务架构转型 | 高利润低产量 ↔ 低利润高产量 | Salesforce（从软件许可转型为SaaS） |
| 价值获取转型 | 变现模式变更 | Android（从付费转为免费+应用收入） |
| 增长引擎转型 | 病毒式、粘性或付费增长模式切换 | Facebook（从校园内病毒式增长转型为付费广告） |
| 渠道转型 | 客户触达方式变更 | Salesforce（从直销转型为自助服务） |
| 技术转型 | 采用不同技术实现相同解决方案 | Apple（从Intel芯片转为ARM芯片） |
转型频率： 许多成功的创业公司在找到产品-市场契合点之前会转型1-5次。
反模式： 没有验证新方向能解决核心问题就“盲目转型”。
详情请见：references/pivots.md
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
1. 粘性增长引擎
Mechanism: High retention, low churn
Formula:
Growth rate = New customer acquisition rate - Churn rateFocus: 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.
机制： 高留存率，低流失率
公式：
增长率 = 新客户获取率 - 流失率重点： 让客户持续回头使用
指标：
- 流失率（每月停止使用的用户比例）
- 留存群组（30/60/90天后仍活跃的用户比例）
- 参与度（日活/月活比值）
示例： SaaS、订阅服务、社交网络
策略： 改进产品直到流失率足够低，自然增长超过流失率。
2. Viral Engine of Growth
2. 病毒式增长引擎
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.
机制： 客户带来其他客户
公式：
病毒系数 = （邀请他人的用户比例） × （发送的邀请数） × （接受邀请的比例）重点： 病毒系数>1.0即可实现指数级增长
指标：
- 病毒系数（邀请→注册转化率）
- 病毒周期时间（被推荐用户发出邀请所需的时间）
- 推荐来源归因
示例： Dropbox、Hotmail、WhatsApp
策略： 将病毒式传播内置到产品中。病毒系数必须>1.0才能自我维持。
3. Paid Engine of Growth
3. 付费增长引擎
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.
机制： 花钱获取客户
公式：
客户生命周期价值（LTV） > 客户获取成本（CAC）重点： 单位经济模型允许持续再投资
指标：
- CAC（客户获取成本）
- LTV（平均客户收入）
- LTV/CAC比值（目标：>3倍）
- 回收期（收回CAC所需的时间）
示例： 电商、传统企业
策略： 优化到每个客户产生的利润足以获取更多客户。
警告： 不要同时使用多个增长引擎。先选一个，优化到极致，再考虑添加其他引擎。
详情请见：references/growth-engines.md
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.
目的： 根本原因分析，防止问题再次发生。
流程：
- 问题发生（bug、宕机、客户投诉）
- 问“为什么会发生这种情况？”→ 得到答案
- 针对这个答案再次问“为什么？”→ 得到第二个答案
- 重复5次，直到找到根本原因
- 在每个层面进行相应的投入
示例：
问题： 网站宕机
- 为什么？ 服务器内存耗尽
- 为什么？ 新功能存在内存泄漏
- 为什么？ 代码未经过内存管理审查
- 为什么？ 基础设施变更没有代码审查流程
- 为什么？ 团队推进速度太快，没时间建立流程
相应的投入：
- 修复当前bug（第1层）
- 添加内存监控（第2层）
- 实施代码审查（第3-4层）
- 放慢速度，建立质量流程（第5层）
反模式： 停留在第1层（只修复表面症状）。
详情请见：references/five-whys.md
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.
原则： 以小批量方式工作，加速学习并减少浪费。
小批量的优势：
- 更快的反馈循环
- 更容易转型
- 当你出错时浪费更少
- 更快的上市时间
示例：
| 大批量工作 | 小批量工作 |
|---|---|
| 构建完整产品后再发布 | 先发布着陆页，再逐步构建 |
| 按季度发布 | 每周或每日发布 |
| 制定12个月路线图 | 制定6周周期计划 |
| 一次性重写 | 增量重构 |
持续部署： 终极小批量 = 每次代码提交都部署。
好处：
- 漏洞能立即被发现
- 学习持续进行
- 每次部署的风险降低
详情请见：references/small-batches.md
Lean Startup Applied
精益创业的应用
For different contexts:
不同场景下的应用：
SaaS Startup
SaaS创业公司
- 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
- 烟雾测试： 着陆页+邮件列表（验证需求）
- 礼宾式MVP： 为10位客户人工提供服务（验证价值）
- 单功能MVP： 构建一个核心工作流程（验证参与度）
- 衡量： 留存率、净推荐值（NPS）、功能使用情况
- 转型或规模化： 基于群组数据决策
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.
- 功能开关： 在功能开关后部署，小范围测试
- A/B测试： 衡量对核心指标的影响
- 淘汰、迭代或规模化： 根据数据决策
详情请见：references/applications.md
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 |
| 误区 | 失败原因 | 解决方案 |
|---|---|---|
| 构建过多功能 | 在验证前造成浪费 | 先通过烟雾测试或礼宾式MVP进行测试 |
| 询问客户需求 | 人们不知道或错误预测自己的需求 | 观察行为，而非依赖观点 |
| 使用虚荣指标 | 产生自我满足的数字，但无法指导决策 | 跟踪群组、转化、留存指标 |
| 无假设就实验 | 没有预测就无法学习 | 在每次实验前写下假设 |
| 转型过慢 | 浪费可用资金 | 提前设定明确的转型触发条件 |
| 跳过创新会计 | 无法判断是否在进步 | 建立基准，衡量优化效果 |
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 |
审核任何产品开发计划：
| 问题 | 如果答案为否 | 行动 |
|---|---|---|
| 最具风险的假设是什么？ | 你的构建基础不稳固 | 梳理信仰跳跃式假设 |
| 你将如何测试它？ | 你在凭猜测行事 | 设计MVP来测试假设 |
| 什么指标能验证/推翻假设？ | 你无法获得学习成果 | 定义可行动指标 |
| 你能用更少的投入测试吗？ | 你构建得太多了 | 进一步缩小MVP范围 |
| 如果实验失败，你会怎么做？ | 没有转型标准 | 提前定义转型触发条件 |
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.
阶段1：问题/解决方案契合
- 目标： 验证问题存在且客户关心
- 方法： 客户探索、烟雾测试、礼宾式MVP
- 指标： 客户愿意付费或做出承诺
阶段2：产品/市场契合
- 目标： 构建客户真正想要的产品
- 方法： 构建MVP，基于使用数据迭代
- 指标： 高留存率、自然增长、高参与度
阶段3：规模化
- 目标： 高效增长
- 方法： 优化增长引擎，改进单位经济模型
- 指标： 可持续、盈利性增长
反模式： 跳过阶段1-2直接进入规模化。
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
- build-measure-learn.md: 循环执行细节、反向规划
- mvp-design.md: MVP类型、设计模式、规模确定
- assumptions.md: 信仰跳跃式假设梳理
- innovation-accounting.md: 指标框架、仪表盘
- metrics.md: 可行动vs虚荣指标、群组分析、指标选择
- pivots.md: 转型类型、决策框架、案例研究
- growth-engines.md: 粘性、病毒式、付费增长引擎详解
- five-whys.md: 根本原因分析、引导指南
- small-batches.md: 批量规模缩减、持续部署
- applications.md: SaaS、企业创新、产品功能
- case-studies.md: Dropbox、IMVU、Zappos、Groupon及失败案例
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.
Eric Ries 是一位企业家和作家，以开发精益创业方法论而闻名。他是IMVU的联合创始人兼CTO，在那里他开创了持续部署和客户开发实践，这些实践成为了精益创业的基础。《精益创业》已被翻译成30多种语言，影响了全球的创业文化。Ries还是长期股票交易所（LTSE）的创始人，这是一个为专注于长期价值创造的公司设计的新型证券交易所。
Overview
概述
Design MVPs, validated learning experiments, and pivot-or-persevere decisions using Build-Measure-Learn.
使用Build-Measure-Learn循环设计MVP、验证性学习实验，以及制定转型或坚持的决策。
Prerequisites
前提条件
- Access to the testing environment or API
- Required CLI tools installed and authenticated
- Familiarity with testing concepts and terminology
- 可访问测试环境或API
- 已安装并认证所需的CLI工具
- 熟悉测试概念和术语
Instructions
操作步骤
- Assess the current state of the testing configuration
- Identify the specific requirements and constraints
- Apply the recommended patterns from this skill
- Validate the changes against expected behavior
- Document the configuration for team reference
- 评估当前测试配置的状态
- 识别具体需求和约束
- 应用本方法中的推荐模式
- 根据预期行为验证变更
- 记录配置供团队参考
Output
输出
- Configuration files or code changes applied to the project
- Validation report confirming correct implementation
- Summary of changes made and their rationale
See testing implementation details for output format specifications.
- 应用于项目的配置文件或代码变更
- 确认正确实施的验证报告
- 变更内容及其理由的总结
详情请见测试实施细节
Error Handling
错误处理
| Error | Cause | Resolution |
|---|---|---|
| Authentication failure | Invalid or expired credentials | Refresh tokens or re-authenticate with testing |
| Configuration conflict | Incompatible settings detected | Review and resolve conflicting parameters |
| Resource not found | Referenced resource missing | Verify resource exists and permissions are correct |
| 错误 | 原因 | 解决方案 |
|---|---|---|
| 认证失败 | 凭据无效或过期 | 刷新令牌或重新进行测试认证 |
| 配置冲突 | 检测到不兼容的设置 | 审查并解决冲突参数 |
| 资源未找到 | 引用的资源缺失 | 验证资源存在且权限正确 |
Examples
示例
Basic usage: Apply lean startup to a standard project setup with default configuration options.
Advanced scenario: Customize lean startup for production environments with multiple constraints and team-specific requirements.
基础用法: 将精益创业应用于标准项目设置，使用默认配置选项。
高级场景: 针对生产环境定制精益创业方法，满足多个约束和团队特定需求。
Resources
资源
- Official testing documentation
- Community best practices and patterns
- Related skills in this plugin pack
- 官方测试文档
- 社区最佳实践和模式
- 本插件包中的相关方法