MVP不是最小化产品，而是最大化学习——重新定义MVP的6个实战方法
微信扫一扫，分享给好友
关闭
开篇：你做的不是MVP，是LSP（Less Shitty Product）
每个产品经理都听过MVP（Minimum Viable Product，最小可行产品）。但90%的团队把它理解错了。
错误的理解：MVP = 简陋版完整产品。挑一些核心功能做出来，能用就行，先上线再说。
正确的理解：MVP是一种"最大化学习"的工具。它的目的不是尽快上线一个能用的产品，而是用最小代价回答你最关键的产品假设。
Eric Ries在《精益创业》里对MVP的定义精髓是：MVP是一种"实验设计"，而不是"产品版本"。你做的每一版MVP，都是为了回答一个具体的、可以用数据验证的假设。
不理解这一点，你的MVP就会变成LSP——一个 Less Shitty Product（不那么烂的产品），看起来能用但什么也验证不了。
方法一：先问"最危险的假设是什么"
MVP的第一步不是画原型，是回答一个问题："你这个产品最危险的假设是什么？"
"最危险"指的是：如果这个假设是错的，产品的整个立论都不成立。
例子：一个"AI 学习伴侣"产品的几个假设：
- 大学生愿意为 AI 学习工具付费（市场假设）
- AI 可以真正替代学习中的答疑环节（技术假设）
- 用户的真实痛点是"无人答疑"而非"没有学习资料"（需求假设）
最危险的假设是#3——如果用户的真实痛点不在这里，整个 AI 答疑的方向都不对。但很多团队会先做#1或#2的验证，因为这两个看起来更"技术性"、更有"成就感"。
MVP 应该永远从最危险的假设开始验证。
方法二：最小验证规模，不是最小功能规模
很多人把 MVP 理解为"小功能版本"。实际上，决定 MVP 大小的不是功能数，而是验证假设所需的最少用户数和最短时间。
如果你能用 5 个用户的访谈验证假设，3 个月的工作都是浪费——直接做用户访谈就好。
如果你需要 100 个用户的真实使用行为数据，半年的访谈也是浪费——你需要快速上线一个能拿到真实数据的版本。
MVP 的规模，应该按"验证假设所需的最少资源"来估算。
方法三：把 MVP 拆成"真实验"和"假实验"
不是所有假设都需要做完整产品。有些假设可以用低成本实验回答。
真实验（需要上线产品）：
- 用户会不会为这个功能付费
- 用户会不会每天打开这个产品
- 用户会不会推荐给朋友
假实验（不需要上线产品）：
- 这个功能是否技术上可行（用 demo 验证）
- 用户是否理解这个概念（用访谈验证）
- 这个产品的核心逻辑是否清晰（用原型验证）
真假设做 MVP，假假设做 demo。两者的资源投入差 10 倍以上。
方法四：用"可以丢弃"的心态设计 MVP
很多团队的 MVP 做得很重，因为心里想着"这个版本要好好打磨，毕竟是给用户看"。
这种心态从根子上就错了。
MVP 是用来"扔掉"的。把它当成一次性的学习工具，而不是长期产品的第一个版本。如果你的 MVP 验证了假设，它会被一个更好的版本替代；如果它没验证假设，它也会被替代。无论哪种结局，MVP 都只是过程，不是结果。
用这个心态设计 MVP，你会愿意：
- 用最丑陋的 UI（哪怕就是文字流程图）
- 用最窄的功能（哪怕只能服务一个场景）
- 用最简单的技术（哪怕后端用 Excel 手工跑）
因为它的价值是学到的东西，不是产品本身。
方法五：MVP 的成功指标是"学到什么"，不是"上线什么"
很多团队评估 MVP 看的是上线速度、功能完整度、用户反馈数量。
错。MVP 的成功指标只有一条：
"我们这次 MVP 学到了什么新东西——并且这个新东西足以改变我们的下一步决策。"
按照这个指标：
- 一次实验后你说"我们学到了用户其实不想要这个功能，所以我们要改方向"——这是成功的 MVP
- 一次实验后你说"我们没学到什么，因为数据不够"——这是失败的 MVP
- 一次实验后你说"我们学到了很多用户喜欢"——这是不完整的 MVP，因为缺少"下一步决策"的判断
MVP 完成的标志是"做出了下一步决策"，无论决策是继续、转型还是停掉。
方法六：避免"临时 MVP 陷阱"
最后一个，也是最隐蔽的一个。
很多团队的 MVP 长期停留在"临时版"状态——因为它"能用"，因为上线了用户有了，因为迁就一下也凑合能用。
这是 MVP 思维中最反直觉的一个点：你必须"主动"把 MVP 替换，而不是"被动"等它自然演化。
原因很简单：MVP 是为验证假设设计的，不是为长期使用设计的。它的所有妥协（丑陋的UI、脏代码、没有边界处理、不完善的安全机制）都会随着时间变成"bug"、"投诉"、"线上事故"。当这些临时架构变成永久架构时，你的迭代速度会越来越慢，直到整个产品失去灵活性。
所以每次 MVP 完成验证后，立刻进入"正式版重构"。不要等 MVP 自然进化，因为那永远进化不出你需要的版本。
实操：6个立即可用的 MVP 重构建议
- **下次开需求评审先问"假设是什么"**：每个需求先问"我们要验证什么假设"，再讨论功能和实现。
- **用一句话写出你的最危险假设**：写不出来，说明你对产品的理解还不够深。
- **把你的 MVP 设计成"扔得掉"的样子**：让它和正式产品用完全不同的技术栈，让你不会有"舍不得"的念头。
- **建立"决策信号"判断标准**：MVP 验证完成时，必须能输出一句"基于这次数据，我们要继续/调整/停掉"。
- **MVP 验证成功后 30 天内启动正式版重构**：不要让临时架构变成永久负担。
- **保留"学习记录"**：每次 MVP 后，写一篇简短记录"我们学到了什么"，这是团队最宝贵的资产。
写在最后：MVP 的本质是一种思维，不是产品阶段
把 MVP 当成产品阶段理解，你会陷入"做最小版本 → 用户反馈 → 加功能 → 变正式版"的循环，最后发现自己做的根本不是 MVP，而是渐进式开发。
把 MVP 当成一种思维理解，你会在每个产品决策时问同一个问题："我们做这件事，是为了验证什么假设？这个假设是不是最危险的？最小验证规模是什么？"
这两个问题的价值，远远超过 100 个方法论和 1000 张路线图。
真正的产品经理，不是把 MVP 当成产品阶段，而是把 MVP 当成思维工具。
这也是高手和普通人的分水岭。