如何成为一名拖垮整个团队的产品经理？
作者：互联网
今天周末了，不写技术文了，写一篇关于产品经理的思考文，各位作产品的小伙伴可以看看，很有警示作用。
众所周知，在企业中，不管是外包企业还是互联网企业，产品经理对于公司的发展都是至关重要的。然而，很多中小型企业的产品经理虽然在产品经理的岗位上，然而并没有达到产品经理应该有的素质和技能。为啥？请看下面关于产品经理的基本技能图谱。
注：图片来自互联网。
说到这里，肯定有很多作产品的小伙伴会问：产品经理真的需要懂这么多吗？这是必须的，上图中的技能只是对于产品经理这个岗位的基本要求。
冰河参加过N次的互联网大厂举办的技术和产品峰会，期间，认识了很多技术和产品大佬，无一例外，对于产品的能力模型，上图中展示的确实是最基本的技能了。
然而，很多中小企业的产品经理根本达不到上图中的要求，做好一个产品经理很难，然而，产品经理要想拖垮整个团队，却非常简单。
产品经理如果想拖垮整个团队，按照下面的方式去执行就好了。
1.对需求缺乏深度思考
面对客户的种种需求，缺乏深度的思考，人云亦云，甚至没有任何记录，就直接进入所谓的设计阶段。设计出来的东西无法说服团队中其他成员，最后，拿客户和公司领导当挡箭牌，“客户说的要这么做”， “XXX领导说的要这么做”，这样即便能够执行下去，与之合作的研发人员心里也肯定不爽，即便项目推进了，产品经理的信誉也完了，以后很难再合作，甚至会有团队成员离职的想象，给团队成员留下一个深刻的印象：坑！
2.不断挖坑
挖坑不断，专坑自己人。给出的产品文档或需求说明书，漏洞百出，或者说根本就没有产品文档和需求说明书，连设计都完全没有任何有意义的标注。一些业务细节点根本不去深度思考，研发人员问到相关细节业务后，支支吾吾，前言不搭后语，或者当场临时拍脑袋想个方案，事后各种问题。反过来说，研发开发的东西Bug很多。
3.不清晰表达设计
对于设计中的功能细节，不去做完整的标记，在项目推进过程中多了非常多的不必要的重复沟通和解释。自以为项目评审的时候说的清清楚楚，结果研发人员几乎每天都会去找产品经理沟通具体细节业务，极大的浪费了时间。然而，他们会反过来说，研发效率有问题（纯粹扯淡）。
4.拍脑袋想当然
不根进实际业务和需求，也不跟进真实客户，不去深刻的了解客户现状。需求凭自己的主观臆断。然而，做出来的东西不是用户想要的，或者需求根本没有覆盖全面，最终，在所谓的设计上临时修补，把锅甩给了研发，说研发还没开发呢。
5.不互通信息
这点在一个项目中有多名产品经理时表现的尤为突出，每个产品经理对于用户的需求和业务的理解都不一样，然而，产品经理与产品经理之前缺乏深度的沟通和思考，多人共同设计一个项目时，业务矛盾点重重，研发根本无法推进工作。
6.害怕背锅
总是想办法把锅甩给别人，原有的设计定稿后，由于某种原因，发现自己设计的貌似有点问题，那好，偷偷修改下，不告诉研发，出问题时，直接甩出一句：研发没有按照设计开发。然而，多名前后端研发人员一致认为设计改了，产品经理就是不承认。设计稿有版本记录可以追溯还好，如果没有版本记录，就扯皮吧！
7.确认的需求随意更改
前期自以为自己理解了客户的需求，设计已和客户确认，研发已经开发完相应的功能。后来发现设计貌似有点问题，又不去跟客户沟通交流，自己随意更改设计，然而，改动的地方并没有清晰的标注出来，交给研发人员时，全靠研发人员自己猜。要么就是找研发讨论半天业务和需求，然而并没有什么卵用。改动确认后的设计，客户并不知情，反正坑就对了。
8.没有产品意识
从思想层面上就没有做产品和设计的意识，设计稿没有版本的概念，总是在当前版本上随意修改，然而给到研发人员的总是最新的“草稿”版本，几乎没有任何有意义的标注，研发人员根本看不出哪里变更了。一个变更点要讨论大半天就对了。研发人员不耐烦的时候，就会抛一句：“跟客户确认了吗？先跟客户确认下再说”。然而，就没有下文了。等到测试时，啊，是研发没修改呀！研发人员心里也是一肚子火。
以上的几点，产品经理按照其中的一两点执行，保证所做的产品或者项目，要么不断延期，要么必败！！
标签：经理,然而,拖垮,研发,客户,产品,一名,设计,团队 来源： https://blog.51cto.com/binghe001/2927207