别YY需求
产品经理提出任何需求，原因一定不是，不是，不是：老板想要、运营需求、竞品已有等等这类**的理由。任何需求，都要从产品目标&用户需求两个层面去考虑，首先找到充足的理由说服自己，然后再去说服技术。


做好信息共享

很多PM在需求评审时只告知要做什么，而不说明为什么要做。是啊，程序猿负责实现功能就好了，说其他的有什么用？然，这种想法是绝对错误的，大家同属一个Team，一定要让每一个人都明确目标，同时也明确自己的努力可以向目标迈进一步。
而且，经验丰富的程序猿会想到功能可能的延伸方向，提前做好可扩展性。


不要强行评估工作量
即使是技术出身的PM，也不要强行去评估工作量并确定工期。切记，专业的事儿交给专业的人去做。

尽量别改需求
对产品来说，改需求是一句话的事儿；对技术来说，改需求可能意味着代码废弃、框架重构...简单说来就是通宵两天写的几千行代码没用了。。所以，承接第1条，别YY需求，所有的需求都从产品目标&用户需求的两个层面去考虑周全，避免在开发的过程中改需求。

及时反馈结果
功能上线后，达成的效果要及时反馈给程序猿（挑好的说），虽然大部分程序猿并不关心运营指标，但自己的努力取得了很好的效果，他们还是很高兴的。同时，也会建立程序猿对PM的信心，信任PM的眼光，由此形成良性循环，沟通上会更加顺畅。

把握好"度"
其实很多同学都缺乏这个，怎么讲呢，举个简单的例子：需求会后定好了上线时间，但是在测试过程中发现一个BUG影响很大，难以解决，怎么办？逼开发通宵加班解决BUG？讲道理你没错，确定好了时间就一定按照时间节点走，但这类难以预见的问题影响开发进度，该怎么办呢？
所谓的把握好"度"，所谓的人情世故，大概这样吧...