lean-startup

精益创业方法论

一种系统化的创业和新产品发布方法，能够缩短开发周期，并快速验证商业模式是否可行。

核心原则

创业是一种管理方式。 成功不需要完美的计划或卓越的洞见，而需要一套系统化流程来验证假设、向客户学习并快速迭代。大多数创业公司失败，并非因为无法打造计划中的产品，而是因为打造了错误的产品：将每份计划都视为一组有待证伪的假设，并投入精力消除浪费、加快经验证的学习，而不是执行一份固定的路线图。

评分

目标：10/10。 根据五项快速诊断指标为计划、实验或指标集打分：回答为“是”得1 分，若还有验证阶梯（第 3 级及以上）的证据支持，则得2 分：

• 9-10： 列出所有重大假设并按风险排序，用真实的 MVP 测试风险最高的假设，定义可执行的指标，并在构建前设定明确的转向标准。
• 5-6： 有假设，也有一些 MVP，但指标只是虚荣指标，或未定义转向标准——无法依据数据做出决策。
• ≤3： 瀑布式思维——先构建完整产品、询问客户想要什么，或在达到产品/市场契合之前就扩大规模。

说明当前得分，以及下一步需要改进的最低分诊断指标。

构建-衡量-学习循环

基本循环：想法 → 构建（产品）→ 衡量（数据）→ 学习（知识）→ 回到想法。

关键见解： 反向规划这个循环：

1. 我们想要学到什么？（待测试的假设）
2. 如何判断是否学到了？（指标）
3. 我们能构建的最小方案是什么？（MVP）

目标： 尽量缩短整个循环所需的时间。

规划实验时，请参阅 references/build-measure-learn.md，其中包含反向规划步骤、实验设计模板、按产品类型划分的循环示例，以及构建和虚荣指标循环的陷阱。

经验证的学习

通过针对真实行为开展实验，了解客户真正想要什么，而不是依赖功能请求、调查或焦点小组（人们往往无法准确预测自己的行为）。衡量客户做了什么，而不是说了什么，并开展能够证伪假设的实验。虚荣指标上的胜利（下载量、注册量，但没有参与度）并不代表学到了东西。

验证阶梯：

级别	证据	强度
1	“我认为客户想要这个”	最弱（个人观点）
2	“客户说他们想要这个”	弱（口头表达的偏好）
3	“客户注册了抢先体验”	中等（承诺较低）
4	“客户支付了定金”	强（真实承诺）
5	“客户正在积极使用它”	最强（显露出的偏好）

目标： 在大规模构建之前达到第 4-5 级。

最小可行产品（MVP）

一种新产品的版本，用最少的投入实现最大程度的验证式学习。它不是原型（验证技术可行性），不是 Beta 版（验证质量），也不是最小可营销产品，而是一种学习载体，往往小得令人难堪、质量不高，通常也比你想象的要小得多。

MVP 类型：

类型	定义	适用场景	示例
礼宾式	假装自动化的人工服务	测试解决方案是否有价值	Food on the Table（人工规划膳食）
绿野仙踪式	表面自动化，后台人工处理	测试是否需要自动化	Zappos（没有库存，从零售商处买鞋）
烟雾测试	着陆页 + 注册入口，没有产品	在开发前测试需求	Dropbox 视频（讲解概念，衡量注册量）
单一功能	只提供一项核心功能	测试哪项功能最有价值	Twitter（只有状态更新）
拼凑式	组合现有工具	在定制开发前测试工作流	Groupon（WordPress + 电子邮件）

**设计问题：**风险最大的假设是什么？验证它所需的最小方案是什么？我们如何衡量它是否得到验证？

在选择和确定 MVP 规模时，请参阅 references/mvp-design.md——其中深入介绍七种类型、类型选择决策矩阵、规模上下限，以及 MVP 设计画布。

孤注一掷的假设

一旦这些假设不成立，你的业务就会失败。找出这些假设，按风险排序（哪种失败会造成致命后果？），并优先测试风险最高的假设——绝不要按测试难易程度排序。

假设类型	问题	测试方法
价值假设	客户在意这个问题吗？	烟雾测试、礼宾式 MVP
增长假设	客户会如何发现我们？	渠道测试、推荐实验
留存假设	客户会再次使用吗？	群组分析、参与度指标
变现假设	客户愿意付费吗？	预购、定价测试

**示例——Dropbox：**孤注一掷的假设：“人们会下载并使用文件同步工具。”测试：在构建大规模基础设施前发布讲解视频。结果：Beta 名单一夜之间从 5,000 人增至 75,000 人，需求得到验证。

在梳理和评估假设时，请参阅 references/assumptions.md——其中包括影响—不确定性矩阵、优先级评分模板、各类假设的测试方法，以及行业特定的假设列表。

创新核算

