后台产品经理的技能掌握有哪些不同和侧重？

简单总结了下去年一整年的后台产品经验

其实，工作经验越多，越觉着工作经验的重要性。然后也就理解了十几年经验的老领导，被阿里录用的原因了。刚开始工作时，根本没有后端的概念。因为压根一开始就是冲着前端去的，觉得喜欢产品经理这个职位也就是因为能自己觉得产品的形态，谁会想到冰山理论下的产品，可能前台实现的是一个小功能，后台需要一整串的业务逻辑和支持。现在做后台，也是因缘际会，设计完前台没人做后台了，才顶上，到现在专攻后端。

后端的确比较低调，相较于前端来说，可能没有华丽的用户数据，做好了没人知，一个支持不到位立马引雷。不过就像我一直认为的，一件事如果做好了没有奖，做坏了一定会被罚，你做不做？

专攻后端之后，发现也并没有减弱成就感，可能摩羯座天生觉得踏实工作就是一种成就感。而且能从繁杂的字段中进行抽象化的思考，对字段进行总结，同时考虑结构化去筛选选择条件，平台型产品，还需将流程梳理之后，考虑可扩展性并实现可配置。每每通过脑图流程图抽丝剥茧出结果，成就感也依旧爆棚，这对自己就足够了。 降成本，提效率 （原线下运营人员，邮件沟通）

后端的起点虽低，但是天花板更高（模块化设计，可拓展性，整体运营效率是否提升），同样的，需要的能力也就更强，除了项目管理能力，还有业务的深入理解，不过这里跟开发撕逼就比前台要具体了，只需用业务要求来说话。不过可能苦逼的一点就是，前台产品经理拍个脑袋想的需求，后台得用尽全身力气去支持了，而且后台涉及的部门之多，拿最近的一个CRM打通的小需求来说吧，前前后后联系的有三四个业务部门

再说些具体的吧，譬如对字段进行结构化，来形成筛选条件时；还需对字段抽象进行合并，解耦出新的字段；针对审核过程动态可配置的目标，引入了工作流。为不同的业务渠道设计不同的审核流程：有哪些审核借点，每个审核节点由哪些人员角色操作，每个审核节点在通过或驳回后的流向，都可以动态配置。业务系统不再关心工作台的概念，信息流和事件流推动完全交由了工作流系统。

文/木秀于林d 百度 高级产品经理

关键字：产品经理, 后台

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！