January 1, 2020

03 · 验证与增长：从"做出来"到"用起来"再到"滚起来"

"If you are not embarrassed by the first version of your product, you've launched too late."

—— Reid Hoffman, LinkedIn 创始人（2013 演讲）

"Build something that 100 people love, not something that 1 million people kind of like."

—— Paul Graham（2013 essay）

02 模块 告诉你"这门生意应该长什么样"——但应该和真的是之间，隔着一整个 03 模块。

很多创业者死在这一步：他们把 BMC 上每个格子都填得很漂亮，然后直接开始写代码、做产品、招团队——结果做出来的东西没人用。

本模块的 9 个工具，回答的是：

"我如何用最低成本验证'这门生意真的有人要'？验证通过后如何系统化增长？"

顺序	工具	阶段	何时用
1	MVP（最小可行产品）	验证	把 02 模块 Lean Canvas 的"最关键假设"变成可测的最小实验
2	Do Things That Don't Scale	早期	MVP 落地后必须手工做的不可规模化的事
3	PMF（Product-Market Fit）+ 40% 测试	验证完成	判断"产品-市场"是否真的契合
4	单元经济学 Unit Economics	验证后	PMF 后才算——验证"这门生意在单元层面是否赚钱"
5	AARRR 海盗指标	增长	PMF 后系统化拆解增长漏斗
6	北极星指标（North Star Metric）	增长	全公司对齐的单一核心指标
7	Aha Moment + 留存曲线	增长	找到让用户"上瘾"的瞬间
8	OKR	战略落地	把北极星指标拆到全员季度目标
9	Founder Mode（创始人模式）	运营哲学	公司变大后，用创始人的方式运营——拒绝切换到经理人模式
10	Pivot 决策框架	早期决策	什么时候坚持，什么时候换方向——YC 最频繁给的建议
11	Go-To-Market Strategy	进入市场战略	4 种 GTM 模式（PLG / SLG / Channel-led / Community-led）
12	Product-Led Growth vs Sales-Led Growth	增长模式抉择	决定整个组织架构的根本选择
13	团队建设——从 3 人到 100 人	选人 · 踢人 · 规模	从合伙人到组织：怎么验证真本事、怎么说分手、3→10→30→100 的协作切换

为什么单元经济学在这里：2026 年调整后，单元经济学从 02 模块移到 03——因为 LTV/CAC 是"这门生意在单元层面是否赚钱"的财务验证，只有 PMF 后才有意义。pre-PMF 算 LTV/CAC 是空谈——用户都还没留下来，何谈 LTV？

为什么 OKR 在这里：OKR 是 03 北极星指标 的直接下游——把"全公司对齐的单一指标"拆解到部门/个人的季度目标。不等到融资（04）才用。

为什么 Founder Mode 在这里：当公司从 PMF 进入增长阶段（10+ 人），创始人面临"是否切换到经理人模式"的压力——这正是 Founder Mode 最相关的时刻。

---

工具一：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（2013 创立）。创始人 Tony Xu 自己开车送外卖，前端是个简单网站——用户下单，Tony 收到，自己去餐厅取餐配送。所有"自动化"都是 Tony 本人。

Wizard of Oz MVP：前端看起来是完整产品，后台完全是人手工完成——用户不知道。

经典案例：Zappos（1999 创立）。Nick Swinmurn 把鞋店的照片挂到网站上，用户下单后他自己去实体店买鞋寄出。没有库存系统，没有 ERP——但验证了"用户愿意在网上买鞋"这个假设。

Landing Page MVP：一个网页 + 一个邮箱输入框。投放广告，看转化率。

经典案例：Buffer（2010 创立）。创始人 Joel Gascoigne 早期只做了一个 landing page，描述"自动发推特"的功能，看有多少人留邮箱。第二天有 100+ 留邮箱——他才开始做产品。

步骤 3：定义"成功"标准

没有成功标准的 MVP 是无意义的。

在发布 MVP 前，必须先定义：

标准	例子
量化阈值	100 个注册 / 10% 转化率 / 30% 留存
质性反馈	5 个用户主动要求付费 / 3 个用户主动推荐
时间窗口	2 周内达成

关键：阈值必须事先写下来——否则你会事后合理化（"虽然只来了 50 个人，但他们的反馈很好……"）。

步骤 4：发布、收集数据、决策

发布后做 3 件事：

1. 看量化数据：达到阈值了吗？
2. 访谈用户：为什么用？为什么不用？哪里失望？
3. 决策：
   • 达到 + 反馈好 → 加大投入，进入 PMF 验证
   • 达到但反馈差 → 调整产品（不是 pivot）
   • 没达到但反馈好 → 改获客渠道
   • 没达到 + 反馈差 → Pivot 或终止

案例：Dropbox 的"视频 MVP"（2007-2008）

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 倍。

硬件专属路径：EVT → DVT → PVT → 量产

软件 MVP 可以 1 周迭代一次，但硬件不一样——一旦开模，改一次的成本是 10 倍起跳。所以硬件创业需要一套比"Build-Measure-Learn"更严谨的阶段门控体系。

这就是 EVT/DVT/PVT 三阶段验证模型——硬件行业的标准流程，也是深圳科创学院体系训练创始人的核心内容。

三阶段总览

阶段	全称	核心问题	典型数量	时间
EVT	Engineering Validation Test（工程验证测试）	"设计能正常工作吗？"	20-100 台	2-4 个月
DVT	Design Validation Test（设计验证测试）	"在所有条件下都能可靠工作吗？"	100-500 台	3-6 个月
PVT	Production Validation Test（生产验证测试）	"工厂能以量产速度持续生产吗？"	500-5000+ 台	2-4 个月
MP	Mass Production（量产）	"稳定交付给客户"	万级以上	持续

EVT：工程验证——"设计能工作吗？"

目标：首次将外观样机和功能样机整合为一个产品形态，使用量产意图的材料和制造工艺。

维度	要求
原型方式	软模具（硅胶/聚氨酯树脂模）可行；3D 打印仅用于概念验证，不算 EVT
零件来源	必须是量产意图的材料——不是 3D 打印件
测试要求	所有关键功能测试站必须到位
典型失败率	~40% 的单元可能因功能/性能问题失败——这是正常的
退出标准	确定一个满足所有功能、性能和可靠性要求的生产配置

常见陷阱：

• 只测试"顺利路径"（happy path），不测试边界条件
• 在 EVT 阶段用 3D 打印件凑合——到 DVT 才发现模具做不出来
• 没有预先定义退出标准，凭感觉"差不多就行"

DVT：设计验证——"在所有条件下都可靠吗？"

目标：验证量产良率，对所有零件进行首次硬模认证。这是硬件创业最容易被低估的阶段——很多团队以为 EVT 过了就快了，结果 DVT 发现一堆问题。

维度	要求
模具	所有零件来自硬模或量产工艺——软模退场
测试	全温范围、全湿度范围、跌落测试、EMC/EMI、合规预测试
外观良率	初期可能为 0%——需要多轮打磨才能达标
退出标准	对所有导致不可接受良率的问题，有高置信度的纠正措施

1:10:100 成本法则：在 CAD 中修复一个缺陷花费 $1；在 EVT 原型阶段花费$10；在 DVT 试产阶段花费 $100；在量产阶段花费$1,000 以上。所以 DVT 是发现问题最后的"便宜窗口"。

PVT：生产验证——"工厂能量产吗？"

目标：以量产速度验证量产良率。PVT 的合格产品将直接销售给客户——这不是"试验"，是"试产"。

维度	要求
产线速度	达到目标产能的 80%+
直通率	目标 95%+（首件通过所有测试站的比例）
认证	所有法规认证必须在 PVT 期间完成（FCC/CE/CCC 等）
退出标准	至少一条产线达到量产速度和良率，其他产线复制已启动

⚠️ 警惕"XVT"陷阱：在进度压力下，有些团队会捏造一个"XVT"阶段——在 EVT 的零件成熟度下完成 DVT 的退出标准。这等于跳过了真正的设计验证，把问题推迟到量产——成本暴涨 10-100 倍。

深圳速度：硬件 MVP 的"作弊码"

深圳科创学院体系的核心竞争力之一，就是把 EVT/DVT/PVT 的周期压缩到极致：

能力	深圳/大湾区	硅谷/其他地区
PCB 打样	12 小时，¥20	3-5 天，$200+
3D 打印/CNC	24 小时	3-7 天
软模具	1-3 周	3-6 周
元器件采购	华强北 1 公里内配齐	线上采购 2-4 周
产品迭代速度	比硅谷快 10-30 倍	基准线
总成本	硅谷的 1/5 到 1/10	基准线

李泽湘 2024："学生上午来深圳，晚上就能完成整个加工流程返回——这在全球任何其他地方都做不到。"

李泽湘的"需求 → 产品 → 技术"原则

传统工程思维是"技术 → 产品 → 需求"（我会什么技术 → 能做什么产品 → 卖给谁），李泽湘体系严格倒过来：

需求（谁买单？）→ 产品（比现有方案好 10 倍？）→ 技术（用什么实现？）

在产品定义确认之前，不讨论技术方案。 这是硬件创业最重要的原则——因为硬件一旦选定技术路线，改的成本是软件的 100 倍。

戴森的第一款吸尘器迭代了 5,127 次——但每一次迭代都是在"产品定义确认"之后的技术优化，不是推倒重来。李泽湘体系训练创始人区分"什么时候改方向"和"什么时候坚持优化"。

常见误区

误区	修正
MVP = 最简陋版本	MVP 是"最小成本验证关键假设"——可以很精致
MVP 没有成功标准	必须事先定义阈值
MVP 完才访谈用户	MVP 发布后立即访谈（24 小时内）
MVP 失败就放弃	失败可能是 MVP 设计问题，不是 idea 问题——分析根因
MVP 太久才发布	MVP > 4 周就太长了——拆得更小

与其他工具的关系

