MVP，让我欢喜让我忧

前几天，我写了一篇文章《MVP已死，有事烧纸》来回答群里黑白子兄弟的问题，但是我感觉还是应该不做标题党，要回归到正常的MVP的探讨中。

在上一篇文章中，我也提到了，之所以起这样的文章名，只是因为我看到一些国外的资料，有人对MVP的现实意义存疑，认为MVP其实把很多产品的发展过程带偏了，就如黑白子兄弟提到的那几个问题。

但是，作为一名老产品人，还是习惯于抛出问题，然后说说个人的想法，好，废话不多说，我就结合我看到的资料和我个人的经历，说一下MVP的问题都有哪些。

问题1：是通过MVP寻找Earlyvangelists，还是向Earlyvangelists提供MVP

我们应该都见过这样一张图：

这张图表明的是一个产品在上市后，不同阶段的消费者的特性和规模情况，但是，这是对一个以正常状态发布的产品而言的，但是在MVP中，就面临这样一个问题，就是MVP是否适应于这条曲线。

尽管MVP的含义是最小可行产品，但是在现实中，很多企业是不太理解这个“最小”是什么意义的。

其实按照ERIC.RIES的解释，“最小”的产品并不一定是一个具备了完全商业化要素的产品，它可以是一个原型，甚至可以是PPT或者手绘图，只需要向客户解释清楚你这个MVP要解决哪些问题，呈现哪些特征，并引起客户的兴趣，产生购买欲望，最终获得LOI就可以了。

但是，这里有个前提需要解决，就是，你的MVP想要呈现给的哪些Earlyvangelists是否存在？如果存在，他们在哪里？

因此，很多企业在应用MVP的时候，就陷入到了一种困惑中，如果我是用MVP去寻找Earlyvangelists，那么，我要找到他们的成本太高，同样，如果已经有了Earlyvangelists，那么，MVP是否能激起他们的兴趣，我们可以想一下，如果你只是用一个原型去展示，那么，激起他们兴趣的效果有多大呢？

当然，我们也可以把原型做的非常高保真，但是又有了两个问题，一个就是高保真的原型并不节省成本，包括金钱和时间上的，另一个就是如果能够做一个高保真的原型，那干嘛不直接做一个正式的产品呢？

也就是说，如何用最低的成本来激发Earlyvangelists的兴趣，企业会算账的，但是，MVP显然不能很好的平衡这种情况，因此，我们就看到了，很多所谓的MVP其实都已经具备了正常发布产品的特质了。

因此，“最小”，这个MVP的特征，事实上也就不存在了。

问题2：如何确定MFS（Minimum Feature Set）

基于第一个问题（Earlyvangelists希望看到的是能激发起他们兴趣的特征），第二个问题就自然而然产生了，MVP的重点不在于呈现功能，比方说，你规划的MVP中有一个会员管理系统，但是会员管理系统算是特征吗，显然不是，这是一种标配，只是一个功能（function）而已，因此，MVP强调特征（feature）的呈现，但是，我们又知道，在MVP中，不是一次性呈现所有的特征的，而是渐进式的。

那么，一个问题来了，确定MFS的标准是什么？换句话说，MF的最小值，最低标准如何确定？

曾经有人问过ERIC.RIES，他也只能这样回答：

“Probably much more minimum than you think.”

可能比你想象的少的多。

这完全没有指导意义啊，因此，采用MVP的企业就按照各自理解的来做了，但是最大的问题来了，一旦标准没法确定，肯定会陷入到无序中。

你产品经理认为A和B特征是应该在MVP中 呈现的，但是研发认为应该是A和C，营销认为应该是B和C，高层一看这那行，别争了，A、B、C都上吧。

于是，MFS最终就成了各个利益相关方各自认知下的特征汇总，而失去了原本的意义。

问题3：MVP提供的线性问题验证过程是可靠的吗

MVP的目标我们已经知道了，就是验证我们在产品中的问题假设是否适真实，从而最终实现PMF（product-market fit），这个过程其实是漫长的，传统方式的基本逻辑是，在没有确定问题的真实性之前是不会做任何和开发有关的事情的，因此，我们就发现，很多产品经理在早期会把大量的精力，通过各种途径放到问题真实性的确认上。

瀑布有好处，也有不足，顺便说一下，瀑布，敏捷这些开发模式一定是适应于不同类型的产品的，千万不要追新潮，而忽视了自身特点的结合，这个有时间了和大家聊一下。

