(原则)如何定义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。
行业的维度，如果是支持通用行业，或者只是某个特定行业，所需要的产品功能以及产品采用的设计是非常不同的,如果是通用行业，产品的可配置性要远远大于只是针对特定行业，但是针对特定行业的产品可以基于行业特点，设计很多贴身的功能。
规模的维度也是一个很重要的维度，比如说跨国公司，本土大公司，中型公司，小型公司，不同规模，地域的公司所需要的产品功能会有很大的差别。一般来说，大公司的业务复杂度很高，如果将大公司的产品给小公司来用，产品易用性很差，培训实施周期太长，这些都是中小企业很难接受的。
所以笔者的一个原则，同一个业务，针对不同规模的公司的解决方案，长期来说是要分产品线的，如果不分产品线，是很难竞争过有针对性的竞争对手的。什么客户都支持，实际上就是没有想清楚目标客户定位。
比如说人事系统的主要使用用户是女性，为什么现在没有一款人力资源管理系统的页面风格是偏女性喜欢风格的呢？如果有，一定让人眼前一亮。
机场扫地机器人
中型企业的招聘管理
中大企业招聘官网搭建工具
零售行业的顾客管理系统
在产品正式开发之前，最好可以基于团队的资源以及产品定位的说明，尽早找到一些符合自己定位的种子用户（有时候在后期等产品原型设计完成后，再来说服种子用户）。如果种子用户很难找到，或者很难被说服的时候，很多时候要反思产品定位以及通过更多的用户调研，从而找到更精确的公司客群以及产品定位。
意思说就是如果要造一辆车，MVP的演进路径应该先造一辆滑板车，然后是自行车，摩托车，然后是汽车之类的。笔者觉得这个在TO C产品是可以这样设计产品路径的。如果在TO B产品里面这样设计产品路径，笔者觉得就是滑天下之大稽了。为什么呢？因为B端产品业务以及逻辑极其复杂，最重要是架构的搭建，如果按照这样的演变路径，每一轮产品基本上都是上都要推翻上一轮的产品以及设计，这在B端的产品里面是不可接受的，从客户体验的角度也是不可接受的。
如果还是拿汽车来举例子，正确的方式可能还是先要有一个可以能动的汽车的框架出来出来，但是很多功能可以缺失，后来再慢慢增加比如说雨刷，多个座椅，转向灯，后备箱，导航等功能，但是需要保证增加后续功能的时候不能推翻原来的设计。
更多文章请长按二维码关注我们，实时了解最新SaaS产品技术深度分析：