• 上游：02 Lean Canvas（提供"最关键假设"）、02 VPC（提供"价值主张"）
• 下游：工具三 PMF 测试（MVP 验证后的下一步）、工具五 AARRR（PMF 后的增长漏斗）

---

工具二：Do Things That Don't Scale

是什么

"Do Things That Don't Scale" 是 Paul Graham 2013 年的同名 essay，全球创业者引用最多的方法论文章。

核心观点：

"早期创业公司必须手工做不可规模化的事——这是验证 PMF 的唯一方式。"

PG 给了 4 个具体策略：

1. Recruit users manually（手工招募用户）——挨个找用户
2. Do things manually that you'll eventually automate（手工做将来要自动化的事）
3. Create a great experience for first users（为早期用户创造极致体验）
4. Build a tight feedback loop（建立紧密反馈循环）

为什么用

核心问题：早期创业者最大的认知错误——"等规模化再说"。

几乎每个 MVP 之后都会出现一个陷阱：产品做出来了，早期用户反馈不错，但只有几十个用户。创始人开始想："我需要规模化——自动化流程、投放广告、建自助注册系统——然后用户自然会来。"

PG 在 2013 年这篇 essay 里明确说了：这个逻辑是颠倒的。你不能从规模化开始——你必须从不可规模化的事开始。 原因不复杂：

1. 早期阶段你的目标是"学习"（learning），不是"规模化"（scaling）。 学习需要深度——你需要和每个用户对话、观察他们用产品、理解他们为什么留下或为什么离开。这些信息不存在于仪表盘里——你必须亲手去获取。
2. 如果你自动化的流程是错的，规模化的结果就是规模化的失败。 在 10 个用户时，你可以从对话中学到你的 onboarding 流程有个致命的 bug。在 10000 个用户时，你只能从流失率曲线里看到"有 60% 的人注册后第二天就消失了"——但你不知道为什么。
3. 早期用户因为你的"手工服务"对你产生忠诚——这是任何自动化都无法购买的。 一个你在凌晨两点亲自回复了 bug report 的用户，未来会是你的产品最热情的传播者。一百个这样的用户——就是 PG 所说的 "make something users love" 的起点。

很多创业者会想：

"我现在只有 10 个用户，挨个联系效率太低，等有 10000 用户再设计自动化流程。"

PG 2013 的回应：

"你不会有 10000 用户的——除非你先把这 10 个用户伺候好。"

逻辑：

• 早期你需要学习（learning）——学习需要深度，深度需要手工
• 后期你需要规模化（scaling）——规模化需要自动化
• 不能跳过"学习"阶段——自动化一个错误的流程，结果就是规模化的失败

怎么用

策略 1：手工招募用户

不要等用户来——主动去找。

YC 的标准建议：早期阶段，每周亲自和 10 个用户对话。

PG 反复讲 Stripe 兄弟的例子：

Patrick Collison 和 John Collison（Stripe 创始人）在 YC 期间（2010 batch），每周手工安装 7 个用户的 Stripe 集成——他们亲自飞到用户办公室，帮用户写代码。

为什么这样必要？因为：

• 早期用户遇到的问题，你不知道
• 你能在用户场景里看到真实使用情况
• 用户因为你的"手工服务"对你忠诚（这是后期无法买的）

策略 2：手工做将来要自动化的事

早期，所有"可自动化"的事都先手工做。

业务	早期手工做	后期自动化
DoorDash	Tony Xu 自己开车送	调度系统
Airbnb	Brian Chesky 亲自帮房东拍照	摄影师网络
Stripe	兄弟手工写集成代码	SDK + 文档
Twitch	Justin Kan 戴摄像头直播 24/7	平台让其他人播

关键：手工做的事，恰好是产品核心价值——这样你能学到产品最关键的部分。

策略 3：为早期用户创造极致体验

PG 2013："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 2013

策略 4：紧密反馈循环

每周做一次：

1. 看用户数据：上周用户做了什么？
2. 访谈 5 个用户：他们喜欢什么？讨厌什么？
3. 改产品：基于反馈快速迭代
4. 重复

循环周期：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（a16z 联合创始人，Netscape 创始人）在 2007 年博客 The Only Thing That Matters 中系统化的概念。这篇博客的标题极其直白——"唯一重要的事"。Andreessen 的核心论点是：创业公司只有一个任务——达到 PMF。在此之前不要做任何别的事。 招人、做市场、谈合作——在 PMF 之前做这些都是在浪费精力。

这个框架在整个创业方法论体系里具有锚定性的地位：它是 01 模块全部用户洞察 和 02 模块全部商业模式设计 的最终验证——你把用户看清楚了吗？把商业模式画出来了吗？很好。现在出去问你的用户："如果明天你不能再用了——你会有多失望？" 用户用脚投票的那个答案，比你在所有 canvas 上画的都要接近真相。

"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% 测试（2009，最经典）

Sean Ellis（"Growth Hacker"概念提出者，2010 博文）在 2009 年发明的简单测试：

"如果明天起你不能用这个产品了，你会有多失望？"

• A. 非常失望
• B. 有点失望
• C. 不失望
• D. 我已经不用了

PMF 阈值：至少 40% 的用户选 A。

Sean Ellis 2009 跑过几十家公司发现：低于 40% 的公司，无论怎么优化增长都是死路；高于 40% 后，增长变成"添加柴火"——投入就有产出。

注意：

• 只调查"活跃用户"——不是注册用户
• 至少 40 个有效回复
• 调查时机：用户使用 2 周后

层次 2：Marc Andreessen 的"感觉"（2007）

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）

目标：找到一群"非常失望如果没有这个产品"的用户。

具体做法：

1. 01 模块用户访谈——找 100 个真实用户对话
2. 02 模块 VPC/BMC——画出价值匹配
3. MVP + DTDTNS——手工服务前 10 个用户
4. Sean Ellis 40% 测试

阶段 2：达成 PMF

特征：

• 40% 测试通过
• 留存曲线水平（不再衰减）
• 用户主动推荐（不需要奖励）

阶段 3：维持 PMF（post-PMF）

目标：在 PMF 基础上扩大规模，但不能稀释 PMF。

具体做法：

• 投放增长（AARRR）
• 招聘团队
• 国际化

注意：很多公司死于"PMF 之后过快扩张"——WeWork（2019）、Quibi（2020）都是反例。

案例：Superhuman 的 PMF 流程（2018-2019）

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 客户的复购率

李泽湘 2024 的标准："用户愿意等你的产品 + 经销商愿意预付定金"——这是硬件 PMF。

常见误区

误区	修正
把"用户喜欢"当 PMF	PMF 是"非常失望如果没有"，不是"喜欢"
过早追求 PMF 后增长	没到 PMF 就投放广告 = 烧钱
40% 测试只用一次	PMF 是动态的，每月测一次
PMF 后停止访谈	PMF 后更要访谈——避免稀释

与其他工具的关系

• 上游：MVP + DTDTNS（PMF 的前置）
• 下游：工具四单元经济学（PMF 后才算）、工具五 AARRR（PMF 后的增长体系）

---

工具四：单元经济学（Unit Economics）

是什么

单元经济学研究的是**"按一个客户单元算，这门生意是否赚钱"**——而不是"按整体算"。

核心公式：

LTV（客户终身价值）> CAC（获客成本）× 3

如果 LTV > 3 × CAC，单元经济学健康；如果 LTV < CAC，每获一个客户就亏一个，客户越多死得越快。

为什么用

核心问题：很多"快速增长"的公司，本质是"快速烧钱"。

"亏在每一个客户身上，靠规模来摊薄"——这是 Webvan（1999 失败）、WeWork（2019）、Ofo（2018 失败）的共同死法。

单元经济学强制你回答：

"去掉所有规模效应，单看一个客户——这门生意能赚钱吗？"

如果不能，规模越大越糟糕。

为什么放在 PMF 后：pre-PMF 阶段，用户都还没留下来——何谈 LTV？单元经济学只有在 PMF 达成后才有意义，因为 LTV 依赖留存曲线，而留存曲线水平是 PMF 的标志。

怎么用

步骤 1：定义"单元"

不同的生意有不同的"单元"：

生意类型	单元
SaaS	一个订阅用户
电商	一个订单
网约车	一次出行
硬件	一台设备
双边市场	一笔交易

步骤 2：计算 CAC（获客成本）

CAC = 销售与营销总成本 / 新增客户数

包括：广告、营销人员工资、销售提成、折扣、推荐奖励。

注意：要区分"paid CAC"（付费获客）和"organic CAC"（自然流量）。只用 paid CAC 做决策——organic 是免费的但不能依赖。

步骤 3：计算 LTV（客户终身价值）

简单版：

LTV = ARPU（单客户单期收入） × Gross Margin × 生命周期

生命周期 = 1 / 月流失率（例：月流失率 5% → 生命周期 = 20 个月）

进阶版——考虑留存曲线衰减：

LTV = Σ (第 N 月留存率 × ARPU × 毛利率)

步骤 4：看 LTV/CAC 比值和回本期

指标	健康标准
LTV/CAC	> 3
回本期（CAC/月毛利）	< 12 个月
CAC 占首单收入比例	< 50%

步骤 5：敏感性分析

关键问题：如果某个参数变差 20%，这门生意还成立吗？

• CAC 上涨 50%（竞争加剧）？
• LTV 下降 30%（留存差）？
• 毛利率从 80% 降到 60%（成本上升）？

如果任何一个变化让你跌破 LTV/CAC = 1，说明这门生意非常脆弱。

案例：Slack 的单元经济学（2014-2017）

Slack 早期数据（2014 年公开数据，简化）：

指标	数据
ARPU	$50/月/团队
平均团队规模	10 人
人均 ARPU	$5/月
毛利率	85%
月流失率（团队级）	3%
团队生命周期	33 个月
LTV（团队级）	$50 × 33 × 85$1,402
CAC（团队级，含销售+营销）	~$300
LTV/CAC	4.67 ✅
回本期	6 个月 ✅

