04 · 融资与战略:怎么活下去?怎么把战略变成行动?
"The default outcome of a startup is failure. The default path of a startup, if nothing changes, is death."
—— Paul Graham, Default Alive vs Default Dead (2015)
03 模块 帮你拿到 PMF——但 PMF 不是终点,而是资本游戏的起点。
很多创业者拿到 PMF 后死在两件事上:
- 现金烧光——以为有 PMF 就能融到钱,结果 Runway 不够撑到下一轮
- 战略漂移——以为有 PMF 就不用再想战略,结果被竞争对手从侧翼包抄
本模块的 11 个工具,回答的是:
"我如何确保公司能在资本寒冬里活下去?如何把战略拆解到全员可执行?"
| 顺序 | 工具 | 类别 | 何时用 |
|---|---|---|---|
| 1 | Default Alive vs Default Dead | 生存判断 | 二元判断"保持当前节奏能否活到盈利" |
| 2 | Runway & Burn Rate | 现金管理 | 现金还能撑几个月 |
| 3 | SAFE(Simple Agreement for Future Equity) | 早期融资 | YC 发明的最快融资工具 |
| 4 | Cap Table(股权结构) | 股权管理 | 谁占多少、稀释后变成多少 |
| 5 | TAM/SAM/SOM(市场规模估算) | 市场判断 | 这笔生意天花板在哪——算清楚再讲故事 |
| 6 | Pitch Deck(10/12 页结构) | 融资叙事 | Demo Day 2.5 分钟的浓缩版 |
| 7 | 第一性原理 | 战略思维 | 回归物理/数学本质重新推演 |
| 8 | 双钻模型 | 决策框架 | 发散→收敛→发散→收敛 |
| 9 | Schlep Blindness + Make something people want | YC 哲学 | YC 创业哲学的两条核心提醒 |
| 10 | OKR | 战略落地 | 战略对齐到全员季度目标 |
| 11 | Founder Mode(创始人模式) | 运营哲学 | PG 2024 年新概念——创始人应该用 Founder Mode 运营公司,而不是切换到 Manager Mode |
工具一:Default Alive vs Default Dead
是什么
Default Alive vs Default Dead 是 Paul Graham 2015 年同名 essay 提出的二元判断工具。
定义:
| 状态 | 含义 |
|---|---|
| Default Alive | 保持当前收入和支出节奏,公司能在现金烧完前达到盈利 |
| Default Dead | 保持当前节奏,必须再融资才能活下去 |
关键:这不是"现在是否盈利"——而是"如果不再融资,最终能不能盈利"。
为什么用
核心问题:早期创业者最大的财务幻觉——"我有 PMF,所以我会融到下一轮"。
PG 的警告:
"Many startups die because they assume they'll raise more money. They are default dead and don't realize it."
Default Alive vs Default Dead 把复杂的财务模型简化成二元判断——你不需要懂 DCF、不需要懂 NPV,只需要回答一个问题:
"如果明天起没人再投我钱,我能不能活到盈利?"
如果答案是"不能"——你不是在创业,你是在融资。
怎么用
步骤 1:列出现金流要素
| 收入 | 支出 |
|---|---|
| 月度 recurring revenue | 月度固定成本(工资、办公) |
| 一次性收入 | 月度变动成本(云服务、营销) |
| 一次性支出(设备、税费) |
步骤 2:计算两条曲线
月份 1: 收入 $50K, 支出 $100K → 净烧 $50K
月份 2: 收入 $55K, 支出 $100K → 净烧 $45K
月份 3: 收入 $61K, 攓出 $100K → 净烧 $39K
...
月份 N: 收入 ≥ 支出 → 净烧 ≤ 0(break-even)
两条曲线:
- 收入曲线:基于当前增长率(保守估计)
- 支出曲线:基于当前 burn rate
步骤 3:判断 Alive/Dead
- 收入曲线在现金烧完前穿过支出曲线 = Default Alive ✅
- 收入曲线在现金烧完前没穿过支出曲线 = Default Dead ❌
步骤 4:如果 Default Dead,三选一
| 选项 | 做法 |
|---|---|
| 加速增长 | 提升 MRR 增长率(产品迭代、销售投入) |
| 削减支出 | 裁员、降薪、减少营销 |
| 融资 | 用稀释换生存时间(最贵选项) |
案例:PG 在 essay 中举的例子
PG 在 Default Alive vs Default Dead 中给了一个具体计算:
假设:
- MRR: $10K,月增 10%
- 月支出: $15K(固定)
- 现金: $100K
计算:
- 月份 1: MRR 5K
- 月份 2: MRR 4K
- ...
- 月份 5: MRR 0.4K
- 月份 6: MRR $16.1K,break-even ✅
结论:这家公司是 Default Alive——只要不增加支出,6 个月内达到盈利。
反过来如果月增只有 5%:
- 月份 1: MRR 5K
- 月份 14: 才接近 break-even,但现金只够撑 7 个月
- 结论:Default Dead——必须融资或削减支出
案例:2022 年 SaaS 公司的 Default Dead 危机
2022 年加息后 VC 收紧,大量 SaaS 公司发现自己 Default Dead:
| 公司类型 | 2021 假设 | 2022 现实 |
|---|---|---|
| 增长率 | 月增 15% | 月增 5% |
| 融资环境 | 随时能融 | 融不到 |
| 估值倍数 | 20x ARR | 5x ARR |
很多 2021 年估值过高的公司被迫"down round"(低估值融资)或倒闭——Stripe、Instacart 等都经历了内部估值下调。
Garry Tan 上任 YC CEO 后(2023)反复强调:"W23/W24 batch 公司必须把 Default Alive 作为目标——不要再假设能轻松融资。"
案例:李泽湘体系的"硬件 Default Alive"
硬件创业的 Default Alive 计算更复杂——因为硬件有库存周期、生产周期、渠道周期。
李泽湘体系的方法:
- 早期不追求 Default Alive——硬件 pre-PMF 阶段必然 Dead
- 靠体系内供应链支持延长时间——XbotPark 共享工厂让硬件公司 burn rate 降低 50%
- CES/Kickstarter 提前验证收入——众筹资金是"无稀释现金"
深圳科创学院 60% 项目 2 年内拿到天使轮——这背后是体系对"Default Dead"的精确管理和"延长时间"的策略。
常见误区
| 误区 | 修正 |
|---|---|
| 过度乐观的增长假设 | 用保守的增长率(现实打 7 折) |
| 忘了"一次性"支出 | 税费、设备、法务都要算 |
| 融资=解决方案 | 融资是最贵选项——优先考虑增长和削减 |
| 算一次就完 | 每月重算一次——节奏变了状态就变 |
与其他工具的关系
- 上游:03 模块的 Unit Economics(单元经济学 + 规模 = Default 状态)
- 下游:Runway(Default Dead 时紧急计算)、融资决策(Default Dead 是融资紧迫性的依据)
工具二:Runway & Burn Rate
是什么
- Burn Rate(烧钱速度):公司每月净亏损——即现金减少的速度
- Runway(跑道长度):现金能撑几个月——即"距离坠毁还有多久"
核心公式:
Runway = 现金余额 / 月度 Burn Rate
例:现金 100K → Runway = 10 个月。
为什么用
Runway 是创业公司的"生命条"——所有决策都要在这个时间窗口内完成。
YC 的标准建议:
"Always have at least 12 months of runway. 6 months is dangerous. 3 months is death."
为什么 12 个月?
- 融资周期:3-6 个月
- 战略调整:3 个月
- 缓冲:3 个月
少于 12 个月,你就被迫做"短视决策"——降价促销、紧急裁员、接受坏条款。
怎么用
步骤 1:算 Gross Burn 和 Net Burn
| 指标 | 定义 |
|---|---|
| Gross Burn | 每月总支出(不含收入抵减) |
| Net Burn | 每月净亏损(支出 - 收入) |
为什么区分?
- Gross Burn 反映"成本结构"——能否削减
- Net Burn 反映"真实烧钱速度"——决定 Runway
步骤 2:算 Runway
Runway = 现金 / Net Burn
步骤 3:根据 Runway 决定行动
| Runway | 状态 | 行动 |
|---|---|---|
| > 18 个月 | 安全 | 全速增长 |
| 12-18 个月 | 健康 | 正常增长 + 准备融资 |
| 6-12 个月 | 警告 | 优先融资 + 削减可选项 |
| 3-6 个月 | 危险 | 紧急融资 / 大幅削减 |
< 3 个月 | 死亡线 | 立即重组 / 卖公司 |
步骤 4:延长 Runway 的 3 个杠杆
| 杠杆 | 效果 | 副作用 |
|---|---|---|
| 削减成本 | 立即生效 | 影响增长(裁员影响产能) |
| 加速收入 | 1-3 个月生效 | 可能稀释品牌(促销) |
| 融资 | 3-6 个月生效 | 稀释股权 |
案例:YC 的 "Runway 数学"
YC 给 batch 公司的标准建议(2023 Garry Tan 时代):
| 阶段 | 建议 Runway | 建议 Burn |
|---|---|---|
| 刚加入 YC | 12 个月 | $50K-100K/月 |
| Demo Day 后 | 18-24 个月 | $100K-200K/月 |
| Series A 前 | 24 个月 | $200K-500K/月 |
关键:Demo Day 融到的钱要够撑到 Series A(通常 18-24 个月)。
案例:Quibi 的反例(2020 年失败)
Quibi(短视频流媒体,2020 年失败):
- 融资:$1.75B
- Burn Rate:$30M/月(早期)
- Runway:约 4 年
听起来 Runway 很长——但 Quibi 的 Burn Rate 在 6 个月内涨到 $50M+/月(内容投入),实际 Runway 缩短到 2 年。
更糟的是:Quibi 的"增长假设"失败——首月注册 300 万后快速下滑。
教训:Runway 不是孤立的指标——必须和增长假设一起看。Burn 高但增长快 = OK;Burn 高但增长慢 = 死路。
案例:李泽湘体系的"硬件 Runway 管理"
硬件创业的 Runway 管理比软件复杂——因为:
- 硬件开发周期长(6-18 个月)
- 量产需要一次性大投入(开模、备料)
- 库存占用大量现金
李泽湘体系的方法:
- 清水湾基金 + XbotPark 基金 + 松山湖种子基金——多层次资金支持
- 共享工厂降低固定资产投入——把"capex"变"opex"
- Kickstarter 众筹作为"预售现金流"——用户先付定金,工厂再生产
深圳科创学院体系内公司平均 Runway 比独立硬件创业者长 1.5-2 倍——这是体系的核心价值之一。
常见误区
| 误区 | 修正 |
|---|---|
| 只看 Net Burn | Gross Burn 决定你能削减多少 |
| Runway > 12 月就放心 | 还要看增长是否跟上 |
| 融资=解决 Runway | 融资稀释股权——优先削减和增长 |
| Burn 固定不变 | Burn 会随公司扩张上涨——动态计算 |
与其他工具的关系
- 上游:Default Alive/Dead(决定 Runway 是否够用的判断)
- 下游:SAFE(Runway 紧张时启动 SAFE 融资)、Pitch Deck(融资叙事要讲 Runway)
工具三:SAFE(Simple Agreement for Future Equity)
是什么
SAFE(Simple Agreement for Future Equity) 是 YC 在 2013 年发明的早期融资工具。
核心机制:
创业者现在收钱,未来(下一轮股权融资时)转换为股权。
现在 ──────► 投资人投 $100K ──────► SAFE 协议
│
▼
下一轮 Series A ──────► SAFE 自动转换为 Series A 股票(按约定折扣)
4 个关键参数:
- Valuation Cap(估值上限):5M 估值"转换
- Discount(折扣):20%——下一轮估价的 8 折
- MFN(Most Favored Nation):如果以后给别的 SAFE 更好条款,本 SAFE 跟进
- Pro Rata Rights:下一轮后能继续跟投的比例
为什么用
对比传统股权融资:
| 维度 | 传统股权融资 | SAFE |
|---|---|---|
| 法律费 | $30K-50K | <$5K(YC 模板免费) |
| 谈判周期 | 2-3 个月 | <1 周 |
| 估值要求 | 必须定价 | 不用定价 |
| 文件页数 | 100+ 页 | 5 页 |
| 灵活性 | 每个投资人条款不同 | 标准化 |
SAFE 让早期融资从"3 个月项目"变成"1 周项目"——这是 YC 对全球创业生态的最大贡献之一。
YC 2013 年发明 SAFE 后,美国早期融资 95%+ 都用 SAFE 或类似工具(AngelList 的 Convertible Note 也在转型)。
怎么用
步骤 1:决定 SAFE 条款
| 条款 | 典型范围 | 谈判策略 |
|---|---|---|
| Valuation Cap | 15M(种子) | 越高对创始人越有利 |
| Discount | 0-25% | 越低对创始人越有利 |
| MFN | 通常包含 | 标准条款 |
| Pro Rata | 通常不包含 | 大投资人会要求 |
关键决策:Cap vs Discount 通常二选一或组合:
- 只有 Cap:估值明确时用
- 只有 Discount:估值模糊时用
- Cap + Discount:取对投资人更有利者
步骤 2:用 YC 模板
YC 提供 免费 SAFE 模板——直接下载,填空,签字。
不要修改模板核心条款——YC 模板已经是市场标准,改动会增加法律成本。
步骤 3:管理 Cap Table
SAFE 不会立即稀释股权——但下一轮转换时会。提前用 Cap Table 软件计算稀释(Carta、Pulley)。
步骤 4:下一轮转换
下一轮 Series A 时:
- 确定估值(如 $20M pre)
- SAFE 持有者按 Cap($5M)转换——比下一轮估值低 4 倍
- SAFE 20M 估值下相当于 $400K 的股票
案例:YC 标准化 SAFE 的起源
YC 2013 年发明 SAFE 之前的早期融资工具是 Convertible Note(可转债)——但它有几个问题:
- 是"债务"——破产时优先偿还
- 有到期日——必须按时转换或还款
- 有利息——增加复杂度
YC 的Carolyn Levy 和 Jared Friedman 团队设计的 SAFE 解决了这些问题:
- 不是债务——是"未来股权承诺"
- 无到期日——下一轮才转换
- 无利息——纯股权逻辑
YC 自己的 batch 公司从 2013 年开始全部用 SAFE——YC 投资的 5,000+ 家公司积累的 SAFE 实践,让这个工具成为全球标准。
案例:中国版 SAFE
中国法律框架下没有完全等价的 SAFE,但奇绩创坛(陆奇的 YC 中国版) 在 2020 年推出了类似工具——通过有限合伙架构实现 SAFE 效果。
李泽湘体系则用更传统的方式:
- 可转债(中国法律允许)
- 直接股权(早期估值低,谈判成本低)
- 战略投资(清水湾基金直接投)
2025 年中国早期融资 60%+ 仍用直接股权——SAFE 在中国的渗透率远低于美国。
常见误区
| 误区 | 修正 |
|---|---|
| SAFE 不是股权 | SAFE 在下一轮会转换成股权——必须用 Cap Table 预算 |
| Cap 越高越好 | 高 Cap 吓跑投资人——要平衡 |
| 修改 YC 模板 | 不要——改动会让法律成本飙升 |
| SAFE 收钱就完 | SAFE 收钱后要管理投资者关系 |
与其他工具的关系
- 上游:Runway(决定何时启动 SAFE)
- 下游:Cap Table(SAFE 转换后更新)、Pitch Deck(融资故事)
工具四:Cap Table(股权结构表)
是什么
Cap Table(Capitalization Table) 是公司所有权结构的表格——谁占多少股、什么类型、稀释后是多少。
简化版 Cap Table:
| 股东 | 股数 | 占比 | 类型 |
|---|---|---|---|
| 创始人 A | 4M | 40% | Common |
| 创始人 B | 3M | 30% | Common |
| 创始人 C | 2M | 20% | Common |
| 期权池 | 0.5M | 5% | Options |
| 种子投资人 | 0.5M | 5% | Preferred(SAFE 转换) |
| 合计 | 10M | 100% |
为什么用
Cap Table 决定了:
- 创始人是否还控制公司(投票权)
- 员工期权的池子大小(招聘能力)
- 未来融资的稀释空间(融资能力)
- 退出时每个人能拿多少钱(激励)
早期 Cap Table 错误,后期修复成本极高——很多公司在 Series C 才发现创始人已经被稀释到 < 10%。
怎么用
步骤 1:建立初始 Cap Table
公司成立第一天,用 Cap Table 软件建立基线(Carta、Pulley、Capbase)。
典型种子前 Cap Table:
| 股东 | 占比 |
|---|---|
| 创始人(合计) | 80-90% |
| 员工期权池 | 10-20% |
步骤 2:每次融资后更新
每次 SAFE / 股权融资后:
- 新投资人加入
- 现有股东稀释
- 期权池可能扩大
步骤 3:模拟稀释场景
用 Cap Table 软件模拟:
- 如果 Series A 融 20M pre,创始人稀释到多少?
- 如果 Series B 融 100M pre,创始人最终占比?
- 如果做到 IPO,创始人还能不能控制公司?
步骤 4:管理员工期权
员工期权的 3 个关键决策:
- 池子大小:种子轮 10%,Series A 后扩到 15-20%
- 行权期:通常 4 年 vesting + 1 年 cliff
- 行权价:当前 FMV(409A 估值)
案例:Mark Zuckerberg 的"控制权设计"
Facebook 的 Cap Table 设计是教科书级的——Zuckerberg 通过双重股权结构(Class B 每股 10 票)维持控制:
| 阶段 | Zuckerberg 经济 ownership | 投票权 |
|---|---|---|
| IPO 前 | 28% | 57% |
| IPO 后 | 22% | 58% |
| 2024 年 | 13% | 61% |
结果:Facebook 经过 20 年 + 多轮巨额融资后,Zuckerberg 经济 ownership 只剩 13%——但投票权 61%,完全控制公司。
这就是为什么 Zuckerberg 能在 2022-2023 年顶住股东压力,豪赌元宇宙——他不需要股东同意。
案例:WeWork 的反例
WeWork 的 Cap Table 是反面教材:
- Adam Neumann 的股票有"超级投票权"(每股 20 票)
- Neumann 个人向公司借钱
- Neumann 把"WeWork"商标卖给公司
- 期权池被随意分配给"朋友"
结果:S-1 公开后投资人惊呆,IPO 失败,Neumann 被踢出公司。
案例:李泽湘体系的"创始人控制"
李泽湘体系内公司典型 Cap Table(以云鲸为例,公开信息简化):
| 股东 | 占比 |
|---|---|
| 创始人建刚 | 30-40% |
| 核心团队 | 15-20% |
| 员工期权池 | 10-15% |
| 清水湾基金 + XbotPark 基金 | 15-20% |
| 其他 VC | 15-20% |
特点:
- 创始人始终是最大单一股东——保证决策效率
- 体系内基金是"耐心资本"——不要求短期估值
- 员工期权池大——硬件创业需要长期激励
常见误区
| 误区 | 修正 |
|---|---|
创始人持股 < 50% 就完了 | 还有控制权设计(双重股权、投票协议) |
| 期权池越大越好 | 太大会稀释创始人——平衡 |
| Cap Table 用 Excel 管 | 必须用专业软件(Carta 等) |
| 不模拟未来稀释 | 必须 Series A/B/C/IPO 全模拟 |
与其他工具的关系
- 上游:SAFE(每次 SAFE 都要更新 Cap Table)
- 下游:TAM/SAM/SOM(市场规模决定了融资额度)、Pitch Deck(融资叙事要展示 Cap Table 的健康度)
工具五:TAM/SAM/SOM(市场规模估算)
是什么
TAM / SAM / SOM 是给一门生意做市场规模估算的三层框架——不是画饼讲故事,而是用数据回答:"这笔生意的天花板在哪?"
| 层级 | 全称 | 含义 | 类比 |
|---|---|---|---|
| TAM | Total Addressable Market | 如果你的产品占领全球 100% 份额,年营收的天花板 | 全世界的披萨消费总额 |
| SAM | Serviceable Addressable Market | 以你当前的商业模式和渠道能触达的市场 | 你能配送范围内的披萨消费总额 |
| SOM | Serviceable Obtainable Market | 现实地看,你 3-5 年内能拿到的市场份额 | 你店第一年实际能卖出去的披萨金额 |
无论你是做 SaaS、卖扫地机器人、还是做自动驾驶矿卡——TAM/SAM/SOM 不是融资 PPT 的装点,而是你自己的战略判断:这个市场值不值得花十年?
为什么用
两个最常见的 Pitch Deck 错误:
- "千亿市场"型:TAM = "全球 XX 行业 $500B"——来自 Gartner 报告的宏观数字。投资人看一眼就关掉:这说明你没想清楚你能吃到哪一块。
- "精确到小数点"型:SOM = "$3,247,891"——没有计算过程,凭空估算。
TAM/SAM/SOM 的价值不在于"给投资人看",而在于逼你自己想清楚:
- TAM 太小(
<$1B):VC 不投,但可能是好生意(lifestyle business) - SAM 和 TAM 差距太大:说明你的商业模式当前无法覆盖大部分市场——需要解释为什么
- SOM 和 SAM 差距太大:说明执行力或竞争壁垒有问题
怎么用
步骤 1:算 TAM —— 两种方法,交叉验证
方法 A:自上而下(Top-Down) 从行业报告出发——Gartner、IDC、Statista、Frost & Sullivan 提供行业总规模。这是起点,不是终点。
方法 B:自下而上(Bottom-Up)——推荐 从"用户数 × 单价"出发:
TAM = 全球目标用户数 × 年客单价
示例(云鲸):
全球扫地机器人潜在用户 = 3 亿家庭(剔除不拖地的文化)× 5% 渗透率
年客单价 = $500(机器 + 配件)
TAM ≈ 1500 万户 × $500 = $7.5B
交叉验证:如果 Bottom-Up 和 Top-Down 差距超过 2 倍,回到 Bottom-Up 检查假设。Bottom-Up 永远比 Top-Down 更可信——因为你拆解了"用户是谁"和"他们付多少钱"。
步骤 2:切 SAM —— 加入现实约束
在 TAM 上叠加:
- 地理约束:当前只在哪些国家/城市运营?
- 渠道约束:线上/线下/经销商——哪个渠道能触达?
- 用户画像约束:你的 Persona 在 TAM 里占比多少?
SAM = TAM × 目标国家占比 × 目标渠道渗透率
示例(云鲸):
TAM = $7.5B(全球)
× 中国 + 美欧日韩 占比 = 70%
× 可以通过电商渠道触达的 = 80%
SAM ≈ $4.2B
关键判断:如果 SAM / TAM < 10%,说明你当前的商业模型有重大扩张障碍——需要在 Pitch Deck 里解释"为什么现在约束大,未来会变小"。
步骤 3:估 SOM —— 你的真实目标
这是整个框架里最难、最容易被虚报的数字。两种方法:
方法 A:类比法(推荐早期公司) 找一个类似的已上市公司在同等阶段的数据。比如:
"Notion 在 2020 年(成立 7 年)的 ARR 约 $30M。我们在一个类似大小的品类,目标是 5 年内达到 Notion 同等规模。"
方法 B:漏斗法(后期公司) 从 SAM 出发,用获客漏斗倒推:
SOM = SAM × 预计市场份额
预计市场份额 = f(销售团队规模、渠道覆盖、竞争格局)
早期公司的诚实做法:SOM 不必给出一个精确数字。可以说"在 84M-210M ARR"。范围比点估计更可信。
步骤 4:判断这个市场值不值得做
| 判断维度 | 软件/SaaS 的阈值 | 硬件/硬科技的阈值 |
|---|---|---|
| TAM 底线 | >$1B(VC 愿意看) | >$5B(硬件 VC 要求更高,因为 margin 低) |
| SAM/TAM | >30%(可扩张) | >20%(硬件天然受地理/渠道约束更大) |
| 5 年 SOM | >$50M ARR | >100K 台出货量 或 >$50M 营收 |
| 增长率 | 市场本身在扩张(>15% YoY) | 品类在从 early adopter 到主流(渗透率拐点) |
**如果 TAM < 500M 的利基市场里你拿到 40% 份额 = $200M 营收 = 一家非常好的公司(lifestyle business),只是不适合 VC。
PG:"There are worse things than building a $50M company." 不是所有生意都需要 VC。
软件 vs 硬件:市场规模估算的关键区别
| 维度 | 软件/SaaS | 硬件/硬科技 |
|---|---|---|
| TAM 计算单位 | 用户数 × ARPU(年) | 出货量 × ASP(平均售价) |
| SAM 约束 | 语言、区域合规(GDPR 等) | 渠道覆盖、售后网络、认证(FCC/CE/CCC) |
| SOM 增长曲线 | 指数型(PLG、病毒传播) | S 曲线(产能爬坡、渠道铺设速度) |
| VC 期望 | $1B TAM 即为可投 | 通常要求 $5B+ TAM(硬件毛利更低) |
| 最常犯的错误 | 假设"全球互联网用户"都是 TAM | 假设"建了工厂就能卖出产能" |
| 验证信号 | 竞品 ARR、搜索量、社区规模 | 现有品类销量、代工厂产能利用率、经销商反馈 |
案例:大疆的 TAM/SAM/SOM 演化
大疆在 2013 年融资时的市场故事:
| 层级 | 2013 年的判断 | 后来实际发生 |
|---|---|---|
| TAM | 航模市场 ~1B = $3B | 消费者无人机市场爆发至 $30B+(大疆自己创造了新市场) |
| SAM | 能用一体化飞控的整机市场 ~$1B | 变成了"会飞的相机"——比原 SAM 大了 10 倍 |
| SOM | 目标 5 年内 $200M | 2017 年做到 $2.7B——远超预期 |
大疆案例的教训:TAM 估算要留"品类扩张"的空间。最好的公司不是抢现有市场,而是扩大市场——TAM 应该是一个动态数字,不是静态天花板。
李泽湘对汪滔的早期判断:"无人机飞控市场非常小,但汪滔在做的事可能定义一个全新品类。"——投资的是"品类创造者"的潜力,不是静态 TAM。
案例:YC 对 TAM 的态度
YC 教 Demo Day 时有一句:
"Don't say 'our market is $100B.' Say 'there are X million people who have Y problem, and each of them spends Z dollars trying to solve it with bad solutions today.'"
YC 要的是 Bottom-Up 逻辑,不是 Top-Down 报告数字。Garry Tan 在 2023 年 Office Hour 里反复说:"Tell me the unit, then tell me how many units. If you can't, you haven't thought about it."
常见误区
| 误区 | 表现 | 为什么错 |
|---|---|---|
| TAM 转贴报告 | "Gartner 说这是 $500B 市场" | 投资人比你还早看到这份报告;你没有自己的判断 |
| SOM = 1% of TAM | "我们只要拿到 1% 就能上市" | 1% 的市场份额不是"保守估计"——大多数公司活不到 1% |
| 假设市场静止 | 用今天的市场大小套 5 年后的自己 | 5 年内市场本身会变——增长或萎缩,你必须给出判断 |
| 无视替代品 | 只算"像我们这样的产品"的市场 | 真正的竞争对手是用户的当前解决方案(含非消费) |
| 硬件忽略售后 | 只算销售营收,不算售后网络成本 | 硬件 SAM 受售后覆盖半径约束远比软件严格 |
| Bottom-Up 没有引用 | "全球有 3 亿家庭"——这数据哪来的? | 每一个数字都要标注来源或假设——这是投资人判断你严谨性的方式 |
与其他工具的关系
- 上游:单元经济学(LTV/CAC 决定了你能多高效地捕获 SOM)
- 上游:Cap Table(股权决定了你愿意为这份市场规模融多少钱、稀释多少)
- 下游:Pitch Deck(TAM/SAM/SOM 是 Deck 的"市场"页核心数据)
- 平行:第一性原理(拿 TAM 数据做第一性推演——"如果 TAM 真的只有 $500M,这个生意还能做吗?")
一句话:TAM/SAM/SOM 不是"编一个大的数字让投资人兴奋"——是你自己的战略地图。Bottom-Up 算出来的 TAM 告诉你值不值得做,SOM 告诉你 5 年目标该定在哪。
工具六:Pitch Deck(10/12 页结构)
是什么
Pitch Deck 是创业公司融资叙事的浓缩版 PPT。
Sequoia Capital 推荐的 10 页结构(业内标准):
- Company Purpose——一句话公司使命
- Problem——你解决什么问题
- Solution——你怎么解决
- Why Now——为什么是现在
- Market Size——市场多大
- Competition——竞品分析
- Product——产品 demo
- Business Model——怎么赚钱
- Team——团队介绍
- Financials——财务/指标
YC Demo Day 版:2.5 分钟 / 5-7 张幻灯片(极简版)。
为什么用
核心问题:早期投资人看 1000+ 个项目/年,你只有 3 分钟让他"想再见一面"。
Pitch Deck 不是"展示公司"——是"让投资人想再见一面"。
Sequoia 的 Alfred Lin:"Deck 的目标不是说服投资人投你——是让投资人想再见你一面。"
怎么用
步骤 1:每页只讲一件事
每页的核心信息用 1 句话能概括:
| 页 | 核心信息 |
|---|---|
| 1 | "We are [公司] and we [做什么]" |
| 2 | "[某群体] 在 [某场景] 下遇到 [某问题]" |
| 3 | "我们用 [某方案] 解决" |
| ... | ... |
步骤2:用数据代替形容词
| 错(形容词) | 对(数据) |
|---|---|
| "增长很快" | "MRR $100K,月增 20%" |
| "市场巨大" | "TAM 5B,SOM $500M" |
| "用户喜欢" | "D30 留存 60%,NPS 65" |
| "团队很强" | "前 Stripe CTO + 前 Airbnb 工程 VP" |
步骤 3:Story First, Data Second
投资人不缺数据——缺的是让你这份数据有意义的故事。
Sequoia 推荐的叙事弧:
- Hook(吸引注意):第一句话让投资人抬头
- Tension(制造冲突):现状有什么问题
- Resolution(解决方案):你的产品如何解决
- Proof(证据):数据/案例
- Ask(要钱):你融多少,达到什么里程碑
步骤 4:Demo Day 极简版
YC Demo Day 只有 2.5 分钟——必须极简:
| 时间 | 内容 |
|---|---|
| 0-15 秒 | Hook:"[公司] is [做什么]" |
| 15-45 秒 | Problem + Solution |
| 45-75 秒 | Traction(数据) |
| 75-105 秒 | Business Model + Market |
| 105-135 秒 | Team |
| 135-150 秒 | Ask:"Raising $X to [milestone]" |
案例:Airbnb 的经典 Deck
Airbnb 2009 年种子轮 Deck 被广泛传阅——被认为是 Pitch Deck 教科书。它的特点:
- 每页只 1 个核心信息
- 大量用图(不是字)
- 数据精确(如 "300 monthly income")
- 故事清晰("Book a room in someone's house instead of a hotel")
这份 Deck 帮 Airbnb 拿到 Sequoia 的 30 亿。
案例:Stripe 兄弟的"反 Deck"
Patrick 和 John Collison(Stripe)的早期融资用反 Deck 策略:
- 不准备 Deck——只准备 API 文档和 demo
- 让投资人飞到旧金山——而不是自己去见投资人
- "我们 5 分钟内让你能收款"——现场让投资人集成 Stripe
这种"show, don't tell"策略后来被称为 "Collison installation"——PG 在 YC 内反复推广。
案例:YC Demo Day Pitch 的演变
YC Demo Day 的 Pitch 风格在 21 年里发生了变化:
| 时代 | 风格 | 代表 |
|---|---|---|
| 2005-2014 (PG 时代) | 哲学化、长句 | Airbnb、Stripe |
| 2014-2019 (Sam 时代) | 数据化、增长叙事 | Coinbase、Rippling |
| 2019-2023 (Geoff 时代) | 远程视频、极简 | Replit、Vanta |
| 2023-至今 (Garry Tan 时代) | AI 叙事、Demo 优先 | Perplexity、Cursor |
Garry Tan 2023 年后的标准:
- 必须 live demo——投资人要看产品在跑
- AI 假设前置——"我们假设 AI 会改变 [某行业]"
- 数据 > 愿景——早期就要 MRR/用户数
常见误区
| 误区 | 修正 |
|---|---|
| 每页塞太多信息 | 一页一件事 |
| 形容词代替数据 | 必须用数字 |
| 不练 Demo | Demo 必须练 50+ 次 |
| 没有"Ask" | 必须明确"融多少,达到什么" |
与其他工具的关系
- 上游:所有前 3 个模块(VPC、BMC、MVP、PMF 等)
- 下游:Demo Day / 投资人会议
工具七:第一性原理
是什么
第一性原理(First Principles Thinking) 是回归最基础的物理/数学/经济事实,重新推导结论的思维方式。
对立面:类比思维("别人这么做,我也这么做")。
Elon Musk 的经典案例(SpaceX):
- 类比思维:火箭很贵(历史上每次发射 $65M),所以发射就是贵
- 第一性原理:火箭的材料是什么?铝、钛、铜、碳纤维——这些材料的市场成本只占火箭售价的 2%。所以火箭理论上可以便宜 50 倍。
结果:SpaceX 把单次发射成本降到 30M)。
为什么用
核心问题:99% 的战略决策是"类比思维"——看竞品怎么做,跟着做。
类比思维的问题:
- 别人可能也是错的(盲从)
- 场景不同(别人的市场 ≠ 你的市场)
- 创新被锁死(永远赶超,永远落后)
第一性原理的价值:让你看到"被共识掩盖的机会"。
Elon Musk:"I think it's important to reason from first principles rather than by analogy."
怎么用
步骤 1:识别"假设"
写下你当前的判断,问"这是基于什么假设?"
例子:
- 判断:"我们的 SaaS 应该定价 $50/月"
- 假设:"因为竞品都是 $50/月"
步骤 2:把假设拆到"第一性"
追问 5 次"为什么":
- "竞品为什么定 $50?" → "因为行业惯例"
- "行业惯例怎么来的?" → "SaaS 早期的标准定价"
- "SaaS 早期为什么定这个价?" → "对标的 Oracle/Salesforce 价格"
- "Oracle 为什么定那个价?" → "基于企业预算阈值"
- "企业预算阈值是什么?" → "每年每人 $600 是企业工具的舒适阈值"
到了第 5 层,你发现**$50/月是基于"企业工具舒适阈值"**——这是 B2B 的情况。但如果你是 B2C 呢?阈值完全不同。
步骤 3:基于第一性重新计算
例:你的 B2C SaaS——
- 第一年目标:1 万付费用户
- 单用户每年愿意为"节省 30 小时"付多少?→ 调研发现 $20
- 所以年定价 1.99 比竞品的 $50 更合理
重新定价后:你的 TAM 比竞品大 10 倍(因为价格门槛低)。
案例:李泽湘的"第一性"创业观
李泽湘的所有方法论都是第一性原理推导的:
"中国不缺优秀的工科人才,不缺全球最完备的制造业产业链,缺的是一套能将人才、技术、市场、产业有效衔接的完整体系。"
这个判断是第一性的——他不参考"硅谷加速器模式"(类比),而是看中国的根本条件(第一性)。
由此推导出:
- 不做 YC 的纯软件模式(中国软件创业门槛低、VC 不缺项目)
- 做"硬件 + 供应链"模式(中国独有的优势)
- 用 30 年时间建体系(短期不可复制)
这就是为什么深圳科创学院无法被国外复制——它是基于中国第一性条件的产物。
案例:YC 的"反第一性"案例
YC 历史上也有"反第一性"的失败:
YC 拒绝 Uber(2009):
- 类比判断:"监管风险大"
- 第一性应该问:"出行市场的真实需求多大?监管能否被需求推动改变?"
- 结果:Uber 改变了全球监管——YC 错过 $100B+ 机会
PG 自己反思:
"我们低估了那些没有明显'hacker'特质的创始人。"
这就是第一性原理的反面教材——用类比("Uber 没有 hacker 特质")替代第一性("出行市场需求")。
常见误区
| 误区 | 修正 |
|---|---|
| 第一性 ≠ 反共识 | 第一性推导可能得出共识结论——重点是过程不是结论 |
| 过度使用 | 不是每个决策都要第一性——日常决策用类比更快 |
| "我觉得"代替第一性 | 第一性必须有客观事实支撑 |
| 推导完不验证 | 第一性结论要用 MVP 验证 |
与其他工具的关系
- 横切:所有模块都可用第一性原理重新审视
- 特别关联:Lean Canvas 的"现有替代方案"、BMC 的"价值主张"
工具八:双钻模型(Double Diamond)
是什么
双钻模型是英国设计委员会(Design Council)在 2005 年提出的设计思维流程模型。
◇─────────────────◇ ◇─────────────────◇
│ 发散 │ │ 发散 │
│ │ │ │
│ 发现 │ │ 发展 │
│ Discover │ │ Develop │
│ │ │ │
│ 收敛 │ │ 收敛 │
│ 定义 │ │ 交付 │
│ Define │ │ Deliver │
◇─────────────────◇ ◇─────────────────◇
第一钻 第二钻
(做对的事) (把事做对)
两个钻石:
- 第一钻:发现(发散)→ 定义(收敛)= "做对的事"
- 第二钻:发展(发散)→ 交付(收敛)= "把事做对"
为什么用
核心问题:创业决策常犯的两个错误:
- 跳过发散直接收敛——只考虑 1 个方案就执行
- 跳过收敛持续发散——考虑 10 个方案,无法决策
双钻模型强制你先发散(多想)再收敛(决策),两轮——既避免过早收敛,也避免分析瘫痪。
怎么用
第一钻:做对的事(解决"做什么")
发现(发散):
- 用户访谈、市场研究、竞品分析
- 目标:收集尽可能多的问题
定义(收敛):
- 把"很多问题"收敛到"核心 1-3 个问题"
- 工具:01 模块 Persona/JTBD、02 模块 VPC
第二钻:把事做对(解决"怎么做")
发展(发散):
- 头脑风暴多种解决方案
- 不评估可行性,先穷举
- 工具:原型、草图、Wireframe
交付(收敛):
- 把"多个方案"收敛到"1 个最优方案"
- 工具:MVP、用户测试
案例:英国设计委员会的 NHS 案例
英国设计委员会用双钻模型帮 NHS(英国国民医疗体系)重新设计护士制服:
- 发现:访谈 500+ 护士,发现问题有 30+ 个
- 定义:收敛到 3 个核心问题(口袋设计、温度调节、移动方便)
- 发展:设计了 50+ 套制服原型
- 交付:选 1 套,全 NHS 推广——护士满意度提升 40%
案例:李泽湘体系的"双钻"实践
深圳科创学院的训练营本身就是双钻模型的应用:
| 阶段 | 活动 | 双钻对应 |
|---|---|---|
| 第 1 周 | 用户访谈 + 场景体验(发现) | 第一钻 发散 |
| 第 2 周 | 定义核心问题 + 选定方向(定义) | 第一钻 收敛 |
| 第 3 周 | 头脑风暴多种方案 + 快速原型(发展) | 第二钻 发散 |
| 第 4 周 | 选定最优方案 + 做 MVP(交付) | 第二钻 收敛 |
李泽湘说:"深圳科创学院是世界上最好的大学"——因为它是用双钻模型训练创业者的完整体系。
常见误区
| 误区 | 修正 |
|---|---|
| 跳过发现直接定义 | 没有发散的收敛是"假定义"——只是基于经验的偏见 |
| 第一钻用太久 | 第一钻通常 2-4 周——超过就是过度分析 |
| 第二钻只做 1 个方案 | 第二钻的发散阶段必须做 5+ 个方案 |
| 不在收敛阶段砍方案 | 收敛必须果断——砍掉 80% 的方案 |
与其他工具的关系
- 互补:与 01 模块用户访谈(提供发现阶段数据)、03 模块 MVP(提供交付阶段验证)
- 延伸阅读:从双钻模型看产品规划 有更详细的产品规划应用
工具九:Schlep Blindness + Make something people want
是什么
这两条都是 Paul Graham 的著名概念,合起来构成 YC 创业哲学的核心。
Schlep Blindness(麻烦盲区)
PG 2011 年同名 essay Schlep Blindness:
"Schlep"是意第绪语,意思是"麻烦的、不愿意做的事"。PG 观察到:创业者会本能地回避真正麻烦的问题——而机会正藏在其中。
例子:
- 创业者扎堆做"另一个社交媒体 App"——因为简单
- 没人做"重新设计医疗账单系统"——因为太麻烦(监管、医院关系、保险)
结果:简单的赛道竞争激烈,麻烦的赛道无人问津。
PG:"The most powerful motivator may be the desire to avoid schlep."
Make something people want
YC 的官方格言,印在橙色贴纸上:
"Make something people want."(做出别人想要的东西)
反面:
"Don't make something people don't want."——这是 90% 失败创业的最简洁诊断。
为什么用
这两条放在一起,是 YC 对"做什么"和"不做什么"的两个根本判断:
| 工具 | 解决的问题 |
|---|---|
| Schlep Blindness | "我应该做什么?"→ 主动找麻烦的问题 |
| Make something people want | "我做对了吗?"→ 验证用户真的要 |
怎么用
应用 Schlep Blindness:刻意找麻烦
每周问自己:
"我们行业里有什么问题是大家都不愿意碰的?"
经典"schlep"领域:
- 医疗:监管复杂、销售周期长、利益方多
- 教育:决策周期长、效果难衡量
- 政府:采购流程慢、政策风险
- B2B 工具:客户分散、定制需求多
- 制造业:供应链复杂、资本密集
YC 反复说:这些领域恰恰是 YC 体系的甜蜜点。
Stripe 做支付(金融监管 schlep)→ 估值 14B Palantir 做政府数据(政府销售 schlep)→ IPO 16.8B
应用 Make something people want:持续验证
每 3 个月问:
"如果明天我们的产品消失了,谁会真的伤心?"
工具:
- Sean Ellis 40% 测试——定量
- 用户访谈——定性
- 流失用户访谈——反向验证
案例:李泽湘体系就是"反 Schlep Blindness"
硬件创业是最大的 schlep:
- 开模要钱
- 量产要供应链
- 售后要服务体系
- 库存要现金流
99% 的创业者回避硬件——但李泽湘体系主动扎进硬件:
"中国不缺优秀的工科人才,不缺全球最完备的制造业产业链,缺的是一套能将人才、技术、市场、产业有效衔接的完整体系。"
李泽湘体系用 30 年解决了硬件 schlep——结果:265+ 家硬科技企业,4 家上市公司,13 家独角兽。
大疆、云鲸、希迪、卧安——全是在别人不愿意碰的硬件 schlep 中长出来的。
案例:YC 的反例——错过 WhatsApp
YC 2009 年拒绝了 Brian Acton 的 WhatsApp 申请——理由是"没有 hacker 特质"。
PG 后来反思:
"我们低估了那些没有明显'hacker'特质的创始人——这是 Schlep Blindness 的另一种表现。"
WhatsApp 2014 年被 Facebook 以 10B+ 潜在回报。
常见误区
| 误区 | 修正 |
|---|---|
| Schlep = 难做 | Schlep 是"麻烦"——有些麻烦的事其实简单 |
| Make something people want = 用户调研 | 用户调研是工具,不是目的——目的是"用户真的要" |
| 只听用户说的 | 用户行为 > 用户言语——用数据 |
| 每次都"make something new" | 改进已有产品也算——只要 people want |
与其他工具的关系
- 横切:贯穿所有模块——是底层哲学不是具体工具
- 特别关联:JTBD(JTBD 帮你找 schlep)、PMF(PMF 是 "Make something people want" 的量化判断)
工具十:OKR(Objectives and Key Results)
是什么
OKR(Objectives and Key Results) 是 Andy Grove 在 Intel 发明、John Doerr 在 Google 推广的目标管理工具。
结构:
Objective(目标):定性的方向性目标
│
├── Key Result 1(关键结果 1):定量的可衡量结果
├── Key Result 2:定量的可衡量结果
└── Key Result 3:定量的可衡量结果
经典例子(John Doerr《衡量什么最重要》):
O:让 Android 成为移动操作系统领导者
- KR1:Android 全球市场份额从 X% 提升到 Y%
- KR2:Android 应用数量从 X 万提升到 Y 万
- KR3:Android 设备激活量从 X 亿提升到 Y 亿
为什么用
核心问题:早期公司有战略但没落地——战略在 PPT 里,员工在做不知道为什么的事。
OKR 解决 3 个问题:
- 对齐:全员指向同一方向
- 聚焦:每季度只做最重要的 3-5 件事
- 可衡量:从模糊愿景到具体数字
John Doerr 给 Google 的第一堂 OKR 课(1999):"如果你写下来,你就更可能做到"。
怎么用
步骤 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 演化
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
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% 说明目标太低 |
与其他工具的关系
- 上游:03 模块北极星指标(北极星 → OKR 的 O)
- 下游:周会/月会(OKR 是议程核心)
工具十一: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 的一次演讲——被在场很多人称为"听过最好的演讲"。
Chesky 的经历:
- Airbnb 成功后,所有人都告诉他"该切换到 manager mode 了"——雇最好的高管,给他们充分的自主权
- 结果:灾难性的。PG 的原文是:"hire professional fakers and let them drive the company into the ground."
- Chesky 开始研究 Steve Jobs 怎么运营 Apple——然后彻底改变了自己的运营方式
- 他重建设计团队的方式与 Jobs 几乎一样——直接深度参与,而不是授权给某个 VP
Founder Mode 的实用价值:
- 对抗"职业伪装者":有经验的高管中有相当一部分擅长在层级组织中生存,但不擅长实际创造价值。Manager Mode 给这些人提供了完美的保护壳——他们只对直接上级汇报
- 保持产品直觉:当创始人被隔离在层层汇报之后,他们失去了对产品细节的感知——而这些细节往往是战略优势的来源
- 拒绝被 gaslighting:PG 指出创始人正在被两边 gaslight——VC/顾问说"你必须切换到 manager mode",而当创始人真的照做后,员工又抱怨创始人不管事了
PG:"The founder who feels like they're being gaslit is probably right."
怎么用
步骤 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
Jobs 是 PG 文章中反复提及的原型案例:
- 年度 Top 100 retreat:不论组织架构,每年带最重要的 100 人去 retreat,讨论下一年的方向。这 100 人的选择本身就是战略信号。
- 亲自看设计细节:Jony Ive 回忆 Jobs 每天都会来设计工作室,不是来"审批",而是来参与讨论——他能看到设计师自己没注意到的问题。
- 拒绝 "hire good people and leave them alone":Jobs 相信跨领域的高标准碰撞才能产生最好的结果。他会把不同领域的专家放在一个房间里争论。
另一个极端是 John Sculley——专业的职业经理人,用 Manager Mode 运营 Apple。结果:Apple 几乎死亡。
案例:Jensen Huang 的 Founder Mode
Nvidia CEO Jensen Huang 是 PG 文章中另一个核心案例:
- 60 个直接下属:传统管理学认为一个人最多管理 7-10 个下属。Jensen 有 60 个,而且他不开 1:1——他让所有讨论在公开场合进行,所有人可以听
- 在食堂吃饭:不设高管餐厅——任何员工都可以在午饭时和他聊
- 直接看代码 review:Jensen 会直接参与技术讨论——不是做决策,而是确保讨论的质量
- 结果:Nvidia 成为全球市值最高的公司之一,而且 Jensen 保持着对技术方向的直觉
案例:深圳科创学院体系下的"创始人深度参与"
李泽湘体系的成功案例也印证了 Founder Mode——
云鲸创始人张峻彬在原型机阶段,自己就是第一个装机工——在松山湖共享工厂,他自己组装第一批 100 台机器。这不是因为缺人,而是因为只有亲自装,才知道设计哪里不合理。
李泽湘说:"我见过最好的硬件创业者,没有一个不是亲自下产线的。不是你去看一眼就走,是你在产线待三天,和产线工人一起吃盒饭。"
这就是硬件版的 Founder Mode——你无法把"造东西的感觉"委托给别人。
与其他工具的关系
- 上游:Schlep Blindness + MSPW(Founder Mode 是 MSPW 的"运营版"——不只做什么,还有怎么运营)
- 上游:第一性原理(Founder Mode 要求创始人基于自己的直觉做判断——第一性原理是这种直觉的理性基础)
- 平行:OKR(OKR 是对齐工具,Founder Mode 是运营哲学——两者可以共存)
- 矛盾:Manager Mode 的组织架构(如果你发现自己公司 50 人以上、产品已标准化、创始人对细节已失去 passion——也许你应该考虑退出)
一句话:Founder Mode 不是"创始人可以任性"的 license——是提醒你:当你被告知"该像职业经理人一样管公司了",你有权利说"不"。因为最好的公司,绝大多数不是职业经理人管出来的。
11 个工具的整体关系图
这 11 个工具的本质:从"PMF 后"到"可持续公司"的 11 步——
- Default Alive:判断公司能否活下去
- Runway:算清楚还能撑多久
- SAFE:用最快工具融资
- Cap Table:管理股权不被稀释失控
- TAM/SAM/SOM:算清楚市场天花板——自己先想明白,再写进 Deck
- Pitch Deck:把融资故事讲清楚
- 第一性原理:用根本逻辑做战略决策
- 双钻模型:用结构化方式做选择
- Schlep + MSPW:用 YC 哲学提醒自己"做什么"
- OKR:把战略落地到全员执行
- Founder Mode:用创始人的方式运营公司——拒绝"你该像个职业经理人了"
完成这 11 步后,你就有了一个真正可持续的公司——不仅有 PMF,还有活下去的资本、清晰的股权和市场规模判断、可重复的战略思维、全员对齐的执行,以及保持创始人直觉的运营哲学。
关联文档
本模块内:本页是 04 模块的唯一文档。
本模块其他章节:
- 01 · 用户洞察——本模块的战略地基
- 02 · 价值与商业模式——本模块的融资叙事来源
- 03 · 验证与增长——本模块的 PMF 前提
关联模块:
- Y Combinator 深度分析——SAFE、Default Alive、Pitch Deck、Schlep Blindness 的源头
- 深圳科创学院深度分析——李泽湘体系的第一性原理与战略落地
- 产品经理的战略规划和业务架构能力
- 万字长文:商业的本质与互联网——战略思维哲学基础
- 从双钻模型看产品规划——双钻模型的另一个角度
- 创业公司融资全生命周期——融资实操
- 产品经理必知必会的商业化变现模式——商业模式扩展
参考资源
- Paul Graham "Founder Mode"(2024 essay)——PG 十年来最具影响力的新概念,原文
- Paul Graham "Default Alive vs Default Dead"(2015 essay)——二元生存判断的源头
- Paul Graham "Schlep Blindness"(2011 essay)——Schlep Blindness 概念
- YC SAFE 模板(2013)——免费下载
- Brad Feld《Venture Deals》(2012)——融资条款的完整指南
- Andy Grove《High Output Management》(1983)——OKR 的概念源头
- John Doerr《Measure What Matters》(2018)——OKR 在 Google 的应用
- Elon Musk "First Principles"(2012 TED)——第一性原理的案例
- 英国设计委员会 "Double Diamond"(2005)——双钻模型的原始报告
- Sequoia Capital "Writing a Business Plan"(2012 blog)——Pitch Deck 10 页结构的源头
- Alex Clayton "Pitch Deck Teardown"(2018-2024 系列)——Pitch Deck 案例