当传统指标失效时，用来衡量进展的方法：收入和客户数都从零起步，而虚荣指标看似漂亮，却无法推动决策。

1. 建立基线

精确衡量当前情况，即使数据为零或令人难堪：转化漏斗（注册 → 活跃 → 留存 → 付费）、参与度（DAU/MAU、会话时长、使用的功能）、经济指标（CAC、LTV、流失率）。

2. 调整引擎

通过实验改善基线指标：A/B 测试定价（每月 9 美元与 19 美元）、新手引导完成率、获客渠道（SEO 与付费推广、推荐）。每项实验都通过验证式学习，致力于实现可衡量的改进。

3. 转型或坚持

当调整陷入停滞时，根据证据作出判断（标准和转型类型见下文 转型或坚持）。

在构建基线仪表板时，请参阅 references/innovation-accounting.md——其中介绍漏斗、群组和经济指标框架。

可执行指标与虚荣指标

虚荣指标让你感觉良好，却不会改变行为；可执行指标能推动决策，并明确因果关系。

虚荣指标	为什么不好	可执行的替代指标
注册总数	总是在增长，缺乏背景信息	注册用户 → 活跃用户的转化率
页面浏览量	无法体现价值	页面停留时间、跳出率
用户总数	包含不活跃用户和已流失用户	活跃用户（DAU、WAU、MAU）
下载量	不代表实际使用	DAU/下载量（激活率）
收入	缺乏背景信息	每个群组的收入、LTV/CAC

可执行指标的三项特征： 可执行（因果关系明确、可复现）、易于获取（简单易懂，人人都能理解）、可审计（可以核查底层数据）。

示例： 虚荣指标：“我们有 100,000 名用户！”可执行指标：“渠道 X 用户的留存率是渠道 Y 的 2 倍——加倍投入 X。”

群组分析： 按注册日期对用户分组，并跟踪他们随时间变化的行为——这是判断产品是否真正有所改进的唯一方法。

构建群组表或选择跟踪指标时，请参阅 references/metrics.md：其中包含五步群组分析演练，以及与精益创业阶段相对应的 AARRR（海盗指标）。

转型还是坚持

转型是有计划的方向调整，旨在验证关于产品、战略或增长引擎的新假设。

适合转型的情况： 实验反复无法验证假设；经过多轮迭代，指标仍然持平；客户反馈与愿景相矛盾；或者相对于资金储备，可用的进展时间太短。适合坚持的情况： 指标正在改善（即使速度缓慢）；确实有所收获；调整方向正确。

转型类型：

转型类型	变化内容	示例
聚焦式	单一功能成为完整产品	Instagram（从 Burbn 的照片滤镜发展而来）
扩展式	产品成为单一功能	Flickr（从 Game Neverending 的照片分享功能发展而来）
客户细分	同一问题，不同客户	Groupon（行动主义平台 → 本地优惠）
客户需求	同一客户，不同问题	Potbelly（古董店 → 三明治）
平台	应用 ↔ 平台	YouTube（约会网站 → 视频平台）
商业架构	高毛利/低销量 ↔ 低毛利/高销量	Salesforce（软件 → SaaS）
价值获取	变更变现模式	Android（付费 → 免费 + 应用收入）
增长引擎	病毒式、黏性或付费模式	Facebook（在大学校园病毒式传播 → 付费广告）
渠道	触达客户的方式	Salesforce（直销 → 自助服务）
技术	技术不同，解决方案相同	Apple（Intel → ARM 芯片）

转型频率： 成功的初创公司在实现产品市场契合之前，通常会转型 1-5 次。反模式： 尚未验证新方向能否解决核心问题就贸然“转型”。

当数据表明可能需要转型时，请参阅 references/pivots.md：其中介绍了数据驱动的转型信号、结构化的转型会议议程、领先指标，以及 Instagram、Slack 和 YouTube 的转型故事。

三种增长引擎

初创公司如何持续获客并留住客户。选定一种增长引擎并将其优化，然后再考虑增加其他引擎——同时运行多个引擎会分散注意力，也会削弱学习效果。

1. 黏性增长引擎

由留存驱动：增长率 = 新客户获取率 − 流失率。跟踪流失率、留存群组（30/60/90 天）和 DAU/MAU。适用于 SaaS、订阅服务和社交网络。策略：持续改进产品，直到自然增长超过流失率。

2. 病毒式增长引擎

客户带来客户：viral coefficient = (% who invite) × (invites sent) × (% who join)；高于 1.0 意味着指数级、自我持续的增长。跟踪该系数、病毒传播周期和推荐归因。适用于 Dropbox、Hotmail、WhatsApp。策略：将病毒传播融入产品本身。

3. 付费增长引擎

付费获客：要求 LTV > CAC（目标 LTV/CAC > 3x）。跟踪 CAC、LTV 和回本周期。适用于电商和传统企业。策略：持续优化，直到每位客户带来的利润足以支持获取更多客户。