Slack 的单元经济学是 SaaS 标杆——这也是为什么 Slack 能在 2019 年以 $230 亿估值直接上市（DPO）。

案例：奇绩创坛投资框架（2020 至今）

陆奇的奇绩创坛（YC 中国版）在评估项目时，单元经济学是核心指标之一。陆奇公开讲过的判断标准：

"我们看早期项目，不要求 LTV/CAC 已经大于 3——但必须能从已有数据推算出，规模放大后能做到 LTV/CAC > 3。"

这就是为什么奇绩创坛会反复问创业者：

• 你的"获客成本"会随规模怎么变化？（规模效应）
• 你的"留存"会随时间怎么变化？（产品迭代效应）
• 你的"ARPU"会随用户深度怎么变化？（交叉销售）

如果三个问题都能正向回答，单元经济学就有放大的可能。

案例：Ofo vs 美团单车的反例

Ofo（2018 年倒闭）的单元经济学：

指标	数据
单车成本	$150-300
单车日订单	3-5 单
单订单收入	¥0.5-1（大量免费券）
单车日收入	¥1.5-5
维护+调度成本	¥3-5/天/辆
单车日毛利	-1 到 -3 元

Ofo 每投放一辆车，每天都在亏钱——规模越大亏得越多。

美团单车（青桔、哈啰类似）能活下来，核心是重新算了单元经济学：

• 提高客单价（取消大规模免费券）
• 提高单车使用率（精准调度）
• 降低维护成本（更耐用的硬件）

常见误区

误区	修正
用整体 P&L 算	必须按一个单元算
不区分 paid/organic CAC	用 paid CAC，因为 organic 不能 scale
不算回本期	LTV/CAC > 3 但回本期 24 个月也是危险的（现金会先烧光）
不算敏感性	一个参数变化就崩盘的生意不能投
不算规模效应	CAC 在规模后是会涨还是降？必须思考

与其他工具的关系

• 上游：02 BMC/Lean Canvas 的"成本结构"和"收入来源"；PMF（PMF 后才算）
• 下游：04 Default Alive/Dead（单元经济学 + 规模 = 公司级 Default 状态）

---

工具五：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 2007 的诊断：

• 衰减 > 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（2006-2008）

环节	Facebook 2006 数据
Acquisition	高——校园口碑
Activation	超快——注册后 1 小时内 60% 加了好友
Retention	超强的 D1/D7/D30 留存（行业最高）
Referral	K 因子 > 1（自然增长）
Revenue	早期没收入（2007 后才商业化）

洞察：Facebook 早期完全没考虑 Revenue——前 4 环做好后，Revenue 自然就来。

案例：奇绩创坛评估框架（2020 至今）

陆奇的奇绩创坛用 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 个特征：

1. 反映用户获得的价值（不是公司收入）
2. 可衡量（有具体数字）
3. 可对齐（全公司都能为它工作）

为什么用

核心问题：早期公司每个部门有不同的 KPI，互相内耗。

部门	自己的 KPI
市场	注册数
产品	DAU
销售	收入
客服	工单响应时间

每个部门优化自己的 KPI——但这些 KPI 之间可能矛盾（市场为了注册数投放低质量流量 → 拉低 Retention）。

北极星指标 = 全员指向同一方向。

怎么用

步骤 1：找候选北极星

每个生意有不同的北极星：

公司	北极星指标
Airbnb	已预订的晚数（Nights Booked）
Facebook	每日活跃用户中加 5+ 好友的比例
Slack	已发送消息数（每周）
Spotify	总收听时长
WhatsApp	已发送消息数
Netflix	每月观看时长
Quora	已回答问题数
Twitch	同时在线主播数

规律：北极星指标都是用户价值的核心——不是公司收入。

步骤 2：用 3 个标准筛选

标准	例子（Airbnb 选 "Nights Booked"）
反映用户价值	"完成一次入住" = 用户获得了价值
可衡量	每天/每周都能查到
可对齐	市场、产品、客服都能影响它

反例：Airbnb 如果用"收入"作北极星——市场可能推高价房源（短期提升收入，但损害用户体验和长期增长）。

步骤 3：拆解到部门

北极星是 North Star，每个部门要有自己的"输入指标"：

                North Star
                    ▲
                    │
        ┌───────────┼───────────┐
        │           │           │
    市场输入    产品输入    运营输入
    注册数      激活率      留存率

例子（Airbnb）：

• 北极星：Nights Booked
• 市场输入：注册房东数
• 产品输入：预订流程转化率
• 运营输入：客服响应时间

步骤 4：每周看北极星

全公司每周看一次北极星——这成为团队的"心跳"。

案例：Slack 的北极星演化（2014-2019）

Slack 早期用"注册用户数"——发现这是错的：

注册用户不等于活跃用户。Slack 改用"已发送消息数"——这反映用户真的在用。

但 Slack 后来发现"已发送消息数"还不够——因为可能少数活跃用户发了很多消息。

Slack 最终的北极星："每周发送 2000+ 条消息的团队数"——这是 PMF 的临界点（团队规模 + 使用深度）。

这就是 Slack 的 Aha Moment——团队发够 2000 条消息后，几乎不会再换工具。

案例：李泽湘体系的硬件北极星

硬件的北极星更复杂——硬件销售是低频行为，不能用 DAU。

公司	北极星
大疆（消费级）	年度活跃飞手数（每年至少飞 10 次）
云鲸	月活扫地机器人（每月至少扫 8 次）
希迪智驾	累计无人驾驶里程（每月）

共同特点：用"使用深度"而非"销售数量"——因为硬件创业的真正价值是用户持续使用，不是销售一次性收入。

常见误区

误区	修正
北极星 = 收入	收入是滞后指标——北极星应该是先行指标（用户价值）
多个北极星	只能有一个——多了就没对齐
北极星永远不变	业务阶段变了，北极星也会变（Slack 就改过）
没有部门输入指标	北极星必须能拆解到部门

与其他工具的关系

• 上游：AARRR（北极星是 AARRR 中某一个环节的核心指标）
• 下游：OKR（把北极星拆到季度目标）

---

工具七：Aha Moment + 留存曲线

是什么

Aha Moment（顿悟时刻） 是用户第一次"感受到产品价值"的瞬间。

经典 Aha Moment 案例：

公司	Aha Moment
Facebook	7 天内加 10 个好友（2008）
Twitter	关注 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（2008）后，新手引导全部围绕"加好友"——这是 Facebook 早期增长的核心引擎。

留存曲线的价值：是 PMF 最客观的指标。

Andrew Chen（a16z）2012："If your retention curve flattens out, you have PMF. If it keeps declining, you don't."

怎么用

步骤 1：用数据找 Aha Moment

方法：Cohort 分析 + 相关性分析。

1. 找出留下来的用户（D30 留存）
2. 看他们在 D7 内做了什么——什么行为显著区分留存和流失用户？
3. 那个行为就是 Aha Moment 候选

注意：相关性 ≠ 因果。需要进一步测试（强制新用户体验这个 Aha Moment，看留存是否提升）。

步骤 2：围绕 Aha Moment 优化新手引导

目标：让用户在最短时间内（最好 D1）完成 Aha Moment。

公司	围绕 Aha Moment 的引导
Facebook	新手引导强制推荐 10+ 好友
Twitter	强制关注 30 个人
Slack	团队加入时强制邀请 3+ 同事
Dropbox	安装后强制完成第一次同步

步骤 3：监控留存曲线

留存曲线的 3 种形态：

形态	含义	行动
持续下降	没 PMF	回到 PMF 验证
下降后水平	有 PMF（小众）	扩大市场
下降后水平且高水平	有 PMF（大众）	加速增长

案例：YC W25 整批的 Aha Moment（2025）

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 才有意义）

---

工具八：OKR（Objectives and Key Results）

是什么

OKR（Objectives and Key Results） 是 Andy Grove 在 Intel 1970s 发明、John Doerr 在 Google 1999 推广的目标管理工具。

结构：

Objective（目标）：定性的方向性目标
    │
    ├── Key Result 1（关键结果 1）：定量的可衡量结果
    ├── Key Result 2：定量的可衡量结果
    └── Key Result 3：定量的可衡量结果

经典例子（John Doerr《衡量什么最重要》2018）：

O：让 Android 成为移动操作系统领导者

• KR1：Android 全球市场份额从 X% 提升到 Y%
• KR2：Android 应用数量从 X 万提升到 Y 万
• KR3：Android 设备激活量从 X 亿提升到 Y 亿

为什么用

核心问题：早期公司有战略但没落地——战略在 PPT 里，员工在做不知道为什么的事。

OKR 解决 3 个问题：

1. 对齐：全员指向同一方向
2. 聚焦：每季度只做最重要的 3-5 件事
3. 可衡量：从模糊愿景到具体数字

John Doerr 给 Google 的第一堂 OKR 课（1999）："如果你写下来，你就更可能做到"。

为什么放在增长阶段：OKR 是 北极星指标 的直接下游——北极星是全公司对齐的方向，OKR 把它拆解到部门和个人的季度目标。只有当公司有一定规模（10+ 人）才真正需要 OKR——3-5 人团队靠口头沟通就够。

怎么用

步骤 1：写年度战略 OKR

公司每年定 3-5 个 O——通常是 CEO 主导。

好 O 的特征：

• 定性（不是数字）
• 有方向性（不是描述现状）
• 有激励性（不是"维护现状"）

步骤 2：写季度执行 OKR

每个 O 拆成 3-5 个 KR——每季度更新。

好 KR 的特征：

• 定量（必须有数字）
• 有挑战（70% 达成率是健康的）
• 有时间窗口（季度内可衡量）

步骤 3：从公司 → 部门 → 个人

层级	OKR 数量	周期
公司	3-5 个 O	年度
部门	2-3 个 O	季度
个人	2-3 个 O	季度

步骤 4：每周 check-in

