MVP已死，有事烧纸？

早些时候，我曾经写过一篇文章《这就是MVP的感觉，产品管理如何应用MVP的逻辑》，这次写这篇文章，可能有些朋友会笑话我说这不是自己打自己脸吗，上个系列还在讲MVP，这篇文章就要贬MVP，各位，你们还真是错怪我了，我在上一个系列中从来没说过MVP好还是不好，只是介绍了一下产品管理和MVP是如何结合的，至于真实效果如何，真的和我没关系啊。

那么，为什么这篇文章要起这样一个耸人听闻的标题呢，一是没法，不做回标题党，估计打开看这篇文章的朋友不多，二呢，则是昨天文达兄弟在二群里抛了个问题，我觉的值得探讨一下，大家看下图：

本来应该在群里探讨一下的，但是倒霉的是，网坏了，今天才修好，我想还是写篇文章来说说我的一点想法吧。

在上一个系列中，我提到了，MVP是什么呢，如果简单用一句话来概括的话，就是：

通过尽可能少的事务获得尽可能多的客户知识。

如果用MVP的提出者-ERIC.RIES-的定义的话，就是：

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

在这个定义中，有三个关键点，分别是：

最少的努力（the least effort）：简单说，就是指有利于减少资源浪费，降低投入风险的工作，这是MVP的形式。

验证的知识（validated learning）：简单说，就是指企业和Earlyvangelists在不断的互动关系中逐渐达成一致的有关Earlyvangelists的信息，这是MVP的目标。

最多的数量（the maximum amount）：简单说，就是指和Earlyvangelists有关的知识的最大可能的集合，这是MVP的结果。

备注：

Earlyvangelists，MVP中专有的一个词汇，由Early Adopter + Internal Evangelist构成，是指那些对你的产品的未来充满了信任和期待，并愿意作为你的客户伙伴一起来做这个产品的那群客户。

其实我们只要好好理解MVP的定义，就知道RIES为什么要提出MVP了，因为他作为技术出身，最怕的是什么呢，就是最终出现“Throwing away working code（徒劳无功的代码）”的情况，当然，所有的程序员都怕这个。

但是站在咱们产品经理的角度看，为什么会出现这种糟糕的结果呢，其实和我们以往的产品构建模式有关系，以前是怎么做的呢，大致就是确定一批问题，然后做一个版本，但是，问题来了，我们不是拿不到用户的问题，而是我们很难在产品正式发布之前就验证这些问题的真实性到底如何。

因此，矛盾就出现了，要验证问题的真实性，那么，必须在产品发布以后，但是，产品一旦发布，如果问题缺乏真实性，那么，产品就面临失败的风险，因此，RIES就提出，MVP的基本逻辑就是：

通过提供最小特征集的产品版本，不断验证客户最大量问题的真实性，最终实现PMF（Product-Market Fit）。

好的，关于MVP就简单说这么多，咱们再回到文达兄弟提的那个问题，为什么他们的MVP搞掉了公司80%的销售资源。

其实，我觉得这个问题可以这样来理解：用掉公司80%的销售资源在MVP上是否正常？

那么，是否正常呢？

我还是先说一下，我会从哪些方面来分析这种情况：

1、我们在选择目标人群的时候，是否选择的是Earlyvangelists？

这是一个关键，一般来说，Earlyvangelists的量不会太大，并且他们也有一些明显的特征：非常信任你的公司和产品；愿意和你一起来做这个产品；对你的产品具有包容心。

因此，首先，我们要从你的目标客群里识别出哪些是Earlyvangelists，然后向他们投入必要的销售资源。

如果是让销售团队撒网去做，那么，这就违背了MVP客群的定位。

2、MVP是否是以最小特征集MFS（Minimum Feature Set）的形式呈现的？

MVP是产品的一个版本，但并不是一个线性迭代的版本，而是以呈现“特征”为主的特定版本，简单说，就是MVP的版本是把具有商业价值或明确定位的特征呈现出来的一个版本。

RIES就举过一个例子，他的一个朋友想做一个企业信息化系统，当时在市场上，这类产品都是功能繁杂，操作繁琐，界面一堆的产品，而他这个朋友想反其道而行之，要做一个极简的系统，那么，这样反定位的MVP的“特征”是什么呢？

就是“简单”，这个一点明确，那么，MVP的第一个版本就知道怎么来设计了，比方说在UE上，如何体现这样的定位，就成了设计原则，而功能什么的，反而不是主要的，因为这个MVP的特征要呈现的是“简单易用”，而不是“功能强大”。

