创业公司应快速推出MVP、迭代改进,避免花时间做100次调查或一年融资;核心是让一百个人爱上你的产品,远比十万人只是有点喜欢要好。
👤 WHO: Y Combinator和早期阶段创始人分享如何构建MVP
🎯 WHAT: 讲解构建最小可行产品的最佳方法,强调快速推出、迭代,避免追求完美
⏰ WHEN: 视频发布时间未知,但建议立即行动,不用等到完美
🌐 WHERE: 创业领域,特别是科技初创公司场景
❓ WHY: 为了尽快了解用户需求并解决实际问题,减少浪费时间在无效活动上
🔧 HOW: 通过快速推出、与首批用户沟通、迭代产品;删减非核心功能;不要爱上MVP,而要爱上客户
💡 SO WHAT: 创业者应优先抓住绝望客户,用粗陋但有效的方案解决紧急问题,一次一个地招募初始客户
“让一百个人爱上你的产品,远比让十万人只是有点喜欢要好得多。” —— Y Combinator
“不要爱上你的MVP,要爱上你的客户、你的用户。” —— Y Combinator
[音乐] 好的,今天我想和大家聊聊如何构建MVP(最小可行产品)。如果你之前没见过这个,这里有个我们常用来帮助创始人理解MVP的梗图,叫做"中等智商梗"。图中那位绝地大师——超级聪明的创始人,做着最正确的事,掌握所有最佳方法;而那个"傻瓜"——初次创业的创始人,完全摸不着头脑。有趣的是,这两位创始人往往比那些拼命想做到完美的聪明创始人更早做出正确决策。所以在MVP这件事上,最佳建议其实是:快速推出产品,不断迭代,让产品尽快交到客户手中,然后从中学习。
无论它是否对他们有帮助,都要不断迭代改进。错误的做法是进行100次调查、600次用户访谈、联系每一个竞争对手,花一年时间融资,雇佣100个人,以及所有其他可能让你分心的事情。这些事情看起来可能很聪明,但实际上并没有突出MVP最关键的一点:只有当你把一个产品放在用户面前时,你才能真正开始了解你的用户。这并不意味着你在RVP中构建的东西一定会成功——它很可能不会成功——它只是开始与用户对话、了解如何解决他们问题的最佳方式。因此,总结一下,作为
早期阶段的创始人应该做到以下几点:首先,快速推出一个最小可行产品;其次,与首批用户沟通,弄清楚如何让产品对他们更有用。你需要关注如何帮助他们实现目标,并思考如何调整和迭代产品,使其真正助力他们达成目标。然后重复这个过程:与更多用户交流,迭代产品;再与更多用户交流,再次迭代产品。通常情况下,经过三到六次迭代后,你的产品愿景会发生显著变化。你学到了很多,但通过与用户对话、让他们看到产品的演变,你实际上能让他们更兴奋、更愿意使用你的产品。
你的产品更有可能让用户愿意付费,而且你能学到的内容比仅与联合创始人讨论或独自思考要多出10倍。因此,如今的挑战在于,很多人都在质疑最小可行产品(MVP),很多人都在谈论最小可行产品或最小有用产品。而实际上,许多创始人只想打造所谓“神级”产品,比如史蒂夫·乔布斯级别的iPhone,改变世界。存在一种误解,认为从小处着手、产品可能不太完善是个坏主意。很多人担心,如果你从一个小产品开始,把它交给客户,而客户不喜欢它,你就再也无法与他们沟通了。我要告诉你的是,在大多数情况下,人们
那些愿意与初创公司交流的人都是早期采用者,他们习惯了使用不太完善的产品。他们之所以愿意与你沟通,并非因为认为你的产品会完美运行,而是因为他们确实遇到了实际问题,并且愿意尝试新软件。因此,你无需担心会失去这些用户——这类人始终在尝试新产品。如果你对他们说:“我无法保证产品从第一天起就完美无缺,但只要你持续与我合作,我们会不断优化改进,最终确保它能满足你的需求。”这类人恰恰会对这种承诺产生共鸣。而那些看到产品出问题就立刻放弃、再也不会使用的人,他们……
他们一开始就绝不会尝试你的产品,他们不是早期使用者,也不使用新软件,所以你完全不必担心失去这些用户,因为你从未拥有过他们,现在也不可能让他们开始使用。在YC,我们经常需要处理的一个问题就是恐惧,这是创始人最大的恐惧——一种模糊的恐惧:“天哪,如果我把产品给别人,他们不喜欢,我的公司就完蛋了。”这其实挺可笑的,因为仔细想想,你的公司并不会真的完蛋,对吧?它不会明天就倒闭,也不是游戏结束,你还没花光钱,联合创始人也不会都辞职。每当我们遇到这种可怕的假设时,我们喜欢深入探讨,问一问:“实际上会发生什么呢?”
就像这样想:最坏的情况是,你和客户交谈,演示了你的产品,但它没成功,客户不想使用。第二天醒来,你的生活有什么不同吗?你不能联系其他人吗?一周后,当你改进了产品,难道不能再次联系那个你演示过的客户吗?你的初创公司真的会因此倒闭吗?大多数时候,当你感到这种恐惧时,你应该做的是直面它,问问自己:这种恐惧真实吗?如果这件可怕的事情发生了,我的公司真的会完蛋吗?感到恐惧本身并不可怕,可怕的是被恐惧驱使行动。因为害怕第一个客户不喜欢,就花一年时间构建最小可行产品(MVP),这才是糟糕的。还有另一群人,他们认为自己知道完美的产品是什么样……
CT就是这样。我知道要花一年时间才能建成,那我为什么要先做一堆糟糕的版本呢?我喜欢把这些人称为“假史蒂夫·乔布斯”,这实际上是对优秀产品人员工作方式的巨大误解。很多人以为乔布斯是那种能在脑海中凭空构想出伟大产品,然后直接推向世界的人。但有趣的是,大多数时候,当人们想到乔布斯最著名的产品时——比如iPod和iPhone——他们并没有花足够时间去观察这些产品在不同时期的迭代过程。通常当有人对我说“哦,乔布斯第一次就推出了惊艳的手机”时,我会反问:“你还记得初代iPhone没有应用商店吗?你还记得……”
第一代iPhone不能录像,你还记得吗?第一代iPhone只支持2G网络,没有3G,所以网速非常非常糟糕。大多数人都不记得了,他们心目中真正的iPhone其实是第三代或第四代产品。第一代iPod有一个实体滚轮,但萨姆(Sam)的手指会卡进去,导致它经常坏掉。即便是伟大的史蒂夫·乔布斯,他的产品也是随着时间不断迭代的。所以,如果你觉得自己像个冒牌乔布斯,认为“我完全知道客户需要什么,只需要筹集1000万美元,花一年时间开发出来,然后发布就行了”,那请再想想吧。既然乔布斯都需要多次尝试才能把产品做对,也许你也需要这样。
我们来看几个例子。在这些例子中,你会发现三个非常简单的要点:第一,这些产品都开发得很快,能迅速进入市场;第二,它们的功能都非常有限;第三,有趣的是,所有这些产品都只吸引了一小部分用户。这些创始人意识到,做出一个能让人们喜爱的小众产品,远比从第一天起就满足所有潜在客户的所有需求重要得多。那么,Airbnb的第一个版本是什么样的呢?如果你在Airbnb刚推出时成为用户,你会错过一些有趣的功能:没有支付功能——如果你在Airbnb上找到住处,无法直接付款,必须通过其他方式安排支付;没有地图视图——你无法看到城市中房源的具体位置,这算是一个相当基础的功能;更有趣的是,你只能睡在气垫床上——不能出租整栋房子,甚至不能出租房间;第四,Airbnb的第一个版本只适用于会议期间。他们会在有会议的城市临时上线服务,会议结束后就关闭。这就是Airbnb的起点,这就是它的最小可行产品。第二个例子是我的公司Twitch。Twitch最初是一个名为Justin TV的网站,我的联合创始人Justin头上戴着一台摄像头,24小时不间断直播。
在Twitch的第一个版本中,只有一个页面,就是你现在看到的这个页面。上面只有一个主播,名叫贾斯汀。当时没有电子游戏,除非我们偶尔随机玩一些游戏,比如《吉他英雄》之类的。而且直播的费用高得离谱,我们当时租用CDN,还没有搭建自己的视频系统。但这就是我们产品的第一个版本。现在你打开Twitch,看到的完全是另一番景象,但一切正是从这里开始的。最后,我们还有Stripe。这是Stripe的第一个版本,当时它甚至还不叫Stripe,而是叫“/depth payments”。那时他们没有任何豪华的银行合作,只与一家小银行打交道。甚至没有与该银行直接对接的账户开设渠道,所以他们只能打电话去办理。
银行每晚都要手动处理文件,才能帮你开设账户,而且几乎没有任何功能。Stripe的第一个版本简陋到连我们当年在Twitch的人都用不了,因为功能太少。但那些能用它的人,是早期阶段的YC初创公司,他们只想从客户那里接受简单的信用卡支付——这就是Stripe最初的全部功能,而这已经足够他们起步了。所以你可能会问:到底哪些人真的愿意用这些糟糕的MVP?你告诉我们,它们会快速构建出来,可能运行得不太好,我们必须反复迭代才能让它们变得好用。这些愿意尝试的早期用户到底是谁?
经历那种体验时,有一个有趣的比喻,是我作为早期创业者时听说的:你要为那些“头发着火”的客户打造第一个版本。我以前一直不太理解这句话的意思——虽然听起来有道理,但我觉得配上故事会更实用。所以想象一下,你现在就是那个人,你的头发正在着火,而此刻你正在观看这个视频。再想象一下,如果我坐在你隔壁的房间里,你希望我能卖给你什么东西来解决这个问题?你的头发正在燃烧。大多数人可能会想到一桶水、水管,或者某种水类工具。那确实是个很棒的产品,就像今天的iPhone一样,能立刻解决你的问题。但我没有那个产品,我是一个创业者。
我现在有一个最小可行产品,我卖给你的是一块砖头。如果我现在卖给你一块砖头,你会怎么做?有些人可能会说,我会离开房间,因为我用不上砖头。但如果你头发着火了,你就会买下那块砖头,然后用它拍打自己的头来扑灭火焰。这就是最小可行产品——它并非完美的解决方案,但作为客户,你正处于极度痛苦之中,以至于你会使用不完美的解决方案来解决问题。这才是你应该追逐的客户。对于那些并不急迫的客户,你可以等待,不必现在就去争取。先抓住那些绝望的客户,别让自己活得太累。我知道你们有些人,尤其是上过商学院的人,可能会说可以跳过这一步,而不是去构建产品。
确定一个MVP,不断迭代、迭代。为什么我不直接调查用户?为什么我不直接和100个用户聊聊,让他们告诉我该构建什么?我希望情况是这样,我希望用户能直接告诉你该构建什么,然后你只要构建出那些东西就能成功。事实上,我认为每个企业都希望如此。问题在于:你的客户是解决他们问题的专家,但他们实际上并不完全知道如何解决自己的问题——那是你的工作,是构建新产品的人的工作。调查或许能帮你理解客户正在经历的痛点,但永远无法帮你找出如何解决那个痛点。你唯一能与客户展开这种对话的时机,是当你能够把一个产品放在他们面前时——最好是一个
糟糕的最小可行产品,然后开始思考“这能解决你的问题吗?”我其实没见过这个步骤有什么捷径。我从未见过能快速构建一个相当粗糙的起步产品的捷径。即使是大型公司,甚至是企业软件公司,如果你回顾过去,它们产品的第一个版本也并非完美,远非如此,它们只是客户愿意使用的最低限度。所以,无论哪个领域,你都必须从最小可行产品开始。我认为我最想强调的一点是,你创业时并非带着所有答案。创建一家初创公司,尤其是在产品市场契合前的第一阶段,核心就是学习,就是吸收一些洞察。
首先,你要把产品推向市场,并在过程中学习。如今大多数解决方案和产品中最优秀的部分,都是在产品发布后才被发现的。那时,创始人们正在从用户那里学习,并不断构建和迭代。推出MVP是启动学习过程最快的方式,而你学得越快,就越有可能比其他人先打造出人们喜爱的产品。假设我已经说服了你,现在你确实想构建一个MVP,那么如何确保快速完成呢?这里有一些技巧:第一,给自己设定一个非常具体的截止日期。如果你给自己两周、一个月或一个半月的时间来完成,相比没有设定截止日期,会更容易确保你构建的是真正的最小可行产品。
写下你的规格。如果你认为启动一个MVP需要五个或十个功能,把它们全部写下来。不要让自己陷入不断纠结“这个功能该不该有”的境地,也不要忘记我们前几天讨论过的某个功能,或者纠结它应该是什么样子、如何运作。如果你把它们写下来,就可以专注于构建,而不是持续争论该构建什么。第三,删减。在你写完所有内容后,逐一审视每个项目,问问自己:真的有客户迫切需要这个功能才能开始使用吗?你可能会惊讶地发现,有多少功能可以留到产品的第二、第三或第四个版本中,从而直接推出产品。
先把那些东西搞定,然后第四点也是最重要的一点:不要爱上你的MVP。它会改变,你会不断迭代它,随着时间的推移它会变得非常非常不同。你要快速行动,不要爱上它,你要爱上你的客户、你的用户,而不是爱上你为了从用户那里学习而构建的那个粗糙的初始产品。好了,希望你已经不需要更多说服了。你明白最简单、最直接、最聪明、最绝地武士的方式就是先构建并发布你的产品,然后迭代它。所以我祝大家好运。在构建的过程中,记住一件事:让一百个人爱上你的产品,远比让十万人只是有点喜欢要好得多。所以当你发布MVP时,做一些无法大规模推广的事情完全没问题,一次一个地招募那些初始客户。如果你在乎这些客户,我保证他们会和你交流,你可以和他们合作,帮助他们找到解决问题的方法,从而也帮助你为他们构建一个出色的产品。非常感谢,祝你好运。