每周团队会议只看 OKR 进度：

• KR 进度多少？
• 卡在哪里？
• 需要什么支持？

OKR 不是年终评估——是每周对齐工具。

案例：Google 的 OKR 演化（1999 至今）

Google 1999 年开始用 OKR（John Doerr 教的）：

阶段	特点
早期（1999-2004）	创始人主导，每个 O 都很激进
中期（2004-2015）	部门 OKR 自治，CEO 抓顶层
成熟期（2015-至今）	OKR 与"登月"项目结合（如 Waymo、Verily）

Larry Page 2012 年的著名 OKR：

O：让 Google 成为机器学习领域的绝对领导者

• KR1：建立 100+ 人的 ML 研究团队
• KR2：在 3 个产品中应用 ML（搜索、广告、翻译）
• KR3：发表 50+ 篇顶会论文

结果：这个 OKR 直接催生了 Google Brain、DeepMind 收购（2014）、TensorFlow 开源（2015）——为 Google 在 AI 时代奠定基础。

案例：YC W25 公司的 OKR（2023-2025）

Garry Tan 2023 年上任后推广的 YC 标准 OKR 模板：

O（季度）	KR
O1：找到 PMF	- KR1：周活用户 +50% - KR2：Sean Ellis 40% 测试达到 30% - KR3：留存曲线 D30 > 30%
O2：建立可重复的销售流程	- KR1：每周 10 个 demo - KR2：从 demo 到 close 转化率 20% - KR3：销售周期 < 30 天
O3：建立健康的团队	- KR1：招聘 3 个核心岗位 - KR2：员工 NPS > 50 - KR3：核心团队稳定性 > 90%

案例：李泽湘体系的"硬件 OKR"

硬件创业的 OKR 与软件不同——周期更长。

云鲸典型 OKR（简化）：

季度	O	KR
Q1	完成 J3 设计	- KR1：硬件设计冻结 - KR2：开模完成 - KR3：BOM 成本降低 15%
Q2	量产准备	- KR1：100 台试产 - KR2：良率 90% - KR3：通过质量认证
Q3	上市	- KR1：首批 1 万台交付 - KR2：渠道铺货 5000 家 - KR3：众筹 $5M
Q4	增长	- KR1：销售 10 万台 - KR2：CES 反馈良好 - KR3：海外渠道签约 10 国

特点：硬件 OKR 的 KR 更"硬"——具体的物理指标（良率、认证、交付）。

常见误区

误区	修正
OKR = KPI	OKR 是对齐工具，KPI 是考核工具——不要混
KR 太多	每个 O 最多 5 个 KR——多了就不聚焦
OKR 用于考核	OKR 用于对齐——考核用单独的"绩效"
OKR 写完不更新	必须每周 check-in
OKR 太保守	70% 达成率是健康的——100% 说明目标太低

与其他工具的关系

• 上游：北极星指标（北极星 → OKR 的 O）
• 下游：周会/月会（OKR 是议程核心）
• 平行：Founder Mode（OKR 是对齐工具，Founder Mode 是运营哲学——两者可以共存）

---

工具九：Founder Mode（创始人模式）

"There are two different ways to run a company: founder mode and manager mode. Till now most people even in Silicon Valley have implicitly assumed that scaling a startup meant switching to manager mode. But from the examples of successful founders, we can infer another way."

—— Paul Graham, Founder Mode (September 2024)

是什么

Founder Mode 是 Paul Graham 2024 年 9 月发表的 essay 中提出的概念——也许是 PG 自"Do Things That Don't Scale"（2013）以来最具影响力的单篇。

核心主张：传统的"公司规模化 = 切换到职业经理人模式"教条是错的。最好的创始人用另一种方式运营公司——Founder Mode——它的操作手册还没有被写出来，但它的轮廓可以从 Steve Jobs、Jensen Huang、Brian Chesky 等人的实践中辨认。

维度	Manager Mode（经理人模式）	Founder Mode（创始人模式）
组织架构	层级分权——CEO 只接触直接下属	扁平穿透——CEO 直接与各层级的人沟通
信息流动	通过层级过滤上报	Skip-level 是常态，不是例外
决策方式	授权给"黑盒子"部门	创始人深入每个细节做判断
用人哲学	"雇好人，给他们空间"	"雇对人，但创始人要亲自看关键细节"
会议模式	按组织架构开	按重要性开——Jobs 每年带最重要的 100 人 retreat，不论职级
公司氛围	专业、流程化	像一个大号 startup
教科书态度	商学院教的"正确方式"	商学院没教，因为没有书写过

为什么用

PG 写这篇 essay 的直接触发是 Brian Chesky（Airbnb CEO）在 YC 的一次演讲（2024）——被在场很多人称为"听过最好的演讲"。

Chesky 的经历：

1. Airbnb 成功后，所有人都告诉他"该切换到 manager mode 了"——雇最好的高管，给他们充分的自主权
2. 结果：灾难性的。PG 的原文是："hire professional fakers and let them drive the company into the ground."
3. Chesky 开始研究 Steve Jobs 怎么运营 Apple——然后彻底改变了自己的运营方式
4. 他重建设计团队的方式与 Jobs 几乎一样——直接深度参与，而不是授权给某个 VP

Founder Mode 的实用价值：

• 对抗"职业伪装者"：有经验的高管中有相当一部分擅长在层级组织中生存，但不擅长实际创造价值。Manager Mode 给这些人提供了完美的保护壳——他们只对直接上级汇报
• 保持产品直觉：当创始人被隔离在层层汇报之后，他们失去了对产品细节的感知——而这些细节往往是战略优势的来源
• 拒绝被 gaslighting：PG 指出创始人正在被两边 gaslight——VC/顾问说"你必须切换到 manager mode"，而当创始人真的照做后，员工又抱怨创始人不管事了

PG 2024："The founder who feels like they're being gaslit is probably right."

为什么放在增长阶段：Founder Mode 的真正考验在公司从 10 人扩展到 100+ 人的过程中——这是 Manager Mode 的压力最大的时候（"你该雇职业经理人了"）。在 PMF 之前，公司天然就是 Founder Mode；PMF 后扩张时，才是 Founder Mode vs Manager Mode 的抉择时刻。

怎么用

步骤 1：识别你是否需要 Founder Mode

Founder Mode 不是对所有公司都适用。判断标准：

信号	表示你需要 Founder Mode	表示你更适合 Manager Mode
产品复杂度	你的产品涉及多个领域的深度耦合（如 Apple 的软硬一体）	你的产品是标准化的、可被流程管理的
创新阶段	你还在定义品类，而非优化已有品类	你在一个成熟市场里做规模化执行
你的独特洞察	你对产品/用户有别人没有的洞察	洞察已经内化到组织中，不需要你个人把关
人才密度	你的核心团队是"匠人"型的，能理解和执行你的高标准	团队足够大，已经建立了独立运转的能力
你的性格	你真的想深入细节——不是控制狂，是有判断力	你对细节感到疲惫，愿意信任专业经理人

关键区分：Founder Mode ≠ micromanagement（微观管理）。PG 在 2025 年补充说："You can go too far in founder mode and veer into micromanaging. The difference is: are you adding value with your involvement, or just adding friction?"

步骤 2：建立 Founder Mode 的操作习惯

习惯 1：Skip-level 常态化

• 不要只和直接下属开会——定期与二级、三级员工一对一
• Jobs 的做法：每年选出最重要的 100 人（不论 title），一起 retreat
• Jensen Huang 的做法：60 个直接下属，不设中间层

习惯 2：在关键决策上保持"第一手信息"

• 不依赖汇报 PPT——直接看原始数据、看用户访谈录像、看产品 demo
• 在"产品方向"和"用人"这两个维度上，永远不委托判断

习惯 3：建立"不通过层级"的信息渠道

• 保留一批早期员工/用户作为直接信息源
• PG 的例子：YC 合伙人会直接和早期创始人保持联系，不通过 batch manager

步骤 3：避免 Founder Mode 的常见陷阱

陷阱	表现	怎么避免
变成 unblockable bottleneck	所有决策都要创始人签，团队停滞	区分"我得看"和"团队完全可以自己定"
Demotivate 团队	创始人跳级干预让中层觉得被架空	Skip-level 是听和教，不是越级下命令
只看细节不看大局	陷在像素级打磨，忘了战略方向	固定时间比例——70% 战略 + 30% 细节
不可复制	创始人不在公司就停摆	把 Founder Mode 的直觉教给下一代 leader
变成 cult of personality	团队盲从创始人，失去独立思考	鼓励争论——Jobs 本人就以激烈争论著称

案例：Steve Jobs 的 Founder Mode（1997-2011）

Jobs 是 PG 文章中反复提及的原型案例：

• 年度 Top 100 retreat：不论组织架构，每年带最重要的 100 人去 retreat，讨论下一年的方向。这 100 人的选择本身就是战略信号。
• 亲自看设计细节：Jony Ive 回忆 Jobs 每天都会来设计工作室，不是来"审批"，而是来参与讨论——他能看到设计师自己没注意到的问题。
• 拒绝 "hire good people and leave them alone"：Jobs 相信跨领域的高标准碰撞才能产生最好的结果。他会把不同领域的专家放在一个房间里争论。

另一个极端是 John Sculley（1983-1993 任 Apple CEO）——专业的职业经理人，用 Manager Mode 运营 Apple。结果：Apple 几乎死亡。

案例：Jensen Huang 的 Founder Mode（1993 至今）

Nvidia CEO Jensen Huang 是 PG 文章中另一个核心案例：

• 60 个直接下属：传统管理学认为一个人最多管理 7-10 个下属。Jensen 有 60 个，而且他不开 1:1——他让所有讨论在公开场合进行，所有人可以听
• 在食堂吃饭：不设高管餐厅——任何员工都可以在午饭时和他聊
• 直接看代码 review：Jensen 会直接参与技术讨论——不是做决策，而是确保讨论的质量
• 结果：Nvidia 成为全球市值最高的公司之一（2024-2025），而且 Jensen 保持着对技术方向的直觉

