《四步创业法》笔记：先验证，再烧钱

Steve Blank 的《The Four Steps to the Epiphany》（中译《四步创业法》，2003 年初版）是硅谷创业方法论的一块地基。Eric Ries 是 Blank 的学生，《精益创业》（The Lean Startup）里那套"构建-测量-学习"，源头就在这本书的客户开发（Customer Development）框架里。

但这两本书的气质很不一样。《精益创业》像一本写给大众的方法论普及读物，而《四步创业法》更像一份带验收标准的工程文档：四步流程，每一步有明确的检查点，过不了关就得回退重做，不许跳关。Blank 自己创过八次业，书里的每一条规则背后几乎都有一个他自己交过学费的故事。

这篇笔记只提炼我认为最有杀伤力的四块内容：核心命题、四步流程、客户访谈铁律、正反两个案例。写给工程师同行看的，所以口吻会比较像"系统设计评审"。

一、核心命题：初创公司不是大公司的缩小版

全书第一页就扔出来的观点，也是理解后面一切的前提：

A startup is not a smaller version of a large company.

大公司做的事是执行一个已知的商业模式：客户是谁、要什么、怎么触达、卖多少钱，都是已知的，所以可以用成熟的那套管理体系——年度计划、KPI、按职能分工、按里程碑考核。

而初创公司面对的全是未知数。Blank 的原话大意为：一家初创公司是一个临时性组织，其使命是寻找一个可重复、可扩展的商业模式。注意"寻找"这个词——在商业模式被验证之前，你在公司里做的一切"执行"都是在拿不确定的假设当事实烧钱。

flowchart LR
    subgraph 大公司["大公司：执行已知模式"]
        A1["商业模式已知<br/>客户/需求/渠道明确"] --> A2["按计划执行<br/>年度预算 / KPI / 里程碑"]
        A2 --> A3["结果可预测<br/>偏差是执行问题"]
    end
    subgraph 初创公司["初创公司：寻找未知模式"]
        B1["全是假设<br/>客户是谁？痛点真不真？<br/>愿意付钱吗？"] --> B2["跑出去验证假设<br/>客户探索 / 客户验证"]
        B2 --> B3{"找到可重复<br/>可扩展的模式？"}
        B3 -- "否" --> B2
        B3 -- "是" --> B4["转型为执行型公司"]
    end

这个命题的工程类比很直接：你不会在需求文档还没写、接口还没定的时候就招 50 个人开干；但无数创业公司恰恰就是这么做的——产品还没人验证过，先把销售团队、市场预算、办公室全都配齐。Webvan（后面详述）就是这么死的。

感悟：做技术的人最容易犯的书里点名的错误，是把"产品能不能做出来"当成主要风险。实际上大多数创业项目里，技术风险远小于市场风险——“能不能做出来"通常有答案，“做出来有没有人买"才是真正的未知数。把资源配比搞反了，再强的工程能力也救不回来。

二、客户开发四步：前两步省钱，后两步烧钱

Blank 提出的客户开发模型（Customer Development）与传统的"产品开发模型”（idea → 开发 → 内测 → 发布 → 大卖）并行，专治后者"发布即巅峰，然后发现没人要"的通病。

先把两种模型的世界观摆在一起对比，差异一目了然：

传统模型的经典剧本你一定见过：拿到投资 → 定一个 12 个月后的发布日期 → 全部资源按这个日期倒排 → 发布当天开香槟 → 三个月后销售数字难看 → “是市场部门不给力” → 换销售 VP → 还是不行 → 没钱了。这个剧本的 bug 在于：从产品立项到发布，全程没有一个环节问过客户。

客户开发模型就是给这个 bug 打的补丁。四步是：

