产品经理进阶成长过程中都会踩的坑
做一个成功的或者好的产品出来是比较难的，除了有平台、资源、时机等问题以外，剩下的因素就都在产品经理自身了。好的产品经理能借助平台，协调资源，能把握时机，但产品经理自己也经常犯错误。做出好的产品能让产品经理的成长加速很多，所以也会出现有的人三年经验就是资深或者专家了，有的人做了五年才做到高级。
做好一个产品经理非常不容易，参加过初级产品经理培训的，讲师通常应该会跟你讲，产品经理要知道和掌握的技能非常的多，所需要涉猎的知识范围非常的广，这些其实也导致产品经理经常容易犯错误，原因很多情况下都是经验不足或者知识面狭窄造成的。这里介绍一些产品经理在成长过程中经常犯的一些错误，供大家借鉴。
一、以自己的需求代替用户的需求
这是最容易犯的错误也是最常见的，很多产品经理在设计功能的时候会从自身需求的角度出发去设计，开口就是“我觉得怎样怎样”，“我认为怎样怎样”，考虑的场景都是他自己使用产品的场景，而没有从目标用户群体使用的场景出发。
他们不去找目标用户群体验证核心业务问题及解决方案，就理所当然的用自己的想法来描述产品故事(用户场景和用户问题)，这样的情况下就容易YY出一些产品需求，而不是真正的用户诉求。很多时候确实因为项目时间比较敢，来不及去找用户验证需求，这个时候也应该理性的去分析目标用户群体的属性和他们使用产品的场景，而不是把自己的需求直接代入。
现在做产品越来越重视数据，这也比较容易让产品经理忽略用户，天天看数据，就用数据的反馈直接取代了真实的场景化需求。数据确实很重要，但数据也容易掩盖用户人性化的需求，要想做出用户体验好的产品，除了看数据表现外，还要结合用户心理活动去设计，这样才能设计出人性化的产品。
产品经理应该学会倾听不同的观点，多和那些敢于批评自己观点的人沟通，多接触一线真正使用产品的人。无论是用户量还小的初创产品，还是用户量已经很大的平台级产品，一定要抽时间了解真正用户的需求和感受，哪怕只是跟他们闲聊，也一定能发现一些和你自己之前想法不一样的结论，只不过这时候要注意甄别需求的真伪。
二、将用户需求混淆为产品需求
可能这一点大家比较难理解，上面还在说要按照用户的需求去设计产品，这一点就开始说不要按用户的需求去设计，这不是相互矛盾么。没错，是有点矛盾，这么说的目的是要大家重视去甄别用户需求的真伪。
大部分产品经理的工作流程是：收集用户需求，整理分析用户需求，把需求落地成原型，编写产品需求文档，然后交给技术人员开发；接下来跟踪项目进度，协调资源，验收成果，最后发布产品。这个工作流程没有毛病，容易出错的不在这个流程上，而是在需求分析阶段，分析的结果会转化成产品需求，如何转化是特别需要注意的问题。
很多人都会背需求分析的方法，做加法，做减法，其实很多人都忽略了一点，就是还要做需求挖掘。如果只是单纯的把用户需求翻译成产品需求，那就真的是人人都可以当产品经理了，那我们产品经理岗位的专业性还体现在哪里？
要从公司核心业务发展和产品设计的角度思考用户需求，然后把用户需求转化成为实际的产品需求。在汽车没有出现的时候，你问用户最想要什么?用户会说，我想要一匹跑得更快的马。用户的需求看上去是要一匹好马，但实际上转化成产品需求时，其实用户需要的是更快的速度。这个例子大家都听说过，但要仔细思考一下这个例子的用户场景。
用户需求是提出一个问题，产品需求是这个问题的解决方案。所以当用户需求被表达为一种解决方案时，要探寻其背后的实际诉求，因为用户的认知水平和场景局限性会影响其提需求的认知。比较好的解决问题的办法是：头脑风暴，加强可行性分析和需求评审，多一点人思考能避免一部分的个体思维局限性问题。
三、将老板需求混淆为产品需求
哈哈，这是一个老生常谈的问题，也可能是很多产品经理内心的痛，我估计这可能也是很多产品经理萌生自己创业当老板的内心底源动力，不想继续憋屈下去。对于大多产品经理来说，都应该遇到过大大小小老板提过来的各种各样的需求，就算明显不靠谱的需求，也不敢反驳，只能安排落地开发。
在这里，我不是要教大家如何去反驳，而是要如何从专业的角度去分析，有一点大家要特别注意，老板之所以能成为老板，肯定有其过人之处，当然那些狐假虎威的，沾亲带故的伪老板除外。老板有老板的格局和视野，他有一些独享的信息和行业经验是你所没有的，而且不说别的，他有他当老板的权利。老板的需求是肯定要听的，老板也是用户之一，他的需求也是用户需求，只是不要听过来直接当成产品需求。行业内老板的典范当属马化腾了，至少公开出来我们所知道的，他都是提了一些靠谱的需求，而且行业内都认为他本身就是个产品经理。
针对老板提过来的需求，更要加强需求分析的深度。要从老板这里深入地追溯他的需求来自哪里，是基于什么样的使用场景和什么类型的用户产生的，有没有具体的实例说明，追溯的过程也是消化探讨的过程，发现不靠谱的地方可以直接沟通。然后花一定的时间和精力去理解，拿出初步的方案，如果方案中和需求差异比较大的，要从公司业务发展和产品核心业务流程的角度，想办法说服老板，按你的方案去设计，毕竟老板也是希望产品越做越好的，只要你是从为了产品发展角度思考的，理由站得住脚，一般老板都是会听的。
另外，一般来说老板的需求大部分都是合理的，只是优先级没有那么高。可以适当的拖延一下，从迭代节奏控制、开发资源消耗情况、需求理解分析需要时间的角度出发，去给到老板一个比较合理的说法。等到下个迭代的时候，如果老板还记得这个需求，并经常问你进度的，就赶紧给他安排实现一部分，老板特有的权利要能适当的满足。
四、将用户行为数据需求混淆为大数据需求
大数据发展到现在，已经到了任何一个行业的产品都需要支持大数据需求去做智能化了。但是很多人的理解更多停留在了数据收集下来可以应用，数据可以生成报表，数据可以用来分析出问题这样的层面，实际大数据建设的最大作用在于辅助做决策参考，以及做业务发展的同比分析和预测分析。像常见的精准化推荐营销，业务流程分析是大数据比较基础的应用。
很多产品经理刚开始做大数据需求的时候，要么借助第三方统计工具做使用行为分析，比如页面间的漏斗分析和用户活跃情况分析；要么开始在产品上埋点，用于做业务流程优化分析。这类分析更多都是基于用户行为数据的分析，由此产生的需求也都是用户行为趋同导致的优化需求，本质上和基于用户反馈的优化需求有点类似，只不过这种是通过数据反馈出来的。
大家很容易忽略掉一类数据就是业务数据的收集和分析，在产品实际运作过程中，基于用户的使用，业务数据会表现出来很多有价值的信息，比如不同时间端某个SKU商品的库存消耗情况，可以用于该SKU实际库存阈值的分析，进而指导虚拟库存的设置。这是很小的一个点，放大了之后，还可以分析仓库货物的周转情况，这样就能预测在大型促销活动的时候，仓库会不会爆仓。
当产品经理在建设大数据系统的时候是基于业务使用场景和发展场景考虑的时候，相应业务数据的收集和处理才会特别留意，从而不至于出现到要分析数据的时候发现很多数据都只有订单里面有，很难剥离出来的情况，甚至是订单数据里面都没有，那就无从下手了。
五、将创新设计混淆为创造一种新模式
对于很多产品经理来说，公司肯定会要求大家在业务模式上、产品设计上去创新，而且这种创新的要求，公司层面只会跟你说它的价值和意义，都是比较大的概念，类似于画饼。在我看来，好的产品经理都是有强烈使命感的，因此很多人都会去绞尽脑汁的想如何才能创新，一些创新的分享、书籍、微课也因此大受欢迎。
老板告诉你要有“颠覆式的设计”，这只是一种想法，可以用于创新的参考，但不能按照这个来执行。公司有“改变世界”或者“改变中国”的使命，这只是创新的目的，也不能按照这个来执行。创新更多的来源于生活当中，并可以应用到生活当中，把人们日常没有用到过，用了之后觉得非常好用的模式，沉淀下来，应用到产品设计当中去。
创新不同于创造，创造可能是对整个行业都会有一个深远的影响，有完善的模式，能商业化，能养活团队，能规模化，能真正抵达用户并让用户接受。譬如滴滴的模式，它的出现改变了整个人们用车出行的行业格局。创造可遇，但不一定可求，因为它需要较长时间的沉淀和研发，很多公司都不一定等得起，除非一开始就从0开始做。
创新应该专注于产品本身，从某个比较小的核心问题入手，找到该核心问题优化的解决方案，完善成小而美的功能，以用户为中心，快速上线去提升产品的整体口碑。让产品的某个核心关键指标好起来，既能提升产品使用量，又能提升团队士气，就已经很好了。个人比较鼓励微创新，把一些细小的功能做到极致，也是一种成功。
六、将正确的设计产品混淆为设计正确的产品
这和“正确的做事和做正确的事”有点像，管理学上，“做正确的事”是指首先要决策正确，找对方向与目标，“正确的去做事”是指方法选择正确，要有效率。“正确地做事”与“做正确的事”有着本质的区别。“正确地做事”是以“做正确的事”为前提的，如果没有这样的前提，“正确地做事”将变得毫无意义。首先要做正确的事，然后才存在正确地做事。
很多产品经理都习惯于被安排，按照领导的安排和意图去做产品，按照团队的分工去完成产品设计，按照既定的内部流程去推进，却很少去想这件事情到底为什么要做，是否真的要做，产品是否真的要这么去设计。按部就班去设计产品，到最后也能出来一个相对完美的产品，但最后很有能就是没人用。越是大公司越容易出现这个问题，因为分工越细，流程化作业的情况就越成熟，这时候产品经理就很容易变成执行者。
设计正确的产品首先要明确产品的发展方向和发展目标，然后朝着这个方向和目标去设计功能，过程中确保不偏离，其实这个过程就是在正确的设计产品。产品经理在设计产品之前，要多思考，要去梳理业务逻辑，找到最合理的设计方式，然后用最有效率的方式去实现它，快速的验证。每个产品经理都有自己的梦想，那就是做一款自己设计出来的好产品，要实现这个梦想，就一定要正确的设计产品。
七、将竞品设计模式当作自身产品的设计模式
很多产品经理都很容易犯这个错误，我们要去做竞品分析，也明确被告知竞品上好的设计要能够借鉴过来，这件事没有毛病。但很多产品经理忽略了一点，竞品分析的根本目的不是为了把人家那边好用的功能抄过来，而是去分析对方的业务模式、业务场景下的产品设计取得成功的原因，或者是合理性存在的原因，进而回来对比自身产品的业务模式、业务场景有哪些优势，哪些不足，然后才是决定哪些地方是可以借鉴的。
我遇到过很多产品经理的工作方式是这样的，拿着他的原型设计稿过来跟我过需求的时候，问他为什么选择这样的设计，回答某某竞品是这样做的，我觉得挺好的，就拿过来用了。这就很尴尬，竞品虽然和自身产品业务模式很像，但还是有差别的，如果没有经过消化就直接拿过来用，很容易抄出个四不像。
要基于自身产品的实际情况，分析在现有的业务模式和用户使用场景下，能否按照竞品的设计模式来，很多交互的效果是可以借鉴的，但往往在布局排版、业务流程、业务信息展示等方面都是需要思考的，要消化成为有自身产品特色的功能，这其实也是在别人的基础做了微创新。
八、将不断添加功能当作提升产品的手段
不可否认，任何产品都需要不断的添加新功能，一方面要满足更多用户的共性需求，另一方面需要适应市场环境和业务环境的变化。而且还有一个前提，就是这些功能经过评估都是必要的，不偏离产品发展方向和业务发展主线的。
但是产品经理不能把持续添加功能当成提升产品的手段，这个问题在既有成熟产品的团队里会比较明显，也就是产品已经成型，分产品线运作的时候，每条产品线都有可能在已有的建设思路和考核指标指导下，不断地生产同质化的功能。所以不合理的产品考核指标，很容易对产品带来负面效果。
况且，不断的添加新功能，不一定能提升整体产品。功能多了，用户也会有选择困难，而且功能入口排列过多，本身对产品就不是什么好事情。我们更需要专注的精力，去把核心业务做大做强。那如何来确定新加的功能是否能给产品带来提升呢？制定合理的产品考核指标非常重要，需要真正从用户的角度思考问题。如何制定合理的考核指标，不同的业务会很不一样，需要综合性思考，确保核心业务能够得到发展。
九、分不清有也挺好和让用户尖叫的功能。
在中国的互联网行业环境下，任何新鲜出炉的产品，不管是国内的还是国外的，只要模式够好，用户喜欢，不需要多少时间，一大波非常类似的产品就会出现在市面上。在这类相似产品的群体中，先来者可能还会分到一杯羹，后来者只能在夹缝中求生存，赶超的机会只在于是否能够后来居上，最终赢得用户的欢心，最准确的抓住用户的痛点，让用户用过之后感叹“这就是我要的产品”。
但是，很多产品经理经常花了很多精力在打造一些“有也不错”的功能。用户体量比较大的产品，任何一个功能，都能满足一部分用户的需求，也都有部分用户在使用。类似的功能需求会永远做不完，这样下去会让产品越来越复杂。微信做了一个很好的榜样，把沟通的功能做到非常方便。
资源总是有限的，产品经理应该把精力放在核心业务上，用户在使用某个产品的时候，内心都会有一个预期，这个预期能超出多少，决定了用户对这个产品的喜好程度，而这可以通过追求极致体验来解决。通过运营不断收集用户反馈，再不断的优化产品，都说做产品讲究的是要对得起本心，产品经理最要对的起的就是自己的专业度。追求极致应该成为我们的工作态度，这样才能做出让用户尖叫的产品。
十、追求详尽的需求文档而不是牛逼的产品
我见过写的非常好的需求文档，很详细很清晰，让我这个产品老兵都自愧不如。写出一份好的需求文档，确实很重要，因为可以帮产品经理理清思路，同时又让开发人员、测试人员知道产品的设计细节。不过对于PRD，应该是够用就好，能确保有效沟通，现在都开始流行直接在原型上写需求逻辑说明，也就是原型需求文档，这样技术人员可以对照着界面看，更有感觉一些。确实有些技术人员会说，看大篇幅的文字，会看晕掉。
产品的主要精力和时间不应该是花在写需求文档上，更多的是要验证需求，有时间可以把原型做的高保真一些，用原型去向用户验证，获得用户的认可和反馈，去感知用户的真正需求。因为产品经理最主要的职责还是做出好产品，写需求文档只是这个职责下面的一项工作而已。
牛逼产品的诞生绝不是需求文档写的好就能产生的，很有可能只是一张思维导图，一个业务流程图，或者是几张纸上原型，就能把方向和发展思路确定下来，从而去指导后续的完善设计。
十一、将产品上线发布当作工作完成
这个错误产品经理也很容易犯，很多人面试的时候让他说一下从需求开始的工作流程，一般说到开发跟进就结束了。这就是对产品生命周期不了解的表现，没有上线后的跟进，只能说是功能上线了，至于是不是做出来一个好产品，那还要看用户的使用表现。
可能跟公司内部的风气有关系，现在都要求除了会干活，还要会作秀，所以发布了一个版本，甚至发布了一个小功能，都会喜报邮件。这种邮件很鼓舞团队士气，只是产品经理不能把产品发布当成完结环节，还要跟进上线后的数据表现，看用户接受程度，然后决定是否需要改进或者推倒重来。
很多产品经理急于发布自己的产品，导致产品体验不好，就算后续快速改进，也很难挽回用户的流失和口碑。现在有很多产品都开始实行A/B Test模式或者灰度发布的形式，就是先切一部分流量去测试新上线的功能，这样是为了避免发布的产品或功能不被用户所接受。
产品发布意味着用户才真正开始使用，成功与否不是看产品是否发布，而是看用户是否真正喜欢。要做到用户喜欢并能用起来，产品发布才是刚刚开始。这个看似很简单的道理，但做起来不那么容易。
十二、以喂饱技术团队工作量而增加功能
很多公司都有类似情况，为了不让技术团队闲下来，要求产品经理能够持续产出。很多时候产品经理没有想好要做哪些功能，为了给出足够的工作，于是临时的做一些小功能。这样的坏处显而易见，不仅是资源上的浪费，更有可能会造成产品变臃肿，变得没有逻辑。要知道前期功能加多了，到后面想减少是很难的。
产品经理要清晰的定出每个阶段、每段时期产品的发展规划，有个稍微粗一点的框架，到了要做的时候就不至于无法产出需求。而前期只是做规划的话，到了时间如果业务发生变化了，需求需要调整也完全来得及。
另外产品经理要与技术人员做充分的沟通，不同的发展阶段，都会有不同的技术底层建设要求，本来就需要在迭代过程中，安插着去做一些技术优化和技术框架搭建的任务，一般很难有技术团队会空下来的情况，除非技术团队特别的不负责任，只是单纯的完成产品交付的需求实现任务。
组织上也要给予产品经理合理的时间去培育产品，也给予产品经理足够的信任。产品经理要发挥自己的专业能力，快速的梳理清楚业务流程和业务诉求，制定出相应的产品规划，与技术团队一起商量迭代的节奏控制，这样才能让产品走上正轨。
总结
这里提到的可能只是其中一部分产品经理常犯的错误，基于我自己的成长经历和带团队的经验总结，不一定适合于所有公司的情况，或者适用于每个成长中的产品经理。如果你是产品经理，你希望自己能快速成长起来，可以对照一下看看自己有没有犯类似的错误，反正有则改之，无则加勉，希望大家都能成长为牛逼的产品经理，设计出更多好产品。