案例：深圳科创学院体系下的"创始人深度参与"（2022 至今）

李泽湘体系的成功案例也印证了 Founder Mode——

云鲸创始人张峻彬在原型机阶段，自己就是第一个装机工——在松山湖共享工厂，他自己组装第一批 100 台机器。这不是因为缺人，而是因为只有亲自装，才知道设计哪里不合理。

李泽湘 2024："我见过最好的硬件创业者，没有一个不是亲自下产线的。不是你去看一眼就走，是你在产线待三天，和产线工人一起吃盒饭。"

这就是硬件版的 Founder Mode——你无法把"造东西的感觉"委托给别人。

与其他工具的关系

• 上游：01 模块 Schlep Blindness + MSPW 哲学（Founder Mode 是 "Make something people want" 的"运营版"——不只做什么，还有怎么运营）
• 上游：01 模块第一性原理（Founder Mode 要求创始人基于自己的直觉做判断——第一性原理是这种直觉的理性基础）
• 平行：OKR（OKR 是对齐工具，Founder Mode 是运营哲学——两者可以共存）
• 矛盾：Manager Mode 的组织架构（如果你发现自己公司 50 人以上、产品已标准化、创始人对细节已失去 passion——也许你应该考虑退出）

一句话：Founder Mode 不是"创始人可以任性"的 license——是提醒你：当你被告知"该像职业经理人一样管公司了"，你有权利说"不"。因为最好的公司，绝大多数不是职业经理人管出来的。

---

工具十：Pivot 决策框架

"A pivot is a structured course correction designed to test a new fundamental hypothesis about the product, business model, and engine of growth."

—— Eric Ries, The Lean Startup (2011)

是什么

Pivot 是在保持愿景不变的前提下，调整产品、用户、技术、商业模式的具体策略。Pivot ≠ 放弃——是结构化的方向修正。

Eric Ries 2011《精益创业》定义了 10 种 pivot 类型——这是创业者最常被忽略的"工具箱"。

为什么用

核心问题：YC 最频繁给的建议之一——"什么时候坚持，什么时候换方向"是早期创业者最难的决策。

两组数据：

• 95% 的成功创业公司都 pivot 过——Airbnb（气垫床→短租）、Slack（游戏→沟通）、Instagram（check-in→照片）
• 但"pivot 上瘾"也是危险信号——每次面试时都说"我们刚 pivot 了"会让投资人警惕

判断标准：pivot 应该是数据驱动的（PMF 长期失败、留存曲线持续下降），不是"感觉驱动"的（"我有点累了"）。

怎么用

步骤 1：识别需要 pivot 的 5 个信号

信号	含义
Sean Ellis 40% 测试长期低于 30%	无论怎么改产品都上不去
留存曲线持续下降（不水平）	用户用一次就走
CAC 持续上升，自然增长消失	用户不再主动推荐
创始团队失去激情	自己都不愿意用产品
竞争对手定义的市场越来越小	你的池塘在干涸

5 个信号里有 2-3 个同时出现 = 应该认真考虑 pivot。

步骤 2：选对 pivot 类型（Eric Ries 10 种）

#	Pivot 类型	改变什么	案例
1	Zoom-in	一个功能变成整个产品	Justin.tv 把"直播频道"功能变成 Twitch
2	Zoom-out	整个产品变成一个功能	Android 起初是相机 OS，后来变成手机 OS
3	Customer Segment	同产品，换目标用户	Facebook 从哈佛学生 → 全球用户
4	Customer Need	同用户，换解决的需求	Slack 把游戏换成了沟通
5	Platform	从 App 变成平台，或反之	Twitter 从"广播 SMS"变成"社交媒体平台"
6	Business Architecture	B2B ↔ B2C 切换	Airbnb 从"做会议住宿"→"短租市场"
7	Value Capture	改变现方式（订阅 → 免费 + 广告 → 交易费）	Affirm 从软件订阅 → 信用分期
8	Engine of Growth	病毒 → 粘性 → 付费三种增长引擎切换	Dropbox 从付费 → 推荐（病毒）
9	Channel	改变销售渠道	Dollar Shave Club 从线下零售 → DTC 订阅
10	Technology	用新技术实现同样功能	Netflix 从快递 DVD → 流媒体

步骤 3：执行 pivot——保留 vs 抛弃

Pivot 不是"推倒重来"——保留什么很关键：

• 保留：愿景、核心价值观、团队信任、关键资源（用户数据 / 技术 / 渠道）
• 抛弃：错误的产品假设、错误的目标用户、错误的增长引擎

案例：Airbnb 的 Customer Need + Zoom-out Pivot（2008-2009）

Airbnb 2008 年定位"会议期间出租气垫床"——服务的是"参加 SXSW 大会的参会者"——这是个很小的市场。

2009 年 Chesky 意识到：人们真正想要的是"便宜又有当地体验的住宿"——不只是会议期间。

Pivot：

• 保留：分享住宿的愿景
• 抛弃：会议场景、气垫床、目标用户群
• 改变：从"会议住宿"变成"全球短租市场"

结果：5 年内变成 $25B 公司，10 年内$100B。

案例：Slack 的 Customer Need Pivot（2012-2013）

Stewart Butterfield 团队做了一款游戏《Glitch》——3 年开发，用户活跃但无法商业化。

但他们注意到一件事：团队内部开发的沟通工具非常好用——所有团队成员都 love 它。

Pivot：

• 保留：开发 Glitch 过程中积累的"沟通工具技术"
• 抛弃：游戏本身
• 改变：从游戏公司变成"企业沟通工具公司"

结果：Slack 上市市值 $230 亿（2019）；Glitch 关闭后被 Butterfield 痛苦地描述为"我人生最大的失败"。

案例：李泽湘体系的希迪智驾（2016-2020）

希迪智驾（CiDi）早期做"通用自动驾驶"——和 Waymo、Cruise 直接竞争——这个市场太烧钱、太远。

Pivot：

• 保留：L4 自动驾驶技术
• 抛弃：开放道路场景
• 改变：聚焦"矿山 / 港口 / 园区"等封闭场景——这些场景的自动驾驶门槛低、商业价值高

结果：2025 年 12 月港交所主板上市——比开放道路的竞争对手早 5+ 年实现商业化。

常见误区

误区	修正
Pivot = 失败	95% 成功公司 pivot 过——Pivot 是常态
Pivot 太频繁	"Pivot 上瘾"是危险信号——每次面试都说"刚 pivot 了"会让投资人警惕
Pivot 推倒重来	保留愿景、团队、关键资源——抛弃的是错误假设
因为"做不下去了"才 pivot	主动 pivot vs 被动 pivot 完全不同——主动的是"看到更好的机会"
Pivot 不告诉投资人	YC 标准建议：pivot 立即告诉投资人（见 04 Investor Updates）

与其他工具的关系

• 上游：PMF（PMF 测试长期失败 = pivot 信号）、单元经济学（LTV/CAC 长期不健康 = pivot 信号）
• 下游：新的 MVP（pivot 后要重新做 MVP 验证新假设）
• 平行：Make something users LOVE（love 的产品不要轻易 pivot——pivot 是因为你做的没人要，不是因为没做到完美）

---

工具十一：Go-To-Market Strategy

"The best product doesn't win. The best product with the best distribution wins."

—— Marc Andreessen, 2020 a16z 演讲

是什么

GTM（Go-To-Market）战略——决定你怎么"进入市场"，即如何让目标用户找到你、买你、留下来。

工具五 AARRR 是漏斗指标——回答"哪个环节漏了"；GTM 战略是更高一层——回答"我们走哪条路进入市场"。

为什么用

核心问题：选错 GTM = 整个组织架构错——比如选了 SLG（销售驱动）却招了一群产品经理，或者选了 PLG（产品驱动）却雇了一个 cold-call 销售副总。

a16z 的 GTM framework（2018 起）是硅谷标准——明确每种 GTM 模式的取舍。

怎么用

步骤 1：选 4 种 GTM 模式之一

模式	核心	适合	代表
PLG（Product-Led Growth）	产品本身是获客/激活/留存工具	低 ACV、自服务、高频	Slack、Notion、Figma
SLG（Sales-Led Growth）	销售团队是增长引擎	高 ACV、复杂决策、B2B 企业	Salesforce、Snowflake、Palantir
Channel-led	通过分销商/经销商	多层级市场、地理扩张	Shopify、Microsoft、SAP
Community-led	通过用户社区驱动	开发者工具、开源产品	Vercel、Supabase、Linear

步骤 2：判断 GTM fit

问 3 个问题：

1. 用户的 ACV（年度合同价值）多大？ —— >10K 走 SLG，`<1K` 走 PLG
2. 决策需要多少人同意？ —— 1 人决策走 PLG，多部门决策走 SLG
3. 试错成本多低？ —— 30 秒试用走 PLG，6 个月 POC 走 SLG

步骤 3：每种 GTM 的关键 KPI

GTM 模式	核心 KPI	关注指标
PLG	转化漏斗	注册→激活→付费转化率、Time-to-Value
SLG	销售管道	Pipeline velocity、Win rate、Sales cycle
Channel-led	渠道激活	合作伙伴激活率、Partner-sourced revenue
Community-led	社区活跃	GitHub stars、Discord 活跃、社区贡献者

案例：Snowflake 的"先 PLG 再 SLG"（2015-2020）

Snowflake 早期 PLG——让数据工程师免费试用 → love 产品 → 团队订阅。

2018 年 IPO 前后叠加 SLG——专门的销售团队服务 Bloomberg、Capital One 这种大企业客户。

双模式 GTM：

• 数据工程师层：PLG（自助试用 → 团队订阅）
• CIO 层：SLG（销售团队 6 个月 POC → 千万级合同）

结果：2020 年 IPO 市值 $700 亿——SaaS 史上最大 IPO。

