如果你正在做一个 MVP，你大概率会反复问自己几个问题：

这个版本够不够？

现在能不能发布？

它是不是还太粗糙？

用户真的能从里面看出价值吗？

很多团队都想把产品做大，甚至一开始就想着走向全球市场。于是他们花了大量时间、资金和精力，把一个功能完整、看起来很成熟的产品做出来，却到最后才发现：用户可能根本不需要它。

产品规模化从来不是一步到位的事。它需要一次又一次实验。而一个好的开始，通常就是先做出一个 MVP，也就是最小可行产品。

Dropbox、Uber 这些后来广为人知的公司，一开始也不是完整形态。它们都是从 MVP 起步，通过减少不必要的成本、节省宝贵时间，先验证想法，再逐步走大。

今天回头看，这些案例之所以经典，不是因为它们一开始就做得多完美，而是因为它们在足够早的时候，验证了一个关键问题：

这个想法到底有没有人需要？

如果你正准备发布一个产品，但还在犹豫要不要等它更完美一点，我们的建议是：不要一直等。先做一个 MVP。

为什么？这篇文章会从几个常见误区讲起，再看看那些知名产品最早是怎么验证想法的。

关于 MVP 的几个常见误解

想理解什么是真正的 MVP，先要弄清楚它不是什么。

MVP 是一个很有用的工具，但前提是你用对它。如果理解错了，它也可能在产品真正开始之前，就把项目带偏。

误解一：MVP 只是产品的小版本

很多创业团队会误解 MVP 的目标。

他们以为 MVP 就是把完整产品砍掉一部分，做成一个“半成品”，然后尽快推出去。

但事实不是这样。

MVP 的重点其实不是“产品本身”。Eric Ries 曾说过：

MVP 是一个过程，而不是一个产品。

最小可行产品本质上是一种学习工具。它不是最终产品，而是用来帮助团队探索：什么样的方案，才能真正解决目标用户的问题。

换句话说，MVP 的价值不在于它看起来像不像最终产品，而在于它能不能帮你把想法拿到用户面前测试，收集反馈，并判断方向是否值得继续。

误解二：MVP 要比竞争对手有更多功能

有些团队会觉得，自己的 MVP 必须功能很全。最好比竞品多几个功能，这样才能显得有优势。

但这通常会让团队陷入另一个陷阱：还没验证需求，就先把大量时间花在功能开发上。

MVP 不应该等到功能完整之后才发布。相反，你应该保留有限的功能，尽快拿去测试。

功能越多，开发时间越长。而你根本无法提前确定，这些功能用户到底会不会喜欢，会不会真的使用。

Eric Ries 建议，先做出那 20% 的功能，而这 20% 最好能覆盖 80% 用户真正会用到的场景。

记住，你现在不是在打造一个伟大的终极产品。你真正要做的，是获得用户反馈。

误解三：MVP 就是低质量版本

MVP 确实应该只包含最少的核心功能。

但有些团队为了快，就牺牲质量，把一个充满 bug、经常崩溃、体验很糟糕的版本丢给用户。

这也不是 MVP。

MVP 可以简单，可以只有一个核心功能，但它必须是可以正常使用的。

如果一个平台到处都是 bug，动不动就崩溃，用户为什么还要继续用？

Steve McConnell 曾说过：

如果你想走得快，就要从重视质量开始。

所以，MVP 不是粗制滥造。它应该是功能少，但体验清楚、流程完整、能让用户真实感受到价值的版本。

真正的 MVP 是什么？

Eric Ries 对 MVP 有一个被广泛接受的定义：

最小可行产品，是一个新产品的某个版本，它能让团队用最少的努力，获得关于客户的最大化验证学习。

也就是说，MVP 的核心不是“发布”，而是验证。

你通过 MVP 去测试想法、收集数据、理解用户，然后决定下一步到底该做什么。

一个合格的 MVP 通常具备几个特点：

它服务于一类明确用户；

它解决一个关键问题；

它能帮助团队更清楚地知道下一步该开发什么，从而少花冤枉钱；

它可以在较短时间内做出来，并尽快进入真实反馈。

MVP 的形态并不固定。每家公司、每个产品的 MVP 都可能完全不一样。

下面这些知名公司的早期案例，能更直观地说明这一点。

好的 MVP 长什么样？从 Dropbox、Airbnb 到 Product Hunt 的早期案例

如果你正在做一个 MVP，你大概率会反复问自己几个问题：

这个版本够不够？

现在能不能发布？

它是不是还太粗糙？

用户真的能从里面看出价值吗？

很多团队都想把产品做大，甚至一开始就想着走向全球市场。于是他们花了大量时间、资金和精力，把一个功能完整、看起来很成熟的产品做出来，却到最后才发现：用户可能根本不需要它。