因此，文达兄弟应该再评估一下，目前这个MVP是不是一个呈现了新产品特征的版本，如果是，那么，再分析一下，是否可以再对符合产品定位的特征进行缩减，用不断迭代的版本来梯次呈现特征集，而不是一次性发布，如果不是，那就要多做一些工作了，特征和功能是既有联系，又有区别的两个概念，如果MVP的版本中承载了太多不痛不痒，无法呈现特征的功能在里面，那势必造成MVP的臃肿，以及开发周期的增加。

同样，对于销售团队来说，一个无法让Earlyvangelists眼前一亮的MVP，是会大大加大销售成本的，大量的销售资源就会消耗在我们和Earlyvangelists的你来我往中，总之，阵地战，是最消耗资源的一种战法。

3、MVP的流程是否影响了销售的投入产出比？

这是MVP的大致流程：

我们可以看出，MVP在企业内，并不是属于哪个特定的业务体系，而是三大体系都有涉及，对于研发体系来说，MVP或许就是把能呈现最小特征的版本做出来，对于营销体系（前期主要以销售团队为主）来说，MVP就是取得Earlyvangelists信任，并有机会拿下单子的承载物，当然，对于咱们产品体系来说，一方面需要向研发说明产品的定位，以及MVP的特征都是哪些，另一方面需要通过销售团队的工作，不断验证我们在产品中的假设是否真实。

但是，在这个过程中，我们做这些工作总得有个关键点，是哪个呢？就是：签署LOI。

也就是意向文件，尽管LOI不是正式的法律文书，但是对于MVP来说，有四个价值：

1）了解这些潜在消费者对这个产品真实的态度；

2）把这些潜在消费者转化成为产品提供需求的输入端；

3）了解这些潜在消费者对产品的价格、竞品的态度；

4）在正式产品发布后，潜在客户可以迅速转化为现实客户，并让这些客户称为传播者。

RIES那帮人也讲到了，MVP很大程度上其实就是客户开发（Customer Development），而不是向客户开展正式的销售。

因此，作为产品经理，我们在做MVP的时候，一定要定一个LOI的量，也就是销售能签到多少LOI就可以进行下一步了。

这就像我们用花洒洗澡，如果在出水管上不安水龙头行不行，当然行，但是水就会一直流，本来用20升水就可以洗一个澡，但是就因为没水龙头，结果用了30升水，但是效果一样，还浪费了水。

因此，LOI就是这个水龙头，要去控制出水量，达到某个既定指标，就需要用水龙头去控制一下，否则，再投入销售资源，很大程度上就是一种浪费了。

毕竟我们是产品经理，要聚焦整个流程，以及对应的产出比指标上。

总结一下，我分析出现文达兄弟这样的情况，可能就是在：

MVP的目标人群：应该以开发Earlyvangelists为主；

MVP的呈现形式：应该以最小特征集（MFS）为开发基础；

MVP的过程指标：以意向文件（LOI）为核心销售指标。

上出了一些状况，当然，我只是从战术操作层面来分析的，如果可能涉及到更高的层面的，我就不能瞎说了，毕竟不了解企业的情况。

好，我们回到文达兄弟的问题上：

用掉公司80%的销售资源在MVP上是否正常？

我的观点是：

这里不能简单的用正常与否来评定，而是要看是否实现了文达兄弟设定的的MVP具体的目标，这些目标可能包括以下其中之一：

1、是否验证了假设问题的真实性？

2、是否获得了既定LOI的数量目标？

3、是否获得了一定数量的Earlyvangelists？

4、是否在逐渐消除正式版本的某些风险？

如果确定实现了其中的某个目标，那么，用掉多少销售资源就是一种正常的情况，当然，前提是我们在开始销售MVP之前，是对销售资源的投入有明确核算的，当然，这个就不仅仅属于MVP的范畴了，所有的产品都要核算的。

关于文达兄弟的这个问题，我就说这么多，但是为什么这篇文章的标题是“MVP已死，有事烧纸”呢？

其实是因为这段时间以来，又看到了国外一些质疑甚至是反对MVP的观点，我觉的很有意思，等我有时间了，我再针对MVP补充一篇反对观点的文章。

当然，对于我个人来说，我其实并不在意谁对谁错，我不说过嘛，产品管理的世界，没有二分法，所有的观点都可以成为我们自己不断完善个人产品管理知识体系的素材来源，从而能够让我们更好管理好产品，服务好企业，并让自己不断的成长，成为一个真正意义上的产品管理者。