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类型：
| 类型 | 定义 | 适用场景 | 示例 |
|---|---|---|---|
| 礼宾式 | 伪装成自动化服务的人工服务 | 测试解决方案是否有价值 | Food on the Table（人工制定餐食计划） |
| 绿野仙踪式 | 虚假自动化，后端人工操作 | 测试是否需要自动化 | Zappos（无库存，从零售商处购买鞋子） |
| 烟雾测试 | 着陆页+注册，无实际产品 | 在构建前测试需求 | Dropbox视频（解释概念，衡量注册量） |
| 单一功能 | 仅保留一个核心功能 | 测试哪个功能最有价值 | Twitter（仅状态更新） |
| 拼凑式 | 整合现有工具 | 在定制开发前测试工作流 | 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 |
| 增长假设 | 客户如何发现我们？ | 渠道测试、推荐实验 |
| 留存假设 | 客户会回头吗？ | 群组分析、参与度指标 |
| ** monetization假设** | 客户会付费吗？ | 预购、定价测试 |
示例：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.
问题： 我们现在处于什么阶段？
衡量当前现状，即使是零或不尽如人意的状态。
需要建立的指标：
- 转化漏斗（注册→活跃→留存→付费）
- 参与度（日活/月活、会话时长、使用的功能）
- 经济性（客户获取成本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.
转型（Pivot）： 结构化的方向调整，旨在测试关于产品、策略或增长引擎的新假设。
何时转型：
- 实验持续无法验证假设
- 多次迭代后指标仍停滞不前
- 客户反馈与你的愿景矛盾
- 进展过慢，消耗过多资金
何时坚持：
- 指标在改善（即使缓慢）
- 有明确的学习成果
- 调整措施朝着正确方向发展
转型类型：
| 转型类型 | 变更内容 | 示例 |
|---|---|---|
| 放大转型 | 单一功能成为整个产品 | 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、 outage、客户投诉）
- 问“为什么会发生？”→ 答案
- 针对该答案问“为什么？”→ 第二个答案
- 重复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周周期计划 |
| 大规模重写 | 增量重构 |
持续部署： 终极小批量=每次代码提交都部署。
好处：
- 立即发现bug
- 持续学习
- 每次部署的风险降低
详情请见：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）的创始人，这是一个为关注长期价值创造的公司设计的新型证券交易所。