如何定义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主要是采购人员，销售人员，库管人员，如果我们能够抽象出目标用户的用户肖像，包括主要性别，教育水平，喜好，使用系统的场景等，对产品功能定义以及设计会非常有帮助。

比如说人事系统的主要使用用户是女性，为什么现在没有一款人力资源管理系统的页面风格是偏女性喜欢风格的呢？如果有，一定让人眼前一亮。

CRM的销售人员办公一般处于移动场景中，那么相关功能在移动端的友好度，就很重要的。如果用户一直坐在PC面前，移动端就不是那么重要的。要解决什么问题对于定位的要解决的问题，一定要简单直接，我们看一些定位相对比较好的例子：

机场扫地机器人

中型企业的招聘管理

中大企业招聘官网搭建工具

零售行业的顾客管理系统

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

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

** 最近看到一个可行的获得种子用户的方式是帮助其做代运营，笔者看到不少面向餐饮，培训，房产中介创业做赋能业务的创业公司，前期都是通过线上代运营的方式来开始的。创业公司通过线上代运营快速产生现金流，活下去，同时找到客户真正的痛点以及操作方式，后面可以再用产品解决方案来将其自动化，这样的路径很符合精益创业的理论。****3: 确定产品路线** 确定种子用户以后，就可以跟客户沟通来确定产品的路线，比如说公司的目标定位是对标Workday，或者Salesforce，那么一口气开发出Workday或者Salesforce的大部分功能然后上线无疑是很愚蠢的行为，这个时候就要将目标进行拆解，确定产品的演变路径。关于MVP的演进路径，原来网上有一张很著名的图，如下：

image

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

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

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

在上一篇文章“如何定义B端产品MVP(上)”里面，我们谈到了定义MVP产品的前面三个步骤，确定产品定位，找到种子用户，确定产品路线，今天我们再来聊聊后面的几个步骤。1: ****确定用****户业务****流程****图 在产品路线确定完成之后，基于产品定义的路线，我们要基于业务目的来确定用户的业务流程图。 还是拿人事模块来进行举例，几个关键的用户业务流程图就包含比如说：员工入职流程，员工合同管理，员工异动流程（调职），员工离职流程等等。

确定用户使用流程图的目的是为了保证产品能够对各个角色的日常业务进行支持，在梳理的时候尽量完整，不要遗漏，也是为了后面梳理每块业务功能点清单以及定义优先级做好准备工作。这方面的文章也很多，笔者就不细说了。

2:****确定功能点清单基于产品的用户使用流程图，确定每个功能的线上功能点清单，类似下图所示：

image

在定义完成每个流程的功能点之后，要做一件事情，就是要确定哪些功能点事放在线上来实现，哪些功能点还是要维持线下的方式，这个也是很重要的一个步骤，可以参考一下如下的原则：

· 线下处理极其灵活，没有什么规则，也很难通过梳理将目前的业务逻辑规范化的流程或者功能建议线下处理。

要知道软件的一个基本原则就是建立一套标准流程或者自动化的规则，如果线下处理极其灵活，很难将规则标准化，那么这样的功能是不太适合做成标准产品功能的，留一点标准的通用口子给到客户，让客户线下处理，将数据输入线上就可以了。

 举一个例子，在薪资里面为什么有那么多税前调整项，税后调整项目，就是各种各样的情况太多，无法标准化，就留了一些口子给用户而已。

· 线下处理比线上处理要方便很多的情况

