权衡，这个词贯穿了产品经理的职业生涯。

每逢遇到了做决策的时候我们总说“价值导向”，但当这个词所涉及的组织和角色几何式上升，各方的着眼点及利益点都不同，我们应该满足谁的需求，资源又该向谁倾斜呢？

在B端产品的链路中，规模越大，组织和角色也越多。对于权衡，是很好的实践案例。

在全心投入B端产品的这半年，在这方面也有了些更深的认识，本文将以B端产品设计为例阐述对权衡的理解，希望能给大家一些帮助。

一、什么是B端产品？

B端产品，其使用对象是企业或者组织，用于提升效率、效果等某一特定领域的问题。对比C端产品，其受众不再是个体而是一类群体，并且与业务的连结也更为紧密。

B端产品的产生主要源于企业的规模化，组织结构增多、分工也愈加明细。链路的加长却使线下运行的成本逐渐增高，无法使边际成本真正地降低。

将业务简化、线上化、自助化做到降本增效，也正是B端产品的作用。

另一方面则是由于市场成熟，业务模式的趋同。同一片红海不会只有一艘轮船，无论是为了保持先发优势还是想后发制人，很关键的一点在于运营的效率。

效率的提升，能让我们更高效的管理、更敏捷的试错，从而更迅速的寻找优秀的业务模式。

二、如何进行B端产品设计？

2-1、梳理业务现状，确立产品定位

产品经理需要有很强的角色转换能力，对于B端产品而言，也称之为业务感。

设计B端产品需要将自身代入业务流程的每一环，对业务的现状进行调研以及梳理。

调研的主要目标如下：

1）业务是如何运作的？

2）运作过程存在什么样的问题?

3）哪些问题已经被解决了，是谁在解决？

4）目前已解决的问题是否符合该业务部门、实施部门的规划以及预期？

5）未解决部分不解决的原因是什么？

6）适不适合由你的团队来解决？

7）投入和产出是否匹配？

设计B端产品，大多会改变旧有的业务运作模式，可能是运作环境、运作流程亦或承载团队。过程中会面临无数的抉择，我们需要慎重考量变更的收益能否抹平变更的成本。

在调研时应覆盖链路不同环节的角色，不能只偏重于业务部门，还应考虑协作部门。其次不应只调研一线执行人员，还应调研负责人的预期。

在调研清晰后才能确立产品的定位，它能面向什么角色提供什么支持。产品毕竟是权衡后产物，只为自身创造的价值不能称之为价值。

2-2、优化并确定业务流程

在上一步骤，通过调研企业中各部门、系统的业务流程，经过分析、评审确定了其中不合理的环节，下一步则是优化并确定核心流程。

跨职能流程图的一轴为部门及角色，另一轴多为阶段，下图是以用户运营系统为例绘制的跨职能流程图：

绘制业务流程目的是表达业务的流向，表现业务部门的业务关系以及作业顺序，描述链路中起点、操作以及终点。

至于使用什么工具、横纵的规范、设计的细节其实并不是特别重要。

2-3、根据产品使用角色进行需求分析

B端的产品的需求，基本都来自于真实的业务场景，换言之，这些需求都是具有实现价值的。

但也正因为是真实的业务，所以需求会牵涉许多部门、角色。链路的加长，会使“要不要做？什么时候做？怎么做？做到什么程度？”这类问题复杂了无数倍。

在这一方面笔者的做法是通过梳理系统角色，从角色出发来权衡需求。

与平台相关的角色，可以粗略的划分为决策者、直接使用者、间接使用者。

其具有以下特点：

在进行权衡时，价值导向是第一位的，但由于不同角色需求的产出价值是波动的，所以并未在上图中表现。

在需求分析时，我们应根据其产出的收益决定资源的倾向、产品设计的深度。其次则是根据角色的代表、使用的场景、关注重心决定产品设计的侧重点。

1）决策者

决策者的主要代表是业务负责人、平台负责人、协作负责人，他们是决定是否使用这个平台的人。虽说价值产出会抖动，但决策者的需求优先级大多在第一顺位。

