初入行PM，常见的错误认知有哪些？

小编语：作为刚入职的我，深感各种认知错误带来的“病痛”。大家一定要认清这些问题，努力的避免他，从而提高自己。PM作为一个综合能力要求极高的职位，严于律己，磨练技能很重要。

1、全局观

当然，作为一个入门的产品经理，我们很多时候都只是负责某一个产品线，或者只是产品的某一个模块，所以并不强求我们必须拥有所谓的全局观。并且全局观这种东西本身也需要时间去积累去养成，入门的时候没有这样的全局观其实是很正常的。

只是，如果看不到全局，不知道最需要解决的问题在什么地方的话，很容易揪着一些细节不放。诚然，很多东西是有改进空间的，但从资源的角度来讲，它们的优先级并不一定高，不一定非得在这个时候解决。很多时候，自以为找到了一个改进产品、改进体验的方向，却被告知“不影响使用”“影响的用户很少”“不要太在意这些细节”，往往自信心这方面会受挫，甚至可能会抱怨，你的想法明明是对的，却不能按着你的思路来做。

这个时候，你需要和你的Leader沟通，了解他这么说这么做的原因，更重要的是，你要尝试着站在他的角度和高度去思考这个问题。不要求你能够和你的Leader在想问题的时候能达到同样的高度，但作为一个产品经理，必须能够跳出自己的角度去看问题，要说服一个人，你必须知道，他关心什么，他顾虑什么。

另外，你如果觉得自己的思路正确，那么应该坚持，但也应该尊重公司的资源安排，将这个需求纳入自己的时间表，而不是一味地追求资源来解决这个问题。

2、独立思考

与上面一条不太一样，我们在工作的时候，很多时候需要听从Leader的安排和指示，但这是建立在自己独立思考的前提之下的。做产品需要有自己的一些理解和思考，一些产品前辈的经验和心得可以借鉴，但不能直接套用，任何设计和方法都不能脱离具体的应用场景。

看到一些你觉得不合理的设计，应该去想当初为什么要这么设计，它们是不是运营、SEO的需求，还是说，这是历史遗留下来的问题，在主体发生改变的时候，没有顾及到这一块，还是说，这就是一个失败的设计。

在和别人沟通需求的时候，也不能直接说，竞品就是这么做的，而应该告诉他们，竞品为什么要这么做，我们是否还能做得更好，该怎么做。竞品这么做，只是说明这种方案在技术上是可行的，但这并不是我们要这么做的原因。你的思考，比你看到的东西更加重要。

现在产品圈有一个词，叫“试错”，对于产品经理而言，同样需要不断地试错，对于新入门的产品经理而言，更是如此。而试错的方法，就是不断地思考，不断地提出自己的想法和思路，并和别人探讨，在探讨的过程中，不断地调整并深化自己对某一个问题的看法。

同时，需要明确一点，即使你现在的想法是对的，也不能保证它是永远正确的，这个世界在不断变化，互联网的生态也在不断变化，需要尝试着去否定自己一些根深蒂固的想法。

3、跨部门沟通协作

沟通协作基本上是一个产品经理的家常便饭，我们每天很大一部分工作内容就是向Leader或者开发设计人员传达我们的产品理念，推动项目的进展。对于一些小团队来说，这种沟通协作往往就是在办公室里说几声，或者中午吃饭的时候探讨一下。

但如果你在一个大公司里，由于你对这个公司的组织架构不够了解，你可能只知道这个问题应该由哪个部门来负责，而不知道应该找谁来沟通这个问题，有些时候，你甚至不知道这个问题应该由哪个部门来负责。

在这种找不到人来解决问题的时候，往往会出现沟通上的不当，有可能是将问题发到一个大的邮件组里，让不相关的人看到了这个问题，也有可能发给了与这个问题无关的人或部门，最终遭遇踢皮球，更有可能问题没有得到解决，你却挨了许多批评。

每个公司应该都有自己的内部沟通方式，有可能是邮件，有可能是RTX，也有可能是其他IM，对于大多数公司而言，邮件应该都是一个非常重要的沟通方式。

首先，你应该知道邮件的一些基本礼仪和要求，不要在工作的邮件中，使用不恰当的词汇和表达方式。当然，邮件礼仪这个太大，不在这里细讲。

其次，你应该确定，这个问题需不需要自己的Leader知晓和跟进。在进行重要的跨部门沟通的时候，我提倡抄送双方的Leader，方便Leader掌握自己项目的进展和这个过程中遇到的问题。不过也需要分情况来讨论，你如果要求别人做事情遭到拒绝，而将这些邮件抄送给对方Leader的话，可能会引起别人的反感，不利于今后的进一步协作。

再者，如果不知道问题该向谁反馈，可以咨询自己的Leader，如果问题的层级比较高，可以交由Leader去跟进。

不太可取的一个方法就是，不分青红皂白发到邮件组里，因为邮件组里的与这个问题接口的可能仅仅只是一两个人，这样会花费大家查收邮件的时间，还有可能将某些不重要的错误和失误公布到所有人面前，这样虽然有利于问题的快速推进和解决，却不一定是每一个人乐于见到的。

