MVP 定义与边界

MVP 是 Minimum Viable Product 的缩写，中文叫最小可行产品。这个概念最早由 Frank Robinson 提出，后来被 Eric Ries 在《精益创业》这本书里发扬光大。它的核心思想很简单：用最小的成本和时间，做出一个能验证核心假设的产品版本。

很多人对 MVP 有误解。有人觉得 MVP 就是"阉割版"，什么功能都没有。有人觉得 MVP 可以做得很粗糙，反正是"最小"嘛。这两种理解都是错的。

MVP 不是阉割版，而是聚焦版。它应该在一个非常窄的范围内，把事情做得非常好。Dropbox 的 MVP 是一个三分钟的演示视频，但这个视频制作精良，清晰地展示了产品的核心价值。Airbnb 的 MVP 是在自己公寓里摆三张气垫床出租，但他们拍了好看的照片，创建了一个能用的网站。Twitter 最早只是公司内部的一个短信工具，员工用来分享"我在干嘛"。这些 MVP 都不"完整"，但在各自聚焦的点上都做得很到位。

为什么要做 MVP

你可能已经有了一个完美的产品蓝图在脑海里。你想象中的用户会怎么使用它，会多么喜欢它。但这里有一个残酷的事实：你的想象很可能是错的。

在 Reddit 的 r/startups 和 r/SaaS 板块，几乎每周都有创始人分享类似的故事。他们花了六个月做一个"完美"的产品，结果上线后发现没人想要。用户要的是 B，他们做的是 A。更惨的是，有些人做了一年，投入了所有积蓄，最后发现整个方向都是错的。

MVP 的价值在于：用最小的成本验证你的假设。做 2 周 MVP，发现没人要，浪费 2 周。做 6 个月"完美"产品，发现没人要，浪费 6 个月。时间、精力、金钱都是有限的资源，先验证，再投入。

2025 年的创业环境比以往任何时候都更强调这一点。AI 工具和无代码平台让做一个 MVP 变得前所未有的快。你的竞争对手可能两周就能做出一个能用的产品。如果你还在追求完美，等你做完，市场可能已经变了。

还有一点在 Reddit 讨论里经常被提到：真实用户的反馈比你的想象重要一百倍。你以为用户会用 A 功能，结果他们根本不用。你以为 B 功能不重要，结果那才是他们最想要的。只有把东西拿给真人用，你才能知道真相。

2025 年 MVP 的新标准

MVP 这个概念从 2011 年流行到现在，已经发生了一些变化。2025 年的用户期望比十年前高多了。Reddit 上有一个讨论很有意思：有人问"MVP 是不是可以界面很丑"，得票最高的回答是"不行，2025 年的用户不会容忍丑的产品"。

这不是说你要做一个完美的产品。而是说，在你聚焦的那个核心功能上，体验必须是好的。你可以只有一个功能，但这个功能的界面不能让人困惑，流程不能卡住，用完之后用户要能感受到价值。

有人把这个叫做 MLP，Minimum Lovable Product，最小可爱产品。意思是 MVP 不只是要"能用"，还要让用户"喜欢用"。这个概念有点过于理想化，但背后的趋势是真实的：用户期望在上升，"凑合能用"的产品越来越难以获得关注。

MVP 应该有付费入口

这是一个很多人忽略的点。Reddit 上关于这个话题的讨论很激烈，但越来越多的成功创始人站在"MVP 就应该收费"这一边。

为什么？因为免费用户的反馈和付费用户的反馈是完全不同的。免费用户可能只是随便看看，他们的"喜欢"可能只是客气。付费用户是掏了真金白银的，他们的反馈才是真实的需求信号。

更重要的是，付费验证了你的商业模式。一个产品可以有 10 万免费用户，但如果没人愿意付费，这个产品就没有商业价值。反过来，一个产品只有 100 个用户，但其中 10 个愿意付费，这就证明了有人愿意为你的价值买单。

在 2025 年的投资人眼里，MVP 阶段最强的信号不是用户数，而是有没有人付费。哪怕金额很小，$200、$500、$1000，都是强烈的产品市场契合（product-market fit）信号。有人说"我先免费获取用户，以后再收费"，这在投资人看来是一个红旗。如果你自己都不相信有人会付费，凭什么让投资人相信？

当然，这不意味着你要在 MVP 阶段就做复杂的订阅系统。一个简单的 Stripe 链接，一个"付费解锁高级功能"的按钮，甚至一个"如果你觉得有用，请付费 $5 支持"的提示，都可以。关键是要有一个途径让用户付费，然后观察有没有人真的付。

怎么定义你的 MVP 范围

这是最难的部分。你脑子里可能有 50 个想法，每一个看起来都很重要。怎么决定做哪些，砍掉哪些？

有一个叫 MoSCoW 的方法很实用。把你所有想做的功能分成四类：Must have（必须有）、Should have（应该有）、Could have（可以有）、Won't have（不做）。MVP 阶段只做 Must have 那一列。

但问题是，很多人分类的时候，把太多东西放进了 Must have。这里有一个很好的检验标准：如果砍掉这个功能，用户还能不能完成核心任务？如果能，这个功能就不是 Must have。

