YC Library：How to Plan an MVP — Michael Seibel（全文搬运）
开场
我叫 Michael，在 Y Combinator 工作，负责运营加速器。在此之前，我做过两家 YC 创业公司，一家在 2007 年，一家在 2012 年。今天我要讲的是最小可行产品，也就是 MVP。我们总是 yelling 创始人不要用行话，但我们自己却有一整套愚蠢的创业行话，MVP 就是其中之一。当你想到 MVP 时，你应该想到的是极其简单的东西。这是你能给第一批目标用户的第一个东西，目的是看看你能否给他们提供任何价值。仅此而已。它极其简单。
先和用户对话再做 MVP
我知道你们上周刚讲过如何想创意、如何找你想解决的问题。我要告诉你们的是，在决定做 MVP 之前，先和一些用户聊一聊是有帮助的。这并不意味着你要进入一个三年的研究状态，或者在行业里工作十年。但一些对话是有帮助的。如果你自己是用户，那就更有帮助了，因为你能判断你的产品是否在为你工作。
我总是被问到一个奇怪的问题："我如何获得第一批用户？"这让我有点困惑，因为理论上，你是决定去解决一个你知道某人有的问题。所以获得第一批用户的方法就是去和那个你知道有这个问题的用户对话。如果是你自己，那就更容易了。如果你正在为一个神秘的、你根本不知道是谁的用户群体做产品，那稍微质疑一下这一点。非常轻微地质疑一下。
早期创业公司的目标
第一步：快速发布
第一步，快速发布。这是从 YC 一开始就有的理念，是过去 10 年来的好建议，而且 continues to be great advice。如果你只能从这场演讲中学到一件事，那就是"快速发布一个烂东西"。仅此而已。 literally 我接下来要说的所有内容基本上都是同一件事的重新总结。
第二步：获取初始客户
早期创业公司需要做的第二件事是获取一些初始客户。让任何人使用你的产品。你不需要有一个让所有人都使用的愿景，只要任何人来互动、看看他们是否能从产品中获得价值就行。你会惊讶于有多少创始人的旅程在没有任何用户实际使用过他们创建的产品之前就结束了。这非常非常常见。所以请跨过这一步。这极其重要。
第三步：和用户对话，获取反馈
接下来，发布 MVP 后，和你的用户（任何一个）对话，获取反馈。这也是一个极其常见的错误，因为大多数创始人在脑子里有一个他们想build的东西。所以他们有一种奇怪的感觉，觉得如果我还没有build完整的东西，获取对这个烂初始东西的反馈是没用的。"当然它不会work，它不是完整的东西。完整的东西需要三年、一千万美元、整个团队。所以对这个 little thing 的反馈是没用的。"
现实是，在某些方面，完整的东西是你脑子里那个非常棒的想法，你应该把它留在脑子里，但它应该非常非常灵活，因为最终你想build的完整东西可能根本不是你的客户想要的。
我有一句话：紧紧抓住你在解决的问题，紧紧抓住你的客户， loosely 掌握你在build的解决方案。
第四步：迭代，不要 pivoting
最后也是最重要的，迭代。我喜欢区分 iterating 和 pivoting。很多创始人一旦想出了如何build something，就会爱上它。所以如果它对某一群用户不管用，他们就开始想："嗯，我想知道这个东西还能解决什么问题？你看，这个螺丝刀实际上并不能拧任何东西，但我想知道它还能解决什么问题。"他们会说："哦，也许你可以用它来做饭。也许你可以用它来打扫。"就像，不，问题是，我需要拧东西，用户是像修理工一样的人，如果你的螺丝刀不能帮助修理工解决问题，那就留住修理工，留住问题，我需要拧东西，修好这个该死的螺丝刀。坏掉的东西不是修理工，也不是他们需要拧东西这个事实。所以，迭代。继续改进你的解决方案，直到它真正解决问题。
如何快速构建 MVP
在大多数情况下，大多数人应该build一个非常 lean 的 MVP。我们的意思是，你应该能快速build它，以周为单位，而不是月。这可以涉及软件，或者老实说，我们看到创业公司只是从一个 landing page 和一个 spreadsheet 开始。
但大多数创业公司可以非常非常快地开始。
功能要极其有限
第二，极其有限的功能。你需要把你用户的需求、你初始用户的需求，压缩到一组非常简单的需求。很多时候，创始人想解决他们所有用户的问题和他们所有潜在用户的问题，而实际上，他们应该只专注于一小群初始用户和他们最高阶的问题，然后其他的先忽略。你应该有一个面向所有人的愿景。你应该有一个非常小的 MVP。这只是一个可以迭代的基础。仅此而已。它只是一个起点。它没有任何特别之处。你只需要开始。所以，请确保你不要觉得你的 MVP 太特别了。
经典案例：Airbnb、Twitch、Stripe 的第一天
这是一个经典例子。这是 Airbnb 最早的 landing page 之一，我相信是 2008 年的。关于 Airbnb 的第一个产品，你可能感兴趣的一件事是，当时没有支付功能。当你在 Airbnb 上找到住处时，你必须和房东当面交换钱。不用说，这是一个非常他妈大的问题，但他们开始时没有支付功能。没有地图视图。你知道当你在 Airbnb 搜索时，你能看到房子在城市里的位置吗？你没有。抱歉。而且，写所有代码的人 Nate 当时是 part time 工作的。好吧？所以每个人都讲这种神奇的故事，说一切从一开始就很完美。Airbnb，从一开始就不是完美的。
下一个是 Twitch。这是 Twitch 第一天的样子。不是很熟悉。嗯，也许有一点点熟悉。那里有一些视频，还有一些聊天。除此之外，什么都没有。Twitch 以 Justin.tv 的名字 launched，那是一个 online reality TV show。只有一个频道，Justin。你必须关注他的生活。如果你不喜欢他的生活，你就得离开网站。仅此而已。视频分辨率极低。有趣的是，一个创始人曾经问我："哦，是不是很奇怪，你们在公寓里有视频。难道没有所有这些，比如，秘密文件和东西，人们能看到吗？"就像，你几乎认不出我们的脸，更不用说我们有的文件了。最重要的是，没有电子游戏。没有电子游戏，除非我们决定在公寓里玩电子游戏。就像，那是电子游戏唯一出现的时候。所以说你可以快速做到这一点。当你想到 Twitch 时，它现在复杂多了。
最后是 Stripe，那时候还不是 Stripe。它叫 /dev/payments，因为，为什么不呢？就像，我们做一个容易记的名字。这是 Stripe 第一天的样子。没有银行交易。我不会告诉你他们具体如何处理支付，但那是 very startup-ey 的方式。几乎没有功能，而且更酷的是，如果你想用 Stripe，Stripe 的创始人会亲自来你的办公室为你集成。这多好？一半是因为他们 desperately 想找任何人使用它，另一半因为这是在用户发现 bug 之前发现 bug 的好方法。你自己来集成。
所以这只是三个极其简单、极其快速 build 的 MVP 的例子。这些都是十亿美元的公司，它们都从大多数人会说相当 shitty 的东西开始。
Heavy MVP：当快速发布不可行时
在极少数情况下，你必须 build a heavy MVP。我两天前做这个演讲时刚发明了这个词，heavy MVP。所以，你知道，也许它会成为一件事。如果你在一个有严格监管的行业，比如保险或银行，有时是无人机，虽然有时不是，launch 很难。你必须先通过一堆监管机构。如果你在做硬科技，如果你在造火箭，几周内造出一枚火箭很难。生物科技，几周内发明一种抗癌药很难。Moonshots。好吧，填上所有其他空白。在地球上钻隧道、造极快替代汽车的车，几周内很难。所以，如果你在这种情况下，请记住你的 MVP 可以从一个简单的、解释你做什么的网站开始。当你和人交谈时，他们可以 refer back 到某个东西，这很有帮助。所以，那可以作为你的开始，你可以在几天内而不是几周内 build 那个简单的网站。所以，在很多方面，也许你的 heavy MVP 比你的 lean MVP 更快，以一种奇怪的、 strange 的方式。
重新定义 Launch：不要等"大日子"
现在我想 briefly 讲一下 launching，因为很多创始人对 launching 有误解。他们看到大公司 launch 东西，就假设那就是创业公司做的。事实上，他们看到他们认为是创业公司的公司（Facebook 现在不太算是创业公司了）获得很多 press 和 buzz，他们在脑子里认为那就是一家成功公司 launch 时的样子。
让我问你们一个问题。有多少人记得 Google launch 的那一天？没有。Facebook 呢？好吧。Twitter 呢？没有。太好了。所以事实证明，launches 根本没那么特别。如果你有一个 magical 的 launch 想法想做，把它扔掉。没那么特别。真正重要的第一件事是获取一些客户。所以，为了让人们感觉好一点，我们用不同的术语。Launch 就是当你获得任何客户的时候，而 press launch，真正令人印象深刻的 press launch，是当人们写文章、一切都很兴奋、你获得所有 buzz 的时候。让我们把 press launch 往后推，让我们把 get-any-customers launch 真的非常快地推出去。那是我们的目标。
为什么必须把产品放到用户面前
当你的客户没有一个可以玩的产品时，你很难向他们学习。你可以和你的客户聊一整天，但你不知道你想build的东西是否能解决他们的问题。如果你把东西放到他们面前，而它没有解决他们的问题，你立刻就知道。所以，世界上所有的研究都是好的，但直到你能把 something 放到人们面前，你根本不知道它是否会work。所以把所有时间花在 pitch deck 上，不如花时间 build 任何你可以给客户的东西。
快速构建 MVP 的 Hack
1. Time box 你的 spec
首先，给你的 spec 设一个时间限制。你的 spec 是在 launch 之前你需要 build 的东西的清单。给它设一个时间盒。说，好吧，如果我想在三周内 launch 会怎样？好吧，我 spec 上唯一能有的东西是我能在三周内 build 的东西。这让你的人生简单多了。它允许你移除所有你不能在三周内 build 的功能。
2. 写下你的 spec
第二，写下你的 spec。这看起来真的很直白，但大多数人把这一点搞砸了。在你 launch 之前改变你在做什么非常容易，因为你从来没有写下来。你开始做 something，你和用户聊，他们说："哦，我永远不会用那个，"或者天哪，你和投资人聊，他们说："哦，那永远不可能是一家公司，因为投资人知道一切。"所以你决定改变你在做什么。因为你从来没有写下来，你甚至没有真正意识到你在改变它。所以你三周的计划变成了三个月的计划。如果你把 shit 写下来，至少你可以诚实地面对自己，你一直在改变你的 spec。
3. 砍掉你的 spec
接下来是砍掉你的 spec。在你三周的 sprint 进行一周后，你可能意识到你在 spec 里加了太多东西，你赶不上截止日期了。没关系。直接砍掉那些明显不重要的东西。如果没有不重要的东西，开始砍重要的东西。这里的大部分目标只是把 anything 放到世界上。一旦你把 anything 放到世界上，继续做下去的 momentum 非常强。一旦你有了任何东西，如果你没有任何东西在世界上，非常容易就是 delay、delay、delay、delay。
4. 不要爱上你的 MVP
最后，不要爱上你的 MVP。太多人爱上他们脑子里的愿景。我给你看的之前的产品没有一个是最初的愿景，它们最终变成的样子。所以请不要爱上你的 MVP。它只是旅程的第一步。你不会爱上你一年级写的一篇论文。就像，那 often 就是你的 MVP 的影响水平。好的。演讲到此结束。我有一点时间提问。有问题吗？完美。没有问题。哦，请说。
Q&A
Q1：用户想要不同功能怎么办？
女士 1：我发现，和用户对话时，我有好几个 subtype segments，当然每一个都想要某个特定的东西，另一个也想要某个特定的东西。所以，数量太小了，它们 kind of 抵消了。那么如何...
Michael：好问题。你和用户对话，他们有很多你想build的东西，但它们之间没有太多重叠。所以我会给你一个 meta 答案：永远不要问用户要功能。永远不要问用户告诉他们想要什么。用户的 job 不是想出功能。那是你的 job。用户的 job 是给你问题。所以，如果你在和这些用户对话，他们在问题上有一些连续性。他们可能不知道如何解决这个问题。
所以他们给你的可能是一个长长的潜在功能清单，他们认为这些功能可以解决问题，而不是花大量时间只谈论他们的问题是什么。他们多久经历一次？有多强烈？他们愿意为解决方案付费吗？他们认识其他有这个问题的人吗？所以，那些就是我想从某人那里得到答案的问题。如果你看到某人 sneak into feature zone，比如，"哦，你知道我爱 Microsoft Word，但我希望有人能build something 让我做 blah blah，"你就要把它推回到，"哦，那你为什么想做 blah？你有什么问题？你多久遇到一次这个问题？"然后把它拉回问题。这就是你如何避免 feature death。这极其常见。
Q2：一直在改 MVP 怎么办？
女士 2：我发现自己在一条非常细的线上行走，一边专注于我的 MVP，一边又在改变它，因为我发现了一个更好的东西。所以，我一开始和所有潜在用户聊我的 MVP，然后我说，"不不不。我们必须做这个，我们必须做那个。"所以，我要不要吃我的 ADD 药，继续我最初开始做的，或者你什么时候停下来，说，好吧，这值得改变？
Michael：哦是的。抱歉。所以问题是，我陷入了一个不断改变 MVP 却不 launch 的循环。显然，很多人陷入这个循环，而很多创业问题的答案是，"停止你在做的事。"就停止。你不必一直改变你的 MVP。也许你一直在改变 MVP 的原因之一是你觉得它很特别。如果你不觉得它特别，你就会停止改变它。你会停止编辑它。
女士 2：我不明白。再解释一遍。
Michael：如果你觉得你的 MVP 很特别，你觉得它必须完美。如果你觉得它必须完美，你会花很多时间 tweak 它。如果你假设它必须真的很 shitty，对吧？就像，如果你觉得，"好吧，我 literally 在找一件我可以在上面画画然后销毁的衬衫，"你不会花很多时间 tailor 那件衬衫，对吧？所以，如果你觉得你的 MVP 不那么特别，你会花更少的时间 tweak 它。
Q3：应该问用户什么问题？
男士 1：假设你 launch 了一个 MVP，你在寻找反馈，你想问用户的关键问题是什么？
Michael：这是一个非常简单的问题。当你想获取 MVP 反馈时，你想学到的关键事情是什么？它是否解决了我想要它解决的问题？就这些。你可以找到 80 种不同的方式回答这个问题，但如果你清楚地理解你在试图解决的问题，那么就很清楚了……通常，你不需要问。如果它在用户面前，你可以看到他们是否在做你想让他们做的事，或者他们是否没有。通常，你可以在数字中看到。如果这是一个他们每天都有的问题，而你介绍了一个用户给它，他们第二天会回来吗？我从来没有见过一个解决人们每天都有问题的产品，它真的解决了问题，而用户只是停止使用它，因为 whatever。所以，这里有很多完全无关的奇怪细微差别。用户是否做了那件事，解决了你想让他们解决的问题？其他问题？后面？
Q4：MVP 应该持续多久？
男士 2：MVP 应该持续多久？我的意思是，你开始成长了，然后下一步是什么？
Michael：你知道创业有什么有趣的地方吗？我不喜欢想时间线，我也不觉得 linking about roadmaps。对于在 pre-MVP 阶段的人，谁知道呢？Launch something。搞明白。你决定做一家创业公司，创业公司的特点之一是从 A 到 Z 怎么走不会清晰。所以，如果你太专注于，"哦，我理解到达 MVP 是步骤 B，但我真的专注于步骤 C、D 和 E，"我会告诉你，"嘿，先解决你面前的问题怎么样？"
Q5：增长 vs 留存，先做哪个？
男士 3：那么，你如何平衡，例如，改进 MVP 以增长客户留存， versus 押注于获取和再生的努力？
Michael：MVP 之后，你应该在增长上工作，还是应该在留存上工作？我爱这个问题。这是世界上最有趣的问题，因为它允许我给出一个荒谬的 canned 答案。两者都是。是的。事情是这样的。很多创始人基本上理解创业是一个多变量问题，但多变量问题很难。所以他们试图把它简化为一个单一变量。所以他们问那个秘密顾问，"哦，什么更重要，增长还是留存？"就像，什么更重要，洗澡还是上厕所，拉屎？我希望你两个都做。抱歉。两者都很重要。作为创始人，你将不得不 juggle 很多事情。是的。好吧。
Q6：用户不愿意谈问题怎么办？
男士 4：你能分享一个故事吗，比如一个创业公司无法和最终用户对话，因为最终用户不想谈论问题，以及他们如何克服这个问题，如果你知道的话。
Michael：让我们明确一下。问题是，如果你的用户有一个他们不想谈的问题，你如何和他们对话？你为什么不告诉我，那是什么？
男士 4：二型糖尿病。
Michael：二型糖尿病。我完全相信你能找到 10 个愿意谈论他们的二型糖尿病的人。我质疑你 starting a startup 去帮助二型糖尿病患者，如果你不认识任何有二型糖尿病愿意和你谈的人。所以我认为那是那种 false setup。就像，我拒绝问题的前提。好吧，下一个问题。请说。
总结
Michael Seibel 这场讲座的核心信息极其简单：
MVP 不是一个产品，它是一个验证假设的工具。你不需要它完美，你需要它足够快地放到真实用户面前，然后迭代到用户真正需要的东西。