最小可行产品：少做一点，学得更快

来自 FabricLoop 团队 · 2026 年 5 月 · 9 分钟阅读

“MVP”这个词被用得太频繁、太随意，几乎已经失去了本来的含义。创始人用它指代精心打磨的 v1 版本发布、粗糙的原型、落地页，以及介于其间的一切。有人拿它当作发布残次品的借口，也有人拿它当作永远做下去的理由（“还不够可行”）。

最初的定义出自 Eric Ries 的《精益创业》，非常精确：MVP 是这样一个产品版本，它让您以最少的投入，收集到最多的关于客户的有效验证性学习。它是学习的工具，而不是产品的发布。

最重要的词：可行

“最小”并不难。创始人天然倾向于做减法。难的是“可行”。一个可行的产品，要能提供足够的价值，让人真正去使用它并给您诚实的反馈——或者理想情况下，愿意为它付费。

没人使用的 MVP 什么也教不了您。带有邮箱注册的落地页，只能告诉您人们对这个概念感兴趣，却无法说明您的解决方案是否真的解决了他们的问题。一个刚打开一分钟就崩溃的原型，只做到了“最小”，没有做到“可行”。

常见错误 做的是您想象中的最小版本，而不是能为特定用户提供核心价值的最小版本。这两者并不相同：前者是随意的，后者是有章法的。

看待 MVP 的最好方式，是把它当作一个带有明确假设的实验。在构建任何东西之前，先写下：

任何 MVP 的假设结构

假设

“我们相信［客户群］想要［结果］，因为［原因］。”

测试

“我们将构建［最小的东西］，来检验他们是否会在［时间范围］内［做出某种具体行为］。”

信号

“如果［可衡量的结果］出现，我们就认为假设成立；如果出现相反的结果，则不成立。”

如果您说不清什么情况下假设会被证伪，那您就不是在检验假设，而是在做产品。只有事先就承诺好“否”是什么样子，MVP 才真正有效。

“没有可证伪假设的 MVP，只不过是一个质量不高的产品。那是两回事。”

MVP 分布在从完全手动到完全自动化的光谱上。您应该处在这个光谱的哪个位置，取决于您想学到什么，以及您愿意为这次测试投入多少。

MVP 保真度光谱

礼宾式（Concierge） 手动交付价值，不用软件。在自动化之前，先弄清这个结果是否重要。

绿野仙踪 向用户展示一个看起来能用的界面，背后则由人工完成履约。在没有基础设施的情况下检验需求。

原型可点击的原型图，或基本可用的版本。检验可用性和流程，而不是完整的可靠性。

功能 MVP 可部署、仅含核心功能的产品。检验真实使用情况、留存和付费意愿。

许多创始人会直接跳到“功能型 MVP”，因为它看起来最名正言顺。但礼宾式 MVP——为 10 位客户手动提供服务——往往两周内就能教给您比六个月开发更多的东西。目标是学习，而不是做产品。

范围的取舍，是大多数 MVP 出错的地方。以下是判断该包含什么的框架：

包括在 MVP 中

从 MVP 中剪切

检验标准：对于您考虑添加的每个功能，都问一句“它能带来什么学习？”如果答案是“没有——只是更好一点”，就砍掉它。等验证了核心确实有效之后，再去做。

这两者并不是一回事，混为一谈会带来问题。MVP 是为验证假设而设计的实验；测试版则是您预期产品的早期版本，在正式发布前拿出来供测试使用。

实验结束后，MVP 可能被完全丢弃；测试版通常是您最终要发布的产品的基础。MVP 的设计目的是让单位投入的学习最大化；测试版的设计目的是在接近完成的产品中找出缺陷。

您可以在写下第一行代码之前就拥有 MVP，但如果没有一个基本完成的产品，就不可能有测试版。

回到您的假设。判断 MVP 是否“有效”，不在于人们是否说了好听的话，而在于他们是否做出了您所预测的具体行为。赞美不是验证，承诺——时间、金钱、反复使用——才是验证。

表明您的 MVP 验证了假设的三个信号：

表明没有验证假设的三个信号：

“您愿意为此付费吗？”测试 如果您不确定反馈是否真实，可以直接问：“您愿意为此每月支付 $X 吗？”然后闭嘴等着。随之而来的那段停顿，是早期产品验证中最能说明问题的数据点。

FabricLoop 如何支持 MVP 流程 MVP 阶段会产生大量反馈——用户访谈、记录、问卷回复、团队争论。FabricLoop 把您的假设、测试结果和结论综合放在同一个讨论串里，这样团队即使在几个月后，也能看到您学到了什么，以及当初为何做出那些决定。