案例：Figma 的 PLG 杀死 Sketch（2016-2022）

Sketch 是设计师工具的霸主（2010-2015）——但它是桌面软件，每人 $99/年。

Figma 用 PLG 颠覆：

• 免费（学生 / 小团队）
• 浏览器直接打开（无需安装）
• 实时协同（团队核心需求）

结果：Figma 2022 年 Adobe 收购估值 $200 亿；Sketch 2024 年市场份额 < 10%。

打败 Sketch 的不是功能——是 GTM 模式。Sketch 必须走"购买 + 下载 + 安装"，Figma 直接"打开浏览器就开始用"。

案例：李泽湘体系的硬件 GTM

硬件创业的 GTM 通常是三段式：

阶段	渠道	验证目标
众筹	Kickstarter / Indiegogo	用户愿意预付定金
展会	CES / IFA	行业媒体主动报道
经销	Amazon / 京东 / 天猫	大众市场购买转化

云鲸 J1 的 GTM：Kickstarter 众筹 $5M → CES 2021 媒体报道 → 京东众筹 + 天猫旗舰店——这是硬件 GTM 的标准模板。

常见误区

误区	修正
"我们既 PLG 又 SLG"	早期必须选一个——同时做两个 = 都做不好
把 AARRR 当 GTM	AARRR 是漏斗指标，GTM 是更高一层的战略
选错 GTM 招错人	PLG 公司招 SLG 销售副总 = 灾难
GTM 一成不变	Snowflake 从 PLG 转 PLG+SLG——GTM 随公司阶段演进

与其他工具的关系

• 上游：PMF（PMF 前不要谈 GTM）
• 下游：PLG vs SLG（GTM 模式的具体抉择）、北极星指标（不同 GTM 有不同北极星）
• 延伸：02 Positioning（GTM 的前提是定位清晰）

---

工具十二：Product-Led Growth vs Sales-Led Growth

"If your product can sell itself, let it. If it can't, you need salespeople. But don't pretend you can do both."

—— Wes Bush, Product-Led Growth (2019)

是什么

PLG vs SLG 是创业公司最关键的增长模式抉择——决定整个组织架构、招人策略、花钱比例。

PLG（Product-Led Growth）：产品本身是获客、激活、留存、付费的工具——免费试用、产品自驱动。 SLG（Sales-Led Growth）：销售团队是增长引擎——demo、POC、签合同。

为什么用

核心问题：选错模式 = 招错人 = 走错路 = 失败。

• 大多数创业者默认 SLG（因为"销售驱动增长"听起来熟悉）——但现代 SaaS 50%+ 是 PLG
• 早期决定 PLG/SLG 的成本最低，后期切换的成本极高（要重新招聘、重组、改 KPI）

怎么用

步骤 1：用 ACR 模型判断

ACR = Activation Cost Ratio

ACR = 让用户达到 Aha Moment 的成本 / 用户付费后的 LTV

ACR	推荐模式
< 0.1（极低激活成本）	✅ PLG
0.1 - 1（中等）	⚠️ 混合（PLG + Sales-assist）
> 1（高激活成本，如需 6 个月 POC）	✅ SLG

步骤 2：PLG 和 SLG 的组织差异

维度	PLG 公司	SLG 公司
CEO 背景	产品 / 设计	销售 / BD
前 10 个 hire	工程师 / 设计师	销售 / SDR
核心 KPI	注册→付费转化率	销售管道 / Win rate
花钱比例	70% 产品 / 30% GTM	30% 产品 / 70% GTM
典型公司	Slack、Figma、Notion	Salesforce、Snowflake、Palantir

步骤 3：PLG 的"产品自驱动"设计

PLG 不是"产品好就够了"——必须故意设计：

• Free tier 必须能独立产生 Aha Moment（不付费就能感受到价值）
• 付费墙（paywall）放在 Aha Moment 之后（先用上瘾再收费）
• 协作功能天然病毒（邀请同事解锁全部功能）
• Onboarding 必须 self-serve（不需要销售介入）

案例：Slack 的 PLG（2014-2019）

Slack 是经典 PLG——团队发 2000 条消息就 love 上，自然带来下个团队。

Slack 的 PLG 设计：

• Free tier：10K 条历史消息（够小团队用）
• 付费墙：超过 10K 历史 / 需要合规导出（企业客户的需求）
• 协作病毒：邀请同事 = 解锁更多功能

结果：5 年内 $230 亿市值，几乎不花钱 marketing。

案例：Snowflake 的 PLG + SLG 混合（2018 起）

Snowflake 从纯 PLG 起，2018 后叠加 SLG：

客户类型	GTM 模式	销售介入
数据工程师（小团队）	PLG	无
中型企业	PLG + Sales-assist	销售帮助已激活用户付费
大企业（Bloomberg / Capital One）	SLG	销售团队 6 个月 POC

关键：Snowflake 不是"既做 PLG 又做 SLG"——是按客户类型分层做。

案例：Linear 的纯 PLG（2019-2024）

Linear 从未雇佣销售——5 年 $50M ARR。

Linear 的 PLG 哲学：

• 创始人 Karri Saarinen 亲自回复 Twitter 每条提及（社区驱动）
• Free tier 永久免费（个人用户）
• 付费墙：团队功能 + 私有项目
• 销售：零

Karri Saarinen 2023："我们不做'让所有人满意的产品'——我们做'让 1000 个深度用户离不开的产品'。"（呼应 01 Make something users LOVE）

常见误区

误区	修正
"我们既 PLG 又 SLG"	早期必须选一个——同时做两个 = 都做不好
PLG = 不需要销售	PLG 也需要销售——但是 Sales-assist（帮助已激活用户付费），不是 cold outreach
PLG 适合所有产品	PLG 只适合 ACR 低的——高 ACV 复杂决策的产品（如 ERP）必须 SLG
SLG 等于"雇佣很多销售"	SLG 的核心是"销售流程的可重复性"——没有 playbook 的销售就是浪费钱
PLG 永远免费	PLG 必须有清晰的付费路径——否则就是慈善

与其他工具的关系

• 上游：GTM Strategy（PLG vs SLG 是 GTM 模式的具体抉择）
• 下游：北极星指标（PLG 公司的北极星通常是"激活用户数"，SLG 公司通常是"ARR"）、OKR（不同模式的 KR 完全不同）
• 平行：02 Pricing（PLG 通常 freemium，SLG 通常 enterprise pricing）

---

工具十三：团队建设——从 3 人到 100 人

"Your first 10 hires determine the next 100. The next 100 determine the next 1000. So get the first 10 right or you're dead."

—— Michael Seibel, YC (2018 演讲)

"Fire fast. It's kinder than dragging it out. Everyone on the team already knows who doesn't belong."

—— Sam Altman, YC (2017 Office Hour)

是什么

团队建设 不只是招聘——是选对人、踢对人、以及让不同规模下的协作不崩溃。三个核心问题：

1. 你怎么知道这个人的能力是真货？ 很多人说话不算话——你需要"腥味"为自己背书
2. 发现人不合适了怎么办？ 顾及感情拖着不踢——最后伤的不是你一个人，是全团队
3. 团队从 3 人涨到 10 人、30 人、100 人，怎么让协作不崩？ 3 人的沟通模式到了 30 人会变成灾难

00 合伙人选择 讲了合伙人——但合伙人 → 第一个员工 → 10 人团队 → 组织的完整链条没讲。本工具把它一次性讲透。

本工具和 00 模块「导引」 的分工：

维度	00 导引：三层合作框架	03 工具十三：团队建设
时机	合伙之前——"我要不要和这个人一起做事？"	合伙之后——"我已经有了团队，接下来怎么管？"
解决的问题	不同深度合作（项目→产品→创业）各自该在开始前聊清楚什么	怎么验证真本事？人不行了怎么踢？3 人到 100 人怎么协作不崩？
输出的东西	一份口头或书面的共识（时间、分工、拍板权、退出约定）	一套可操作的流程（作品集审查、付费试做、背调话术、离职 SOP、规模速查表）

简单说：00 帮你选对人，03 帮你管好已经选的人。 两个都要——选对了但管崩了，和选错了硬撑，结果都一样是死。

为什么用

三个致命数据：

• 选错人：1 个错误早期招聘 = 损失 6 个月时间 + 稀释团队信任 + 错误文化传染（YC 统计）
• 踢太慢：团队里每个人都知道谁不该存在——只有 leader 不知道，或者知道却不敢做。拖得越久，优秀的人走得越快（"为什么烂的人留下，好的人反而要走？"——这就是优秀员工离职的第一理由）
• 规模不匹配：3 人团队的"口头同步"在 30 人团队里变成"谁也不知道谁在做什么"——30% 的团队在跨过 20 人时经历第一次协作崩溃

---

一、选人验证——让"腥味"为自己说话

大多数人面试表现和实际工作能力之间的差距，比你想象的大得多。一个人能在 30 分钟里讲得头头是道——不代表他能周末两天把一个模块写出来。你需要证据，不是表态。

1.1 让对方出作品集——不是看，是审

不要接受"我做过某个项目"的口头描述。要求对方拿出可以直接看的东西：

角色	要什么证据	怎么看
工程师	GitHub 上 3 个他自己写的 commit，不是团队的	看 commit message 是否清晰、代码结构是否干净、PR 讨论里他怎么回应 review
设计师	Figma 源文件，而非 PNG 成品	看他的图层命名、组件复用、变体使用——这比最终效果图更能说明他是不是"能协作的设计师"
产品经理	一份他写的 PRD 或用户访谈记录	看他是否区分"用户说了什么"和"用户实际做了什么"——这是 PM 的分水岭
运营/市场	一次他主导的活动复盘	看有没有数字、有没有归因、有没有"如果重来我会……"——没反思 = 没成长

关键原则：证据必须是他个人的产出，不是"我们团队做了 X"。一个人在团队项目里的贡献，往往被他自己的描述放大了 3 倍。

