决策：产品经理的取舍之道
本文主要的感悟来源于B端和平台业务，大抵是不适用于所有产品的，尤其是To C的产品或业务。
在现实情况下，兼顾业务实现、管理质量、用户体验等多方价值的“完美”产品是很难存在的，由于商业行为天然存在的逐利性，投入产品设计和研发的人员资源总是有限。
在B端业务中，由于其目标行业、覆盖场景的范围，因资源问题需要做出的取舍尤其常见。
下面展开谈谈常常会遇到的决策场景类型。
一、以业务为中心or以用户为中心
C端产品更接近日常生活，知名度更广、声量更高，所以市面上大部分产品经理的分享习惯以用户为中心的框架来设计产品，但实际上在2B的业务中，单纯以用户为中心的设计会有诸多不足。
产品或者说信息系统有整体性、逻辑性、时效性等特点，得以支持复杂度高、需要多角色协作的业务活动，但其本质仍是解决问题的手段之一。如果在特定场景有更高效率、更低成本的手段能解决问题，产品设计就不是第一优先级的解决方案。
所以，产品的第一优先级仍是解决业务问题，而不是用户体验。（仅说明优先级，不是用户体验完全不重要的意思）
经常会有同学抱怨，内部系统如OA、财务结算平台、订单管理等怎么怎么难用，体验怎么怎么差。其实究其本质，这些系统的出现不是在满足操作者的使用体验，而都是为管理质量和管理效率服务的。
这个就是典型的为业务服务而非为用户（操作者）服务的场景，体现也是B端业务与C端业务主要的区别（B端是客户（付费角色）与用户（使用角色）分离的）。
这时候有人会犯嘀咕：“不对啊，我做的业务也是To B的，但是用户使用体验我们也很重视啊”。
那基本上就2种可能：
- 用户操作体验已经差到对业务目标流程有阻塞（如成交）或显著的导致成本增加了（如客户咨询量）。
- 业务红海，业务本身已经没东西可以卷了。
二、扩展性与过度设计
前些年阿里中台带来的中台风潮，一直到今年阿里拆中台的尘埃落定，“中台”这个词或多或少的会出现在产技人的视野里。“中台”本身偏技术概念，产品经理没有这个能力和背景展开，这里要讨论的是伴随“中台”而来的扩展性。
扩展性
“指一个软件和系统能够让其他程序员在未来能增加新的功能以及修改现有功能，并且新增功能的同时还必须不损害现有系统或软件功能”（wiki释义）。
白话点讲，就是当前的设计是否能兼容或者快速适应未来业务的变化。看似是技术同学的工作范畴，但在部分To B复杂业务场景中，花大量时间接触业务方，理解并抽象业务的角色是产品经理。
扩展性设计的过程是在抽象业务，抽象程度越高扩展性越强，配置越灵活，但是否抽象程度越高就是越好的设计呢？
- 不尽然。一方面，配置灵活带来的是更高的开发和测试成本，于业务而言，配置的大多数场景可能存在理论里的“伪场景”，所以很大一部分可能是无用的投入。
- 另一方面，越抽象越通用的设计，在一定程度上是“牺牲”业务细节的，进而“牺牲”一部分的业务效率。
高扩展性的设计，适用于需要快速试错的业务方向，但对于大多数业务知识相对稳定的场景，需要谨慎权衡，否则可能会因为过度设计，让本不富裕的开发资源雪上加霜。
提到抽象设计，这里推荐一本书：《“图解”产品：产品经理业务设计与UML建模》。
笔者认为是目前市面上对产品最友好的领域设计和UML建模的工具书，过去DDD（领域驱动设计）的相关书籍和文章主要面向的是开发人员，序言之后很快就进入技术设计层面的讨论，读起来十分痛苦且收获有限，于非技术同学十分不友好。
三、长尾需求是否要被满足
面向C端的长尾场景做的产商品服务，近些年获得成功的案例屡见不鲜，但面对B端业务的长尾需求，应该是怎样一套决策逻辑？
这里总结下笔者的分析链路：
- 长尾需求出现的原因是什么：线下业务不规范？没有引导用户导致的奇异使用姿势？
- 长尾需求是否能通过非产品手段解决？
- 长尾需求是否是阶段性的，是否在未来可能成为主流？
- 是否有其他不可抗力：如大客户需求依赖？政治需求等等
面对长尾需求需要谨慎取舍，因为长尾需求很可能一不小心就做成ROI极低的“私人定制”。
四、结语
对于从业3年以上的产品经理，相信基本工作技能已然扎实，什么需求分析、绘制原型、跨职能沟通等在这个阶段都不太值得再做展开。
这个阶段产品经理的工作实际上是在不断地做决策，核心竞争力来源于做正确决策的范围和能力，是对逻辑能力、业务建模、行业理解等的综合考验。
本文作者 @gxxx 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