每个业务流程如果你严格的去梳理功能点，发现会有各种各样的情况需要进行处理，这个时候非常考察B端产品经理化繁为简的能力，打一个大家都会碰到的公司里面请假的比方吧，会有很多人考虑设计如下的功能：a:如果员工申请了休假，老板还没有批的时候，是否需要一个撤销功能，让员工可以撤销可以提交已经申请的单子啊？b:如果老板长时间没有审批，是否要设置一个几天自动审批通过的功能，不同公司默认审批通过，审批拒绝是否还要设置一个参数啊？c:如果申请休假，老板拒绝了，是否可以支持在原来的单子上面直接修改之后直接提交啊？

  说实话，现实中笔者特别怕碰到这种逻辑严谨，又没有梳理能力的产品经理，不断的增加功能点，**而增加的功能点会带出很多其他的特殊情况，导致越来越复杂。**实际在MVP阶段，这些场景线上统统不需要支持，**但是要保证的一点是这些场景发生的时候，业务不至于开展不下去。**

  事实上MVP阶段只要保证支持最基本的业务流程，员工可以提交请假，老板可以审批通过或者拒绝，上次这三种情况前期都可以支持，对于场景a，你跟老板口头或者微信说一下，让他拒绝就解决了。对于场景b，不好意思，老板这么久没有批，现在通讯这么发达，可以微信跟老板说一声批一下就好了。对于场景c，老板拒绝后，你重新提交一张请假单子，输入日期和选择假种有那么大的工作量吗？

3:****确定功能点的优先级确定功能点的优先级一般来说需要依据如下几个维度：

· 基于功能需求的****强****烈度

判断功能需求的强烈度，用户痛感强烈程度的指标是很重要的维度，比如说员工入职流程是否要支持员工自助入职（员工输入自己的基本信息），如果对于一个中小公司来说，一年也没有几个新员工入职，那么这种信息的输入完全放在HR端进行输入就可可以了。员工自助入职功能根本不需要，或者很后期才考虑就好。

   如果目标客户是针对特大客户，每天新员工入职的量是很大的，如果这个是客户一个提升效率的主要诉求。那么前期的优先级就需要提高。**切记所有的考量都要基于产品的定位以及业务场景，是任何判断的一个基准。**

· 基于功能使用的****频****率

频率也是功能优先级一个重要的指标维度，比如说组织架构调整的调整，有些公司可能一年都做不了一次组织架构的调整，那么组织架构调整的功能就可以优先级不要那么高。笔者曾经看到一些项目的设计，前期就考虑了很多非常极端低频的事务处理。前期在极端情况****处****理的开****发****上面花****费****了大量****时间****，最后****产****品开****发****周期极其****长****。另外在****产****品****设计****上面，极端****case****的****处****理也揉在了正常流程中，****导****致****产****品极其****难****用。实际上这些极端低频的功能几年都用不了一次，完全可以放在后期。另外前面一些年刮起了****B****端一切功能移****动****化的****风****潮，将很多低****频****使用，或者大多****时****候是用****户****坐在****PC****面前使用的功能移****动****化，****实际****上没有人用，浪****费****了很多人力物力，也因****为****复****杂****的功能****让****管理系****统****的移****动****端疲****惫****不堪，体****验****极差。在移动化如此盛行的今天，笔者想问您一句，您真的需要将功能移动化吗？功能点的取舍是考验产品经理水平的一个很重要的衡量标准，不同的****产****品定位，不同的公司****资****源，不同的****团队****能力，同****样****的****题****目的最佳答案一定是不一****样****的。

· 避免过度设计

有些产品经理考虑问题因为还是比较窄，也由于没有技术背景，不太了解不同设计对应的开发工作量，经常容易过度设计，那个提出app皮肤要根据手机壳颜色进行适配需求的产品人就是一个很典型的例子。 我也举一个非常简单的例子，在进行员工或者客户信息维护的时候，经常有员工或者客户的地址需要进行维护的情况，有些人有一个地址，有些人二个，最多有些人三个地址，于是可能有些产品设计很自然就设计对地址进行行级支持，支持无限添加扩展。如果最极端的情况是三个地址，你的产品定位又不是需要支持全世界大客户，类似sap的定位。用列级支持最多三个地址就够了，开发工作量小，对于用户来说前端也挺易用。 整体来说，基于产品定位，业务场景，团队情况对于大小问题化繁为简，设计最佳，最简路径是非常重要的。通过上下篇这些步骤，希望可以帮助大家定义出一个B端产品的MVP功能。也欢迎大家留言讨论！