如何定义好B端产品的MVP(上）

MVP是Minimum Viable Product的缩写，意思是最小可行产品.最近几年在移动互联网时代，在TO C产品研发以及推向市场的时候，这个概念很是盛行。说说比较有名的二个例子：

一个例子是Zappos，创始人Nick为了证实人们有网上购买鞋子需求的想法，在一开始先到当地的专柜去拍鞋子的照片放到网上，如果有人下了单，他就跑去店里购买。这样，他一开始并没有仓储的压力，也不需要投入成本去搭建一个真正的电商平台。2009年Zappos被Amazon以12亿美元的价格收购。

还有一个例子就是Dropbox, 刚开始创始人也不知道Dropbox是不是被大家所需要，所以先拍了一个视频，视频主要是演示Dropbox所能解决的痛点以及使用场景，之后把视频放到Youtube上面，很多网友通过视频来到Dropbox网站留言表示了强烈的使用意愿，也正是这2分多钟的视频为Dropbox带来了上千万的用户。

大家看了这二个例子，是否发现了一个问题，C端产品，特别是一些创新的商业模式因为有很大的未知数，所以前期MVP最重要的目的是验证需求是否存在，商业模式是否成立？基于这个验证的需求来实现最简的MVP,然后慢慢迭代开发演变。

但是TO B的产品和TO C的场景有很大的不同，TO B的业务要复杂很多，对比To C需求也要确定很多，除了少数完全创新性的To B产品以外，大多数TO B产品的MVP不是为了验证需求是否存在，而是让产品用最小的代价最短的时间面市，从而可以让产品的研发可以让用户需求来进行驱动，避免闭门造车的尴尬以及产品出来之后和客户期望南辕北辙的风险。

那么TO B的产品应该怎样来定义MVP呢？笔者建议遵循下面的步骤来定义B端产品的MVP。

1. 确定产品定位

定位主要要确定三个问题，客户是谁，用户是谁，要解决什么问题。

客户是谁的问题，一般来说，有二个维度需要考虑，一个是行业的维度，一个是规模的维度。

所以笔者的一个原则，同一个业务，针对不同规模的公司的解决方案，长期来说是要分产品线的，如果不分产品线，是很难竞争过有针对性的竞争对手的。什么客户都支持，实际上就是没有想清楚目标客户定位。

在确定了客户是谁之后，我们要进一步了解用户是谁。 比如说人事系统的用户是HR,CRM的用户主要是市场和销售人员，ERP主要是采购人员，销售人员，库管人员，如果我们能够抽象出目标用户的用户肖像，包括主要性别，教育水平，喜好，使用系统的场景等，对产品功能定义以及设计会非常有帮助。

比如说人事系统的主要使用用户是女性，为什么现在没有一款人力资源管理系统的页面风格是偏女性喜欢风格的呢？如果有，一定让人眼前一亮。在我的前一篇文章“To B SaaS软件如何才能像To C一样极致易用？”也提到过怎样基于用户来设计极致易用的B端产品，大家可以参考。

CRM的销售人员办公一般处于移动场景中，那么相关功能在移动端的友好度，就很重要的。如果用户一直坐在PC面前，移动端就不是那么重要的。

对于定位的要解决的问题，一定要简单直接，我们看一些定位相对比较好的例子：

一个原则就是说明文案都是大家都能理解的名词，不能有需要解释的名词，比如说你现在说我要做一个滴滴打人的产品，大家现在能理解，但是如果在滴滴打车出现之前，你说滴滴打人是你的定位，就没有人能够听懂. 现在很多公司在说明自己定位的时候，很喜欢加上新零售，人工智能，生态，入口这样的字样，很多时候让人越听越糊涂，这些本身意义很含糊宽广的字样会让其定位更加模糊。 整体来说公司定位需要极其简洁，不能长篇大论，最好15个字以内，如果太长，请简化之。

2. 确定种子客户

在产品正式开发之前，最好可以基于团队的资源以及产品定位的说明，尽早找到一些符合自己定位的种子用户（有时候在后期等产品原型设计完成后，再来说服种子用户）。如果种子用户很难找到，或者很难被说服的时候，很多时候要反思产品定位以及通过更多的用户调研，从而找到更精确的公司客群以及产品定位。

最近看到一个可行的获得种子用户的方式是帮助其做代运营，笔者看到不少面向餐饮，培训，房产中介创业做赋能业务的创业公司，前期都是通过线上代运营的方式来开始的。创业公司通过线上代运营快速产生现金流，活下去，同时找到客户真正的痛点以及操作方式，后面可以再用产品解决方案来将其自动化，这样的路径很符合精益创业的理论。

3. 确定产品路线

确定种子用户以后，就可以跟客户沟通来确定产品的路线，比如说公司的目标定位是对标Workday，或者Salesforce，那么一口气开发出Workday或者Salesforce的大部分功能然后上线无疑是很愚蠢的行为，这个时候就要将目标进行拆解，确定产品的演变路径。 关于MVP的演进路径，原来网上有一张很著名的图，如下：

意思说就是如果要造一辆车，MVP的演进路径应该先造一辆滑板车，然后是自行车，摩托车，然后是汽车之类的。笔者觉得这个在TO C产品是可以这样设计产品路径的。如果在TO B产品里面这样设计产品路径，笔者觉得就是滑天下之大稽了。为什么呢？因为B端产品业务以及逻辑极其复杂，最重要是架构的搭建，如果按照这样的演变路径，每一轮产品基本上都是上都要推翻上一轮的产品以及设计，这在B端的产品里面是不可接受的，从客户体验的角度也是不可接受的。

如果还是拿汽车来举例子，正确的方式可能还是先要有一个可以能动的汽车的框架出来出来，但是很多功能可以缺失，后来再慢慢增加比如说雨刷，多个座椅，转向灯，后备箱，导航等功能，但是需要保证增加后续功能的时候不能推翻原来的设计。

对于特别复杂，开发周期长的产品，通过巧妙的设计产品路径，分批上线，从而可以避免闭门造车的尴尬局面以及风险，快速上线产品也能够给予客户信心。而这些，对于创业公司都是关系生死的问题。

在下一篇文章，我们再来讨论一下B端产品定义的后续步骤，关于业务流程图定义，功能点梳理以及功能点优先级定义的原则。

作者：李东林（微信公众号：SaaS产品说；微信号：jianguzhuxin），原ADP大中华区产品负责人，14年To B研发与产品设计，团队管理经验，主导过多款大型企业管理软件的设计、研发、上线，也有过2年移动互联网TO C的创业经验，欢迎大家加我微信交流。