lean-startup

精益创业方法论（Lean Startup Methodology）

一套用于打造初创企业和推出新产品的系统化方法，旨在缩短开发周期，快速验证商业模式的可行性。

核心原则

创业本身就是一种管理。 成功不需要完美无缺的计划，也不靠灵光一现——它需要一套系统化的流程来验证假设、向客户学习并快速迭代。绝大多数创业项目之所以失败，并不是因为没把计划的东西做出来，而是因为“做出了没人要的东西”：要把这份计划视作一连串等待证伪的假设，把精力放在消除浪费、加速**验证性学习（validated learning）**上，而不是死板地按既定路线图执行。

评估打分

目标：10/10 分。 参照以下五行“快速诊断法”为项目计划、实验设计或指标体系打分——回答为“是”即得 1 分；若同时有验证梯队（Validation Ladder，3 级及以上）的实际证据支撑，则得 2 分：

• 9–10分： 梳理出每一项大胆假设（Leap-of-faith assumption）并按风险排序，最危险的假设已通过真实 MVP 验证，定义了可执行指标，且在研发前就设定了明确的转型触发标准。
• 5–6分： 提出了假设也做了一定 MVP，但指标属于虚荣指标，或者没定义转型标准——无法根据数据做决策。
• ≤3分： 典型的瀑布式思维——先开发完整产品、直接问客户想要什么，或者在还没达到 PMF（产品与市场匹配）时就盲目扩规模。

输出时请说明当前得分以及得分最低、最需要优先修复的诊断项。

构建-衡量-学习循环（Build-Measure-Learn Loop）

最基础的运作循环：想法（IDEAS）→ 构建（BUILD，产品）→ 衡量（MEASURE，数据）→ 学习（LEARN，认知）→ 返回想法（IDEAS）。

关键洞察： 规划循环时要逆向倒推：

1. 我们究竟想学习/验证什么？（要测试的假设）
2. 怎样才算验证成功？（衡量指标）
3. 能用来测试的最简版本是什么？（MVP）

终极目标： 尽量缩减跑完单次循环的总时间。

规划实验时，请参阅 references/build-measure-learn.md 了解逆向规划流程、实验设计模板、不同产品类型的循环案例，以及常见的构建陷阱与虚荣指标陷阱。

验证性学习（Validated Learning）

通过针对用户真实行为的实验，探明客户真正想要什么——而不是靠功能需求清单、问卷调查或焦点小组（因为人们往往无法准确预测自己的行为）。要衡量客户做了什么，而不是他们说了什么；要运行具备可证伪性的实验。那些虚荣式的胜利（比如只看下载量、无留存的注册量）并不属于有效学习。

验证梯队（Validation Ladder）：

层级	证据类型	验证强度
1	“我觉得客户会想要这个”	最弱（主观猜想）
2	“客户说他们想要这个”	较弱（口头表态）
3	“客户报名预约了早期试用”	中等（低度付出/低承诺）
4	“客户支付了意向金/订金”	较强（真实付出/实际承诺）
5	“客户正在高频活跃使用”	最强（显示偏好/实际行动）

目标： 在大规模投入开发前，验证层级至少达到 4–5 级。

最小可行产品（MVP）

能够以最少精力实现最大化“验证性学习”的产品版本。它既不是验证技术可行性的原型（Prototype），也不是注重品质的 Beta 版，更不是最小可售产品（MMP）——它是一个学习载体，通常简陋得让人有些拿不出手，而且规模远比你想象的还要小。

MVP 常见类型：

类型	定义	适用场景	经典案例
礼宾型（Concierge）	伪装成自动化的纯人工服务	验证解决方案是否有价值	Food on the Table（初期人工帮用户规划每周食谱）
绿野仙踪型（Wizard of Oz）	前台看像是自动化，后台全靠人工手动打理	验证是否真的需要做自动化	Zappos（初期没库存，用户下单后创始人跑去鞋店零售买来寄出）
冒烟测试（Smoke test）	仅有落地页 + 注册入口，完全没有产品实体	研发前先验证市场需求	Dropbox 早期演示视频（仅讲解概念并收集预约注册）
单功能型（Single feature）	只保留最核心的一项功能	验证哪项功能最核心、最具价值	Twitter（初期仅支持发简短状态 update）
拼凑型（Piecemeal）	组合现有的第三方工具	自研前先验证整体业务流程	Groupon（初期仅用 WordPress 博客 + 邮件通知）

