开始实施之前
【说不清需求价值】，技术问“为什么要做”的时候，支支吾吾，或者说“老板要的、运营要的”，成为了传话筒，是最Low的，相反，能有理有据的顶老板的产品经理，通常会在大家的眼中逼格满满；
【没想到功能细节】，表现为技术问细节（当然，是涉及业务的细节，不是技术实现细节）的时候，自己还没想过，现场想，被发现了，或者因为是接二手需求，并不知道、也没有去追溯这个需求的初衷；
【帮技术评估工作量】，特别是技术出身的产品经理容易犯这个错，潜台词就是“希望加活”，我评估过了，这些都能做掉的，不要给我偷懒；
【逼着技术团队承诺】，产品经理想的是，如果技术承诺了，但却做不到，这样自己就没责任了，但很多事情，在开始的时候是谁也不知道的，应该大家在一条船上同舟共济，这就是“接力跑”和“踢足球”在交棒/传球之后的区别；
实施过程中
【做了一半改需求】，scrum里的表现就是sprint内的非受迫需求变更，大家很难忍受的是产品经理自己没想清楚，而导致的劳动浪费，俗话说“没有变更就没有伤害”，碰到性子烈的就直接要干架了，当然，如果是外部市场变了，大家都可以理解；
【开发过程中消失】，你可以出差、可以开会，但是要能及时响应技术的问题，要不然，为了进度大家照着自己的想法做下去，验收的时候产品经理跑出来说“这不是我要的”，可不要怪没人理你；
【过度关注实现细节】，帮技术决定技术方案，也是技术出身的产品经理容易犯的错，越俎代庖了，会降低技术同学的积极性，渐渐的就完全打工心态了；
产品发布之后
【发布后没有反馈】，技术人员也需要从市场、用户那里获得反馈，从而知道自己做的事情产生了价值，提升成就感，做完发布，石沉大海，大家是不可能有owner感的；
【无节奏感】，让技术人员忙一阵闲一阵，发布之后再忙着研究接下来做什么，让技术人员在干死干活的高强度之后突然不知道做什么，几天后又开始要赶进度；
开发人员最讨厌产品经理的地方比如说
需求不清晰，当开发人员问PM需求的时候，发现PM也弄不清楚；
需求总变更，比如说系统分析都做完数据库设计都完成的阶段了，需求居然又变了。其实需求总变更的原因是PM没有决策能力，往往被运营、合作方、老板或者上司所左右，权衡来权衡去导致需求总变更；
太年轻、缺乏经验、缺乏常识、缺乏个人魅力等，这样会导致比如说无法反馈数据、商业价值判断有偏差、对项目控制稀里糊涂、思维结构化不足等；
太过于市场化或者用户导向，虽然这个不一定是坏事，但毕竟如果一个人的思维过于活跃或者天外飞仙，会导致丝毫不顾及任何技术可实现性，衍生出很多的问题，当然这个也可以归于第3点。
从和开发合作这个层面看. 产品经理应该有3个事情要做好
能明确的确定需求: 要在开发前将所有人的需求在自己这里汇总和明确. 不能含混不清, 不能只规划眼前的一步, 不能无规划的朝令夕改,。
能准确的阐述需求: 从脉络到细节, 尽量完整而准确的说明, 落实到文字而非口头, 对可能会变更和扩充的要有单独的说明。
3. 对资源和可行性的充分了解和反馈: 沟通中明确需求是否可行,了解人力/技术难度/外部资源/周期/风险都能有清晰的认识, 并可根据技术反馈调整和补充需求.