1.2 付费试做项目——钱是最好的过滤器

一次付费的短期试做，比十轮面试都管用。规则很简单：

• 1-2 天的真实任务——不是模拟题，是你 backlog 里真实需要做的事
• 按市场价格付费——不要免费。付费 = 你尊重他的时间；也 = 他拿了钱就必须按真实工作标准交付
• 看三样东西：
  1. 交付质量：他做出来的东西能不能直接用？
  2. 沟通方式：遇到 ambiguity 他主动问，还是闷头按自己的理解做？
  3. 准时性：约定的时间交付了吗？迟了有没有提前说？

早期 1-3 号员工原则上都应该经过付费试做——因为你赌的不是这个人"行不行"，是你的公司"活不活"。

1.3 参考检查——三句话撬开前雇主的嘴

不要只看候选人给的 reference——他会给你说好话的朋友。真正有效的是背靠背找前同事：

对方身份	怎么问	听什么信号
前同事（平级）	"如果有一天你自己创业，你会拉他入伙吗？"	沉默超过 3 秒 = 不会。任何形式的"well…he's interesting" = 不会
前上级	"他最大的弱点是什么？你为这个弱点做过什么管理动作？"	如果对方说"没有"——在撒谎。每个人都有弱点。如果对方说了但后面加"但其实是小事"——那可能就是大事
前下级	"你觉得他在压力下会怎么对你？"	"他会保护团队" vs "他会找 scapegoat"——这两个答案区分了所有 leader

YC 经验：前 10 号员工的参考检查率应该做到 100%。一个没做参考检查就发 offer 的早期招聘 = 赌博。

1.4 第 1-3 号员工的招聘标准

关键原则：第 1-3 号员工决定公司文化。

YC Michael Seibel（2018）的标准：

• 必须能独立 work（不需要 micromanage）
• 必须能做 generalist 的事（不是只做一件）
• 必须 love 你的产品（不是只 love 你的工资）
• 必须接受早期风险（股票 > 现金）

招聘渠道（按优先级）：

1. 个人网络——前 1-3 号 100% 来自创始人网络
2. 推荐——前 4-10 号主要来自现有员工推荐
3. 招聘平台（LinkedIn / AngelList）——10 号员工开始用

1.5 Generalist vs Specialist 时机

阶段	推荐	原因
员工 1-3	Generalist（通才）	早期一切都在变——通才能快速切换
员工 4-10	Specialist（专家）+ Generalist 混合	业务开始稳定——某些岗位需要专精
员工 10+	Specialist	组织开始分工——专才创造高产出

---

二、退出机制——在第一天就把分手规则讲清楚

这是绝大多数早期团队最不敢谈、代价也最大的部分。

你觉得"都是朋友，谈退出的规则伤感情"——但事实是：不谈退出规则，到时候伤的才是真感情。 在关系最好的时候，把关系最坏时的规则写下来——这不是不信任，是保护这段关系。

2.1 Offer 之前就要说清楚的 5 句话

这 5 句话不在合同里，但比合同更管用——因为它在考验开始之前就设置好了预期：

#	要说的话	为什么这是"开头就说好"
1	"我们会有一个试用期——对你和我都试用。在这个阶段，你可以随时走，我也可以随时决定不合适。这不是威胁，是双向保护。"	拆掉"一旦入职就不能走"的心理包袱。双向试用 = 双方都有退路 = 双方都不会觉得被绑架
2	"期权分 4 年给——第 1 年结束才拿到第一笔。如果你在第 11 个月离开，一分钱期权都没有。这不是抠门——这是我需要确认你是长期的人。"	在对方还没投入感情之前，就把 vesting 摊在桌上。他接受了才入职——而不是入职 3 个月后"突然发现被剥削"
3	"如果有一天你或者我觉得不合适，我们怎么办？我的承诺是：我会给你一个诚实的 feedback，而不是突然通知你走。我也希望你给我同样的尊重。"	设置了一个"我们之间可以有 difficult conversation"的预期——这是所有健康分手的前提
4	"你写的所有代码/设计/文档，都属于公司——这是入职当天签的文件里写的。不是我不信任你——是因为如果以后有投资人或者收购方来问'这些东西是谁的'，公司要能回答。"	把 IP 归属这件事从"不信任"翻译成"公司的基础设施"。不是针对你，是所有人
5	"如果你离开，无论是主动还是被动——你的代码会留在仓库里，你的 commit 记录会一直保留。你在公司做过的所有贡献，没有人能抹掉。你只是不再是团队的一员了——你不是敌人。"	这是最重要的一句。它告诉对方：分手 ≠ 被清洗。你的工作痕迹会一直存在，你的声誉不会被抹杀——所以你不用在分手时拼命证明自己

这 5 句话的本质：把"可能会发生"的尴尬，变成"我们已经聊过"的默契。 聊过的东西不会吓到人——突然袭击才会。

2.2 Vesting——你最基本的退出保护

合伙人部分（00 模块）讲了 vesting，但前几个员工同样需要：

要素	合伙人	前 10 号员工
Vesting 周期	4 年	4 年
Cliff	1 年	1 年
加速条款	部分创始人要求 double trigger	员工一般不要求
离职后行权期	通常 90 天（ISO 标准）	90 天——但务必在合同里写清楚

一个被忽略但致命的问题：员工离职后必须在 90 天内行权（付钱买期权，否则作废）。但你的公司还没上市——这些期权不能随时卖，等于离职员工要掏一笔可能不小的钱买一张"不知道什么时候能变现的票"。很多人放弃行权——这等于他们在公司干了一两年，股票一分钱没拿到。

你应该做的事：在 offer letter 里把这件事讲清楚。不要说"公司给了你 10000 股期权"就完了——补一句："离职后你有 90 天决定是否行权，行权需要约 $X 的成本"。让他在入职第一天就知道这不是"白给的钱"。

2.3 怎么踢人——不伤团队的 4 步操作

当你确定一个人必须走——能力不够、文化不匹配、或者业务方向变了——以下是实际操作：

Step 1：你必须在其他人发现之前做决定

团队里每个人都知道谁不行——比你早 3 个月就知道。他们不说，是因为在等你说。你拖得越久，优秀的人越怀疑"这个 leader 是不是不敢做 hard call"——然后他们开始更新简历。

判断标准：如果你第三次对同一个人的同一个问题感到沮丧——这就是 fire 信号。不是因为这个人突然变差了，是因为你终于承认他不会改变了。

Step 2：一对一，当面说。不要绕。

错的做法	对的做法
"公司最近在做一些调整……"	"我决定让你离开团队。"
"也许我们可以试试换个岗位……"	"这不是能力问题——是我们需要的方向和你能提供的不匹配。"
说 30 分钟铺垫	3 分钟说完核心，剩下的时间回答他的问题

你需要提前准备好的：

• 最后一天是几号
• 赔偿方案（至少 N+1，他是早期员工——他在你最困难的时候加入了）
• 期权怎么处理（如果没到 cliff，明确说"很遗憾但 vesting 中断了"；如果到了 cliff，告诉他 90 天行权窗口和金额）
• 他需要签什么文件（离职协议、IP 确认——入离职都要 IP 确认）

Step 3：对团队，诚实但不八卦

当天——最晚第二天——把团队叫到一起。话术：

"XX 不会再和我们一起工作了。这是我和他共同的决定，不是因为谁做错了什么。我感激他在这里的每一份贡献。具体原因我不能替他说——但我想让你们从我嘴里听到这件事，而不是从小道消息。"

不要做的事：

• ❌ 不要说"他不是能力不行"——如果他就是能力不行，你在侮辱团队智商
• ❌ 不要说"他家里有事需要休息"——谎言会被戳穿，且显得你懦弱
• ❌ 不要列他的错误清单——你是在通知团队，不是在审判

要传达的信息：我们做了一起决定。他被尊重地对待了。公司会继续往前走。

Step 4：一对一和留下来的核心员工聊

通知完的 24 小时内，和团队里每个人单独聊 5 分钟。不需要解释"为什么走"——你需要确认的是：

• "你还好吗？你有什么问题想问我？"
• "我需要确认——你对公司方向没失去信心吧？"

大多数人会说"没事"——但他们会看你怎么 handle 这次分手。你 handle 的方式，就是他们对"如果我有一天要离开，公司会怎么对我"的答案。

2.4 代码和 IP 归属——不是信任问题，是基础设施

入职第一天签的字比任何口头承诺都管用：

文件	内容	不签的后果
IP 转让协议	在职期间所有工作成果（代码/设计/文档）的 IP 归公司	人走了说"那段核心代码是我写的，你继续用要付钱"
保密协议	公司信息不得外泄	人走了带着用户数据和竞品吃了顿饭
竞业禁止（视法律管辖区）	离职后 N 个月内不得去直接竞争对手	人走了直接加入竞品的同一个业务线

这些文件不是针对谁——是公司每一个人都签。第一天就签。 签完了归档在 HR 系统里——不要在融资尽调时翻箱倒柜找。

---

三、规模切换——3 → 10 → 30 → 100 的协作模式

核心原则：每一个规模拐点，你必须主动摧毁上一阶段的协作方式——否则它会在你不知情的时候自己崩溃。

3.1 3 人：创始人之间的默契

维度	模式
沟通	随时。同一张桌子，同一条 Slack 线程
决策	创始人 x 3 口头共识。每个人知道所有事
会议	不需要正式会议。Daily standup 在下楼买咖啡的时候顺便做完
分工	模糊。一个人管产品、一个人管代码、一个人管增长——但谁忙不过来了另外两个随时顶上

这个阶段的优势是信息完全对称——没有"我不知道"这回事。这个阶段的危险是你以为下一个阶段也会是这样。

3.2 10 人：必须开始写下来

当团队到 10 人，口头同步已经失效了——有些人不知道某些决策是怎么做出来的。你必须开始：

