MVP 迭代方法论：从 0 到 1 的产品工程实践

MVP（Minimum Viable Product）可能是产品领域被误用最多的概念之一。太多人把 MVP 理解为”做个简陋的版本先上线”，然后上线之后发现用户不买账，就归结为”市场还没准备好”。

MVP 不是关于简陋，而是关于验证。它的核心问题是：用最小的成本，验证你最大的不确定性。

从假设开始，不是从功能列表开始

大多数产品失败不是因为做得不好，而是因为做了没人要的东西。所以 MVP 的第一步不是列功能，而是列假设。

假设通常有三层：

很多团队直接跳到了方案假设——“我做一个 AI 摘要工具”——但从没验证过问题假设：“用户真的需要 AI 来帮他们做摘要吗？他们现在是怎么处理的？”

实践建议：在写第一行代码之前，先找 5-10 个潜在用户做深度访谈。不要问”你觉得这个产品好不好”（他们会礼貌地说好），而是问”你上一次遇到这个问题是什么时候？你当时怎么解决的？“

验证假设不一定需要写代码。根据假设的类型，MVP 可以有不同的层次：

做一个着陆页，描述你的产品价值主张，放一个”加入 waitlist”的按钮。投一点广告引流，看转化率。

如果连一个注册邮箱都收集不到，说明要么你的价值主张不够吸引人，要么你找的渠道不对。

做一个看起来自动化的产品，但背后其实是人工处理。用户感知到的是”AI 自动分析”，实际上你在后台手动分析然后返回结果。

这个方法可以验证方案假设——如果用户对”人工假冒 AI”的结果满意，那说明方案方向是对的，接下来只需要工程化。

只做核心功能，不做注册系统、不做仪表盘、不做通知、不做会员体系。用户能完成核心任务就够了。

一个经典的例子：Dropbox 的 MVP 甚至不是一个可用的产品——而是一段视频。Drew Houston 录了一个 3 分钟的演示视频放在 Hacker News 上，一夜之间 waitlist 从 5,000 涨到 75,000。他验证了需求，然后才开始做产品。

MVP 上线之后，最大的诱惑是”加功能”。用户反馈说想要 X、Y、Z，团队就开始排期做 X、Y、Z。一个月后，产品从 MVP 膨胀成了一个臃肿的半成品。

健康的迭代是这样的：

“做更多”和”做更好”是两个方向。早期产品应该先做更好。

作为工程师，我见过太多 MVP 项目在技术选型上过度设计：

MVP 阶段的技术选型原则很简单：选你最熟的、能最快上线的。

技术债在 MVP 阶段不是问题。如果产品验证成功、用户量真的上来了，你有充足的理由和资源去重构。如果产品失败了——那些精心设计的架构就是纯粹的浪费。

MVP 阶段不需要复杂的数据看板。你只需要盯住几个核心指标：

Sean Ellis 有一个经典的 PMF 测试：“如果明天这个产品不能用了，你会有多失望？“如果超过 40% 的用户选择”非常失望”，你可能已经找到了 PMF。

MVP 的核心功能应该是完整的、可用的。“核心功能有 Bug”不叫 MVP，叫半成品。MVP 减少的是功能范围，不是质量。

MVP 是一个阶段，不是一个长期状态。如果你的产品上线三个月还在说”我们还是 MVP”，通常说明你在回避真正的问题——产品没有找到 PMF。

产品做出来了，放在那里不会有人自动来用。MVP 需要同步验证分发渠道。你的用户在哪里？怎么触达他们？这些问题和产品本身一样重要。

MVP 的本质是一种思维方式：在不确定的环境里，用最小的成本获取最多的信息。

它不只适用于创业。在大公司内部做新项目、在开源社区发起新工具、甚至在个人生活中尝试新事物，MVP 思维都适用。

核心就一句话：先证明值得做，再想怎么做好。