文章目录
产品经理就是传话筒
回想十年前，那时我刚刚入行，在一家央企的IT部门担任外包小弟，每天的工作就是负责一个模块的需求和BUG修改。当时的需求和BUG都来自同一个人——“需求人员”，也就是现在的产品经理。起初，接收到的需求还是一个完整的Word文档，但渐渐地，连文档都没有了，即便有文档，打开后也只有一句话。我把这种需求称为“一句话需求”。
那时候，我心想：这工作怎么这么简单？不就是一个传话筒吗？甚至连筛选都不做了，哪怕是排个优先级也好。从那时起，我对产品经理这个岗位就有了一个刻板印象——“产品经理就是个传话筒”。
总有种怼产品的冲动
曾经有一段时间，每次需求评审时，我总是有一种刻意去挑战产品经理的冲动。这并不是因为我看不惯产品经理，而是那时候的我们作为软件工程师，总带着一股自负的心态，认为在这个IT部门里最有价值的就是软件工程师。如果在需求评审中不能找出一些需求文档中的逻辑漏洞，就会觉得不够权威，没有地位。
这种心态让我们在每次评审时都非常挑剔，试图通过挑出问题来证明自己的专业性和重要性。最无奈的是，产品自己定的逻辑，最后还得来问研发这个他曾经自己定下来的逻辑是什么，研发也只能无奈的回去一边心里抱怨一边梳理逻辑。这种情况下，研发人员不仅要承受额外的工作压力，还要面对这种不合理的沟通方式。每次遇到这种情况，内心难免会有诸多不满，但为了不影响工作，只能硬着头皮去重新理解和整理逻辑。
产品的工作难在哪了
回到标题上，我们来罗列下，产品经理哪些事，是我一个研发做不来的。
维护与业务方的良好关系
你知道每次上线出现BUG，影响了业务生产时，是谁在背后为你擦屁股吗？是产品经理。如果当时上线没验证出来，夜里突然出问题了，是谁第一个接到业务的电话么？是产品，而问题的原因并非需求本身也并非是产品设计不合理，是研发的问题，那么业务部门会问责道产品这里，将一些难听的话甩给的还是产品。而一个产品能够接住这些话并不是那么轻松的，如果一个系统是产品驱动的业务时，产品经理确实可以强势一些。然而，中国大部分公司都是业务驱动的，IT部门只是个支持部门，目的是通过软件助力业务更好地发展。产品经理在这种背景下承担了更多的责任与压力，成为了业务与研发之间的桥梁，一边既要迎合业务提交过来的需求，一边还要想办法说服研发去满足这个需求。如果没有一个与业务部门良好的关系，那么产品夹在中间是非常难受的和痛苦的，一旦被业务投诉，产品就得想出一个客观合理但又不能真的让研发来背锅的原因，来去解释这次上线的问题，当然如果真的没办法解释了，也就只能实话实说好了。毕竟出来混迟早要还的。
推进项目的进度
一个项目在立项阶段，产品经理要与业务方频繁接触来去收集项目相关信息，此时产品经理的压力是最大的，PRD阶段也是最烧脑的，研发只需要按照需求文档实现产品即可，烧脑的地方是在如何实现，只要是思路清晰不算是什么难事，而产品经理就没有那么轻松了，他们既要确保自己从业务那里收集上来的信息是确定的，同时还是判断这些信息和诉求是否合理，并且还要输出一份研发能看得懂，尽量不让业务和研发打回的PRD文档。不要小看这个过程，他非常考验一个产品经理的沟通能力，设计能力与组织协调能力，这是编码所比不了的能力，而且还是模仿不来的。那么产品具备了这些能力，才能把项目顺利的往前推进。只要他能让研发认可了自己的PRD，同时协调研发给出一个业务能接受的排期，如果研发的排期太长，他还要再返工跟业务沟通看能不能砍掉一些需求。如果业务说不行，他还要再跟研发沟通看能不能加加班赶赶进度。这个左右协调的过程其实很痛苦，不是一个直男研发能干的了的。所以不要小瞧一个产品，他没你想象的那么简单。
总结
本文并没有根据一个产品经理的基本素质来去描述产品经理的工作，而是从实际工作中产品经理要面临的问题去描述了产品经理的不容易，当然就没有说研发就容易，只是这篇文章是我在做了管理后，亲自跟产品经理工作后的亲身体会，愿天下所有的产品经理和研发是相亲相爱的一家人。
