产品经理受大多数人诟病的原罪就是需求变更。当设计师或开发人员加班加点做的差不多时，产品经理要改需求，那大家肯定都会骂他不靠谱。然而事实上，改需求未必是不靠谱的表现，因为可能是市场机会变了，或者外部暴露了问题，勇于提出是好事。那么产品经理什么样的行为才是真不靠谱的？下面几个例子需要引以为戒。
需求传话筒
面对业务方提的需求，缺乏独立和深度的思考，稍作抵抗就放弃挑战对方，并很快进入了方案产出阶段。特别在面对老板的需求时，只想着如何快速响应和满足需求，急于把方案出好，产品经理成了方案设计师。等到项目评审，开发们问为什么要做，那必然是没法有理有据地说服别人。最后不得已，拿业务方/老板来当挡箭牌，或者直接打感情牌，那在开发们的心里是绝不会服的。即便项目有了推进，产品经理的信誉也早已破产，后面的合作就难了。
当需求的价值与合理性需要轮到开发来质疑时，那产品经理就是需求传话筒而已。
设计经理
经常过度关注细节设计，强调主观用户体验。在产品的交互和视觉设计方面，提过多个人意见，指手画脚，干扰设计师的工作，甚至提的需求直接到了像素级别。不信任设计师的专业能力，也提供不了有效的数据支撑，只凭自己的感受要求设计稿返工修改。最后好说歹说，产出了大家勉强都满意的版本，然而实际效果却没有本质差别。
产品经理不去思考业务逻辑、用户场景和发展规划，只沉浸在设计细节的优化上，那便成了设计经理，还是不专业的那种。
挖坑不断
提交的产品文档漏洞百出，缺乏很多必要功能点的描述。一些细节没有想到，当开发问到后支支吾吾，或者现场想了个不完善的方案，事后问题重重。一些想清楚的功能细节，却嫌麻烦，写的不够明确，多了很多重复的沟通与解释。自以为项目评审时说的清清楚楚，结果隔一天开发就跑过来再问一遍。项目进程中，开发、设计有问题，不能及时的响应，有时候甚至找不到人。最后产出的结果，要么不是自己想要的，要么只能打回去改正。
产品经理文档梳理不清，过程跟进沟通不给力，那就是挖坑不断，毁项目不倦。
爱想当然
不看产品数据和反馈，新的需求全凭主观臆想。也没有深刻地去了解用户现状，只想着怎么样改善现有功能，盲目追求更新变化，脱离了用户基础。把自己的喜好当成用户的喜好，总觉得新上的功能用户一定喜欢。
产品demo上，爱加技术细节，太偏实现性，认为这样对开发更友好。出方案时，容易想实现起来要怎么做，会不会做不了，限制了思维。甚至经常帮技术想实现方案、评估工作量，多此一举反而适得其反，引起开发们的反感。
信息不共享
对于团队同学，项目的信息没有做好共享。前期的产品目标没有讲透，大家没有很好的共识，信息不透明，容易导致产品的不健康发展。产品上线后的数据和反馈，产品经理敝帚自珍，不和团队分享，大家都感受不到产品的价值感和成就感，降低了积极性，就容易造成打工心态，团队信任感和归属感缺失。还有的产品经理，产品有喜报时知无不言言无不尽，但是碰到处境不好就沉默是金。这在某种程度上是保护团队，让大家安心做事，实际上却没有真正地把团队绑到一条船上，风雨同路。如果大家从别人口中听到产品的消极消息，那结果反而更差。
害怕背锅
遇到问题，优柔寡断，不敢决断和担责。作为项目的虚拟领导者，在产品需要作出选择时，犹犹豫豫，想到天荒地老，没有拍板的勇气，最后蹦出一句：两种方案都可以吧，你们看成本和风险来定。有时候因为被技术挑战了需求，矫枉过正，后面的需求都不敢再提，只怕多生麻烦。没有抱着产品负责人的心态来做事，担心出了问题背锅，所以总希望运营能够担保，技术能够承诺，这样就把压力顺势化解了，责任不会找到自己。但真出了问题，大家通常第一个骂的，还是产品经理，这种做法只是自我安慰而已。
以上种种诠释了不靠谱的产品经理行为，与经验无关，大家切记避免。最后，都说评价一个人靠不靠谱，就看是不是“凡事有交代，件件有着落，事事有回音”，其实产品经理也是一样。