flowchart LR
    S1["① 客户探索<br/>Customer Discovery<br/><br/>验证问题：痛点存在吗？<br/>我们的方案解得对吗？<br/>成本：极低，PPT 和原型就够"]
    S2["② 客户验证<br/>Customer Validation<br/><br/>验证交易：真的有人付钱吗？<br/>销售流程可重复吗？<br/>成本：低，创始人亲自卖"]
    S3["③ 客户创造<br/>Customer Creation<br/><br/>制造需求：市场教育<br/>品牌、渠道、放量获客<br/>成本：高，开始烧钱"]
    S4["④ 公司建设<br/>Company Building<br/><br/>组织升级：从游击队到正规军<br/>建部门、定流程、规模化<br/>成本：高，全面扩张"]

    S1 --> CP1{"检查点 1<br/>找到可验证的<br/>问题-方案匹配？"}
    CP1 -- "不过关 → 回退" --> S1
    CP1 -- "过关" --> S2
    S2 --> CP2{"检查点 2<br/>拿到真实订单？<br/>销售路径可重复？"}
    CP2 -- "不过关 → 回退" --> S1
    CP2 -- "过关" --> S3
    S3 --> CP3{"检查点 3<br/>需求被验证可放量？"}
    CP3 -- "不过关 → 收缩回炉" --> S2
    CP3 -- "过关" --> S4

这张图里有几个关键点值得掰开说：

2.1 前两步的核心任务是"证伪”，不是"证明"

客户探索阶段，创始人要走出办公室（Get Out of the Building），拿着假设去找几十上百个潜在客户聊。目标不是听到"你这个想法真棒"，而是尽可能快地发现自己的假设错在哪。Blank 的态度近乎残忍：在产品发布前，你的商业计划书上关于客户的一切内容都只是猜测，创始团队唯一该做的事就是把这些猜测一条条拎出来验证。

客户验证阶段更进一步：光说"我喜欢"不算数，得有真实的购买行为。有没有人愿意付钱、付款流程跑不跑得通、第一单的销售周期多长、能否复制出第二单第三单——这些构成了"可重复的销售路线图"。

2.2 前两步要抠门，后两步才配烧钱

书里反复强调一条纪律：在客户验证通过之前，花大钱是犯罪。因为此时你根本不知道自己要放大的是什么——把一个错误的模式放大十倍，只会死得十倍壮观。反过来，一旦前两步跑通，后两步（客户创造、公司建设）就要敢于重投入，因为这时候烧钱烧的是"已验证的公式"。

这个"先省后烧"的节奏，和很多人理解的融资节奏正好相反：刚拿到钱时最该克制，验证闭环后才该激进。

2.3 回退不是失败，是流程的一部分

注意图里的回退箭头——这是《四步创业法》比后来的很多简化版方法论更"硬核"的地方。每个检查点都是硬闸门：验证不过关，就退回去调整假设重新探索，不允许带着未验证的假设进入下一阶段。Webvan 式的死法，本质就是跳过了检查点 1 和 2，直接按第 3、4 步的规模花钱。

2.4 检查点到底查什么：一张验收清单

“检查点"如果停留在口号层面就毫无约束力。把每一步的过关标准落成可核对的问题清单，它才真正变成闸门：

检查点 1（客户探索 → 客户验证）

• 问题确认：访谈的几十个人里，是否有足够多的人承认这个痛点真实存在且重要？（不是"有点意思”，是"这确实烦到我/花我钱了"）
• 方案确认：听完你的方案描述后，客户的眼神是亮了还是礼貌性点头？有没有人追问"什么时候能买到"？
• 产品定义收敛：最小产品功能集是否已经收敛到一个可以拿去卖钱的版本，而不是越聊越大？

检查点 2（客户验证 → 客户创造）

• 真实订单：有没有不是看创始人面子下的订单？（熟人单、友情单要打折甚至剔除）
• 可重复性：第二单、第三单的销售路径和第一单是否相似？如果每单都是创始人刷脸+定制化，那是咨询不是产品；
• 经济性可算：获客成本、销售周期、毛利，能不能算出一个"投入一块钱回来不止一块"的初步公式？

检查点 3（客户创造 → 公司建设）

• 放量有效：市场投入加大后，获客成本是否仍然可控，还是一边际就崩？
• 组织就绪：团队能否从"什么都能干"的游击队，切换成有分工有流程的正规军而不崩盘？