产品规模化从来不是一步到位的事。它需要一次又一次实验。而一个好的开始，通常就是先做出一个 MVP，也就是最小可行产品。

Dropbox、Uber 这些后来广为人知的公司，一开始也不是完整形态。它们都是从 MVP 起步，通过减少不必要的成本、节省宝贵时间，先验证想法，再逐步走大。

今天回头看，这些案例之所以经典，不是因为它们一开始就做得多完美，而是因为它们在足够早的时候，验证了一个关键问题：

这个想法到底有没有人需要？

如果你正准备发布一个产品，但还在犹豫要不要等它更完美一点，我们的建议是：不要一直等。先做一个 MVP。

为什么？这篇文章会从几个常见误区讲起，再看看那些知名产品最早是怎么验证想法的。

关于 MVP 的几个常见误解

想理解什么是真正的 MVP，先要弄清楚它不是什么。

MVP 是一个很有用的工具，但前提是你用对它。如果理解错了，它也可能在产品真正开始之前，就把项目带偏。

误解一：MVP 只是产品的小版本

很多创业团队会误解 MVP 的目标。

他们以为 MVP 就是把完整产品砍掉一部分，做成一个“半成品”，然后尽快推出去。

但事实不是这样。

MVP 的重点其实不是“产品本身”。Eric Ries 曾说过：

MVP 是一个过程，而不是一个产品。

最小可行产品本质上是一种学习工具。它不是最终产品，而是用来帮助团队探索：什么样的方案，才能真正解决目标用户的问题。

换句话说，MVP 的价值不在于它看起来像不像最终产品，而在于它能不能帮你把想法拿到用户面前测试，收集反馈，并判断方向是否值得继续。

误解二：MVP 要比竞争对手有更多功能

有些团队会觉得，自己的 MVP 必须功能很全。最好比竞品多几个功能，这样才能显得有优势。

但这通常会让团队陷入另一个陷阱：还没验证需求，就先把大量时间花在功能开发上。

MVP 不应该等到功能完整之后才发布。相反，你应该保留有限的功能，尽快拿去测试。

功能越多，开发时间越长。而你根本无法提前确定，这些功能用户到底会不会喜欢，会不会真的使用。

Eric Ries 建议，先做出那 20% 的功能，而这 20% 最好能覆盖 80% 用户真正会用到的场景。

记住，你现在不是在打造一个伟大的终极产品。你真正要做的，是获得用户反馈。

误解三：MVP 就是低质量版本

MVP 确实应该只包含最少的核心功能。

但有些团队为了快，就牺牲质量，把一个充满 bug、经常崩溃、体验很糟糕的版本丢给用户。

这也不是 MVP。

MVP 可以简单，可以只有一个核心功能，但它必须是可以正常使用的。

如果一个平台到处都是 bug，动不动就崩溃，用户为什么还要继续用？

Steve McConnell 曾说过：

如果你想走得快，就要从重视质量开始。

所以，MVP 不是粗制滥造。它应该是功能少，但体验清楚、流程完整、能让用户真实感受到价值的版本。

真正的 MVP 是什么？

Eric Ries 对 MVP 有一个被广泛接受的定义：

最小可行产品，是一个新产品的某个版本，它能让团队用最少的努力，获得关于客户的最大化验证学习。

也就是说，MVP 的核心不是“发布”，而是验证。

你通过 MVP 去测试想法、收集数据、理解用户，然后决定下一步到底该做什么。

一个合格的 MVP 通常具备几个特点：

它服务于一类明确用户；

它解决一个关键问题；

它能帮助团队更清楚地知道下一步该开发什么，从而少花冤枉钱；

它可以在较短时间内做出来，并尽快进入真实反馈。

MVP 的形态并不固定。每家公司、每个产品的 MVP 都可能完全不一样。

下面这些知名公司的早期案例，能更直观地说明这一点。

Zappos：先拍鞋，再验证人们会不会在线买鞋

今天的 Zappos 是全球知名的在线鞋类零售商，年收入超过 10 亿美元。

但在它刚开始时，创始人 Nick Swinmurn 只有一个假设：

人们会不会愿意在网上买鞋？

为了验证这个想法，他没有先投入大量资金进货，也没有开发一个复杂的电商系统。

他做的事情很简单：去当地鞋店，把一双双鞋拍下来，然后把照片上传到一个简单网站上。

如果有人点击购买，他就去店里把那双鞋买下来，再寄给顾客，并处理付款流程。

就这样，一个人、一个想法、一个几乎没有成本的 MVP，开始验证在线买鞋这件事到底有没有需求。

这个案例很典型：Zappos 最早验证的不是供应链，也不是仓储系统，而是“用户是否愿意在网上买鞋”这个最核心的问题。

Dropbox：产品还没完整开放，先用一个视频验证需求

