03 · 验证与增长：从"做出来"到"用起来"再到"滚起来"
"If you are not embarrassed by the first version of your product, you've launched too late."
—— Reid Hoffman, LinkedIn 创始人
"Build something that 100 people love, not something that 1 million people kind of like."
—— Paul Graham
02 模块 告诉你"这门生意应该长什么样"——但应该和真的是之间，隔着一整个 03 模块。
很多创业者死在这一步：他们把 BMC 上每个格子都填得很漂亮，然后直接开始写代码、做产品、招团队——结果做出来的东西没人用。
本模块的 6 个工具，回答的是：
"我如何用最低成本验证'这门生意真的有人要'？验证通过后如何系统化增长？"
| 顺序 | 工具 | 阶段 | 何时用 |
|---|---|---|---|
| 1 | MVP（最小可行产品） | 验证 | 把 02 模块 Lean Canvas 的"最关键假设"变成可测的最小实验 |
| 2 | Do Things That Don't Scale | 早期 | MVP 落地后必须手工做的不可规模化的事 |
| 3 | PMF（Product-Market Fit）+ 40% 测试 | 验证完成 | 判断"产品-市场"是否真的契合 |
| 4 | AARRR 海盗指标 | 增长 | PMF 后系统化拆解增长漏斗 |
| 5 | 北极星指标（North Star Metric） | 增长 | 全公司对齐的单一核心指标 |
| 6 | Aha Moment + 留存曲线 | 增长 | 找到让用户"上瘾"的瞬间 |
工具一：MVP（Minimum Viable Product，最小可行产品）
是什么
MVP 是 Eric Ries 在 2011 年《精益创业》中提出的概念。核心定义：
MVP 是"能让你以最少成本验证最关键假设"的产品版本。
注意三个关键词：
- 最少成本：不是"最小功能"，是"最小成本"
- 最关键假设：不是所有假设，是会被证伪后让整个生意不成立的那个
- 验证：目的是学习，不是卖钱
MVP ≠ Demo：Demo 是给投资人看的，MVP 是给真实用户用的。
MVP ≠ 最简陋版本：如果最简陋版本让用户失望，你学到的不是"假设错了"，而是"产品太烂"。
为什么用
核心问题：90% 的创业者死于"做完产品后发现没人要"。
传统瀑布式开发：
想法 → 6 个月开发 → 发布 → 发现没人要 → 死
精益式开发：
想法 → 1 周 MVP → 用户测试 → 学习/调整 → 再 MVP → ... → PMF → 大投入开发
MVP 的本质：把"6 个月学一次"变成"1 周学一次"——学习频率提高 24 倍。
怎么用
步骤 1：识别最关键假设
参考 02 模块 Lean Canvas——你的"最关键假设"是什么？
典型最关键假设：
| 生意类型 | 最关键假设 |
|---|---|
| 新品类 | 用户愿意为这个新品类付费 |
| 订阅 SaaS | 用户愿意按月付费而不是一次性 |
| 双边市场 | 双方都愿意上来 |
| 硬件 | 用户愿意为这个硬件掏钱（不是 App 免费） |
| AI 产品 | 用户愿意把工作流交给 AI |
步骤 2：选择 MVP 类型
不同假设对应不同 MVP 类型：
| MVP 类型 | 适合验证 | 成本 | 时间 |
|---|---|---|---|
| Concierge MVP（侍者式） | 用户愿意为这个价值付费吗？ | 低 | 1 周 |
| Wizard of Oz MVP（绿野仙踪式） | 整个流程跑通后用户会用吗？ | 低 | 2 周 |
| Landing Page MVP | 用户对价值主张感兴趣吗？ | 极低 | 1 天 |
| Crowdfunding MVP | 用户愿意为这个产品付定金吗？ | 中 | 1 月 |
| Single Feature MVP | 单一核心功能是否产生 retention？ | 中 | 4 周 |
Concierge MVP：前端看起来是产品，后台是人工在做。用户感觉在用产品，实际是你手工服务。
经典案例：DoorDash 早期。创始人 Tony Xu 自己开车送外卖，前端是个简单网站——用户下单，Tony 收到，自己去餐厅取餐配送。所有"自动化"都是 Tony 本人。
Wizard of Oz MVP：前端看起来是完整产品，后台完全是人手工完成——用户不知道。
经典案例：Zappos 早期。Nick Swinmurn 把鞋店的照片挂到网站上，用户下单后他自己去实体店买鞋寄出。没有库存系统，没有 ERP——但验证了"用户愿意在网上买鞋"这个假设。
Landing Page MVP：一个网页 + 一个邮箱输入框。投放广告，看转化率。
经典案例：Buffer。创始人 Joel Gascoigne 早期只做了一个 landing page，描述"自动发推特"的功能，看有多少人留邮箱。第二天有 100+ 留邮箱——他才开始做产品。
步骤 3：定义"成功"标准
没有成功标准的 MVP 是无意义的。
在发布 MVP 前，必须先定义：
| 标准 | 例子 |
|---|---|
| 量化阈值 | 100 个注册 / 10% 转化率 / 30% 留存 |
| 质性反馈 | 5 个用户主动要求付费 / 3 个用户主动推荐 |
| 时间窗口 | 2 周内达成 |
关键：阈值必须事先写下来——否则你会事后合理化（"虽然只来了 50 个人，但他们的反馈很好……"）。
步骤 4：发布、收集数据、决策
发布后做 3 件事：
- 看量化数据：达到阈值了吗？
- 访谈用户：为什么用？为什么不用？哪里失望？
- 决策：
- 达到 + 反馈好 → 加大投入，进入 PMF 验证
- 达到但反馈差 → 调整产品（不是 pivot）
- 没达到但反馈好 → 改获客渠道
- 没达到 + 反馈差 → Pivot 或终止
案例：Dropbox 的"视频 MVP"
Drew Houston 2007 年在 YC S07 batch。他最初想做一个真正的 Dropbox MVP——能跑的代码。但他发现：
"文件同步是个非常难做的技术——增量同步、冲突解决、跨平台。做完一个能跑的 MVP 至少要 6 个月。"
他换了一个思路：做一个"假装在用 Dropbox"的视频。
视频内容：
- Drew 坐在屏幕前，演示"Drag file to Dropbox folder" → 文件"自动"出现在另一台电脑
- 配上他的旁白解释
- 加了一些"极客彩蛋"（Linux 命令行、XKCD 漫画）
视频发到 Digg.com（早期 Reddit）后：
| 时间 | Beta 注册用户 |
|---|---|
| 发布前 | 5,000 |
| 发布后 24 小时 | 75,000 |
Drew 后来说：
"我用了 3 分钟的视频，学到了 6 个月的开发才能学到的东西——'用户真的想要这个东西'。"
这是 Wizard of Oz MVP 的极致形态——技术上是 wizard of oz（视频里的"同步"是剪辑的），但验证的假设是真实的。
案例：李泽湘体系硬件创业的 MVP 路径
硬件创业的 MVP 比软件难得多——做一个原型至少要 3 个月、几万块。李泽湘体系的方法论是**"原型快速迭代"**，本质上是硬件版 MVP：
云鲸扫地机器人 J1 的 MVP 路径（简化）：
| 阶段 | 形态 | 验证假设 | 时间 |
|---|---|---|---|
| 0 | 纸质原型（草图） | "自动洗抹布"这个 idea 团队认同 | 1 周 |
| 1 | 纸板模型 | 用户对"基站 + 机器人"形态接受 | 2 周 |
| 2 | 3D 打印 + 现有飞控 | 基站与机器人的机械结构可行 | 1 月 |
| 3 | 工程样机（10 台） | 真实场景中能洗抹布 | 3 月 |
| 4 | 量产样机（100 台） | 工厂量产工艺可行 | 2 月 |
| 5 | 小批量量产（1000 台） | 用户愿意付费 | 1 月 |
关键：每一阶段都验证一个具体假设，任何一阶段失败就回到上一阶段，而不是"坚持做下去看结果"。
共享工厂的价值：XbotPark 共享工厂让云鲸能在 1-3 阶段以极低成本迭代——如果自己建工厂，1-3 阶段成本会高 10 倍。
常见误区
| 误区 | 修正 |
|---|---|
| MVP = 最简陋版本 | MVP 是"最小成本验证关键假设"——可以很精致 |
| MVP 没有成功标准 | 必须事先定义阈值 |
| MVP 完才访谈用户 | MVP 发布后立即访谈（24 小时内） |
| MVP 失败就放弃 | 失败可能是 MVP 设计问题，不是 idea 问题——分析根因 |
| MVP 太久才发布 | MVP > 4 周就太长了——拆得更小 |
与其他工具的关系
- 上游：Lean Canvas（提供"最关键假设"）、VPC（提供"价值主张"）
- 下游：PMF 测试（MVP 验证后的下一步）、AARRR（PMF 后的增长漏斗）
工具二：Do Things That Don't Scale
是什么
"Do Things That Don't Scale" 是 Paul Graham 2013 年的同名 essay，全球创业者引用最多的方法论文章。
核心观点：
"早期创业公司必须手工做不可规模化的事——这是验证 PMF 的唯一方式。"
PG 给了 4 个具体策略：
- Recruit users manually（手工招募用户）——挨个找用户
- Do things manually that you'll eventually automate（手工做将来要自动化的事）
- Create a great experience for first users（为早期用户创造极致体验）
- Build a tight feedback loop（建立紧密反馈循环）
为什么用
核心问题：早期创业者最大的认知错误——"等规模化再说"。
很多创业者会想：
"我现在只有 10 个用户，挨个联系效率太低，等有 10000 用户再设计自动化流程。"
PG 的回应：
"你不会有 10000 用户的——除非你先把这 10 个用户伺候好。"
逻辑：
- 早期你需要学习（learning）——学习需要深度，深度需要手工
- 后期你需要规模化（scaling）——规模化需要自动化
- 不能跳过"学习"阶段——自动化一个错误的流程，结果就是规模化的失败
怎么用
策略 1：手工招募用户
不要等用户来——主动去找。
YC 的标准建议：早期阶段，每周亲自和 10 个用户对话。
PG 反复讲 Stripe 兄弟的例子：
Patrick Collison 和 John Collison（Stripe 创始人）在 YC 期间，每周手工安装 7 个用户的 Stripe 集成——他们亲自飞到用户办公室，帮用户写代码。
为什么这样必要？因为：
- 早期用户遇到的问题，你不知道
- 你能在用户场景里看到真实使用情况
- 用户因为你的"手工服务"对你忠诚（这是后期无法买的）
策略 2：手工做将来要自动化的事
早期，所有"可自动化"的事都先手工做。
| 业务 | 早期手工做 | 后期自动化 |
|---|---|---|
| DoorDash | Tony Xu 自己开车送 | 调度系统 |
| Airbnb | Brian Chesky 亲自帮房东拍照 | 摄影师网络 |
| Stripe | 兄弟手工写集成代码 | SDK + 文档 |
| Twitch | Justin Kan 戴摄像头直播 24/7 | 平台让其他人播 |
关键：手工做的事，恰好是产品核心价值——这样你能学到产品最关键的部分。
策略 3：为早期用户创造极致体验
PG 说："Treat your first 10 users like they're the most important people in the world."
具体做法：
- 给他们 CEO 的私人手机号
- 24 小时内回复所有问题
- 上门服务
- 听他们的所有建议（不一定采纳）
"If you can make 100 users love you, they will recruit the next 10,000." —— PG
策略 4：紧密反馈循环
每周做一次：
- 看用户数据：上周用户做了什么？
- 访谈 5 个用户：他们喜欢什么？讨厌什么？
- 改产品：基于反馈快速迭代
- 重复
循环周期：1 周。不是 1 月。
案例：YC W25 整个批次的 "Do Things That Don't Scale"
Garry Tan 在 2025 年 CNBC 采访中公开的数据：
"W25 整个批次周增长 10% WoW——这是 YC 21 年历史里从未出现过的数据。"
为什么 W25 这么特别？Garry 解释：
"因为 AI 让每个创始人都能做更多手工的事——以前需要 5 人的事，现在 1 个 founder + AI 就能做。"
这恰恰是 "Do Things That Don't Scale" 的 AI 时代升级版：
- 以前：1 个 founder 手工服务 10 个用户
- 现在：1 个 founder + AI 手工服务 100 个用户
- 早期手工的边界被 AI 推开了 10 倍
案例：李泽湘体系的"硬件 Do Things That Don't Scale"
硬件创业的 "Do Things That Don't Scale" 更难——你不能"挨个送硬件"。李泽湘体系的方法：
云鲸早期（2020 年前）：
- 创始人亲自去用户家里安装第一台机器
- 创始人亲自接听客服电话
- 创始人亲自去工厂盯第一波量产
希迪智驾早期：
- 创始人亲自驻扎矿山调试第一台矿卡
- 创始人亲自给矿山主 CEO 打电话销售
硬件 "Do Things That Don't Scale" 的本质：用 founder 的时间换供应链/用户的信任——这是后期任何员工都无法替代的。
常见误区
| 误区 | 修正 |
|---|---|
| "等规模化再说" | 没有手工阶段的规模化是空中楼阁 |
| 手工做非核心的事 | 手工做的事必须是核心价值，不是边缘功能 |
| 过早自动化 | 没访谈 50 个用户就别自动化 |
| 觉得手工"低效" | 早期的目标不是效率，是学习 |
与其他工具的关系
- 互补：MVP（MVP 是"做什么"，DTDTNS 是"怎么做"）
- 下游：PMF（DTDTNS 的目标是 PMF）
工具三：PMF（Product-Market Fit）+ 40% 测试
是什么
PMF（Product-Market Fit） 是 Marc Andreessen 在 2007 年博客 The Only Thing That Matters 中系统化的概念：
"Product-market fit means being in a good market with a product that can satisfy that market."
Andreessen 的著名论断：
"The only thing that matters is getting to product/market fit."（创业唯一重要的事就是达到 PMF）
PMF 的判断方法
判断 PMF 有 3 个层次：
层次 1：Sean Ellis 40% 测试（最经典）
Sean Ellis（"Growth Hacker"概念提出者）在 2009 年发明的简单测试：
"如果明天起你不能用这个产品了，你会有多失望？"
- A. 非常失望
- B. 有点失望
- C. 不失望
- D. 我已经不用了
PMF 阈值：至少 40% 的用户选 A。
Sean Ellis 跑过几十家公司发现：低于 40% 的公司，无论怎么优化增长都是死路；高于 40% 后，增长变成"添加柴火"——投入就有产出。
注意：
- 只调查"活跃用户"——不是注册用户
- 至少 40 个有效回复
- 调查时机：用户使用 2 周后
层次 2：Marc Andreessen 的"感觉"
Andreessen 在博客中说：
"You can always feel when product/market fit is happening. The customers are buying the product just as fast as you can make it. The servers are on fire. Money is piling up in the bank account. Sales are taking too long, you're hiring sales and customer support reps as fast as you can."
反过来：
"You can also feel when it's not happening. The word 'pivot' keeps coming up. Your investors are nervous. Your engineers are bored."
层次 3：量化指标
| 指标 | PMF 阈值 |
|---|---|
| 自然增长（非付费）占比 | > 50% |
| 30 天留存率 | > 40% |
| NPS（净推荐值） | > 40 |
| 主动流失率（月） | < 5% |
| 用户主动推荐率 | > 20% |
怎么用
阶段 1：发现 PMF（pre-PMF）
目标：找到一群"非常失望如果没有这个产品"的用户。
具体做法：
- 01 模块用户访谈——找 100 个真实用户对话
- 02 模块 VPC/BMC——画出价值匹配
- MVP + DTDTNS——手工服务前 10 个用户
- Sean Ellis 40% 测试
阶段 2：达成 PMF
特征：
- 40% 测试通过
- 留存曲线水平（不再衰减）
- 用户主动推荐（不需要奖励）
阶段 3：维持 PMF（post-PMF）
目标：在 PMF 基础上扩大规模，但不能稀释 PMF。
具体做法：
- 投放增长（AARRR）
- 招聘团队
- 国际化
注意：很多公司死于"PMF 之后过快扩张"——WeWork、Quibi 都是反例。
案例：Superhuman 的 PMF 流程
Superhuman（CEO Rahul Vohra）在 2019 年公开了他们的 PMF 方法论，被称为"工程化的 PMF"：
| 步骤 | 做法 |
|---|---|
| 1. 调查 | 对所有活跃用户跑 Sean Ellis 40% 测试 |
| 2. 细分 | 把"非常失望"用户的人口统计学/行为画像出来 |
| 3. 焦点 | 把产品重心放到这群"非常失望"用户身上 |
| 4. 改进 | 询问"为什么你没用 A 选项？我们还缺什么？" |
| 5. 跟踪 | 每周跑一次调查，看 40% 比例的变化 |
| 6. 内部对齐 | 全公司共享 PMF 分数 |
Superhuman 用这个流程把 PMF 分数从 22% → 58%。
案例：李泽湘体系的 PMF 判断
李泽湘体系没有用 Sean Ellis 测试——但用硬件特有的 PMF 信号：
| 信号 | 含义 |
|---|---|
| 首日售罄 | 云鲸 J1 首发 30 秒售罄——PMF |
| 众筹超额 | 深圳科创学院体系公司 Kickstarter 众筹目标超额 10 倍以上 |
| CES 反馈 | CES 展位人流密度 + 媒体主动报道 |
| 回头客 | 经销商/To B 客户的复购率 |
李泽湘的标准："用户愿意等你的产品 + 经销商愿意预付定金"——这是硬件 PMF。
常见误区
| 误区 | 修正 |
|---|---|
| 把"用户喜欢"当 PMF | PMF 是"非常失望如果没有"，不是"喜欢" |
| 过早追求 PMF 后增长 | 没到 PMF 就投放广告 = 烧钱 |
| 40% 测试只用一次 | PMF 是动态的，每月测一次 |
| PMF 后停止访谈 | PMF 后更要访谈——避免稀释 |
与其他工具的关系
- 上游：MVP + DTDTNS（PMF 的前置）
- 下游：AARRR（PMF 后的增长体系）、Unit Economics（PMF 后才需要算）
工具四：AARRR 海盗指标
是什么
AARRR 是 Dave McClure（500 Startups 创始人）在 2007 年提出的指标体系，也称为"海盗指标"（Pirate Metrics）——因为 AARRR 像海盗的叫声。
5 个环节：
Acquisition（获客）→ Activation（激活）→ Retention（留存）→ Referral（推荐）→ Revenue（收入）
┌────────────────────┐
│ Acquisition 获客 │ ← 用户怎么找到你
│ 100% │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Activation 激活 │ ← 用户第一次用好
│ 40% │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Retention 留存 │ ← 用户持续回来
│ 20% │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Referral 推荐 │ ← 用户带来新用户
│ 10% │
└─────────┬──────────┘
▼
┌────────────────────┐
│ Revenue 收入 │ ← 用户付费
│ 5% │
└────────────────────┘
为什么用
核心问题：早期公司不知道增长瓶颈在哪。
- 投放了广告，但没收入 → 哪个环节断了？
- 用户注册但不付费 → 激活？留存？付费转化？
AARRR 把"增长"拆成 5 个可单独诊断的环节——每个环节有专门的优化方法。
怎么用
步骤 1：定义每个环节的指标
| 环节 | 关键指标 | 健康标准（SaaS） |
|---|---|---|
| Acquisition | UV、注册转化率 | CAC < LTV/3 |
| Activation | 完成核心功能的用户比例 | 首日激活 > 50% |
| Retention | 周/月留存率 | 月留存 > 40%（B2C），> 80%（B2B） |
| Referral | 邀请率、K 因子 | K 因子 > 0.5 |
| Revenue | ARPU、付费转化率 | 付费转化 > 5% |
步骤 2：找瓶颈
把当前每个环节的转化率填进去，看哪一环衰减最大。
Dave McClure 的诊断：
- 衰减 > 80% 的环节 = 当前最大瓶颈
- 优化瓶颈 = 投入产出比最高
反例：很多公司一上来优化 Acquisition——投更多广告。但如果 Retention 只有 5%，再多获客也留不住——先优化 Retention 才是杠杆最大。
步骤 3：每个环节的优化方法
Acquisition：
- SEO、SEM、社交媒体、内容营销、KOL、活动
- 关键：测试多个渠道，找到 CAC 最低的
Activation：
- 改善新手引导（onboarding）
- 减少第一次使用的摩擦
- 关键：定义"激活" = 用户完成核心功能 1 次
Retention：
- 邮件/推送召回
- 内容/功能更新
- 关键：留存是 PMF 的体现——留存低不是 marketing 问题
Referral：
- 推荐奖励（双边奖励）
- UGC 内容
- 关键：先有强 Retention 才能有 Referral
Revenue：
- 定价策略
- Upsell / Cross-sell
- 关键：先证明用户愿意付 1 块，再想怎么让他付 100 块
案例：Facebook 早期的 AARRR
| 环节 | Facebook 2006 数据 |
|---|---|
| Acquisition | 高——校园口碑 |
| Activation | 超快——注册后 1 小时内 60% 加了好友 |
| Retention | 超强的 D1/D7/D30 留存（行业最高） |
| Referral | K 因子 > 1（自然增长） |
| Revenue | 早期没收入（2007 后才商业化） |
洞察：Facebook 早期完全没考虑 Revenue——前 4 环做好后，Revenue 自然就来。
案例：奇绩创坛评估框架
陆奇的奇绩创坛用 AARRR 评估项目：
"我们看早期项目，重点看 Activation 和 Retention——Acquisition 可以靠投放，Revenue 可以靠定价，但 Activation 和 Retention 是产品本质。"
常见误区
| 误区 | 修正 |
|---|---|
| 5 个环节平均用力 | 先诊断瓶颈，再重点优化 |
| 过度优化 Acquisition | Retention 低时，再多获客也没用 |
| 5 个环节独立看 | 它们是漏斗——上游影响下游 |
与其他工具的关系
- 上游：PMF（PMF 后才能用 AARRR 系统化）
- 下游：北极星指标（北极星是 AARRR 中某一个环节的核心指标）
工具五：北极星指标（North Star Metric）
是什么
北极星指标（North Star Metric, NSM） 是 Sean Ellis 在 2017 年《Hacking Growth》中提出的概念。
定义：
"全公司对齐的、反映用户获得价值的单一核心指标。"
不是：
- 收入（不是用户视角）
- 注册数（不反映价值）
- DAU（不区分深度）
北极星指标的 3 个特征：
- 反映用户获得的价值（不是公司收入）
- 可衡量（有具体数字）
- 可对齐（全公司都能为它工作）
为什么用
核心问题：早期公司每个部门有不同的 KPI，互相内耗。
| 部门 | 自己的 KPI |
|---|---|
| 市场 | 注册数 |
| 产品 | DAU |
| 销售 | 收入 |
| 客服 | 工单响应时间 |
每个部门优化自己的 KPI——但这些 KPI 之间可能矛盾（市场为了注册数投放低质量流量 → 拉低 Retention）。
北极星指标 = 全员指向同一方向。
怎么用
步骤 1：找候选北极星
每个生意有不同的北极星：
| 公司 | 北极星指标 |
|---|---|
| Airbnb | 已预订的晚数（Nights Booked） |
| 每日活跃用户中加 5+ 好友的比例 | |
| Slack | 已发送消息数（每周） |
| Spotify | 总收听时长 |
| 已发送消息数 | |
| Netflix | 每月观看时长 |
| Quora | 已回答问题数 |
| Twitch | 同时在线主播数 |
规律：北极星指标都是用户价值的核心——不是公司收入。
步骤 2：用 3 个标准筛选
| 标准 | 例子（Airbnb 选 "Nights Booked"） |
|---|---|
| 反映用户价值 | "完成一次入住" = 用户获得了价值 |
| 可衡量 | 每天/每周都能查到 |
| 可对齐 | 市场、产品、客服都能影响它 |
反例：Airbnb 如果用"收入"作北极星——市场可能推高价房源（短期提升收入，但损害用户体验和长期增长）。
步骤 3：拆解到部门
北极星是 North Star，每个部门要有自己的"输入指标"：
North Star
▲
│
┌───────────┼───────────┐
│ │ │
市场输入 产品输入 运营输入
注册数 激活率 留存率
例子（Airbnb）：
- 北极星：Nights Booked
- 市场输入：注册房东数
- 产品输入：预订流程转化率
- 运营输入：客服响应时间
步骤 4：每周看北极星
全公司每周看一次北极星——这成为团队的"心跳"。
案例：Slack 的北极星演化
Slack 早期用"注册用户数"——发现这是错的：
注册用户不等于活跃用户。Slack 改用"已发送消息数"——这反映用户真的在用。
但 Slack 后来发现"已发送消息数"还不够——因为可能少数活跃用户发了很多消息。
Slack 最终的北极星："每周发送 2000+ 条消息的团队数"——这是 PMF 的临界点（团队规模 + 使用深度）。
这就是 Slack 的 Aha Moment——团队发够 2000 条消息后，几乎不会再换工具。
案例：李泽湘体系的硬件北极星
硬件的北极星更复杂——硬件销售是低频行为，不能用 DAU。
| 公司 | 北极星 |
|---|---|
| 大疆（消费级） | 年度活跃飞手数（每年至少飞 10 次） |
| 云鲸 | 月活扫地机器人（每月至少扫 8 次） |
| 希迪智驾 | 累计无人驾驶里程（每月） |
共同特点：用"使用深度"而非"销售数量"——因为硬件创业的真正价值是用户持续使用，不是销售一次性收入。
常见误区
| 误区 | 修正 |
|---|---|
| 北极星 = 收入 | 收入是滞后指标——北极星应该是先行指标（用户价值） |
| 多个北极星 | 只能有一个——多了就没对齐 |
| 北极星永远不变 | 业务阶段变了，北极星也会变（Slack 就改过） |
| 没有部门输入指标 | 北极星必须能拆解到部门 |
与其他工具的关系
- 上游：AARRR（北极星是 AARRR 中某一个环节的核心指标）
- 下游：OKR（04 模块——把北极星拆到季度目标）
工具六：Aha Moment + 留存曲线
是什么
Aha Moment（顿悟时刻） 是用户第一次"感受到产品价值"的瞬间。
经典 Aha Moment 案例：
| 公司 | Aha Moment |
|---|---|
| 7 天内加 10 个好友 | |
| 关注 30 个人 | |
| Slack | 团队发 2000 条消息 |
| Dropbox | 1 台设备上完成 1 次同步 |
| Zynga | 第一次回到农场发现作物长大了 |
| Twitch | 第一次看直播时发礼物 |
留存曲线：用户在不同时间点的留存率折线图。
留存率 %
100 │ ●
80 │ ●
60 │ ●
40 │ ● ● ● ● ● ← 平台（PMF 标志）
20 │
0 └──────────────────→ 时间
D1 D7 D14 D30 D60
留存曲线的关键判断：是否"水平"——
- 水平曲线 = 留下了一批死忠用户 = PMF
- 持续下降曲线 = 用户持续流失 = 没有 PMF
为什么用
Aha Moment 的价值：找到它 → 强制所有新用户走到这个时刻 → retention 大幅提升。
Facebook 发现"7 天加 10 个好友"这个 Aha Moment 后，新手引导全部围绕"加好友"——这是 Facebook 早期增长的核心引擎。
留存曲线的价值：是 PMF 最客观的指标。
Andrew Chen（a16z）："If your retention curve flattens out, you have PMF. If it keeps declining, you don't."
怎么用
步骤 1：用数据找 Aha Moment
方法：Cohort 分析 + 相关性分析。
- 找出留下来的用户（D30 留存）
- 看他们在 D7 内做了什么——什么行为显著区分留存和流失用户？
- 那个行为就是 Aha Moment 候选
注意：相关性 ≠ 因果。需要进一步测试（强制新用户体验这个 Aha Moment，看留存是否提升）。
步骤 2：围绕 Aha Moment 优化新手引导
目标：让用户在最短时间内（最好 D1）完成 Aha Moment。
| 公司 | 围绕 Aha Moment 的引导 |
|---|---|
| 新手引导强制推荐 10+ 好友 | |
| 强制关注 30 个人 | |
| Slack | 团队加入时强制邀请 3+ 同事 |
| Dropbox | 安装后强制完成第一次同步 |
步骤 3：监控留存曲线
留存曲线的 3 种形态：
| 形态 | 含义 | 行动 |
|---|---|---|
| 持续下降 | 没 PMF | 回到 PMF 验证 |
| 下降后水平 | 有 PMF（小众） | 扩大市场 |
| 下降后水平且高水平 | 有 PMF（大众） | 加速增长 |
案例：YC W25 整批的 Aha Moment
Garry Tan 在 CNBC 采访中提到的 W25 整体数据：
"整个批次周增长 10% WoW。"
为什么 W25 的留存曲线特别漂亮？Garry 解释：
"因为 AI 让 Aha Moment 来得更快——以前用户需要用 1 周才能'get it'，现在用 1 小时。"
例子：
- AI 写代码工具（Cursor、Replit Agent）：第一次让 AI 写一段代码就能立刻运行
- AI 搜索（Perplexity）：第一次问问题立刻得到带引用的答案
- AI 客服：第一次替换 50% 工单立刻看到成本下降
AI 时代的 Aha Moment 设计原则："用户用一次就看到结果"。
案例：李泽湘体系硬件的 Aha Moment
硬件的 Aha Moment 更难——用户买了之后第一次使用就是 Aha Moment 候选。
| 公司 | Aha Moment |
|---|---|
| 大疆 Phantom | 第一次起飞拍出第一张航拍照 |
| 云鲸 J1 | 第一次回家看到干净的地板 + 自动洗完的抹布 |
| 希迪矿卡 | 第一次无人驾驶安全完成一班运输 |
深圳科创学院的方法：训练创始人特别关注"首次使用体验"——硬件的 Aha Moment 在工厂无法模拟，必须真实场景。
常见误区
| 误区 | 修正 |
|---|---|
| Aha Moment 是猜的 | 必须用数据找——cohort 分析 |
| Aha Moment 找到就够了 | 必须强制新用户走到这个时刻 |
| 留存曲线只看 D30 | 要看 D1/D7/D30/D90——不同时段有不同问题 |
| 留存曲线一直下降就放弃 | 改产品后曲线会变——持续监控 |
与其他工具的关系
- 上游：北极星指标（Aha Moment 是北极星的"前置信号"）
- 下游：增长投放（Aha Moment 找到后，CAC 才有意义）
6 个工具的整体关系图
这 6 个工具的本质：从"假设"到"指数级增长"的 6 步——
- MVP：用最少成本验证最关键假设
- DTDTNS：手工做不可规模化的事——这是 PMF 的前提
- PMF：判断"产品-市场"是否真的契合——40% 测试
- AARRR：拆解增长漏斗，找瓶颈
- 北极星指标：全公司对齐到一个指标
- Aha Moment：找到让用户上瘾的瞬间——加速 retention
完成这 6 步后，你就有了一个真正能滚起来的生意——下一步是 04 模块：融资（让生意走得更快）+ 战略思维（让决策更准）。
关联文档
本模块内：本页是 03 模块的唯一文档。
本模块其他章节：
- 01 · 用户洞察——MVP 验证的输入
- 02 · 价值与商业模式——PMF 的前提
- 04 · 融资与战略——增长后的资本化
关联模块：
- Y Combinator 深度分析——PMF、Aha Moment 案例源头
- 深圳科创学院深度分析——硬件 MVP/PMF 案例
- 产品伪需求的基本特征和验证模型——与 PMF 互补
- 小红书从 0 到 1 运营体系——AARRR 实操
- 万字复盘语音直播产品的从 0 到 1——PMF 实操案例
参考资源
- Eric Ries《精益创业》(The Lean Startup, 2011)——MVP 和 Build-Measure-Learn 的原始著作
- Paul Graham "Do Things That Don't Scale"(2013 essay)——DTDTNS 的源头
- Paul Graham "Startup = Growth"(2012 essay)——PMF 与增长的哲学
- Marc Andreessen "The Only Thing That Matters"(2007 blog)——PMF 概念的源头
- Sean Ellis "Find Your Product Market Fit"(2009 blog)——40% 测试的源头
- Sean Ellis & Morgan Brown《Hacking Growth》(2017)——北极星指标系统化
- Dave McClure "Startup Metrics for Pirates"(2007 演讲)——AARRR 的源头
- Andrew Chen "Law of Shitty Clickthroughs"(2012 blog)——获客渠道衰减
- Rahul Vohra "How Superhuman Built an Engine to Find Product Market Fit"(2019)——工程化 PMF