必须引入	具体做法
Weekly written updates	每周末每人写 5 行：这周做了什么、下周做什么、卡在哪。不用漂亮——但必须有。创始人先写
创始人 1:1（每周）	从 1 号员工开始，每周 30 分钟 1:1——不是布置任务，是听。问一句"你这周有什么 frustrate 你的事？"
决策权边界	明确哪些事不用问你——比如"选什么 UI 库"工程师自己定，"给用户赔多少钱"你必须批
正式 standup	每天 10 分钟——每个人说 1 分钟。不能超过

这个阶段最容易犯的错误：创始人还在用 3 人时代的逻辑——什么都要自己批。结果创始人变成 bottleneck，团队开始等——等到优秀的人受不了就走了。

3.3 30 人：管理层出现了

30 人——你不可能直接管 29 个人。你需要第一个 manager layer。

必须引入	具体做法
Team lead	每个 3-7 人的小团队有一个 lead。lead 不是"管人"的——是"把信息和决策在创始人和团队之间翻译"的人
Weekly all-hands	每周 30 分钟全员会：创始人讲上周 3 个亮点 + 本周 3 个优先事项 + 公司关键指标——然后 Q&A
Skip-level 1:1（每季度）	创始人直接和不是自己 direct report 的人聊——跳过 lead。不是 bypass lead，而是确认 lead 下面的声音你也能听到
部门 OKR	每个小团队的季度目标——不是创始人一个人定，是 lead 提案 + 创始人 approve

这个阶段最容易犯的错误：创始人不信任 lead，继续 skip-level 下任务——lead 被架空，团队在两个指挥系统里混乱。

3.4 100 人：制度替代个人

100 人——你不可能认识每个人。你现在运营的是一个组织，不是一个"大号团队"。

必须引入	具体做法
正式 org chart	每个人有明确的上级、角色、职责范围
季度规划周期	Q1 定 OKR → Q2 执行 → Q3 审视 → Q4 调整。不再是每月改方向
入职流程（onboarding）	新员工第 1 周谁来带、第 1 个月学什么、第 1 个季度完成什么——系统化
离职访谈	每个主动离职的人，HR 做一次 30 分钟访谈——不是挽留，是找出"为什么走"的系统性原因
文化文档	把"这里的人怎么工作"写成一页纸——不是价值观口号，是具体的行为描述。比如"我们吵架但不记仇"比"坦诚沟通"有用 10 倍
创始人的角色	不再是"最了解产品的人"——是"不断讲为什么这家公司存在的人"。你从 product leader 变成了 story teller

这个阶段最容易犯的错误：创始人觉得"公司大了，可以不管人了"——恰恰相反。100 人阶段，创始人不参与每一个 hire——但对每一个 manager 的 hire 仍然要有 veto。

3.5 规模切换速查表

团队规模	沟通方式	决策方式	创始人最该做的事	最容易爆的雷
3 人	口头、随时	三人共识	写代码、见用户	以为下个阶段也能这样
10 人	书面更新 + standup	创始人批关键决策，普通决策下放	每周 1:1 + 写 weekly update 带头	创始人变成 bottleneck
30 人	weekly all-hands + lead 层	lead 提方案，创始人 approve	面试每一个 lead + skip-level 1:1	创始人架空 lead，团队双头指挥
100 人	制度 + 季度规划	部门负责人批，创始人只批战略级	讲故事 + 招 manager + 保护文化	创始人觉得"可以不管人了"

---

案例：Stripe 兄弟的第 1 号员工（2010）

Patrick 和 John Collison 第 1 号员工是工程师 Saikat Saha——他后来成为 CTO，是 Stripe 文化的奠基人之一。

为什么是他：

• Patrick 的大学同学（个人网络）
• 通用工程师（generalist）
• Love Stripe 的"开发者优先"理念
• 接受 0.5% 期权 + 低于市场价的工资

Patrick Collison 2015："Saikat 不是我们招的第 1 个员工——他是 Stripe 文化的第 3 个定义者（我和 John 之后）。"

案例：Airbnb 的"文化委员会"（2009-2014）

Brian Chesky 前 10 号员工组建了 Airbnb 文化委员会——这个委员会决定谁能加入公司。

机制：

• 前 10 号员工是"文化守护者"
• 任何新 hire 必须经过 2 个文化委员会成员面试
• 文化不匹配的人——即使能力很强——也不招

Brian Chesky 2014："我们的招聘标准不是'这个人能不能 ship'——是'这个人能不能让 Airbnb 的文化延续到下一个 100 人'。"

这个机制持续了 5 年，是 Airbnb 能在 1500+ 员工时还保持 startup 文化的原因。

案例：Netflix 的"Keeper Test"——最诚实的淘汰机制

Netflix 的 Keeper Test 简单到残酷：

"如果这个人今天提离职，你会努力挽留他，还是你会觉得松了一口气？"

如果答案是"松了一口气"——立刻给他一笔丰厚的遣散费，让他走。不是因为他是坏人，是因为他对你团队的贡献已经低于你为他付出的管理成本了。

Patty McCord（Netflix 前 CHRO）2009："一个足够好的团队不需要'还行'的人。'还行'的人会传染——他们降低了整个团队的标准。"

案例：李泽湘体系的"工厂合伙人"（2018 起）

SZCAI 体系的硬件公司前 3 号员工必须有一个"懂工厂"的人——这不是合伙人，但是不可或缺的"第 0.5 号"。

李泽湘 2024："硬件创业的前 3 号员工，必须有一个能睡在产线上的人。这个人不是合伙人——但他比合伙人还重要，因为产品能不能造出来全靠他。"

希迪智驾的第 1 号员工：不是 AI 工程师，是一个有 20 年矿山经验的老矿工——他负责把"AI 自动驾驶"翻译成"矿山工人能听懂的语言"。

---

常见误区

误区	修正
前 10 号招 specialist	必须招 generalist——早期一切都在变
招朋友	朋友 ≠ 合适的员工——参考检查 + 试做项目
不做参考检查	早期 1 个错误招聘 = 损失 6 个月
期权给太少	前 10 号员工的期权必须够"买一辆车"的程度——否则留不住
招太快	前 10 号员工必须在 12-18 个月内招完——再快会稀释文化
招太慢	招太慢会拖垮业务——找到一个就用，别等"完美的"
不淘汰	前 10 号员工里若有不合适的——立即淘汰。早期没时间养闲人
顾及感情不敢踢人	你拖得越久，对"不能走的人"伤害越大——他们每天在和工作质量不行的人打交道
踢人不给赔偿	早期员工在你最困难时加入了——N+1 是基本尊重
不开 vesting 证明	离职员工有权知道自己的行权金额和截止日期——这是法律义务，也是基本体面
3 人模式的沟通用到 30 人	每一个规模拐点必须主动升级协作模式——见规模切换速查表
不签 IP 转让协议	入职第一天签——融资尽调时补签的成本是 100 倍。签完了归档

与其他工具的关系

• 上游：00 合伙人选择（合伙人是 hiring 的前提——合伙人不对，招不到对的人）
• 下游：04 Cap Table（员工期权进入 Cap Table）、Founder Mode（团队建设是 Founder Mode 的组织化——CEO 必须深度参与每个关键 hire）
• 平行：OKR（前 10 号员工深度参与 OKR 制定——他们定义"公司怎么工作"）

---

13 个工具的整体关系图

这 13 个工具的本质：从"假设"到"可持续增长的公司 + 可执行的组织"的 13 步——

1. MVP：用最少成本验证最关键假设
2. DTDTNS：手工做不可规模化的事——这是 PMF 的前提
3. PMF：判断"产品-市场"是否真的契合——40% 测试
4. 单元经济学：验证"这门生意在单元层面赚钱吗"——LTV/CAC > 3（PMF 后才算）
5. AARRR：拆解增长漏斗，找瓶颈
6. 北极星指标：全公司对齐到一个指标
7. Aha Moment：找到让用户上瘾的瞬间——加速 retention
8. OKR：把北极星拆解到全员季度目标
9. Founder Mode：公司变大后，用创始人的方式运营——拒绝切换到经理人模式
10. Pivot：PMF 失败时，结构化地调整方向——Eric Ries 10 种类型
11. GTM Strategy：选 4 种进入市场模式之一——决定整个组织架构
12. PLG vs SLG：GTM 的具体抉择——ACR 模型判断
13. 团队建设：从 3 人到 100 人——选人验证（作品集+付费试做+背调）、退出机制（开头就说的 5 句话+怎么踢人不伤团队）、规模切换（3→10→30→100 的协作模式速查表）

完成这 13 步后，你就有了一个真正能滚起来且可持续的公司 + 能执行的组织——下一步是 04 模块：融资（让生意走得更快）+ 把故事讲给投资人。

---

关联文档

本模块内：本页是 03 模块的唯一文档。

本模块其他章节：

• 00 · 开始之前：合伙人选择——本模块的零号前提
• 01 · 用户洞察——MVP 验证的输入
• 02 · 价值与商业模式——PMF 的前提
• 04 · 融资与战略——增长后的资本化

关联模块：

• Y Combinator 深度分析——PMF、Aha Moment、Founder Mode 案例源头
• 深圳科创学院深度分析——硬件 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 与增长的哲学
• Paul Graham "Founder Mode"(2024 essay)——PG 十年来最具影响力的新概念，原文
• 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
• Andy Grove《High Output Management》(1983)——OKR 的概念源头
• John Doerr《Measure What Matters》(2018)——OKR 在 Google 的应用
• Formlabs "EVT/DVT/PVT Guide"(2023)——硬件验证三阶段的完整指南，原文
• Instrumental "EVT/DVT/PVT Whitepaper"(2020)——硬件验证的工程最佳实践，原文
• 李泽湘 "C端创业一举六得"(2026.02 广东省高质量发展大会)——年轻人 C 端硬件创业的六个战略优势
• 华强北生态系统——深圳硬件迭代速度的数据来源（1.45km²、11.5 万商业实体、48 小时从设计到生产）