#前言

这篇文章来自于微信公众号产品小妖，具体作者是谁忘记了，如有侵权，请与我联系。文章有共鸣，讲的都是经验之谈，程序员看了会流泪，产品经理看了会沉默，其中一些场景我也碰到过，感同身受。做产品没那么简单，尤其是团队化来完成一个项目，专业素养和沟通同样重要。

正文

开始实施之前

• 说不清需求价值，技术问“为什么要做”的时候，支支吾吾，或者说“老板要的、运营要的”，成为了传话筒，是最 Low 的，相反，能有理有据的顶老板的产品经理，通常会在大家的眼中逼格满满；
• 没想到功能细节，表现为技术问细节（当然，是涉及业务的细节，不是技术实现细节）的时候，自己还没想过，现场想，被发现了，或者因为是接二手需求，并不知道、也没有去追溯这个需求的初衷；
• 帮技术评估工作量，特别是技术出身的产品经理容易犯这个错，潜台词就是“希望加活”，我评估过了，这些都能做掉的，不要给我偷懒；
• 逼着技术团队承诺，产品经理想的是，如果技术承诺了，但却做不到，这样自己就没责任了，但很多事情，在开始的时候是谁也不知道的，应该大家在一条船上同舟共济，这就是“接力跑”和“踢足球”在交棒/传球之后的区别。

实施过程中

• 做了一半改需求，scrum 里的表现就是 sprint 内的非受迫需求变更，大家很难忍受的是产品经理自己没想清楚，而导致的劳动浪费，俗话说“没有变更就没有伤害”，碰到性子烈的就直接要干架了，当然，如果是外部市场变了，大家都可以理解；
• 开发过程中消失，你可以出差、可以开会，但是要能及时响应技术的问题，要不然，为了进度大家照着自己的想法做下去，验收的时候产品经理跑出来说“这不是我要的”，可不要怪没人理你；
• 过度关注实现细节，帮技术决定技术方案，也是技术出身的产品经理容易犯的错，越俎代庖了，会降低技术同学的积极性，渐渐的就完全打工心态了。

产品发布之后

• 发布后没有反馈，技术人员也需要从市场、用户那里获得反馈，从而知道自己做的事情产生了价值，提升成就感，做完发布，石沉大海，大家是不可能有 owner 感的；
• 无节奏感，让技术人员忙一阵闲一阵，发布之后再忙着研究接下来做什么，让技术人员在干死干活的高强度之后突然不知道做什么，几天后又开始要赶进度。

全过程都有

• 优柔寡断无决断，是产品经理最要不得的品质，就是在已经讨论完毕后，大家都等着你拍板的时候“你说吧，往哪儿走我们就跟着办”，这时候你说“啊，那个，各种方案各有利弊啊，我也不知道怎么办啊，你们有什么好想法……”，你就完蛋了；
• 报喜不报忧，产品经理总想藏着掖着一些信息，比如“老板在考虑干掉这个项目”这类信息，出发点可能是好的，但，当大家通过其他途径知道了以后，互信就完全打破了，大家会觉得“你还是把我们当资源”。