选择或调整增长引擎时，请参阅 references/growth-engines.md，其中涵盖降低流失率的策略、K 因子和病毒式循环设计、LTV/CAC 优化、渠道经济效益表，以及产品与引擎匹配框架。

五个为什么

根因分析：问题出现时，连续问五次“为什么？”，然后在每个层级按比例投入资源，而不只是处理症状。

示例——网站宕机：

1. 为什么？ 服务器内存耗尽
2. 为什么？ 新功能存在内存泄漏
3. 为什么？ 代码审查时没有检查内存管理
4. 为什么？ 基础设施变更没有代码审查流程
5. 为什么？ 团队推进太快，没有建立流程

按比例投入资源： 修复缺陷（1），添加内存监控（2），实施代码审查（3-4），放慢速度以建立质量流程（5）。反模式： 止步于第 1 层。

主持研讨时，请参阅 references/five-whys.md，其中包含三个完整示例（服务中断、流失率激增、发布失败），以及如何处理分叉的追问链、归咎倾向和超出控制范围的根因。

小批量

采用小批量工作，可加快反馈循环、更轻松地调整方向、在判断错误时减少浪费，并缩短上市时间。

大批量	小批量
构建完整产品后再发布	先发布落地页，再构建产品
每季度发布	每周或每天发布
规划 12 个月路线图	规划 6 周周期
一次性彻底重写	渐进式重构

持续部署是终极的小批量实践：每次提交都部署，立即发现缺陷，持续学习，并降低每次发布的风险。

设置更快的发布节奏时，请参阅 references/small-batches.md，其中涵盖持续部署流水线及其前提条件、功能标志类型、渐进式发布检查清单和工作拆解技巧。

精益创业实践：从创意到规模化

阶段 1——问题／解决方案匹配： 通过客户探索、烟雾测试和礼宾式 MVP，验证问题是否存在以及客户是否在意。指标：愿意付费或作出承诺的客户。

阶段 2——产品／市场匹配： 构建 MVP，并根据使用数据反复迭代。指标：高留存率、有机增长和强参与度。

阶段 3——规模化： 优化增长引擎和单位经济效益。指标：可持续且盈利的增长。反模式： 跳过阶段 1-2，直接进入规模化。

按情境划分：

• SaaS 初创公司： 烟雾测试（落地页 + 邮件列表）→ 为 10 位客户提供礼宾式 MVP → 单一功能 MVP → 衡量留存率、NPS 和功能使用情况 → 根据群组数据调整方向或扩大规模
• 企业创新： 将创新核算与核心业务指标分开，保护团队免受季度营收压力影响，根据经验证的学习里程碑逐步解锁资金
• 产品功能： 在功能标志后部署 → 针对核心指标进行 A/B 测试 → 根据数据决定终止、迭代或扩大规模

需要按具体情境制定方案时，请参阅 references/applications.md（SaaS、企业创新、产品功能）；需要为当前决策寻找完整先例时，请参阅 references/case-studies.md，了解 Dropbox、IMVU、Zappos 和 Groupon 的完整案例，包括失败经历。

常见错误

错误	失败原因	修正方法
构建过多	验证前就浪费资源	先通过冒烟测试或礼宾式服务进行测试
询问客户	人们并不了解或会误判	观察行为，而非观点
虚荣指标	数字看起来令人欣慰，却无法指导决策	跟踪群组、转化率和留存率
没有假设	不做预测就无法学习	每次实验前先写下假设
转向太慢	浪费时间和资金储备	预先设定明确的转向标准
跳过创新核算	无法判断是否在进步	建立基线，衡量调整工作的成效
过早优化规模	在达到产品市场契合前就开始打磨	先验证所学；质量会随着证据而来

快速诊断

审核任何产品开发计划：

问题	如果答案为否	行动
风险最高的假设是什么？	根基不稳	梳理重大假设
你将如何测试它？	你只是在猜测	设计 MVP 来测试该假设
哪项指标能验证或推翻它？	你将一无所获	定义可采取行动的指标
能否用更少的资源进行测试？	过度构建	进一步缩小 MVP 的范围
如果实验失败，你会怎么做？	没有转向标准	预先定义转向触发条件

延伸阅读

如需了解完整框架、研究和案例分析：

• 《精益创业》，作者 Eric Ries
• 《创业之道》，作者 Eric Ries（将精益创业应用于成熟企业）

关于作者

Eric Ries 是一位企业家和作家。他在担任 IMVU 联合创始人兼 CTO 期间开发了精益创业方法论，并开创了该方法论背后的持续部署和客户开发实践。《精益创业》已被译成 30 多种语言，并塑造了全球创业文化。他后来创立了长期证券交易所（LTSE）。