Dropbox 做的是云存储和文件同步服务。

它的产品体验很好，可以让文件在不同设备之间顺畅同步。但当时市场上已经有不少竞争对手，用户也已经习惯了一些已有工具。

问题是：Dropbox 要怎么证明自己值得被使用？

Dropbox 团队很清楚，只要用户真正试过服务，就会理解它的价值。但在早期，直接让用户完整体验产品并不容易。

于是创始人 Drew Houston 想了一个办法：做一个三分钟视频，演示 Dropbox 如何进行文件同步。

这不是一条普通的产品演示视频。它还加入了一些只有早期技术用户能会心一笑的小梗，用来吸引第一批愿意尝鲜的人。

Drew 后来提到，这个视频给网站带来了几十万访问，Beta 等待名单从 5000 人一夜之间增长到 7.5 万人。

他们自己都被这个结果震惊了。

Dropbox 的 MVP 并不是一个完整开放的产品，而是一条能让用户理解价值的视频。它验证的是：当人们看懂这个方案后，会不会愿意等待并尝试。

Airbnb：从一间公寓里的充气床开始

Airbnb 最早并不是今天这样复杂的平台。

2007 年，旧金山要举办美国工业设计师协会大会。三位创始人判断，会议期间可能有不少人找不到住处。

于是他们把自己小公寓里的床位整理出来，又放上充气床，在一个简单网页上发布出租信息。

很快，就有三位客人愿意住进来。

这件事证明了一个关键点：有人真的愿意住进陌生人的家里，并为此付费。

当这个想法被验证后，他们才开始继续思考，如何重新设计平台、扩大供给和需求。

今天的 Airbnb 已经拥有 1.5 亿用户、400 万房源，估值达到 300 亿美元。不仅提供住宿，还为用户提供目的地城市里的餐厅、活动、评价和评分等信息。

但它最早的 MVP，其实只是一个简单网页和几张充气床。

Spotify：先只做好一件事，流畅播放音乐

2000 年代初，Napster、The Pirate Bay 这类盗版媒体网站遍布互联网。那时候，想做一个新的音乐流媒体平台，看起来几乎不可能。

但 Napster 关闭后，Spotify 联合创始人 Daniel Ek 看到了机会：如果用户可以用很低的费用，立刻听到合法音乐，会不会愿意使用？

Daniel Ek 和 Martin Lorentzon 做出的 MVP 只解决一件事：播放音乐。

最早试用这个应用的人，是他们的家人和朋友。

当他们看到这个想法确实有吸引力后，才把应用推向更大的受众。等 Spotify 被更多用户接受，他们又开始签下更多音乐人，并拓展到更多国家。

到了 2018 年 6 月，Spotify 已经成为覆盖 79 个国家的音乐、播客和视频点播服务，付费订阅用户达到 8300 万。

Spotify 的早期版本没有一开始就追求庞大曲库、复杂推荐系统和各种社交功能。它先验证了一个基础体验：用户是否愿意用一个流畅的方式听合法音乐。

Uber：先连接乘客和司机，再逐步扩展功能

今天很难想象没有 Uber 的时代。它现在已经拥有 4200 万用户。

但 2010 年，Uber 第一次出现在旧金山 iPhone 用户面前时，功能非常简单。

当时它的名字还是 UberCab，重点只是连接用户和出租车司机，并完成应用内支付。

界面也很简单。

只有在 Travis Kalanick 和 Garrett Camp 确信这个想法可以服务更大人群后，他们才开始不断完善产品。

后来，Uber 才陆续增加 GPS、实时追踪、评分和评价、拼车、车费分摊、多目的地、预约出行、日历快捷入口等功能。

Uber 的早期 MVP 没有试图一次性解决所有出行问题。它先证明了一件事：用户是否愿意通过手机叫车并在应用内完成支付。

Buffer：没有产品，也能先测试用户愿不愿意买单

Buffer 是一个很好的落地页 MVP 案例。

创始人 Joel Gascoigne 使用 Twitter 已经有一段时间。他发现自己发的推文在粉丝中越来越受欢迎，于是想发得更频繁一些。

但问题是，保持规律发推并不容易。

于是他想到：能不能做一个工具，帮助用户提前安排推文发布时间？

他觉得，可能不止自己有这个问题。

为了验证这个想法，Joel 做了一个两页网站。

当时并没有真正的产品。

后来，他又想测试另一个更关键的问题：人们会不会为这样的工具付费？

于是他在网站上加了一个定价页面。

当他发现确实有人感兴趣后，才不再犹豫，开始真正开发产品。

Buffer 的故事很适合提醒早期团队：你不一定要先把产品做出来，才能验证需求。有时候，一个清晰的落地页和一个价格页面，就能帮你判断方向是否值得继续。

Twitter：从公司内部短信状态工具开始

