其实我觉得很大程度上在于工作的性质在变，而人员架构还没能适应这种变化。以前团队大都在做项目而不是产品，因为做项目只需要对特定的客户负责，所以才会搞什么需求文档之类的东西，只要需求确定了，工程师听命从事就不会有太大的问题。在这个背景下，PM 的职责更多的是管理资源：人力、时间、财力等等，而工程师也没必要发挥太多的主观能动性，服从安排做好手头的事情就 OK。
后来开始做产品了，最大的问题就是没需求了，或者说需求始终在变，成了水无常形。PM 定好的计划工程师逐渐不再愿意盲从，因为没有特定的客户来验收，谁敢保证你就是对的？在此等状况下，就会出现 #9 @kgen 所说的那些普遍情况。
这里有一个关键的前提就是：长久以来，人员架构的安排就是 PM 是“管人”的，所以当意见不合的时候，这种管理权就会造成 PM 和 工程师之间的冲突。以前做项目的时候工程师不怎么管需求，所以就很少会发生这种冲突，但现在改做产品之后一切就都不一样了。
我所在的公司经历了这种“阵痛”也好长时间了，后来无意当中在团队里出现了一个“产品经理”的角色，这个角色很有意思，他对产品开发有着平均水平之上的理解和设计能力，对用户需求、信息架构、用交互界面等等都有较强的能力（相比于团队以前多做项目为主），但他又不是 PM，他在团队的编制是属于设计师的。
于是情况忽然有了改观。PM 还是做他的老行当，管理和分配资源，调控时间和进度等等，这个“伪产品经理”则担负起了对于产品研发的落地工作，而他和其他的工程师又是平等的地位，不存在谁服从谁或是谁命令谁的情况，有争议大家一起讨论得出结果。表面上看起来争吵似乎变多了，不像从前那么“和谐”了，但所有人的积极性也都变高了，整个项目的进度和质量都在不断提高。
我觉得我们是幸运的，因为这个“伪产品经理”是设计师出身，但是又对技术非常热爱（尽管水平不算高，但是绝对是懂得那种人，不会胡整），善于听取众人的意见，又不会对 PM 及其他高层轻易妥协。就好像是一个润滑剂，短短几个月的时间一下子就把转型产品开发的团队给激活了。我们老大（产品部门总监）一直在说：捡了个宝，捡了个宝啊……
对楼主也想这么说，不妨找找看身边有没有这样的人，其实 PM 的日子也不好过，能有人促进大家完成这种转变才是积极的方式。
对了，还有一件事，中间我们经历过一次公司的重组和搬迁，当时项目组的前 PM 打算另谋高就的，于是老板让这个“伪产品经理”去做 PM，没想到他拒绝了！他的理由是：做了 PM 就没人和我吵架了，没意思……呵呵，所以在我看来，主要负责设计产品的人就应该只对产品负责而不要去做管理工作，特别是管人的工作，这哥们深谙其道啊。
我是个 PM，说一下我的看法。
有些程序员沉浸在技术海洋中，对自己产品业务毫无想法。和这类程序员沟通特别的累，开沟通会时只会 say no，毫无建设性意见。这时候专横就很重要。
有些程序员对于产品很有热情，与他们沟通时会有思想的碰撞，很多没想到的流程、idea 都会蹦出来。这时候我就特别兴奋。
不同的人差太多，对待所有人都以尊重为前提，愚蠢的话少说。
我一直觉得 pm 应该是很厉害的人来做才比较好。因为这个人的很多决策会直接影响技术的价值。但悲剧的是目前有很多定位非高端的 pm。他们很多人对技术一无所知。什么需求随口就来，而不靠谱其可行性。这才是我比较担心的。
不知道这个 PM 的产品原型是他自己 闭门造车 还是 经过了项目参与人员的充分沟通 。若是前者那他就是个不称职的 PM，若是后者，则作为技术人员应该在项目立项初期多提建议，多讲自己想法，不该妥协的要据理力争，但项目一旦定稿，就按照需求做即可，否则大家都根据自己想法做，项目后面就不可控了。
另外产品经理和 PM 应该是分离的两个角色，人都是有惰性的，若两个角色混在一起，会牺牲掉两个角色交叉的一部分义务，做不出出色的产品。
不过这些还是针对传统的 IT 开发流程，针对创业中的各位大圣们，这些都是浮云。