你会发现这张清单的每一个问题都是可以回答"是/否"的——这正是它和"我们感觉进展不错"的区别。

感悟：这个流程对工程师来说应该特别眼熟——它就是软件工程里的"阶段门"（stage-gate）和"快速失败"（fail fast）思想在商业侧的对应物。我们没有理由在写代码时信奉持续集成、小步验证，到了判断"要不要做这件事"时却改用信仰驱动。

三、客户访谈铁律：只问过去行为，不问未来承诺

这是全书里我认为实操价值最高的一节。客户探索阶段的核心动作是访谈，而访谈有一个巨大的陷阱：如果你问客户"你会不会买"，你几乎一定会得到误导性的答案。

原因是双重的：

• 客户出于礼貌或者对你的好感，倾向于给出鼓励性回答（尤其在熟人访谈里）；
• 人在假设性问题上的自我预测能力极差——“你会为了省一小时每月付 50 块吗”，答"会"的人里真掏钱的寥寥无几。

所以 Blank 的铁律是：问过去的行为和既成事实，不问未来的意愿和假设的承诺。

flowchart TB
    subgraph WRONG["❌ 错误问法：问未来承诺"]
        W1["'如果我做出这个功能<br/>你会用吗？'"]
        W2["'这样的产品<br/>你愿意付多少钱？'"]
        W3["'你会推荐给你的<br/>同事/朋友吗？'"]
    end
    subgraph RIGHT["✅ 正确问法：问过去行为"]
        R1["'你现在是怎么解决<br/>这个问题的？详细说说。'"]
        R2["'上次这个问题让你<br/>多花了多少时间/钱？'"]
        R3["'你为解决这个问题<br/>已经试过什么？花了多少预算？'"]
    end
    WRONG --> HARM["得到的全是礼貌性肯定<br/>和拍脑袋的数字<br/>→ 虚假的市场信心"]
    RIGHT --> GOLD["得到的是事实、数字<br/>和现有替代方案<br/>→ 可以证伪的证据"]

几条我实践下来觉得最管用的推论：

1. “你现在怎么解决"是金矿问题。 如果客户现在对这个问题根本没有解法、也懒得找解法，那"痛点"多半没你以为的那么痛。真正痛的问题，客户往往已经在用 Excel、人工、土办法凑合解决——这些临时方案就是你要替代的对象，也是最好的需求说明书。
2. 问到具体数字为止。 “挺浪费时间的"是观点，“每周三个人天"是事实。访谈要追到最后那个数字，数字才有决策价值。
3. 警惕"功能许愿单”。 客户说"如果加上 XX 我就买”，多数情况下加了也不会买。要追问的是"没有 XX 让你损失了什么”，损失越具体越真实。
4. 承诺要用成本来检验。 口头说好不算数，愿意试用、愿意引荐决策人、愿意预付定金、愿意签意向书——让客户付出哪怕一点点真实成本，信号强度立刻真实一个数量级。

访谈执行层面还有三个实操细节，都是容易踩的坑：

坑 1：访谈熟人。 第一批访谈对象最容易找的是朋友、前同事、行业熟人——但他们恰恰是信号最差的受访者：碍于情面不愿意泼冷水，又因为了解你而过度脑补你的方案。熟人访谈可以用来打磨访谈提纲，但其结论不该计入验证证据。真正有价值的访谈发生在"和你没有私交、对你的成败无所谓"的陌生人身上。

坑 2：演示欲太强。 访谈进行到第五分钟，你就忍不住打开电脑开始讲产品——从这一刻起访谈就死了，剩下的全是客户对你演讲的社交性回应。正确顺序是：先用 80% 的时间挖对方的现状和行为史，最后留一小段再谈方案，并且把方案描述成"我们在琢磨的一个东西"而不是"我们牛逼的产品"。姿态越低，真话越多。