设计思考提问： 最危险的假设是什么？能验证它的最小化载体是什么？我们如何衡量它是否被成功验证？

在选择与界定 MVP 规模时，请参阅 references/mvp-design.md 了解 7 种 MVP 类型的深度拆解、类型选择决策矩阵、规模上下限边界以及 MVP 设计画布。

大胆假设（Leap-of-Faith Assumptions）

一旦验证为错误，就会导致整个项目崩盘的核心假设。必须找出它们，按风险高低排序（哪个失败会致命？），并优先测试最危险的假设——绝不能按“哪个容易做”来排优先级。

假设类型	核心提问	测试方法
价值假设（Value hypothesis）	客户真的在乎这个痛点吗？	冒烟测试、礼宾型 MVP
增长假设（Growth hypothesis）	客户将如何发现我们？	渠道测试、裂变推荐实验
留存假设（Retention hypothesis）	客户用完后还会再来吗？	同期群分析（Cohort analysis）、活跃度指标
变现假设（Monetization hypothesis）	客户愿意付费吗？	预售预订、定价测试

经典案例——Dropbox： 其关键的大胆假设是“大家愿意下载并使用文件同步工具”。测试方式：在耗巨资构建高并发扩容架构前，先做了一版讲解功能的演示视频。结果：预约名单一夜之间从 5,000 人暴增至 75,000 人，市场需求得到强力验证。

在梳理与排序假设时，请参阅 references/assumptions.md 了解“影响度-不确定性矩阵”（Impact-Uncertainty matrix）、优先级打分模板、各类型假设对应的测试方法以及针对特定行业的假设清单。

创新核算（Innovation Accounting）

在传统财务/运营指标失效时（如刚上线时收入与用户数为零，或者虚荣指标看起来很好却无法指导决策），用来准确衡量项目进展的方法。

1. 建立基线（Establish the Baseline）

精确测量当下的真实情况，哪怕数据为零或难看：转化漏斗（注册 → 活跃 → 留存 → 付费）、参与度（DAU/MAU、单次时长、功能使用率）、单元经济学（CAC、LTV、流失率）。

2. 引擎调优（Tune the Engine）

通过迭代实验提升基线指标：例如定价 A/B 测试（9 美元/月 vs 19 美元/月）、新手引导完成率优化、获客渠道对比（SEO vs 投放 vs 推荐裂变）。每一次实验都要通过验证性学习，锁定可衡量的指标改善。

3. 转型还是坚持（Pivot or Persevere）

当指标调优进入平台期、再难提升时，基于数据证据作出决策（具体判定标准与转型类型见下文**“转型还是坚持”**章节）。

在构建基线看板时，请参阅 references/innovation-accounting.md 了解漏斗、同期群及单元经济学指标框架。

可执行指标 vs 虚荣指标（Actionable vs. Vanity Metrics）

虚荣指标让你自我感觉良好，却无法指导实际行动；可执行指标能够驱动决策，并清晰反映因果关系。

虚荣指标	为何有害	可执行替代指标
总注册用户数	只增不减，缺乏上下文	注册→活跃转化率（转化率）
页面浏览量（PV）	不代表用户获取了价值	停留时长、跳出率
累计用户数	混入了大量流失/僵尸用户	活跃用户数（DAU、WAU、MAU）
总下载量	下载了不等于在使用	DAU / 下载量（激活率）
总营收数额	缺乏视角 context	分同期群营收、LTV/CAC 比值

可执行指标的三大特征： 可执行（因果关系明确，可复现）、易懂（简单直观，团队所有人都能理解）、可审计（底层数据可被复核抽查）。

对比案例： 虚荣指标：“我们现在有 10 万用户了！”；可执行指标：“渠道 X 进来的用户留存率是渠道 Y 的 2 倍——我们应该加码渠道 X。”

同期群分析（Cohort Analysis）： 按注册时间将用户分组，并持续追踪他们随时间推移的行为变化——这是判断产品是否真正改善的唯一有效手段。

在搭建同期群数据表或选择追踪指标时，请参阅 references/metrics.md 了解五步同期群推演指南以及与精益创业阶段契合的 AARRR 海盗指标模型。

转型还是坚持（Pivot or Persevere）