另一个思路是问一个问题：我到底要验证什么假设？

如果你的假设是"人们愿意为 AI 写作工具付费"，那你的 MVP 只需要一个 AI 写作功能和一个付费按钮。用户登录、注册、个人设置、历史记录，这些都不是验证核心假设所必需的。

如果你的假设是"程序员愿意为代码审查工具付费"，那你的 MVP 只需要一个代码审查功能和付费入口。其他的都可以以后再加。

MVP 应该多久做完

在 Indie Hackers 和 Reddit 上，关于这个问题的讨论很多。大部分成功的独立开发者给出的建议是：2 到 8 周。

如果你用无代码工具或者 AI 辅助开发，2 周做出一个能用的 MVP 完全可行。如果你需要写代码，4 到 8 周是一个合理的范围。如果你的 MVP 超过 10 周还没做完，很可能是范围定得太大了。

有一个很好的建议：如果你发现自己在 MVP 阶段花了超过 2 个月的时间，停下来问问自己，是不是在做一个"完美产品"而不是 MVP？是不是有些功能其实可以砍掉？

还有一个常见的陷阱：为了"以后扩展方便"，花大量时间设计架构。这通常是过度设计。在 MVP 阶段，技术债务是可以接受的。先验证假设，证明有人要这个东西，再去还技术债。如果假设是错的，那些精心设计的架构全都白费了。

真实案例：经典 MVP 故事

Dropbox 的故事值得反复讲。创始人 Drew Houston 没有先做一个复杂的文件同步系统，而是做了一个三分钟的演示视频，展示 Dropbox 会怎么工作。这个视频发到 Hacker News 上，一夜之间注册列表从 5000 人涨到 75000 人。视频验证了需求存在，然后他们才开始真正开发产品。

这个案例的启发是：MVP 不一定是一个能用的产品，可以只是一个验证需求的工具。演示视频、落地页、人工提供服务、甚至一个表单，都可以是 MVP。关键是用最小的成本回答一个问题：有人需要这个东西吗？

Airbnb 的故事也很经典。创始人交不起房租，就在自己公寓里摆了三张气垫床，在一个设计会议期间租给参会者。每晚 80 美金，三个人都愿意住。这就验证了一个假设：陌生人愿意住在陌生人家里。整个过程没有写一行代码，用的是已有的工具和资产。

Twitter 最早是 Odeo 公司内部的一个短信工具，员工用来分享自己在干什么。没有转发，没有私信，没有话题标签，就是一个简单的"我在干嘛"状态更新。这个极简的版本在小圈子里跑通了，然后才逐渐加功能、扩规模。

这些案例的共同点是：创始人没有追求完美，而是用最小的资源验证了核心假设。假设验证了，再投入更多资源去完善产品。

常见的 MVP 错误

在 Reddit 和 Indie Hackers 上，有几个 MVP 错误被反复提到。

第一个是功能太多。这是最常见的。"再加一个功能就更完美了"，"用户肯定会喜欢这个功能"，结果加着加着就变成了一个庞大的系统，永远做不完。有人管这个叫"Minimum Viable Bloatware"，最小可行膨胀软件。

第二个是功能太少，少到产品不能用。有人做了一个"MVP"，只有一个按钮，点一下什么都不发生。这不是 MVP，这是一个 Demo 都算不上的东西。MVP 虽然功能少，但应该能让用户完成一个完整的任务，获得一个完整的价值。

第三个是没有收集反馈的机制。上线了，等着用户自己来说话。问题是大部分用户不会主动给反馈。你需要在产品里加上反馈入口，在用户使用过程中弹出问卷，或者主动联系早期用户做访谈。没有反馈，MVP 就失去了意义。

第四个是追求错误的指标。有人只关注注册用户数，"哇，有 1000 个人注册了"。但这些人有多少真的用了产品？有多少人愿意付费？免费注册数是一个虚荣指标，付费用户数和留存率才是真实的信号。

第五个是闭门造车。花了几个月做一个"完美"的产品，然后发布，发现没人想要。在开发 MVP 之前，应该先跟潜在用户聊天，确认问题真的存在，确认你的解决方案方向是对的。很多成功的创始人建议：在写代码之前，先跟 20 个潜在用户做访谈。

你的 MVP 检查清单

做完 MVP 之前，问自己几个问题。

第一，这个 MVP 解决的是不是一个核心问题？不是三个问题，不是"顺便也能解决"的问题，而是一个明确的、用户真正痛的问题。

第二，用户能不能完成一个完整的任务？从头到尾，不会卡住，不会需要去别的地方完成剩下的步骤。

第三，有没有付费入口？哪怕是一个简单的按钮，让用户有机会用钱投票。

第四，有没有收集反馈的方式？用户能不能告诉你哪里好、哪里不好？

第五，能不能在 2-3 周内做完？如果估计要更久，很可能范围定得太大了。

如果这些问题的答案都是肯定的，那就开始做吧。不要再想了。

---

下一章聊工具选型。Cursor、Windsurf、Codex、Claude，选哪个？同的产品类型适合不同的工具。