B端产品往往因其庞大的数据量和复杂的业务背景，在前期的产品设计方向不能从众多的相互矛盾的“需求丛”包围圈中突围出来，结合公司团队在适量的经济和技术支撑下做到解决主次矛盾，抢先占领高地，再去处理其他非主级别的需求。
作为效率为先工具，B端产品在整体的设计方向上是把不同角色各自的工作任务进行合理的规划重构，实现岗位数据化便捷操作，在大幅提升工作效率的同时还能精确记录各自岗位的数据记录，为后期的业务决策赋能和降低运营管理成本。
业务广泛，相干人员诸多带来的就是业务背景，各自需求的混乱多样，如果将接收到的需求和功能进行合理的规划安排，不仅考验产品经理对产品的把控能力，也是产品能否经受市场竞争的关键因素，需求的满足顺序，侧重点，实现的难易程度，展示的方式，是否有对业务职责进行重设计，实现的成本高低等等都会体现出产品不同的能用性，可用性，易有性，这些特征的体现直接影响着产品是否能赢得市场的争抢。因此，面对B端产品如此纷繁复杂的需求要求，产品经理应当如何去处理呢？
先做最小可用性的B端产品出来，在市场中去体现产品真正的价值——MVP（Minimum Viable Product）
什么是最小可用性产品？
借用一张最经典的例子，如果现在你有一个不知道是否好坏的想法——做汽车，然后你想测试用户是否接受这个想法，那么你是先造两个轮子去测试呢还是先造个滑板车去测试呢？
想造车的目的是为了满足用户有更快的出行方式前提下能获得更好的使用体验，但是这个目标太大耗费的资源很多，如何快速地验证这个想法可行呢？先对车进行核心功能凝结：
获取更快的速度，舍弃一些体验，就这样最终凝结出脚板车，一个最小可以增加人的行进速度而且实现非常简单的初版方案。可能它的使用体验不太友好，速度提升也没那么明显，但它满足了“你”最开始的核心想法：提升用户的行进速度，这才是用户最终愿意为它买单的核心价值。试问你拿4个很豪华的车轮子和脚板车去让用户选择，4个轮子虽然很豪华，外观漂亮，结实，但没什么用，连最基本的用户功能需求都不能满足，不能让用户加快速度！
类推到B端产品也是一样的道理，B端产品有CRM,ERP,WMS,OA...等各种不同类型和场景的系统，但终归是为了提升员工的使用效率，降低企业用工成本，这样企业老板才会为该产品买单付费。对于还不是成熟的产品来说，产品经理需要做的，就是在接收需求之后，无论是通过用户调研，访谈或上司老板提出的要做的功能需求时，要以产品定位为核心，适当对需求进行合并拆分，以围绕产品的核心方向为依据进行重要程度划分，在满足需求的前提下，先做出最小可行性方案，抢先让用户体验在实践中反馈产品存在的问题和需要改良的地方比产品经理自己头脑风暴闭门造车添加了大量用户使用后觉得冗余的功能更易让产品向好的方向去发展。特别是对于B端产品来说，逻辑上的复杂和数据上的交叉，做加法容易，做减法很难。前期将产品做的过于复杂只会限制产品的可拓展性和功能局限性，也就是耦合性过高，导致后期面对公司业务上的调整时不得不另外重新开发系统和搭建数据库去满足公司新的需求而不是在已有的系统中进行改良。
读到这里我想你应该想到了一个问题，我在举上面的那个例子时建立了一个前提，就是我们大家都知道只有4个轮子的车子是不能算一个可用的产品，但有4个轮子的踏板却能够正常使用，所以你能很轻松地把最小可行性进行拆分。设想如果现在你只见过踏板和马，根本就没见过汽车，只有老板或者甲方知道汽车这个概念，并且想让你最终能够完成的产品也是汽车，这又如何去论证该过程中某些想法是否能行得通呢？对应到实际工作中，如果你现在从事的就是一个你接触没有太深入的领域，然后需要根据获取和接收到的需求做方案论证，怎么去拆分最小MVP去论证呢？
简单来说就是先必须让自己熟悉基本的行业内容后，再进行方案论证。可以通过目前公司内部已有的资源，文件，规范或与之相关的东西；询问同事或者上司，老板；了解这个会涉及到的有哪些用户，联系他们，要实际地最好能面对面询问他们工作内容和遇到的问题，如果条件可以，自己实地过手一遍能获取的信息更丰富真实；在基本信息，角色概念清晰后比对竞品也才能看出数据流和功能点之间的关系。在做这些时，一定要随时做好记录和标记，后面整理形成规范的文档，无论是功能版本迭代还是需求取舍都能获得参考立足点。这样，行业基本的信息情况将尽可能地系统性性掌握，那么最小MVP也能顺利地实施下去了。
MVP中的核心要素就是：梳理出任务的核心流程，并能明确每个流程对应着有哪些角色和操作。
在前期你通过多种途径熟悉业务背景和需求的采集后，此时你心中可能有N多想法，但是，一定要围绕着梳理出的核心流程，将功能合理分配到对应的流程和角色上，每一个功能和角色所能操作的数据在你添加时都要考虑到是否会偏离核心流程，结合2/8定律，面对多种情况下举棋不定时选择最通用的一种情况先进行开发，处于孵化中的产品在初期不建议把现实中即使存在的但使用率不高的其他情况也开发出来，不仅不利用后面其他功能的设计，也对未来产品上线后反馈存在真正的需要优化之处可拓展性变弱，这其实还是在说MVP这回事，但在实际工作中时，它无处不在，不只是产品大的方向上，就小的功能，分支情况，可编辑可操作的数据等的聚舍都是一次次在套用MVP方法论。
另外，在产品的设计过程中，无论是大方向上的迭代还是细节功能上的取舍，犹豫不定时都是自己对于业务背景的熟悉程度没有细致入微，你无法判断做了与否对于用户会带来多大的影响。犹豫的过程不仅浪费时间，而且后面如果遇到争议时也没有足够的底气去面对。可以看到，需求理解的层次在很大程度上是你对业务背景理解是否足够细致。当理解了业务背景后在面对接收到的需求时就能轻松地明白需求对应的需要设计开发的功能是什么，会关联到的角色并与之带来的影响都会自然地在脑海中一一流动。
这是作者目前在工作过程中，实地探索过来的一些并十分有效的经验教训，可能总结还有梳漏之处，希望能给大家在工作或学习中带来帮助或灵感。
