YC Library:如何规划 MVP — Michael Seibel
英文原题:How to Plan an MVP 出处:ycombinator.com/library/6f-how-to-plan-an-mvp 讲师:Michael Seibel — YC 合伙人,Justin.tv / Socialcam / Twitch 联合创始人 系列:YC Startup School
先说结论:MVP 不是产品,是用来验证假设的工具
如果你对 MVP(最小可行产品,Minimum Viable Product)的理解还停留在"功能简陋的第一版产品",我建议你把 Michael Seibel 这场讲座重新读一遍。
Michael 是 Twitch 的联合创始人,在 YC 做合伙人多年,看过上千份 MVP。他这场讲座想讲的其实只有一句话——
MVP 不是产品,它是你能放到第一批用户面前、看自己能不能给他们带来一点点价值的第一个东西。仅此而已。
这句话的关键不是"简陋",而是"能不能验证"。很多人花三个月做出一个自以为完整的 MVP,结果没人用——那它就不是 MVP,只是一个写错了假设的实验。
我读完这场讲座最强烈的两个感受:
- "快速发布一个烂东西"胜过"慢速发布一个完美东西"。Michael 把这句话反复强调,而且后面所有的内容都是这句话的变体。
- 别爱上你的 MVP。MVP 只是你旅程的第一步,就像你一年级写的论文——你不会把它装裱起来挂墙上。
下面我把讲座的核心拆成几节来讲,每节都带上我的解读。
一、开场:MVP 到底是什么
Michael 的开场很坦诚——YC 总是喊着让创始人别说行话,结果 YC 自己有一堆蠢透了的创业行话,MVP 就是其中之一。
他给 MVP 的定义是:
极其简单的东西。这是你能给第一批目标用户的第一个东西,目的是看自己能不能给他们带来任何价值。仅此而已。
我的解读:这一定义里最重要的三个词是"第一批""任何价值""仅此而已"。
- "第一批"——MVP 不是给所有人用的,是给一小群有强烈痛点的人用的;
- "任何价值"——不需要解决全部问题,解决一点点就行;
- "仅此而已"——别把它神圣化,它就是个实验装置。
如果你把 MVP 当成"产品的第一版",你就会忍不住往里加功能。如果你把它当成"验证假设的实验",你就会舍得砍功能。
二、做 MVP 之前:先和用户对话
Michael 在讲座里反复强调一个反直觉的点——做 MVP 之前,先和一些用户聊聊。
但这不是让你去做两年的行业研究,也不是让你在行业里干十年。只是一些对话就够了。
如果你自己就是目标用户,那就更省事——你能直接判断自己的产品到底有没有用。
Michael 提到一个让他困惑的问题:"我如何获得第一批用户?"他的回答很直白——
理论上,你是决定去解决一个你知道某人有的问题。所以获得第一批用户的方法,就是去和那个你知道有这个问题的用户对话。
如果你正在为一个"你根本不知道是谁"的神秘用户群体做产品——Michael 的建议是:轻微地质疑一下自己。
我的解读:这一段戳中了很多创始人的通病——先做产品再找用户。正确的顺序应该是:先认识一群有具体问题的人,再做解决这个问题的 MVP。MVP 不是用来"发现用户"的,是用来"验证你已经认识的那群用户"的。
三、早期创业公司的四个目标
Michael 把早期创业公司要做的事拆成四步。我把它整理成表格,加上"我的注解":
| 步骤 | Michael 的说法 | 我的注解 |
|---|---|---|
| 1. 快速发布 | "快速发布一个烂东西" | 全场讲座的核心,后面都是这句话的变体 |
| 2. 获取初始客户 | 让任何人使用你的产品,不需要愿景 | "任何人"比"目标用户"更重要,先有人用再说 |
| 3. 和用户对话获取反馈 | 不要等做完整再听反馈 | 大部分创始人卡在这一步,觉得"还不够完整,听了也没用" |
| 4. 迭代(不是 pivot) | 留住问题和用户,改解决方案 | 迭代 ≠ 转型,这是关键区分 |
3.1 第一步:快速发布
Michael 说这是 YC 从一开始就有的理念,过去 10 年是好建议,现在依然是好建议。
如果你只能从这场讲座学到一件事,那就是"快速发布一个烂东西"。
3.2 第二步:获取初始客户
你会惊讶于有多少创始人的旅程,在没有任何用户实际使用过他们创建的产品之前就结束了。
我的解读:这一句要划重点。很多创始人不是死在产品差,而是死在从未把产品放到真人面前。他们一直在"完善",完善到公司倒闭。
3.3 第三步:和用户对话获取反馈
这一步是最常见的错误。很多创始人的逻辑是:
"当然它不会 work,它不是完整的东西。完整的东西需要三年、一千万美元、整个团队。所以对这个 little thing 的反馈是没用的。"
Michael 的反驳很精彩——
现实是,完整的东西是你脑子里那个非常棒的想法,你应该把它留在脑子里,但它应该非常非常灵活——因为最终你想 build 的完整东西,可能根本不是你的客户想要的。
他给了一句值得贴墙上的话:
紧紧抓住你在解决的问题,紧紧抓住你的客户,松松掌握你在 build 的解决方案。
我的解读:这三个"抓"的松紧对比,是这场讲座最精华的一句。问题要紧、客户要紧、解决方案要松——因为解决方案一定会变,问题和客户不会。
3.4 第四步:迭代,不要 pivot
Michael 特意区分了 iterate(迭代)和 pivot(转型)。
很多创始人一旦做出来一个东西,就爱上了它。如果它对某一群用户不管用,他们就开始想——
"嗯,我想知道这个东西还能解决什么问题?你看,这个螺丝刀实际上并不能拧任何东西,但我想知道它还能解决什么问题。也许你可以用它来做饭。也许你可以用它来打扫。"
Michael 的反驳——
不。问题是,我需要拧东西,用户是修理工。如果你的螺丝刀不能帮修理工解决问题,那就留住修理工,留住问题,我需要拧东西——修好这个该死的螺丝刀。坏掉的不是修理工,也不是他们需要拧东西这件事。
我的解读:这个螺丝刀的比喻绝了。迭代是修螺丝刀,pivot 是把螺丝刀改成锅铲。前者是改解决方案,后者是连问题都换了。大部分时候你该做的是前者。
四、如何快速构建 MVP
4.1 时间单位是"周",不是"月"
大多数人应该 build 一个非常精简的 MVP。你应该能快速 build 它,以周为单位,而不是月。
这可以涉及软件,也可以只是一个 landing page(落地页)加一个 spreadsheet(电子表格)。大多数创业公司可以非常快地开始。
4.2 功能要极其有限
把你初始用户的需求,压缩到一组非常简单的需求。
很多创始人想同时解决所有用户、所有潜在用户的所有问题。正确做法是——专注一小群初始用户和他们最高阶的问题,其他先忽略。
你应该有一个面向所有人的愿景。但你应该有一个非常小的 MVP。
我的解读:这一段是全场最反直觉的地方——愿景要大,MVP 要小。愿景是讲给投资人和未来用户听的,MVP 是给第一批真实用户用的。这两个尺度不能混。
五、经典案例:Airbnb、Twitch、Stripe 的第一天
Michael 用三个十亿美元公司举例,证明它们都从"相当烂"的东西开始。我把这三个案例做成表格,加上"我的注解":
| 公司 | 第一天的样子 | 我的注解 |
|---|---|---|
| Airbnb(2008) | 没有支付功能(必须当面给现金)、没有地图视图、写代码的 Nate 还是 part time | 连核心闭环都残缺,但能验证"有人愿意住陌生人家" |
| Twitch(当时叫 Justin.tv) | 只有一个频道(Justin 本人)、视频分辨率极低、没有电子游戏(除非创始人在公寓玩) | 它的第一天根本不是直播平台,是一个 online reality TV show |
| Stripe(当时叫 /dev/payments) | 没有银行交易、几乎没有功能、创始人亲自上门帮你集成 | "创始人亲自集成"听起来 low,但这是发现 bug 的最快方式 |
这只是三个极其简单、极其快速 build 的 MVP 的例子。这些都是十亿美元的公司,它们都从大多数人会说相当烂的东西开始。
我的解读:这三个案例的共同点不是"简陋",而是——它们都先验证了最核心的那一个假设。Airbnb 验证"有人愿意住陌生人家里",Twitch 验证"有人愿意看另一个人生活",Stripe 验证"开发者愿意用更简单的支付"。核心假设验证了,功能可以慢慢补。
六、Heavy MVP:当快速发布不可行时
Michael 承认,极少数情况下你必须做一个"重型 MVP"(他两天前刚发明了这个词)。
适用于:
- 严格监管行业——保险、银行、有时是无人机;
- 硬科技——造火箭,几周内造不出来;
- 生物科技——几周内发明抗癌药,做不到;
- Moonshots——在地球上钻隧道、造极快替代汽车的车,几周内做不到。
但 Michael 提醒——
即使在这些情况下,你的 MVP 也可以从一个简单的、解释你做什么的网站开始。当你和人交谈时,他们可以 refer 回去看。
在很多方面,你的 heavy MVP 可能比你的 lean MVP 更快——以一种奇怪的方式。
我的解读:这一段很关键。重型行业的创始人最容易拿"我们做不出 MVP"当借口拖延。Michael 的意思是——哪怕你造不出火箭,你也能在几天内做出一个网站,用它来收集意向、验证需求。"造不出来"不等于"不能 launch"。
七、重新定义 Launch:不要等"大日子"
很多创始人对 launch(发布)有误解——他们看到 Facebook、Google 这种公司 launch 时铺天盖地的媒体报道,就以为那就是 launch 的样子。
Michael 现场问了一个问题:有多少人记得 Google launch 的那一天?Facebook 呢?Twitter 呢?
答案:没有人记得。
Launch 根本没那么特别。如果你有一个 magical launch 的想法想做,把它扔掉。
Michael 区分了两种 launch:
| 类型 | 含义 | 我的注解 |
|---|---|---|
| Launch | 当你获得任何一个客户的时候 | 这是你要追求的——快、早、不完美 |
| Press Launch | 媒体报道、buzz、兴奋 | 这是你要往后推的——等你有 traction 再做 |
让我们把 press launch 往后推,把"获得任何一个客户"的 launch 真的非常快地推出去。
我的解读:这一段对所有纠结"什么时候 launch"的创始人都是解药。Launch 不是大日子,Launch 是你拿到第一个客户的瞬间。纠结 launch 时机的人,90% 是在逃避"还没人用"这个事实。
八、为什么必须把产品放到用户面前
当你的客户没有一个可以玩的产品时,你很难向他们学习。
你可以和客户聊一整天,但你不知道你想 build 的东西是否能解决他们的问题。
如果你把东西放到他们面前,而它没有解决他们的问题,你立刻就知道。
世界上所有的研究都是好的,但直到你能把东西放到人们面前,你根本不知道它会不会 work。
我的解读:这一段是讲座的哲学核心——研究代替不了实验。访谈、问卷、focus group 都有用,但它们都不能告诉你"你的方案到底行不行"。只有把方案放到用户手里,真相才会浮现。
九、快速构建 MVP 的 4 个 Hack
Michael 给了 4 个实操技巧。我整理成表格加注解:
| Hack | Michael 的说法 | 我的注解 |
|---|---|---|
| 1. Time box 你的 spec | 给 launch 前要做的事设时间盒(如 3 周),只做能在这段时间做完的 | 时间盒倒逼砍功能,最有效 |
| 2. 写下你的 spec | 大多数人没写下来,改了也不自知,3 周变 3 个月 | 写下来才能诚实面对自己的反复 |
| 3. 砍掉你的 spec | 一周后发现赶不上?直接砍,没有不重要的就砍重要的 | 目标只是"把任何东西放到世界上" |
| 4. 不要爱上你的 MVP | 你不会爱上你一年级写的论文,MVP 也一样 | 爱上 MVP = 反复 tweak = 永远 launch 不出去 |
9.1 Hack 1:Time box 你的 spec
你的 spec 是在 launch 之前你需要 build 的东西的清单。给它设一个时间盒。
如果我想在三周内 launch 会怎样?我 spec 上唯一能有的东西是我能在三周内 build 的东西。
9.2 Hack 2:写下你的 spec
在你 launch 之前改变你在做什么非常容易,因为你从来没有写下来。
如果你把东西写下来,至少你可以诚实地面对自己——你一直在改变你的 spec。
9.3 Hack 3:砍掉你的 spec
在你三周的 sprint 进行一周后,你可能意识到你在 spec 里加了太多东西。没关系。直接砍掉那些明显不重要的东西。如果没有不重要的东西,开始砍重要的东西。
这里的大部分目标只是把任何东西放到世界上。一旦你把任何东西放到世界上,继续做下去的 momentum 非常强。
9.4 Hack 4:不要爱上你的 MVP
太多人爱上他们脑子里的愿景。我给你看的之前的产品没有一个是最初的愿景——它们最终变成的样子。
请不要爱上你的 MVP。它只是旅程的第一步。
我的解读:这 4 个 Hack 里,Hack 1 和 Hack 3 是配套的。Time box 让你一开始就砍掉做不完的,砍 spec 让你中途继续砍。两个砍下来,你的 MVP 就真的"最小"了。
十、Q&A 精选
讲座最后有 Q&A,我挑几个最关键的整理。
Q1:用户想要不同功能怎么办?
提问:我和用户对话,不同 subgroup 想要不同的东西,怎么平衡?
Michael:永远不要问用户要功能。用户的 job 不是想出功能,那是你的 job。用户的 job 是给你问题。
如果有人 sneak 进 feature zone("我爱 Word,但希望有人做个 X"),你要把它推回——"你为什么想做 X?你有什么问题?你多久遇到一次?"
我的解读:这一段是用户访谈的金科玉律。用户擅长描述痛苦,不擅长开药方。把功能请求翻译回问题,再自己设计解决方案。
Q2:一直在改 MVP 怎么办?
提问:我陷入了一个不断改 MVP 却不 launch 的循环。
Michael:停止。停止改。
你觉得 MVP 很特别,所以你一直在 tweak 它。如果你假设它必须真的很烂——就像你找一件可以画画然后销毁的衬衫——你就不会花时间 tailor 它。
我的解读:这个比喻太到位了。把 MVP 当衬衫,你才会反复修改;把 MVP 当画布,你才会下笔就画。
Q3:应该问用户什么问题?
提问:launch 了 MVP 后,要问用户的关键问题是什么?
Michael:
它是否解决了我想要它解决的问题?就这些。
如果这是一个用户每天都有的问题,你介绍了一个解决方案,他们第二天会回来吗?我从来没见过一个真的解决了日常问题的产品,用户却不用它的。
我的解读:只问一个问题,看用户是否在做你想让他们做的事。其他都是噪音。
Q4:MVP 应该持续多久?
提问:MVP 应该持续多久?下一步是什么?
Michael:我不喜欢想时间线。
创业公司的特点之一是从 A 到 Z 怎么走不会清晰。如果你太专注于"到达 MVP 是步骤 B,但我真的想要步骤 C、D、E"——我会告诉你,先解决你面前的问题怎么样?
我的解读:这一问暴露了创始人的通病——想得太远。MVP 阶段唯一该想的就是"launch 出去",后面的 CDE 等真 launch 了再说。
Q5:增长 vs 留存,先做哪个?
提问:MVP 之后,先做增长还是先做留存?
Michael:这是一个允许我给出荒谬答案的问题——两者都是。
什么更重要,增长还是留存?就像问"什么更重要,洗澡还是上厕所"——我希望你两个都做。
很多创始人理解创业是多变量问题,但多变量很难。所以他们想简化成单变量。别这么做。
我的解读:Michael 这个回答虽然调侃,但点破了创业的本质——没有银弹,所有变量都要同时管。
Q6:用户不愿意谈问题怎么办?
提问:如果用户有不想谈的问题(比如二型糖尿病),怎么和他们对话?
Michael:我质疑你 starting a startup 去帮助二型糖尿病患者——如果你不认识任何有二型糖尿病、愿意和你谈的人。
我拒绝这个问题的前提。
我的解读:这一问是全场最狠的回答。如果你连 10 个愿意聊的目标用户都不认识,你就不该做这个方向。MVP 不是用来"发现用户"的,是用来"验证你已经认识的用户"的。
十一、核心要点总结
我把讲座反复强调的几条拎出来,每条配我的解读:
-
MVP 是验证假设的工具,不是产品。 我的解读:把它当实验装置,不当作品。
-
快速发布一个烂东西。 我的解读:慢是最贵的错误。
-
紧紧抓住问题和客户,松松掌握解决方案。 我的解读:问题客户是常量,方案是变量。
-
迭代,不要 pivot。 我的解读:修螺丝刀,别把螺丝刀改成锅铲。
-
不要爱上你的 MVP。 我的解读:爱上它 = 永远 launch 不出去。
参考链接(References)
| # | 资源 | 链接 |
|---|---|---|
| 1 | YC Library 官方页面 | ycombinator.com/library/6f-how-to-plan-an-mvp |
| 2 | YouTube 视频 | youtube.com/watch?v=1hHc6tCNifg |
| 3 | Michael Seibel 的 Twitter | twitter.com/mwseibel |
| 4 | 相关 YC 文章:How to Start a Startup: Talking to Users | [[YC-Library-How-to-Start-a-Startup-Talking-to-Users]] |
| 5 | 相关 YC 文章:How to Build Products Users Love | [[YC-Library-How-to-Build-Products-Users-Love]] |
| 6 | 相关 YC 文章:How to Launch Again and Again | [[YC-Library-How-to-Launch-Again-and-Again]] |
| 7 | 相关 PG 文章:Do Things That Don't Scale | [[PG-Do-Things-That-Dont-Scale]] |
| 8 | 相关 PG 文章:Default Alive or Default Dead | [[PG-Default-Alive-or-Default-Dead]] |
术语表
| 英文 | 中文 | 解释 |
|---|---|---|
| MVP | 最小可行产品 | Minimum Viable Product |
| Iteration | 迭代 | 基于用户反馈反复修改产品 |
| Launch | 发布 | 把产品公开给用户 |
| Prototype | 原型 | 早期版本的产品 |
| Pre-MVP | MVP 之前 | 还没有可发布产品的阶段 |
| User Feedback | 用户反馈 | 用户对产品的意见 |
| Pivot | 转型 | 基于市场反馈改变方向 |
| Cohort | 同期群 | 同一时间段加入的用户 |
| Retention | 留存 | 用户持续使用的比例 |
我的一点小结
Michael 这场讲座表面讲 MVP,实际讲的是创始人的心理障碍。
大部分创始人不是不会做 MVP,而是不敢做 MVP——怕它太烂被人笑话,怕它不完整丢了面子,怕它一发布就证明了自己的想法是错的。
Michael 这场讲座的价值就在于,他用 Airbnb、Twitch、Stripe 这种十亿美元公司告诉你——它们的第一天都烂得要命,但它们都 launch 了。
如果你正在纠结 MVP,我建议你今天就开始做一件事——打开文档,写下你的 spec,给 spec 设一个 3 周的时间盒。3 周后,不管多烂,launch 出去。
launch 了你就赢了一半,没 launch 你就什么都没赢。