-- NO.12 --

这是Becomewiser的第12篇文章

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

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

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

在全心投入B端产品的这半年，在这方面也有了些更深的认识，

01  什么是B端产品？

运营的效率。

02 如何进行B端产品设计？

变更的收益能否抹平变更的成本。

能 面向什么角色提供什么支持。产品毕竟是权衡后产物， 只为自身创造的价值不能称之为价值。

是以用户运营系统为例绘制的跨职能流程图：

其次则是根据角色的代表、使用的场景、关注重心决定产品设计的侧重点。

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

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

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

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

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

在上图中，还包含了平台的研发、测试以及运营。这是因为只有 投入到 业务需求以及非功能性需求的建设之中 。

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

这一角色，多为与平台业务某一环节所关联的研发、测试成员。

2）业务模式足够成熟

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

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

关于标准化的细节可以查看此前关于 《前端配置化系统的设计思路》 ，这次想谈谈标准化可能陷入的误区： 认为解耦一定能提升效率，更爱设计组件而非插件。

对于迅速变化的业务系统，插件更能够提升效率，组件却可能增加枷锁。判断是否插件的标准是：是否独立可用，

为了快速响应业务 ，如果标准服务反而拘束了业务的发挥空间，影响了C端用户的操作体验，这就本末倒置了。

提升效率也不一定会提升效果 。

资源的再分配。

提升效率不仅是简化链路、优化流程，还包含 停止投入 。

写在最后

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