Michael Seibel - How to Plan an MVP

### TL;DR MVP 是你能给第一批目标用户的最简产品，用来检验你是否能为他们创造任何价值。尽快发布一个糟糕的东西，然后迭代。 ## 什么是 MVP？ MVP 代表“最小可行产品”（Minimum Viable Product）。Michael Seibel 在 Y Combinator 负责运营加速器，他曾创办过两家 YC 初创企业。他强调，MVP 应该极其简单——仅仅是你可以交给第一批目标用户、用来检验你是否能为他们创造任何价值的东西。仅此而已。 在构建 MVP 之前，最好先和一些用户聊聊。如果你自己就是用户，那就更容易判断产品是否有效。获得第一批用户的方法就是去和你知道有那个问题的人聊；如果用户是你自己，那就更简单了。 ## 初创公司在发布前的目标 ### 1. 快速发布 这是 YC 十年来一直秉持的理念：快速发布一个糟糕的东西。如果你只能从这次演讲中学到一件事，那就是这个。 ### 2. 获得一些初始客户 任何人开始使用你的产品都算数。不必一开始就让所有人都用，只要有人能从中获得价值即可。很多创始人的旅程在第一个用户真正使用产品之前就结束了，这是非常常见的错误。 ### 3. 与用户交流并获取反馈 大多数创始人脑子里有一个完整的想法，因此会觉得从糟糕的初始版本获取反馈没有用。但现实是，你脑子里的完整版可能根本不是客户想要的。记住：紧紧抓住你要解决的问题和你的客户，但解决方案要灵活多变。 ### 4. 迭代（而非 pivot） 很多创始人一旦学会了如何构建某样东西，就会爱上它。如果它对某类用户不起作用，他们会想“这东西还能解决什么其他问题？”这就像是螺丝刀不擅长拧东西，你却想用它来做饭。正确的做法是：留住你的用户和问题（比如“我需要拧东西”），然后修复那个该死的螺丝刀。 ## MVP 应该有多精简？ 大多数人的 MVP 应该能在几周内快速构建出来，而不是几个月。功能极其有限，只专注于一小批初始用户和他们最高优先级的问题。对所有人要有愿景，但 MVP 要非常小——它只是一个迭代的起点而已。 ### 经典例子 - **Airbnb（2008 年）**：第一个版本没有支付功能，用户需要亲自和房东交换现金；没有地图视图；代码由 Nate 兼职编写。 - **Twitch（当时叫 Justin TV）**：只有一个频道（Justin），视频分辨率极低，没有电子游戏（除非 Justin 本人玩游戏）。 - **Stripe（最初叫 slashdev/payments）**：没有银行合作协议，功能极少，甚至创始人是亲自到客户办公室帮忙集成支付。 这些公司如今都价值数十亿美元，但都始于极其简单的 MVP。 ## 什么情况下需要“重型 MVP”？ 如果你身处受严格监管的行业（保险、银行）、硬科技（火箭、生物科技）、登月项目之类，可能无法几周内造出产品。这时你的 MVP 可以以一个简单的网站开始，解释你是做什么的。与人交流时，有一个可参考的东西会很有帮助。这个网站可以在几天内建好，反而比“精益 MVP”更快。 ## 对“发布”的误解 很多创始人认为初创公司发布产品应该像大公司那样获得大量媒体关注。但事实上，没人记得 Google、Facebook 或 Twitter 的发布日期。发布本身并不特别。把“发布”定义为“获得任何客户”，把“媒体发布”推迟。尽早获得客户比什么都重要。在客户没有产品可摆弄时，你很难学到东西。所有研究都很好，但只有把东西放到人们面前，你才能知道它是否有效。 ## 快速构建 MVP 的技巧 1. **给规格说明书设定时间盒**：如果计划三周内发布，规格说明书上只能放三周内能构建出来的功能。 2. **写下你的规格说明书**：很多人从不写下来，所以很容易在发布前不断改变方向。写下来才能对自己诚实。 3. **削减规格说明书**：冲刺进行到一周时，如果发现加太多东西，果断剪掉不重要的，甚至剪掉重要的。目标是先把任何东西发布出去。 4. **不要爱上你的 MVP**：爱上一个初稿是很危险的。所有成功的产品最终形态都与初始愿景不同。你的 MVP 的影响力常常和小学一年级写的作文差不多——只是旅途的第一步。 --- Source: [Michael Seibel - How to Plan an MVP](https://www.youtube.com/watch?v=1hHMwLxN6EM)