而MVP呢，目前结合最多的就是敏捷，对于这种小步快跑，不断迭代的模式来说，如何处理快速和真实的矛盾，这就成了我们必须要处理的一对矛盾。

也就是说，MVP和敏捷的结合，是在一种具有很大风险的未知和不确定性下开始介入正式产品的，尽管MVP会用MFS来尽可能的减少不确定性和风险，但是这只是数量的一种控制，而不是性质的控制。

并且，MVP对问题的验证假设了一种情况，就是这个验证过程是一种线性的，比方说，基于A问题，Earlyvangelists会提出B问题，基于B问题，会提出C问题，这样，就会形成一个线性的问题链。

但事实上，咱们都有体会，消费者肯定不是这样的，他们会从A直接跳到C，然后再回到B，甚至直接从A就到了他们的认知体系中。

因此，一旦线性验证过程被打破了，那么，你所呈现的MVP就会被消费者否定，因为，他们没有从你的MVP中看到他们想要的特征，没有看到他们的问题具有可解决的现实性。

从而，你最终想提供的解决方案或许就脱离了你的预设。

尽管在本文中提到了三个MVP的问题，但是，我还是开篇说到的，作为一个老产品人，尽量站在一个客观的角度来认知一种思想，当然，我的目的也很明确，就是从这些思想中吸取对产品管理工作有现实意义的内容，从而更加完善起自己的产品管理知识体系。

最后呢，说一个我们曾经讨论过的一个案例，来看看优秀的MVP是什么样的。

这个案例可能比较老了啊，不知还有多少朋友记得团购，最早的团购网站是美国的groupon，但是可能没多少朋友知道，groupon其实是从一个blog开始的。

我们可以分析一下，为什么groupon要从blog开始呢，原因很简单，就是因为blog完全可以呈现团购这种服务的MVP，原始的团购形态是什么，很简单，就是发布一款商品的信息，然后看有多少人愿意购买，人多了，就可以和供应商讨价还价，然后参与到这个团购中的消费者都可以用优惠的价格获得同样的商品。

就这么简单，说白了，团购的原始形态其实就是一个商品的信息发布平台，并不是真正意义上的电商，因为不涉及到自己实现支付，物流什么的，就是纯发布一款商品的信息。

而blog呢，大家现在估计没人玩了，简单说，不就是建立起一个个人的信息发布平台，然后结交志同道合的朋友，那么，发布什么信息就由博主来控制了，你可以发布文章，我当然可以发布商品信息了，然后通过blog中的留言这些简单的功能，就可以实现团购的目的了。

这样构建的成本非常低，不通过原型，不通过自己的开发，只是通过第三方的blog就可以了，并且要呈现的特征也非常简单和明显。

而Earlyvangelists的获取呢，groupon的创始人也并没有花大力气去获取，因为通过blog呈现出来的特征足以激发起看中“量价比”的Earlyvangelists这些消费者的欲望，并且他们还愿意主动传播，因为人越多，量越大，越能省钱啊。

同时，在这个过程中，groupon也会发现很多问题，并且能够通过低成本的修改而逐渐完善，比方说支付，开源的blog完全可以找一个第三方的支付插件解决。

当然了，团购进入到国内后，因为市场环境和消费者意识上的差异，在后续的发展中就出现了发展路线上的差异，我记得国内的团购网站后来就越来越朝电商平台发展（品类增加，产品丰富，支付，物流自己控制），而国外的依然坚持自己的方向，记得groupon进入中国后（名字叫高朋），很多人就觉的高朋做的很low。

通过这个案例，我想我们应该对MVP的思想有了更深刻的理解，我们不妨再好好体会一下ERIC.RIES对MVP的定义：

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

MVP是一个新产品的版本，它允许团队以最少的努力收集最多数量的关于客户的经过验证的知识。

当然，最后我还是要留一个问题，ERIC.RIES是在《Lean Startup》这本书中提出的MVP的概念，其实他更多的是在指导初创公司（初创公司的三个急迫需求：快速找到客户；快速把产品做出来；快速把业务做起来）如何走好第一步，那么，问题来了，对于那些已经成熟的，有了一定规模的公司，MVP是否还适用呢？

这个问题就留给大家，如果有兴趣，我们可以一起交流，在合适的时候，我会提供一个案例来和大家分享。