什么是MVP？最小可行产品怎么定义

MVP（最小可行产品）指为验证核心假设而开发的、能向真实用户交付核心价值的最小版本。

然而，这个解释在实践里经常变形，有人当它是功能残缺的半成品，有人把原型或PoC（概念验证）也当成MVP，结果往往一致：第一个版本做出来了，原本要验证的假设却没有答案。

要避开这些坑，本文把最小和可行两个条件拆开看，再分清MVP与原型、PoC的边界，最后用几个问题筛一遍功能范围。

一、MVP常被误读成什么

第一种误读，是把MVP当成故意做粗糙的半成品。团队砍掉说明、反馈入口和基本体验，理由是MVP不需要完善，能跑就行。用户拿到后不知道怎么用，核心流程走不通，最后得到的数据既不反映需求，也不反映付费意愿。

第二种误读，是用原型代替MVP。原型解决的是界面对不对、流程顺不顺，通常在内部或小范围里演示，没有真实交易，也没有真实用户在真实场景里的行为。它适合沟通想法，不适合验证市场。

第三种误读，是把PoC当作MVP。PoC回答的是技术方案能不能实现，比如某个算法能不能跑通，某个接口能不能稳定调用。这个结论对研发重要，对市场判断没有帮助。

这三种误读的共同点，是只看见功能少，没看见MVP为了验证什么。MVP本质上是验证工具，关键不是交付了多少功能，而是用多低的成本拿到了可执行的用户反馈。

二、最小可行产品怎么定义

最小可行产品怎么定义，得把最小和可行拆开看。

最小，指功能少到只够验证核心假设，不是砍得越多越好。假设你要验证用户愿不愿意付费，支付环节就是保留项，不是可以砍掉的加分项。如果首版连支付都没有，用户再喜欢内容，你也判断不出他是否愿意掏钱。砍功能的前提，是能说清这项功能和要验证假设的关系；说不清的功能才该砍。

可行，指这一版能被真实用户使用，并解决一个具体问题。可行不要求功能完整，但要求用户能独立走完主流程，产生可观察的行为。一个只能演示的视频播放页不是可行版本，用户注册后能看到能付费的页面才叫可行。

一句话收束：最小可行产品，是能跑通核心价值并检验关键假设的最少功能集合。操作上有个小口诀：先写下你当前最大的不确定点，再逐个砍功能，一直砍到留下的功能只够验证这一个不确定点为止。

三、MVP与原型及PoC的边界

原型、PoC和MVP回答的是不同阶段的问题。下表从用途、使用对象、验证问题和是否上线四个维度做了区分。

三者容易混淆，是因为有的项目会先做原型或PoC再开发MVP，看起来像同一条线上的不同叫法。但原型和PoC完成时，项目还没进入真实市场；MVP上线后，才能获得用户的真实反应。原型和PoC可以作为MVP的前置步骤，但不能替代MVP。

四、软件团队怎么划MVP

用一个在线课程产品做例子。假设团队最大的不确定点是：用户愿不愿意为系统化课程付钱。这个假设不能写成用户需不需要学习内容，因为内容需求通常已经成立，真正没验证的是付费意愿。

按这个假设，首版只需要三件事：课程列表、支付、视频播放。课程列表用来判断哪些内容能吸引用户点进来；支付流程用来记录有没有人走到支付页、有没有人完成购买；播放器用来确认内容交付能不能正常跑起来。评论、问答、学习进度追踪都可以往后放，它们会改善体验，但不影响核心假设的验证。

范围划到这里，验收标准就不该是功能按时上线，而是能拿到关键行为数据：多少人打开课程页、多少人进入支付页、多少人付费。数据到这一步，假设是否成立才有答案。

五、判断最小可行的四个问题

范围划定后，可以用四个问题过一遍。

第一，这个功能集能否独立解决用户的一个真实问题？用户不会因为你知道他缺什么就留下来，他要的是打开就能用。如果缺了某项功能，用户根本不愿继续走，那这项功能必须保留。

第二，这一版出来，当初写下的核心假设能得到验证吗？能观察到什么指标？例如在线课程产品要看的指标是注册到支付的转化率。如果指标没有提前想清楚，发布后容易拿到一堆数据却分不清重点。

第三，有没有某项功能删掉后不影响上述验证？删不掉的，要有理由。登录流程可能增加摩擦，但它是确认交易身份的前提，值得保留；社区评论能促进留存，但删掉不影响付费假设的验证，可以留到下一版。

第四，这个功能集能在合理成本内快速上线吗？如果开发周期要半年，多半还可以再缩小。MVP的周期应该短到允许你快速试错；周期越长，越晚拿到真实反馈，验证成本也越高。

四个问题全部通过，才算同时满足最小和可行。二者不能拆开理解。

六、MVP是迭代的起点

MVP不是一次交付物，发布不意味着项目完结。精益创业里有一个构建、度量、学习的循环：构建MVP，度量用户行为，从数据判断假设是否成立，再决定下一步。

下一步通常有三种结果。假设被验证，就补全下一个高优先级功能；假设部分成立，就调整范围或换个人群再试；假设证伪，就停止投入，换一个方向重新验证。迭代方向应当由数据和用户行为驱动，而不是由内部猜测驱动。

产品进入高频迭代后，反馈量会快速变大。把需求池、首版范围和后续反馈记录放在同一个项目管理工具中，例如禅道，可以让每次版本范围的变更有迹可循。但工具只解决记录问题，要不要保留某个假设，决定权仍然在用户反馈手里。

七、常见问题解答

什么情况下不适合做MVP？

当核心假设已被市场或同类产品验证，没有未知风险时，不必做MVP，可直接做完整功能；需求被合同或合规固定、边界明确的定制项目也不适合。

一个小型MVP大概要投入多少成本？

没有固定数字，主要看假设复杂度和所需数据点。通常用现成工具加少量开发，或人工流程代替未完成功能，把成本花在验证目标上，而非体验美化。

MVP验证失败，是不是代表产品方向错了？

不一定。可能只是目标人群、定价或实现方式选错。先回看原始假设和指标，找到数据在哪一步断裂，再决定微调范围还是换方向。

免费试用算不算一种MVP形态？

看验证对象。若验证注册和使用意愿，试用可直接验证；若验证付费意愿，试用只能筛出有兴趣的用户，还需配合付费转化观察。

回到开头那句直答。MVP的本质不是少做功能，而是用最低成本验证核心假设。划好首版范围后拆成需求清单，交给真实用户行为检验，下一版才知道往哪里走。