Twitter 的起点，来自一家叫 Odeo 的播客公司。

当时，Jack Dorsey、Evan Williams、Biz Stone 和 Noah Glass 四位软件开发者，正在寻找办法拯救一项逐渐走下坡路的业务。

Jack 提出了一个想法：通过短信服务发布实时状态。

Biz Stone 建议把项目命名为 Twttr。于是他们开始做一个只提供核心功能的产品：通过短信发布状态更新。

最早，Twttr 只是 Odeo 员工内部使用的工具。

它确实受到欢迎，但也出现了一个问题：员工在短信上花了不少钱。

这促使创始团队决定把 Twitter 推向更大的市场。几个月后，他们让用户可以通过网页界面访问应用，而不再只依赖短信。

Twitter 逐渐流行起来，每天发布的推文达到 2 万条。

今天，Twitter 已经是一个价值数十亿美元的社交网络，拥有 3.3 亿月活用户。

它最早验证的不是完整社交网络，而是一个非常简单的行为：人们愿不愿意发布实时状态，并关注别人正在做什么。

Product Hunt：先从邮件列表开始

Ryan Hoover 热爱各种产品，因此想做一个服务，帮助大家分享和发现新产品。

但 Ryan 不是软件工程师，他也不想花几周时间去开发一个平台，却不知道有没有人真的需要。

于是，他先在 Linkydink 上用邮件列表的方式启动项目。

他写了一篇博客文章介绍这个想法，并分享给自己的关系网络。

几天内，Ryan 就收到了积极反馈，这让他有信心继续推进。

随后，他联系了朋友 Nathan，对方帮他做了一个线框图。他们决定把这个线框图分享给科技行业里的 50 个人，收集反馈。

Product Hunt 就这样开始了自己的旅程，最终成长为一个拥有百万用户的平台。

这个案例的重点在于：Product Hunt 最早并不是一个完整社区产品，而是一份邮件列表和一张线框图。

它先验证了一个很小的问题：是否有人愿意持续发现和讨论新产品。

MVP 开发：为什么要从小版本开始

从 MVP 起步，可以帮助团队节省时间、精力和资源，也能让产品从一开始就走在更正确的方向上。

这种方法已经被很多年的实践证明有效。

下面是一些采用 MVP 方式开发的产品案例。

Your Livingroom Trainer：先验证人们是否愿意在家接受线上训练

Kathryn Tracy 有一个假设：人们可能愿意在不出门的情况下，和认证教练或健身教练一起训练。

为了验证这个想法，她先做了研究。她去了健身房，向教练和健身爱好者收集反馈，用来验证这个概念是否成立。

之后，Kathryn 找到团队，希望做一个在线训练平台的 MVP。

这个 MVP 的主要目标，是从早期用户那里获得反馈，看看哪些地方做对了，哪些地方还需要改进。

团队设计了一条简单用户流程：

注册 → 创建个人资料 → 搜索 → 预约 → 付款

决定实现的功能包括：

• 注册，并支持上传文件证明教练资质；
• 个人资料；
• 搜索；
• 视频课程；
• 日程安排；
• 通知；
• 平台内支付。

这个 MVP 没有一开始就做成复杂平台，而是围绕用户完成一次线上训练所需的核心流程来搭建。

NightApp：先用一个核心功能验证夜生活热力图

Yannig le Bars 在基辅生活了四年后，想到一个点子：为基辅和巴黎的夜生活做一个热力图。

为了验证这个想法，他希望先做一个 MVP，而且只包含一个核心功能：基辅的实时热力图。

用户可以通过全景视图，查看基辅各个派对场所的人气情况和描述。管理员则可以通过后台添加新地点和内容。

当这个概念被验证，并且应用吸引了用户注意后，团队才继续开发其他功能。

后续新增的功能包括：根据用户位置动态筛选相关地点、注册、用户资料等。

NightApp 后来也扩展到一些法国城市，并支持乌克兰语、法语和俄语。

这个例子说明，MVP 不需要覆盖所有城市，也不需要一开始就做完整社交功能。它先验证的是：用户是否需要用热力图来发现夜生活场所。

最后想说

如果你愿意承担不必要的风险，当然可以直接开发一个完整产品，然后期待它一上线就受到市场欢迎。

但更稳妥的方式，是先做一个 MVP。

用 MVP 验证市场需求，减少错误，观察用户行为，了解用户偏好，然后再决定后续怎么做。

MVP 的价值不在于“做得小”，而在于它能让你更早接触真实用户，更早知道自己到底该不该继续，以及应该往哪个方向继续。

如果你还有关于如何正确构建 MVP 的问题，也可以继续和团队交流，或者在评论区留下你的想法。我们也期待和更多 Indie Hackers 一起讨论，如何用 MVP 把一个新想法真正带到现实世界里。