其关注的重心是边界以及收益，边界是指业务流向是否正确、人力损耗是否减少，收益则是否正向、是否达到预期。

直接和间接使用者，更侧重于局部的价值，而决策者则更侧重于全局，在产品设计上我们须考虑的是决策者的全局视图。

2）直接使用者

直接使用者首要的代表是业务运营，他们是产品发展的中坚力量。

其对产品的依赖性越高，产品创造价值的可能性才越大，业务运营的需求优先级略低于决策者，但大多数情况高于其他的角色。

在需求分析上，由于业务运营的需求零散且差异性高，我们需要提炼业务的共性，牺牲较为定制化的逻辑，对平台而言，全局效率的提升会比个别业务的体验更为重要。

在上图中，还包含了平台的研发、测试以及运营。这是因为只有支撑人员的效率提升，才有更多的资源能投入到业务需求以及非功能性需求的建设之中。

在需求分析及资源倾斜时至少要保证30%的资源分配给于非功能性需求，否则暂时性的繁荣迟早会被故障击破。

当业务支持和产品建设形成良性循环，能用和好用兼备，业务运营乃至决策者的观感才会不断提升。

3）间接使用者

这一角色，多为与平台业务某一环节所关联的研发、测试成员。其关注重点是，做什么以及怎么做。

前者是边界，后者则是接入或使用的流程和规范，在这里则不赘述了。

2-4、沉淀业务需求，封装标准化服务

B端产品的本份是降本增效以及建立规范，而建立规范又来源于“降本增效”的沉淀。

什么时候应该考虑标准化呢？在观测时间线足够长的前提下，应符合以下的条件：

1）系统建设足够完善

2）业务模式足够成熟

3）标准化的收益能超出变更的成本

如果标准化的需求被拒绝，不妨在深入思考需求背景是否符合上述的条件。

这次想谈谈标准化可能陷入的误区：认为解耦一定能提升效率，更爱设计组件而非插件。

对于迅速变化的业务系统，插件更能够提升效率，组件却可能增加枷锁。判断是否插件的标准是：是否独立可用，插件可以灵活组装、随时舍弃的，组件却是相互衔接且密不可分。

电脑主机上的USB接口，只要硬件符合接入标准，无论你是U盘、硬盘还是手机都可以与之通讯。而组件则如同电脑的主机，运作需要有电源，将数字信号转换为模拟信号则需要显卡。

但无论哪种思路，始终还是为了快速响应业务，如果标准服务反而拘束了业务的发挥空间，影响了C端用户的操作体验，这就本末倒置了。

2-5、效果追踪与资源再分配

效果追踪，是权衡的重要工具，其作用是监测产品稳定性以及评估业务价值。

前者是执行效果，后者则是运营效果，这两个数据的提升，都能帮助各个团队建立信心。

执行效果，指在一定时间范围内执行的任务数量、速度、成功率、错误率等，更偏向产品的风险控制，如果执行效果不达标，前进一步却退三步，支持再多的业务也没有意义。

而运营效果则是B端产品价值的体现，虽说B端产品的价值之一是降本增效，但当效率面向不同的业务模式、运营人员，会让量化变的很困难。而另一方面，提升效率也不一定会提升效果。

运营效果的追踪，一方面能够使运营闭环，另一方面则是为了资源的再分配。

如果将企业比作一辆汽车，C端业务更多的是在踩油门，而B端支撑则更多的要考虑踩刹车。提升效率不仅是简化链路、优化流程，还包含停止投入。

追踪业务效果，可以让我们知道业务的优劣对比，帮助我们决定资源倾向。

三、写在最后

最后谈谈个人心态的变化吧，得益于B端的确定性更高，让我能够有信心、耐心，愿意看的更长远些。

以前的我喜欢追求产品设计上的难度，不喜欢做简单的需求，甚至还会对业务同学不耐烦。现在则不再在意难度，只在意有没有用，也许有时做的事情并不“高级”，但我却能够坚定的往前走。

产品的路很枯燥也很漫长，“做好的产品，不是做好的产品经理。”这句话与大家共勉。

-END-