最后，是沟通的方法和技巧，一些专业性的问题应该避免邮件的往复讨论，而应该找个地点当面直接地沟通。沟通的时候不要让对方觉得你在求着他办事，也不要让对方觉得你就这么将皮球踢给了他。

要让对方明白，你们的目标是一致的，是为了公司的利益，同时要不断地跟进这个问题，在必要的时候协调其他资源，协作他解决这个问题。方法和技巧同样是个大问题，也不在这里细讲。

4、对产品的了解

尽管你可能做不到对整个公司的产品都非常熟悉，但你一定要足够了解自己负责的那一部分产品。

多用用自己的产品，尽量全面地使用到每一个功能，每一个按钮，每一个页面。要能够知道页面的哪个位置是什么内容，这其中会有多少个二级页面，这么多页面是以什么结构组织在一起的，一个特定链接、按钮点击之后，会出来什么内容。

与此同时，需要从用户的角度去看这个产品，每一个操作的结果是否符合你的预期。然后在这个过程中，慢慢梳理你觉得不佳的地方，整理下来，想想改进的方法。

另外，也梳理自己不清楚的地方，为什么产品这个功能要这么做，为什么交互流程是这个样子的，多问几个为什么，然后整理下来，和自己的Leader探讨，如果他不能给你一个满意的解答，需要问问他这些问题可以去找哪些人。

如果是App的话，可以看看产品的版本更新记录，看看现在这个版本是怎样迭代来的，各个功能是在什么时候加进来的，变化的方向是什么。

更重要的是，对数据的了解和掌握，PV、UV 、停留时间、跳出率、404率等等，电商网站的话，还需要关注相应的转化率，通过这些数据来帮助自己梳理哪些位置或哪些内容是用户经常点击查看的，每一部分的内容都会影响到多少用户，哪一个功能算得上是这个产品的核心功能，哪些问题是需要解决的，这些问题的优先级又是如何。

5、重视用户反馈

用户提出反馈和建议之前，肯定经过了一定的思考，所以我们需要花费一定的时间去听一听用户的反馈。

诚然，大部分用户想的并没有产品人员那么多，许多用户的反馈，我们已经注意到，并且已经在改进，也有一些用户的建议，是我们之前各种权衡之后没有采纳的。正因为如此，不少产品人员并不将用户反馈当回事。

其实，我这里所说的“重视用户反馈”并不是一种方法论，而是一种态度。会对产品提出反馈的用户，不敢说一定是资深用户、深度用户，但一定是对产品有所期待的用户，我们需要去倾听这一部分用户，不只是听他们的反馈，更要听一听他们对产品的一些看法和使用心得，必要的时候保持联系，在新产品上线或内测的时候邀请他们体验产品，并对产品提出一些想法。

这一部分用户其实很好满足，只需要让他们感觉到自己的意见和想法受到重视。面对一个普通用户、乃至一个新用户的吐槽，处理得当，往往能够将这个用户转化为自己的核心用户。

我们不迷信用户反馈，但我们需要珍惜每一个对我们抱有期待的用户。

6、时间管理

做产品，往往手里头会有许许多多的任务，需要多线程地去处理各方面的问题，而对于一个刚入门的产品经理来说，由于负责的事情还不够多，所以很多时候会陷入突然不知道干嘛的状况，所以时间管理非常重要。时间管理同样是个大话题，在这里不多做赘述。

说到时间管理，也就要扯一下工作与学习的关系。

产品经理需要不断跟进业界的动态，作为一个刚入门的产品经理，更需要不断地学习各种产品技能，了解产品的一些基本方法论。但还是要明确一点，工作才是 你坐在这个办公室里的原因，是公司付薪水让你去做的事情。

学习成长应该将其放在工作之后，或者将其融入到工作之中，而不是迷失在所谓的学习和娱乐之中。其实，认认真真地做好自己的工作，是进步最快成长最快的一种方法。

7、证明自己工作的价值

每天工作之余，需要分析一下自己的工作，想想自己的工作有什么不足，更要想想如何来证明自己的工作的成效。这一点或许会比较功利，但这也是每一个职场人都必须面对的——我们如何说服自己的Leader，向他们证明自己工作的价值。

对于产品人员来说，提出需求是一件非常简单的事情，难的是提出靠谱的需求，所以产品人员应该避免为了提需求而提需求，通过不断地提需求，使自己显得好像很忙碌的样子，而没有使产品得到改进。当然，靠谱的需求，本身就是一个非常模糊的概念，所以我们需要通过一些方法和手段来证明自己提出的需求是相对靠谱的，证明自己的工作是有一定价值的。

很多时候，我们会说自己优化了用户体验，或者说使界面变得更加简洁易用，但这往往只是非常主观的想法，没办法直接说服自己的 Leader，甚至更高一层的老板。不同层次的人看重的东西不太一样，对于老板而言，他不需要知道用户体验发生了什么变化，他需要知道的是数据的变化。

所以，前面讲到了，做产品，必须要了解相关产品线的数据，要学会用数据说话，更要懂得分析数据变化背后的原因。要用数据证明自己的工作，而不仅仅只是用UI、用户体验这种东西来忽悠别人。

最后，与所有的产品经理和有志于产品的同学们共勉！