坑 3：一个人访谈一个人记。 访谈现场的信息密度极高，语气、迟疑、眼睛亮起来的瞬间，速记根本记不全。理想配置是两个人：一个人负责聊，另一个人负责记，事后立刻对笔记。Blank 甚至建议团队集体复盘每一场访谈，因为同一句"挺好的"，创始人听的是希望，旁观者听的是敷衍。

踩坑类比：这跟技术面试里"行为面试法"（讲一个你做过的项目）碾压"假设性问题"（如果是你会怎么做）是同一个原理——过去的行为是未来行为最好的预测器，假设性回答基本等于噪音。

四、反面教材：Webvan，用 8 亿美元验证了一个没验证过的假设

书里没把 Webvan 当成重点案例写（书出版时它刚死），但它是"跳过检查点直接烧钱"最完美的标本，值得每一个读过这本书的人记住。

Webvan 是 1999 年前后最风光的电商明星：做生鲜杂货网上配送，理念放到今天都不过时（你可以把它理解成早了十五年的每日优鲜/Instacart）。它的问题不在想法，而在节奏：

• 商业模式从未在小规模上验证过——客单价、配送密度、履约成本、复购率这些决定生死的数字，全都停留在商业计划书里；
• 团队直接按"模式已成立"的剧本行动：融资数亿美元，开建覆盖全美的自动化仓储体系，单个仓库造价数千万美元，还签下十几亿美元的建设合同；
• 仓储是重资产、强固定成本结构，只有订单密度足够高才摊得薄。而真实情况是订单密度远低于预期——仓库建得越先进，闲置得越壮观，每天开门就是巨额亏损；
• 2001 年 7 月，Webvan 申请破产保护，前后烧掉超过 8 亿美元，成为互联网泡沫破灭时最昂贵的尸体之一。

用客户开发的视角复盘，Webvan 的死法一目了然：它把第③步（客户创造）和第④步（公司建设）的动作，在第①②步还完全没有通过检查点的时候，就以全美规模执行了。假设没被验证，执行得越完美、越坚决，死得越快越贵。

对照组：二十多年后，生鲜前置仓模式在订单密度足够高的城市被部分验证成立——这说明 Webvan 的"想法"未必全错，它错的是在错误的密度上、用错误的资本结构、抢跑了十几年。商业模式的验证里，时机和单位经济模型（unit economics）和方向一样重要，而这恰恰是只有小步试错才能探出来的东西。

五、正面教材：E.piphany，拎着原型上门，改完定位再上市

E.piphany 是 Blank 自己创办的第八家公司（1996 年创立，企业级软件），书里用大量篇幅复盘了它早期的客户开发过程，可以说是全书方法论的原型案例。

故事的关键转折：Blank 团队最初对产品定位有一套自己的假设（面向某类企业用户的分析工具），他们没有关起门来把产品做"完整"再亮相，而是拎着还很粗糙的原型，直接坐到潜在客户的办公室里演示、听反馈。

这一圈跑下来，团队发现了一个他们完全没预料到的事实：客户最兴奋的、最愿意掏钱的功能点，和团队自认为的"核心价值"不是一回事。客户的需求、预算归属、采购链条，都在访谈中露出了和商业计划书里不一样的真面目。

于是 E.piphany 修正了产品定位和价值主张——瞄准客户真实承认的那个痛点，而不是创始人想象中的那个。修正后的定位被市场接住，公司于 1999 年在纳斯达克上市。

这个故事里最值得工程师细品的，是"原型"的定位：原型的价值不是展示你做得多好，而是给客户一个可以批评的靶子。 空手去访谈，客户只能凭想象回答，回到第三节的陷阱；带着粗糙的原型去，客户会指着具体的东西说"这个没用"“我要的是那个”——这些才是能证伪假设的证据。Blank 管这个过程叫"现实扭曲力场的解毒剂"：创始人都活在自己的愿景里，只有客户基于真实使用场景的冷水能解毒。

六、与《精益创业》的关系：老师比学生更"硬核"

两本书的关系一句话能说清：Eric Ries 在斯坦福旁听了 Blank 的客户开发课程，后来 Blank 还投资了他的公司 IMVU 并亲自盯这套方法的执行。《精益创业》的"构建-测量-学习"循环、MVP、转型（pivot），都能追溯到《四步创业法》。

