高阶产品经理，如何用系统解决问题

 

不少刚入行的产品经理，视角大多局限在功能层面：

 

接到一个任务后，对需求稍加分析，就开始画原型、写文档、做评审、推动开发上线。

 

对他们来说，一个页面、一个交互，甚至一个字段的改动，就是他们唯一关注的点。

 

不可否认，新人阶段把重点放在表现层、功能层等基础技能打磨上，是非常正确的——毕竟这是一个初级产品经理的本职工作，也是能力提升的基础。

 

但一个3年以上经验的产品经理，就不应该在功能细节层面过度用力，只关心表现层。

 

见过一个5年经验的高级产品经理，主导做产品方案时，只考虑前端页面的交互和具体功能，几乎不思考后端逻辑、业务流程和线下配合规则——结果做的方案被各方质疑，最后试用期被淘汰。

 

3年以上经验的产品经理在做产品方案时，应该站在更高的层面，拥有更宽广的视角，设计一个系统，用系统去解决一个问题。

 

一、只关注功能带来的问题

 

只关注功能设计，是新人的本职，却是有一定经验的产品经理必须要避免的问题。

 

1. 问题解决的效果不明显

 

一般来说，一个业务流程会有多个节点，每个节点互相配合，最后达成一个总的业务目标；一个具体问题的出现，很多时候是业务流程中的多个节点共同作用的结果。

 

某电商APP的下单转化率很低，但造成该问题的原因可能有：

 

商品详情页描述吸引力不够；

商品价格没有优势；

用户对商品质量不放心；

支付接口不稳定，支付失败率高。

······

 

这些原因的共同作用下，导致了下单转化率很低。

 

一个功能，一般都是针对某个节点而设计的，只作用于某个节点；作用于单个节点的功能，当然对问题的解决有一定的价值。

 

但由于一个业务流程中，各个节点是互相关联和影响的——某个节点的问题改善了，但其他关联的节点并没有改善，最后叠加到一块，很可能对整体的问题改善效果并不明显。

 

如果更换更稳定支付通道，支付成功比例由原来的50%提升到99%；但因为详情页转化率只有1%，最后导致整体的下单转化率只是从0.5%提升到0.99%。

 

支付节点提升了49%，但下单转化率只提升了0.49%。

 

2. 影响个人成长

 

从领导那接收工作任务，按领导的思考结果和要求来设计功能，推动开发上线，是初级产品经理的工作。

 

这种工作状态，会导致我们在设计方案时，缺乏独立思考。

 

领导已经明确的告诉我们，要做什么和要怎么做，但我们却不知道为什么要做这些，更不知道为什么要这么做。

 

领导给小明下了一个任务：在用户注册页面最下方新增“邀请码”字段，非必填。

 

这个任务对小明来说，非常简单。

 

如果小明不去追问，那他只知道要在注册页面的最下方新增一个非必填的字段。

 

至于为什么要新增这个字段、为什么要在最下方增加、为什么要设置成非必填，他并不清楚。

 

缺乏独立思考，就会导致个人成长缓慢——因为我们只是一个机械手，替别人完成了一个任务，我们的能力和思维，并没有通过完成这个任务得到提升。

 

长此以往，我们只是接收任务、完成任务的熟练度提升了而已。

 

本质上，依然还是个熟练的初级产品经理。

 

二、什么是系统？

 

系统是由多个互相关联、互相作用，共同完成一个目的的组件的集合；在一个系统中，多个组件各司其职，完成各自职责范围内的任务；各个组件互相协作，共同完成一个目标。

 

餐厅有一套餐厅运营系统：在这个系统中，迎宾台负责迎接顾客、服务员负责打扫卫生、点餐员负责引导顾客点餐下单、厨房负责制作菜肴、送餐员负责将菜肴送到顾客桌上、采购员负责采购食材、收银员负责收钱······

 

餐饮业务的每一个节点，都有对应的角色负责。大家各司其职，共同给顾客提供良好的用餐体验，帮助餐厅获得更多的营收。

 

与功能在单个节点优化该节点的问题不同，系统能全面、完整地解决一个复杂问题。

 

如果普遍反馈餐厅用餐体验不佳，单个功能的解决方案可能是与顾客有接触的员工要更有礼貌。

 

但系统的解决方案是全方位的改进。比如，卫生打扫更干净、点餐指引更贴心、更好水平更高的厨师、更快的上菜速度、采购更新鲜的食材······

 

三、系统的特点

 

1. 完整性

 

系统能覆盖业务流转的全过程，系统中的每个组件，分别在各自所在的节点发挥作用，任何一个节点都不能掉链子。

 

在餐厅运营系统中，每个岗位提供的服务都履行了各自的工作职责，所有的岗位同时运作，缺一不可。

 

如果没有人去采购食材，那厨房就没有办法制作菜肴；如果没人打扫卫生，那餐厅就会很脏乱；如果没有迎宾，进入餐厅的顾客数可能就会减少······

 

实现了业务闭环的系统，远比单个功能提供的作用要完整、有效。

 

2. 可扩展、可优化

 

由于系统是由多个组件组成的，每个组件完成各自的负责的部分任务；系统可以根据业务的需要，扩展出新的组件。同时，原有的组件也可以持续升级迭代，达到更好的效果。

 

为提升点餐环节的效率，可以将服务员引导点餐，升级为顾客扫码点餐；为了让顾客更满意，可以增加饭后甜点，免费向顾客提供。

 

系统在服务业务的过程中，不断地扩展新组件，不断优化已有组件，整体发挥的作用就越大，对业务的支持力度就越强，业务目标的达成度也越高。

 

3. 业务目标导向

 

单个功能的目标，取决于该功能对应业务节点的职责及该节点当前要解决的问题。并不直接指向业务目标。

 

而系统的目标，一定是指向业务的。

 

业务目标，就是系统的目标。

 

扫码点餐功能，只是为了完成点餐环节的任务，解决点餐环节的效率问题。

 

而餐厅运营系统的目标是：为顾客提供良好的餐饮体验，帮助餐厅获得更大的营收——这也是整个餐厅的业务目标。

 

4. 整体成本低

 

达成任何一个业务目标，都是有成本的。

 

只考虑功能层面，我们对成本的考虑，就会集中在这个功能上——能否做最小的改动、能否用最小的服务器资源消耗、能否在更短的时间内开发上线，就成了我们思考的方向。

 

此时，我们就可能会做很多的妥协。最终这个功能并没有很好的支持整体业务的运转，在业务运作的其他节点，可能要付出更高的成本。

 

设计活动报名审核功能时，为了节约开发成本，把审核功能做成了人工审核——看起来功能层面的成本是减少了，但为了业务顺利运作，客服需要投入了大量的人力成本。

 

而在设计系统时，我们在成本方面的关注点变成了整个系统的成本；当某个节点的方案设计导致整体成本过高时，我们就会修改对应一个甚至多个节点的方案，使得整体的成本更低。

 

当我们设计活动报名系统时，为使得整体成本更低，我们就会开发自动审核功能，无需客服介入，或者仅在出现问题时介入。

 

这不仅确保了活动报名审核工作的顺利开展，还大幅度降低了整个业务的成本。

 

总结

 

有一定工作经验的产品经理，应该尽快跳出被动接收任务、实现别人想法的工作状态，切换到做思考全局、设计系统来解决问题的状态。

 

作者：产品慎思录

微信公众号：产品慎思录