Just now a development manager and the product manager of the brother project team got into a fight. The thing is probably that when the two sides are connected, the other side wants us to provide an interface, but our side is actually two completely different entity concepts. The development manager thinks that two basic interfaces should be provided, and it is unscientific to synthesize one.
The quarrel was inextricable, and I kept the dog silent, hoping that they could solve it by themselves in the end. In the end, he was still caught, Guo, what are you going to do...
Before, a pair of project managers and product managers who were more incompatible came to me and chatted separately, "Is this project manager taking too much care..." and "Is this product manager taking too much care...". The conflicts accumulated over time, and finally became public, and the people in the group cursed all over the country, so the company had to do a transfer.
Touching the scene, talking about product managers and R&D...
1. The Past and Present of Products and R&D
This kind of conflict often breaks out between the R&D leader and the product manager. The probability of conflicts is closely related to the qualifications and background of the R&D leader. If your company recruits a R&D manager, and JD's position is a project manager, the probability of conflict will be greatly increased.
project manager
Although the abbreviations are PM. But when more experienced practitioners see PM, most of them should first think of project managers. In the pre-mobile Internet era, the first person in charge of an average-sized software team was usually the project manager.
At that time, the person who was responsible for drawing prototypes and communicating requirements was called a requirements analyst. The word product manager is rarely mentioned yet.
In terms of the responsibilities of the project manager, it can be generally understood as the project leader (different from the narrow project manager), who is responsible for connecting with customers, understanding requirements, leading project development, testing, and delivering the entire process. (The R&D project manager I interviewed actually had someone who was in charge of asking for accounts -_-||).
Because he is fully responsible for the project, while the responsibility is heavy, the rights are correspondingly relatively large. Including, formulation of project budget, determination of demand, personnel assessment, etc. Requirements analysts are usually led by the project manager and are assessed by the project manager, and the project manager is the first to take the blame for the delivery effect. Naturally, the requirements writing should be listened to by the project manager.
It can be seen that the quality requirements for software project project managers in the early years were still very comprehensive.
product manager
随着互联网（主要是移动互联网的兴起），做“产品类型的项目”的项目比做“定制类型的项目”要前途远大光明的多。于是，做产品类“项目”的机会大大增加，进而产品经理这个概念开始被广泛提及，一本《人人都是产品经理》更是火遍大江南北。
产品经理的职责，侧重于产品的设计规划。相当于拆分了之前项目经理做需求分析部分工作的职责，产品设计的好坏，需求是否合理，是不是卖的出去，用户是否满意，这些类型的锅，理论上从项目经理转移到了产品经理头上。
此时画原型，传达需求的人员，也会被叫做产品经理，或者产品助理。
但是，现实中受规模限制，顶着产品经理的Title，能实际承担产品经理的工作，自主为产品设计，和推广效果负责的产品经理还是很少的。
一二十人的软件公司大把，本小利薄，倾全力打造的一，两个产品，不可能你说咋做就咋做，往往老板才是那个真正的产品经理。
由此可见，现在的产品经理，多数在之前的项目经理眼中，就是他曾经治下的需求分析员，所以公司如果设有产品经理，那就最好不要用“项目经理”的Title招研发负责人了……
二、为何而怼
大家都知道，美国在中东搞事情，是为了石油！
而我们作为科技行业从业者，无意义的冲突也应该尽量避免，损人也不利己。但凡冲突，总要为点儿啥，不该只凭个人好恶或非要争个高低。工作中还是应该理性经济一点，少动感情 :-)。
然鹅，据我观察，很多怼产品的研发人员都不清楚自己怼的目的诉求，怼的毫无说服力；而产品经理也不理解自己为啥被怼，被怼的很懵逼。
需求不合理
当研发人员说出这句话的时候。通常代表，以研发人员的经验，产品提出的需求，比较稀有另类。这其实可以理解为建设性意见。产品经理应该首先审视自己的需求，是否逻辑合理，是否有更好的解决方案，心态开放，不要过于坚持做自己，一路走到黑。
如果确认没问题，产品应该向研发人员阐明设计初衷，研发能认可则皆大欢喜，如果实在谈不拢，产品经理的大招就是。“我对产品的定义负责，锅也是我背，所以只要逻辑没有矛盾，技术可以实现，大家按我的方案来做就好。”
而在研发人员的角度，如前所述，如果公司设置了产品经理职位，产品的定义职责应当就不是研发人员背锅了。本着“谁背锅，谁负责”，责权对应的一般原则。产品对所有需求有最终决定权，未来用户打上门来，也是打产品，不会打你的。
如果需求没有逻辑上的问题，合理性由产品最终决策，研发人员顶多“友情”的提示下，“按你说的来， 那以后有问题，@你哦”。
实现不了
如果研发人员怼出“实现不了”时，这可以算是研发人员的大招了。但作为产品经理也不要轻言放弃，产品经理要评估下你所提需求的实际难度以及必要性，然后决定是否坚持需要实现。
如果决定坚持需要实现，常见的回怼策略是。“那竞品XXX 和 XXX都实现了，这个功能很常见啊，不然我们PK不过他们啊”。 如果最终谈不拢，那就说“要不你向研发领导反馈下，看公司有没有其他大牛有相关经验，或者请示下是不是需要招聘这方面的专门人才”，都是很上的了台面的说辞。
而从研发人员角度出发，“实现不了”，这个措辞应当谨慎使用。这其实就是直接承认我不行（男人一般不能说不行）o(*￣︶￣*)o。所以在这么怼之前，务必考虑清楚，“实现不了”这件事情如果放在桌面上讨论时，理由是不是充分，是不是合理，会不会显得自己太不行：-）。
实现成本高
对于实现成本较高的需求，球其实主要在产品经理这边。相当于研发人员已经给你预警了，实现这项功能预算很高，你要想清楚要不要做，做不做你定。主要是会对产品形成一定的心理压力。
此时产品无非是，慎重思考，选择坚持或者放弃，切忌说“这个功能我觉得很简单啊，一天搞定。”这类，YOU CAN YOU UP的引战的话。如果坚持要做，那么理由应当充分，以便研发搞出一个天价预算放在桌面上评审时，你能够说服大家功能有必要做。
研发人员从成本角度提出疑问，应当实事求是，注意理由的充分及合理性。如果是人手一个的功能，到你这里需要一个特别不美丽的价格，研发人员要能经受得住其他人的挑战。
这里研发人员应该坚守的底线是，复杂的功能自然对应于更长的周期，更高的预算。只要好功能而不给好价钱（资源）的行为，就是压榨，应该严正抗议，据理力怼。同时要避免自我设限，稍微复杂或欠缺经验的功能就打退堂鼓，给产品经理施加压力。
这不属于产品需求
产品经理应当注意，不要无意义的越界。如果不是必要的需求规格，不要写在产品需求中，可以交给研发去自行实现，这样会更加的其乐融融。
例如如果你需要一个好吃的苹果，而颜色无所谓的话，就不必要定义我要一个“红色”的苹果，因为也许研发实现成蓝色会更加的方便快捷。否则，研发会觉得你管的太宽。每一个明确定义的需求都应当围绕解决原始需求，有所依据。如果研发的同学问你既然你需要一个好吃的苹果，那为啥一定要红色的，你应该有合理解释，而不是……人家就是想要
同时研发的同学应该认识到，所有需求都可以写入产品需求，写入产品需求的内容，都是由产品经理背锅。例如客户需要一个网站，产品需求要求，后端用Java，前端用Vue+ElementUI，研发的同学可能认为这不属于产品应该管的事情。
然而，如果产品经理给出的解释是，客户明确指令要用这样的语言框架实现，因为客户有自己的研发团队，只熟悉这些相关语言技术，后期他们会接手维护，这些要求是写在商务合同里的。那么显然这是一个非常合理的产品需求，并不是多管闲事。即便他没有合理解释，写到产品需求里，你可以质疑，但如果产品经理坚持，只要给钱（认可提供相应的资源，周期），你还是要想办法实现，毕竟他是为成本背锅的人。
随便加需求
如果因为需求错漏，而变更的需求，作为产品经理，认错态度要诚恳，让研发的同学原谅你，从而避免他们把延期交付，因为你搞错变更了需求的锅非常讲道理的甩给你:-)。
如果增加需求是客户要求，无法推挡，那么你要向外向上管理，告诉客户或者管理者，新的需求对应新的设计，开发，测试成本。不要让，研发的同事义务劳动（只干活，不提供相应资源）。
而研发的同学要心胸开阔，人非圣贤，需求的错漏，客户也好，老板也好，产品也好，难免斟酌后发现新的错漏，或者有更紧急的事项插入，对变化要持开放的心态。当然如果，只加事儿，不加预算，那还是要用力怼的。
之前非要做的，结果都没业务用
产品经理要理解，用心做出来的东西没人用，确实很伤研发的心，如果是加班生产的那就更伤心:-)。如果是产品经理自己琢磨出来的，那还是低调做人，有错就认。如果是外部或上级压力，那就后续尽量做好对上/外，管理，与研发同一战线，劝他们三思后行，同时，锅可以适当甩给他们;-)。
研发的角度看，做的东西，就像自己的娃，希望他有个好归宿的心情可以理解。但冷酷点说，谁都希望一次做好做对，而且浪费和试错的成本，主要还是老板来承担了，上班就是出卖劳动力，只要薪水按约定付了，也没啥好说的，不必太玻璃心。既然雇你来上班就不可能然你闲着，其他的手艺人，哪个不是，你说咋整就咋整，活儿多多益善，给钱就行:-)。
三、相处之道
只要钱到位，玻璃全干碎
产品经理要有劳动有价的认知，没有所谓简单的功能，必然被怼 YOU CAN YOU UP。如果你提了复杂高大上的需求，增加或者变更了计划外的需求，那都需要研发的同学，撸起袖子，加油干，才能将你的需求，落地为功能实现。而你就应该与研发的同学站在同一战线，向外或向上管理，为研发的同学尽可能多背书，争取相应的资源（时间，预算）。切忌，用“我提的功能很简单，他们却要一年”来拆研发的台。
研发的同学应当在力所能及的范围内，多快好省地建设社会主义。复杂的功能，以及计划外的变更，在配套对应资源的情况下，不应该理解为压榨，应该理解为锻炼机会。永远做简单的增删改查，用最基本的控件，需求复杂点儿就不会做，做不了，如何成长为大牛？
先说断，后不乱
组织要注意研发与产品经理间可能出现的矛盾，要注意宣贯研发经理与产品经理的职责定位。除了招聘，入职培训环节，在平时的一些争议解决中，也要讲职责，讲流程。绩效考核中，应当注意责权对应，谁背锅，谁决策。
就这样被你征服
二人互动也必然会分出强弱，征服对方，建立信任还是要凭借实力。
产品经理要摆脱项目经理眼中，“就是个画图的战五渣”的固有成见，要秀出你对行业，对竞品的非凡理解，并一直带领大家走在正确的道路上，用户越来越多，评价越来越好，钱越赚越多。
而研发人员则可以通过强大高效的研发能力，只有想不到，没有做不到，让产品经理信任你的技术能力，进而信任听取你的，成本预估，方案建议。
合作生，分则死
产品经理决定了一个产品所可能达到的最高高度，而研发则决定一个产品所能达到的实际高度。产品经理与研发的冲突会导致，产品过度设计，项目成本虚高等内耗问题。最终导致项目很难多块好省的完成。
最终项目不赚钱，老板也不可能分钱 ，两败俱伤。
So，和气生财 ;-)