“这是产品经理要考虑的，我只管写好代码就好了”，我曾有过这种想法。产品经理就要把所有产品逻辑考虑清楚，然后交付PRD给开发人员进行研发，瀑布or迭代研发一个个里程碑。不过想法总是美好的，现实是大家总是刀剑相向。

产品经理如何惹怒开发人员？

1. 业务不清晰，研发人员不懂业务语言，产品经理不能把业务讲明白；
2. 产品深度太浅，经不起推敲，研发人员觉得是敷衍，不专业；
3. 产品流程不顺甚至复杂，用户体验糟糕；
4. 不听开发人员建议，觉得他们没有产品思维；
5. 状态设计不全，还坚持己见；
6. 没有完整的PRD，把想法告诉研发直接开始码代码，没有评审；
7. 没有数据指标，乱拍脑袋定东西；
8. 这么简单的功能，怎么需要这么久；
9. 着急上线，不给开发人员留思考时间，实际上并没有那么着急；
10. 把需求扔给开发人员就不管了，不追进度，不看效果；
11. 非功能性需求根本不考虑；
12. ……

开发人员如何惹怒产品经理？

1. 一味追求技术，不学习业务语言，不学习领域知识，听不懂需求；
2. 评审PRD时不提出问题和风险，等项目快上线了才暴露出来；
3. 码代码前不好好读PRD，出问题直接怪产品；
4. 以为技术是万能的，不去拒绝一些不合理的需求，最后做砸了；
5. 数据状态和异常流程这事需要好好跟产品经理梳理，产品经理没我们想的全这是一定的，不要怪他们；
6. 只为代码负责，用户体验不是我们要考虑的；在涉及到网络、设备等方面的用户体验，我们比产品7. 经理更懂；
7. 遇到问题不找产品沟通，随意定方案；
8. 代码一团糟，不可维护，不可扩展，新需求迟迟做不了；
9. 老出问题，怪产品经理设计不合理，考虑不全；
10. 很明显的产品体验问题，不提出来，不解决；
11. ……

产品经理应花大部分时间在商业画布、产品规划、产品逻辑、产品运营、用户体验上。涉及到具体功能点应该大致给出研发方向，不然研发是没有方向的，很可能导致不断地返工。

业务开发人员、系统开发人员、SRE或运维人员，其实已经有产品思维了，比如我们梳理业务架构、系统架构、功能点、系统流程、异常流程、数据流程、数据状态、系统配置等等，这些不都是产品的一部分吗？只是这些跟技术绑定的比较紧密而已。

产品经理在产品细节、异常流程、数据状态等方面很可能不如研发人员。这个时候需要大家一起坐下来沟通并梳理。我的观点是：越透明，越高效。

我们首先应该是一名产品经理，然后才是一名开发人员。而且我们是一个团队，应该一起考虑如何做好产品。不过我们应该把自己的专业度提高，否则产出的方案经不起推敲，老是产出残次品，大家的信任危机接踵而来，谁也说服不了谁，决裂厮杀，最终产品失败。

小马哥说过：产品经理要把自己当做一个“最挑剔的用户”。开发人员要用心思考产品，而不是公事公办的态度。你要知道用户、同行会关注你的产品，在这种驱动下开发人员要有责任心去主动完成。不能说等到产品做好了，流水线一样送到面前再做。40%~50%产品的最终体验应由开发人员决定的。小马哥说过：产品经理要把自己当做一个“最挑剔的用户”。开发人员要用心思考产品，而不是公事公办的态度。你要知道用户、同行会关注你的产品，在这种驱动下开发人员要有责任心去主动完成。不能说等到产品做好了，流水线一样送到面前再做。40%~50%产品的最终体验应由开发人员决定的。