产品经理在日常工作中可能时常要接触MVP概念，因为在实际业务里，产品经理需要通过拆解MVP来验证产品的可行性。那么，这类MVP思想或者敏捷迭代的思想，是否适用于大型B端项目或者传统IT项目？小步快跑、快速迭代的概念在什么场景下还能适用呢？

01

最近在复盘梳理内部的一些产品发展历程，发现有一段时间我们的产品迭代流程特别有意思。

我目前在一家以卷和快速迭代著称的互联网公司，做一款传统行业中各类线上化工具都很成熟的一个行业新产品。当时有一家和我们深度合作的公司，历史用的另外一家行业内知名度和成熟度很高的产品。出于战略的一些诉求，我们不得不将仅研发了三个月的软件给到这家公司使用，当时整体的产品完成度只有10%不到。

而我们要面对的用户群体，是一群线下作业场景复杂，综合素质比较一般的用户群体。可想而知，硬着头皮上的结果就是所有人都很累。

在做一个B端产品的时候，首先要考虑的是，如何将一个产品做的符合业务诉求，达到降本增效的目的。而当时的我们，不仅没有达到这个目的，反而因为系统的不完善，额外给我们的用户群体增加了许多麻烦。

比如，当时需要用户在录入某些信息的时候双系统录入，某些业务流程在两个不同的系统之间切换。与此同时，我们也面对着大量的吐槽，诸如为什么系统不完善就让使用，之前的系统那么好用为什么要切换。这个系统是多么多么的烂等等。

再后来，因为系统的不完善，我们把这个试用阶段拖得很长。为了让这家公司更早的用到我们自己的产品，我们除了在疯狂的加班赶产品的同时，还需要改一些之前为了让他们更好的试用做的一些临时的逻辑或者功能。而这些功能，本来是不需要做的。

那最终的结果如何呢——这段长达半年的试用期，对我们产品的改进没有任何的作用。

主要是几个原因：

1. 历史功能的不完善，导致我们没办法发现全链路上的问题，这些问题往往才是决定性问题。
2. 我们不仅要让他们快速的试用，还需要让他们快速的切换系统，所以在试用期间我们还在疯狂的卷功能。即便真的有些用户有问题，因为优先级的原因也排不上。
3. 一些临时的能力，以及断掉的业务流程，让用户根本没办法正常的使用产品，加之旧系统也没有关闭，所以很多的用户都不去试用，而我们竟无法反驳。

那这次试用有没有收获呢，肯定也是有的，让我们知道了做这么一款复杂的产品，草率的试用，不仅影响客户的体验，也影响我们的工作状态。

回过头来再看这段经历，会发现当我们以一个互联网敏捷迭代的视角去看某个大型B端项目的从0到1 的建设，这种设想本身就有很大的问题。

一个传统行业的复杂IT项目实施可能是需要经过数年的研发，以及详细且周密的项目实施流程才能完整的交付。而所谓的敏捷迭代或者MVP的思想，完全不适用于这种场景。

02

一个产品经理的基本能力不就是如何拆解MVP，来验证产品的可行性么。那为什么我会说现在的产品已经没有MVP了。

其实还是现在的互联网行业，垂直赛道的SaaS行业太卷了。目之所及，都是红海。你所能想到的点子，基本上市面上都有着可以参照的竞品。当你希望以最小可行性方案去验证市场时，你会发现市场上充满着比你功能完善，价格还优惠，实施流程还贴心的产品。你会发现你一个粗糙的产品根本没有出路。

所以这个时候，所谓的差异化竞争，是在你必须具备基本的闭环逻辑下之外的竞争。半成品的产品，基本没有出路。你说你某个功能做的特别好，体验最佳，行业顶尖。但是这个产品该有的其他功能都很粗糙。那不好意思，基本上不会有人买单。

03

不仅是B端，在互联网产品以及软件行业高度发达的今天，任何产品都面临着这样的问题。

我比较喜欢研究一些笔记类的软件。市面上的很多笔记软件都使用过。我很多产品，很多功能都逐渐趋同。比如，当notion大火后，各大笔记软件基本上都跟进了notion的一些产品思路。比如以块的形式作为承载形式。“/”键可以新增内容等等。除了一些像素级一样的软件某lai，某us等，语雀和飞书这种本来体验就不错的协同文档类的软件也跟进了这种交互。

作为一个笔记类的软件，难道不能能写，能记录就可以了吗。这种能力，明显不是一款笔记软件的基本能力，不符合一款产品最小可行性方案的逻辑。但如果你没有这些，你可能刚投入市场就失去了很多的竞争力。这也是为什么，最近几年虽然各类笔记软件层出穷，但恨不得一出来就给你一个王炸，各种知识网络，多维表格等等功能一股脑的全部都整上的原因。

04

那什么场景下，这种小步快跑，快速迭代的思路还适用呢？

从单独产品的视角来看，我觉得很难有出路了。需要以一个另外视角去看。你能给你的客户带来哪些新的价值。这些价值如何能转化成产品的一些能力，以及你所能提供的服务是不是独一无二的。

我曾经在一家外卖公司做过一段时间的企业服务。当时我们提供给客户的第一版产品也很粗糙。基本上只可以点单，充值，对账，开票等等这些都不满足，只能线下操作。

但我们还是谈了几家客户。因为在当时的那个阶段，只有我们能给他们提供这种服务。不仅如此，在和他们签约的时候，我们还没有开始研发产品，一切从零开始。

回到第一个例子。为什么我们当时的产品那么烂，客户还是在半成品的情况下试用我们的系统并且最后硬着头皮切了呢。其实也是因为这次合作我们不仅仅卖的是软件，还是一整套的服务体系，这个产品只是其中的一项。我们带给他的收益，要远高于切系统的成本。且需要和我们合作，就必须得切系统。

所以这个时候，MVP已经不是单独站在产品的视角了，而是一整套服务体系。你能提供给客户的服务是什么，这个服务下，有哪些环节的必须的，这些必须的环节里面，软件服务是不是必不可少的一环，没有软件能不能走的下去。

这两个例子下，点餐服务场景中，最小服务闭环是，我可以点餐。这个即是我服务体系的MVP，所以只要我提供了一个点餐系统，你这个服务系统就可以运行起来。

提供作业系统的这个场景下，最小的服务体系是我们所提供的一种交易模式，这种模式短期可以先通过临时的方案跑着，而为了更精准和更及时的监测到我们的收佣，以及通过一些产品能力去赋能客户，软件是我们可以逐步迭代的一个能力。所以这个时候，产品将不再是这个服务体系内的MVP，而是到了某个阶段必须要用到，不可或缺的工具。这个时候，我们根本不需要去验证它的市场反馈程度。因为MVP已经走完了。

C端的逻辑也是一样的，当一个抖音跑出来了，用户需要的不是另外一个抖音，而是能给用户提供不一样服务的短视频产品。腾讯连续上了十几个类抖音的APP都没有成功，反而最后的视频号有了一些起色。那是因为在和微信以及公众号的深度结合中，视频号找到了自己差异化的定位。

如果以传统的MVP思路，腾讯的十几个短视频APP都没毛病，快速的投放一些产品验证市场。但这样，只能被市场淘汰了。