如何规划一个能快速上线并真正验证想法的 MVP

你完成了种子轮融资，招聘了两名工程师，并制定了六个月的资金周期用于产品发布。六个月后，你拥有了一款打磨精良的产品，却无法回答这轮融资本应回答的那个问题：真的有人想要这个吗？这是早期软件领域最常见、也最昂贵的错误。就好比先浇筑地基、搭好墙体、装好厨房，然后才去检查你所建造的社区是否有居民。

MVP 本应防止这种情况发生。然而我们看到的大多数所谓 "MVP"，其实是创始人心目中完整产品的缩小版。那不是 MVP。那是一个小型的 V1，它教给你的东西几乎不会比一周的用户对话加一个落地页更多。

MVP 是一个问题，而不是一个产品

"minimum viable product"（最小可行产品）这个短语常被误解为 "尽可能最小的产品"。它不是。它是你能够放到真实用户面前、用来回答某个你无法用其他方式回答的具体商业问题的最小事物。

如果你的问题是 "忙碌的餐厅老板是否愿意每月支付 99 美元来自动化库存对账"，那么 MVP 就是任何能够证实或证伪这一点的东西。通常那是一项人工运行的服务、一份电子表格，或者一个简陋的网页表单，配合真实的人在幕后完成实际工作。它几乎从来不是一款拥有身份认证、计费系统和移动端响应式仪表盘的全栈应用。

重新定义会改变你构建的东西。当问题成为锚点时，那些不能让你更接近答案的功能会被砍掉。剩余的范围既小、又锐利、又站得住脚。

四种烧掉资金周期的范围规划错误

在数十次 MVP 合作中，我们看到相同的、代价高昂的模式反复出现。

构建平台而不是产品。 创始人在一位付费用户还不存在时，就花几周时间投资于管理面板、多租户架构、基于角色的权限系统和分析仪表盘。这些是真实产品的真实需求。在 MVP 阶段，它们是一种赌注——赌你已经知道自己在构建什么。你并不知道。你正在试图搞清楚。

把 "上线必需" 和 "回答问题必需" 混为一谈。 上线一家商店需要一个结账流程。但用来测试购物者是否会购买某个具体产品时，它并不必需；一个 "通知我" 按钮加上人工开票，就能以极低成本证明购买意愿。

在向任何人展示之前先追求打磨。 一个粗糙的 MVP 落到真实用户手中，胜过一个打磨精良、却无人观看的演示。市场给你信号，团队给你的是意见。

把 MVP 和原型混为一谈。 原型是要丢掉的。MVP 是薄的，但却是真实的。它处理真实交易或提供真实价值，即便背后的管道是胶带拼凑的。混淆两者，你要么得到六个月后让自己后悔的脆弱代码，要么得到一个精美的、可点击的、没人为之付费的模型。

对每个功能的唯一测试

在任何功能进入 MVP 范围之前，请提出一个问题：如果我们移除这个功能，MVP 是否仍然能回答我们最初想测试的那个商业问题？如果答案是肯定的，就砍掉它。

诚实地应用这个测试，会砍掉一份典型初始待办列表中的 60% 到 80%。创始人会抗拒，因为每砍掉一个功能都感觉像是失去一个赌注。事实并非如此。那只是把赌注推迟到你拥有数据、可以做出更好判断的时刻。

五步范围规划路线图

以下是我们在为客户规划真正 MVP 时所走过的顺序。

1. 用一句话写下商业问题。 不是产品愿景。是可证伪的问题。"胡志明市的工厂经理是否会每月支付 200 美元，购买一款替代纸质记录的移动端停机跟踪应用？" 这是一个问题。"构建一个停机跟踪平台" 不是。

2. 找出能够回答它的最小产物。 对于某些问题，那是一个落地页加上 20 份预订单。对于另一些问题，那是一个由人工在后台支持的两屏移动应用。对极少数问题而言，那才是一个完整的软件产品。

3. 起草功能列表，然后无情地裁剪。 对每一项应用上面那个唯一的测试。把其余所有内容推到一个 "V1.1" 列表中，只有在 MVP 回答了问题之后才回头看它。

4. 设定一个硬性的时间预算，而不是功能预算。 诚实规划范围时，六到十二周对大多数 MVP 来说已经足够。如果计划超过这个时间，那说明范围有误。回到第 3 步。

5. 提前定义成功标准和终止标准。 "如果试用用户中有 15% 在 30 天内转为付费用户，我们就继续；否则我们转向或停止。" 在你开始构建之前写下这些数字，能够在日后保护你免受沉没成本推理的影响。

这在实践中是什么样子

一位物流客户找到我们时，坚信自己需要一个六个月的构建计划：司机端应用、调度员网页应用、客户门户，以及一个路线优化引擎。而他们真正的商业问题要窄得多：小型货运运营商是否愿意为更好的任务匹配支付月费？我们规划了一个八周的 MVP。一个单独的调度员网页应用、一个 Telegram bot 替代原生的司机应用，以及一个在幕后运行的人工匹配流程。上线十周后，他们已经拥有 40 位付费运营商，并获得了清晰的信号——这个模式行得通。完整的平台后来才建成，由收入资助，并由真实使用数据（而非创始人的假设）来塑造。

与之相反的另一种情况很容易想象：六个月的构建，一个打磨精良的四合一产品，然后才发现他们的哪些假设是错的。

这种纪律会不断累积

把 MVP 的范围规划好，不是一次性的练习。它是一种习惯。同样的纪律，日后会把那些每两周交付一个功能的团队，和那些花一个季度做出无人使用的发布的团队区分开来。早早学会这一点的创始人，会构建出与市场保持贴近的公司。学不会的创始人，往往在想法用完之前就已经烧完了资金周期。

如果你正盯着一份已经感觉沉重的范围文档，那就是你需要裁剪的信号。如果你不确定哪些裁剪是安全的，那就是一个值得与经验丰富的伙伴展开的对话。在 MerkTechs，我们已经帮助越南和东南亚各地的团队，把 MVP 从需要季度才能交付，规划成能在数周内上线的样子，而且更重要的是，它们带回来的是一个答案，而不是一份愿望清单。如果你正处于这个阶段，我们随时乐于展开第一次对话。