但读法上我推荐两本都读，而且先读这本：

• 《精益创业》告诉你要快——快速构建、快速测量、快速学习，小步快跑；
• 《四步创业法》告诉你跑到哪算一站——检查点不通过就不许进入下一阶段，“快"必须受闸门约束。

更细一点的对比：

只读《精益创业》的团队容易得一种病：把"快速迭代"当成不验证就扩张的遮羞布——反正我们在迭代嘛。Blank 的框架对这种自欺没有容忍度：检查点的定义是白纸黑字的（有没有真实订单？销售路径可不可重复？），过关就是过关，没过关就回退，没有"我们正在 pivot 的路上"这种模糊地带。

感悟：把它映射到工程语境就是——MVP 是手段不是目的，目的是拿到那张"检查点通行证”。一个团队如果连"本轮迭代要验证哪个假设、验证标准是什么"都答不上来，那它做的不是精益创业，是精益许愿。

七、思考与感悟

1. “找模式"和"执行模式"需要完全不同的能力组合，甚至不同的组织形态。 探索期需要的创始人是侦探：低 ego、能忍受否定、善于从只言片语里拼真相；扩张期需要的管理者是指挥官：定目标、建体系、规模化复制。Blank 在第四步专门讨论了这种转型之痛——很多公司死在第二步到第三步之间，不是模式没验证，是组织没跟着切换。这对技术团队选搭档、看创业机会都是很好的评估框架。

2. 检查点思维可以下放到一切不确定性高的工作。 我读完之后把这套"假设 → 验证 → 不过关就回退"的循环用到了技术选型上：新框架引入前先定义"什么指标算验证通过”（性能提升多少？开发体验改善如何量化？），跑 spike 验证，不达标就体面撤退。这比"先用起来再说，不行再换"省下的沉没成本是实打实的。

3. 客户访谈是一门反直觉的手艺，工程师尤其需要补课。 我们的职业习惯是"给方案"，客户刚说半句痛点，脑子里架构图都画好了。访谈恰恰要求把方案摁住，专注挖对方的行为史。这需要刻意练习，但它的回报率极高——无论是创业、做内部工具还是接需求，“用户真正的问题是什么"永远是最值得先验证的假设。

4. 节奏感比正确性稀缺。 Webvan 的方向二十年后被证明部分成立，E.piphany 的原型粗糙得不好意思见人——胜负手不在谁的起点更正确，而在谁把"验证"和"投入"的顺序摆对了。先验证，再烧钱；先小人后君子；先证伪，后放大。这大概是全书最值得抄在墙上的九个字：先验证，再烧钱；不过关，就回退。

本篇小结

• 初创公司的本质是"寻找可重复、可扩展商业模式的临时组织”，不是大公司的缩小版——用执行体系管理探索期，是多数创业死亡的总根源。
• 客户开发四步：客户探索（验证问题-方案匹配）→ 客户验证（验证真实交易、可重复销售路径）→ 客户创造（放量获客）→ 公司建设（组织规模化）。前两步要省，后两步才配烧；每步有检查点，不过关必须回退。
• 客户访谈铁律：只问过去行为，不问未来承诺。“你现在怎么解决的"比"你会不会买"值钱一万倍；口头好评是噪音，付了成本（时间、引荐、定金）的信号才是证据。
• 两个案例对照：Webvan 未验证商业模式就按全美规模建仓，2001 年破产烧掉超 8 亿美元；E.piphany 拎着粗糙原型上门挨骂，修正定位后 1999 年上市。
• 它是《精益创业》的源头，且更硬核：MVP 和迭代必须有检查点约束，否则"快速迭代"会退化成"快速许愿”。

• 读书笔记

• 读书笔记
• 创业
• 客户开发
• 精益创业
• 产品

方糖猫（大可）

18 年后端架构，现在独立做 AI 产品。这里记录 AI 视频、AI Agent 与工程实践。