转型（Pivot）是一次有针对性、结构化的方向修正，旨在测试关于产品、战略或增长引擎的新假设。

何时应该转型： 当实验反复无法验证假设、即使多次迭代指标依然平躺、客户反馈与最初愿景背道而驰，或者推进速度太慢耗不起 Runway 时。何时应该坚持： 当关键指标在向好改善（哪怕比较缓慢）、团队获得了清晰的有效认知，且细节微调正在朝着正确方向迈进时。

常见转型类型：

转型类型	改变了什么	经典案例
局部放大（Zoom-in）	将原本的一个单点功能放大为整个产品	Instagram（从复杂项目 Burbn 中剥离出滤镜相册功能）
全局缩小（Zoom-out）	将原本的整个产品缩减为大产品里的一个功能	Flickr（从网游 Game Neverending 缩减为图片分享功能）
目标客户群（Customer segment）	解决同样的痛点，但换了一批目标受众	Groupon（从公益维权平台转型为本地团购）
客户需求（Customer need）	锁定同一批客户，但解决他们另外的痛点	Potbelly（从古董店转型为三明治连锁店）
平台转型（Platform）	从独立应用变为平台，或反之	YouTube（从在线交友网站转型为通用视频平台）
商业架构（Business architecture）	在“高毛利低频”与“低毛利高频”模式间切换	Salesforce（从传统软件买断转型为 SaaS 订阅）
价值捕获（Value capture）	改变变现/盈利模式	Android（从收费操作系统转型为免费系统+应用生态分润）
增长引擎（Engine of growth）	在病毒式、粘性或付费增长模式间切换	Facebook（从高校病毒式传播转型为付费广告模式）
渠道转型（Channel）	改变触达与交付产品给客户的方式	Salesforce（从直销团队拓展为用户自主直购/自服务）
技术转型（Technology）	用不同的底层技术解决同样的问题	Apple（Mac 从 Intel 芯片架构转型为自研 ARM 架构）

节奏与频率： 成功的初创企业在找到 PMF 前，通常会经历 1–5 次转型。反模式陷阱： 未能验证新方向是否解决了核心问题，就盲目频繁“转型”。

当数据信号提示需要转型时，请参阅 references/pivots.md 了解基于数据的转型信号、结构化转型会议议程、先行指标以及 Instagram、Slack、YouTube 的真实转型故事。

三大增长引擎（The Three Engines of Growth）

初创企业实现可持续获取与留存客户的三种机制。请先挑选一种引擎深入优化，再去考虑叠加其他引擎——同时跑多个引擎会分散精力并干扰认知获取。

1. 粘性增长引擎（Sticky Engine of Growth）

由留存率驱动：增长率 = 新客获取率 − 用户流失率。重点追踪流失率（Churn rate）、同期群留存（30/60/90 天留存）以及 DAU/MAU。适用于 SaaS、订阅制服务、社交网络。核心策略：持续打磨产品，直到自然增长率超越流失率。

2. 病毒式增长引擎（Viral Engine of Growth）

由用户带用户驱动：病毒系数 K = (老用户邀请比例) × (人均发送邀请数) × (被邀请人转化比例)；K 值大于 1.0 意味着指数级、自驱式的爆发增长。重点追踪病毒系数、病毒循环周期时长（Viral cycle time）及推荐归因。适用于 Dropbox、Hotmail、WhatsApp。核心策略：将病毒式传播机制直接内置于产品流程本身。

3. 付费式增长引擎（Paid Engine of Growth）

靠投入资金获取客户：要求满足 LTV > CAC（目标 LTV/CAC > 3x）。重点追踪 CAC（获客成本）、LTV（客户生命周期价值）及回本周期（Payback period）。适用于电商及传统商业。核心策略：不断优化模型，直到每个客户产生的利润能够沉淀出资金去购买更多新客。

在选择或调优增长引擎时，请参阅 references/growth-engines.md 了解降低流失的策略、K 因子与病毒循环设计、LTV/CAC 优化、渠道经济学对照表以及产品与增长引擎匹配框架。

五个为什么（The Five Whys）

根因分析法：当问题发生时，连续追问五次“为什么？”，然后在各个层面按比例投入资源进行修复——而不是只救火表象。

案例——网站突然宕机崩了：

1. 为什么？ 服务器内存溢出了