产品经理遇见“闹心”的职场关系

编者按：本文来自微信公众号“Kevin改变世界的点滴”（ID:Kevingbsjddd），作者：Kevin改变世界的点滴。

在疫情特别时期，身边有几个想离职的产品经理仍然在看机会。即使在这个阶段可能会很难，但是也希望脱离“闹心”的职场斗阵关系。

有人的地方，就有江湖。

▲职场如江湖

无论是哪种类型的企业，都会存在以个人利益为争斗的职场argue。而混乱的爆发出现在人员对工作低效、方向疑惑后产生的。

每个人在工作里都喜欢做事实的团队，每一分每一秒都是有意义、有价值的。不是因为担心得罪人、顾虑人情就延期任务甚至是选择放弃任务。

但公司发展越来越快，势必会在人员和业务扩展上出现问题。导致业务不规范、人员闲杂人多、工作分不清。

我这里列举两类产品经理在工作因职场关系产生的现象。

需求优先级老是排不上

需求背后代表着开发、设计、运营人员的投入。当产品经理所在的项目被公司不看好、或降低权重，则会暂停对项目资源的投入。

很多产品经理作为项目下的成员，自然不知道在项目战略层发生了什么？导致项目突然没有资源了或需求延期

▲产品的需求优先级

其实这就是职场的斗阵故事开始了。因为项目有降低的，就有项目权重被提高….

新领导、新资源、新势力都会争取到项目的优先级提高。而背后的老方式、老领导难免会成为项目延期的对象。

80%的情况同个项目组不同产品部的背后故事

一个互联网产品会分前端后台。之前我有写过关于前端、后台的分享。

前端产品经理与后台产品经理是割裂的吗

同样针对一个产品线也有C端产品、和平台产品的说法。

比如一个C端APP的背后推荐逻辑、运营配置，就是靠着OSS（运营支持）系统来支撑。app除了完成前端功能性的功能搭建外，平台就是将APP的获取数据通过清洗、筛选，提供给公司其他产品线作为支持。

比如曾经我在腾讯医疗负责一个项目是由大数据平台和前台APP产品共同组建的。

由于2个产品属于同一个产品线项目，密不可分。所以开发资源如何在C端和平台端分配，需要严格依靠需求排列上就会有优先级要求了。

▲前端后台

但用户端和平台端其实是不可调和的，双方都希望对方能够减少自己的工作量。比如用户端的需求是平台端提供足够的支持能力，但平台端又希望能够控制住用户端的需求，严格按照平台端的能力做产品迭代和发展。

▲平台和用户端各自侧重点 

比如APP上的广告配置，产品初期会让APP的后台做配置化。可是随着产品迭代，广告的配置需要在APP、H5等多个端口。将广告平台移植到平台端才是更合理。

但平台端又可能认为广告配置不在其他APP产品线上有需求，希望APP自己完成广告系统。

随着时间，需求双方会变成矛与盾的问题。用户端需求过多，就导致平台无法标准化，而成了某个产品线用户端的后台。平台端希望构建支持多个用户端需求的方式

▲平台端迭代放心

因此同一个产品线下，部门之间需求优先级、话语权的争夺就特别重要了。通常来说如果产品线有一个总的产品负责人会好安排。但如果平台端、用户端，在设立之初就是2条不同的产品线。

所以双方难免在合作上都希望尽可能减少自己的工作和任务。最后仍然需要老板或更上一层管理。

20%的战略层考虑

产品经理仍然是一份工作。

我们在入职选工作工作的环境和项目我们是可以选择的。公司的内部调整仍然是可以做工作的选择。

用户体验设计要素提到产品经理在需求设计上要站在最外层：战略层考虑。

▲战略层考虑产品设计

如果要想获得更多的话语权和缩短职场斗阵烦恼时间，调研公司的新项目启动资金、资源投入、与公司的主流业务关系。会在战略层上避免进入未来被淘汰的团队项目。

因为有的项目是在做垂死挣扎、有的是在做大展宏图。

所以选择后者显然会是有利于职场上的提升。

同时在职场中，产品经理精通项目管理、文档、原型。所以沟通成了一个非常重要的工作。

包括业务沟通、需求沟通、任务沟通，搞清楚要做什么、领导希望怎么做、团队可以怎么做，是一个产品经理的沟通主要事情。

所以战略层选择的失败，难免会在职场斗阵中面临整个部门被下掉的情况。

有人的地方，就有江湖

上面的两种职场斗阵，一个是点一个是面。

点：产品线内的上下游

面：公司战略层的选择

两者角度分别是产品经理的工作上下游、和部门横向流转。

产品的上下游，一定有一方是需求的限制，另一方是需求的支持方向。比如客服业务部门对产品部，产品部门是想限制业务部门的需求；产品部门之间，则是一方支持、一方限制；

产品线之间有独立的创新项目，也有因为主业务需要展开的2、3条产品线。

最后要说的是既然都逃不过职场斗阵，至少知道这问题的分类，以后再跟进这类分类做好本职工作再根据实际情况解决是最好的。