【精选】产品经理们的前车之鉴.pdfVIP

产品经理们的前车之鉴 首先分享的是黄赞志老师从自身经历出发总结的干货 ： 1 全局观 当然 ，作为一个入门的产品经理 ，我们很多时候都只是负责某一个产品线 ，或者只是产品的某一个 模块 ，所以并不强求我们必须拥有所谓的全局观。并且全局观这种东西本身也需要时间去积累去 养成 ，入门的时候没有这样的全局观其实是很正常的。 只是 ，如果看不到全局 ，不知道最需要解决的问题在什么地方的话 ，很容易揪着一些细节不放。 诚然 ，很多东西是有改进空间的 ，但从资源的角度来讲 ，它们的优先 级并不一定高 ，不一定非得在 这个时候解决。很多时候 ，自以为找到了一个改进产品 改进体验的方向 ，却被告知“不影响使用”“ 影响的用户很少”“不要太在意这些细节” ，往往自信心这方面会受挫 ，甚至可能会抱怨 ，你的想法明 明是对的 ，却不能按着你的思路来做。 这个时候 ，你需要和你的Leader沟通 ，了解他这么说这么做的原因 ，更重要的是 ，你要尝试着站在 他的角度和高度去思考这个问题。不要求你能够和你的 Leader在想问题的时候能达到同样的高度 ，但作为一个产品经理 ，必须能够跳出自己的角度去看问题 ，要说服一个人 ，你必须知道 ，他关心 什么 ，他顾虑什 么。 另外 ，你如果觉得自己的思路正确 ，那么应该坚持 ，但也应该尊重公司的资源安排 ，将这个需求纳 入自己的时间表 ，而不是一味地追求资源来解决这个问题。 2 独立思 与上面一条不太一样 ，我们在工作的时候 ，很多时候需要听从Leader的安排和指示 ，但这是建立在 自己独立思考的前提之下的。做产品需要有自己的一些理解 和思考 ，一些产品前辈的经验和心得可 以借鉴 ，但不能直接套用 ，任何设计和方法都不能脱离具体的应用场景。看到一些你觉得不合理的 设计 ，应该去想当初为什么要这么设计 ，它们是不是运营 SEO 的需求 ，还是说 ，这是历史遗留下 来的问题 ，在主体发生改变的时候 ，没有顾及到这一块 ，还是说 ，这就是一个失败的设计。 在和别人沟通需求的时候 ，也不能直接说 ，竞品就是这么做的 ，而应该告诉他们 ，竞品为什么要这 么做 ，我们是否还能做得更好 ，该怎么做。竞品这么做 ，只是说明这种方案在技术上是可行的 ，但 这并不是我们要这么做的原因。你的思 ，比你看到的东西更加重要。 现在产品圈有一个词 ，叫“试错” ，对于产品经理而言 ，同样需要不断地试错 ，对于新入门的产品经理 而言 ，更是如此。而试错的方法 ，就是不断地思考 ，不断地提 出自己的想法和思路 ，并和别人探讨 ，在探讨的过程中 ，不断地调整并深化自己对某一个问题的看法。同时 ，需要明确一点 ，即使你现 在的想法是对的 ，也不能保证 它是永远正确的 ，这个世界在不断变化 ，互联网的生态也在不断变化 ，需要尝试着去否定自己一些根深蒂固的想法。 3 跨部门沟通协作 沟通协作基本上是一个产品经理的家常便饭 ，我们每天很大一部分工作内容就是向Leader或者开发 设计人员传达我们的产品理念 ，推动项目的进展。对于一些 小团队来说 ，这种沟通协作往往就是在 办公室里说几声 ，或者中午吃饭的时候探讨一下。但如果你在一个大公司里 ，由于你对这个公司的 组织架构不够了解 ，你可能只知道这个问题应该由哪个部门来负责 ，而不知道应该找谁来沟通这个 问题 ，有些时候 ，你甚至不知道这个问题应该由哪个部门来负责。在这种找不到人来解决问题的 时候 ，往往会出现沟通上的不当 ，有可能是将问题发到一个大的邮件组里 ，让不相关的人看到了这 个问题 ，也有可能发给了与这个问题无关的人或部门 ，最终遭遇踢皮球 ，更有可能问题没有得到 解决 ，你却挨了许多批评。 每个公司应该都有自己的内部沟通方式 ，有可能是邮件 ，有可能是RT X ，也有可能是其他IM ，对于 大多数公司而言 ，邮件应该都是一个非常重要的沟通方式。 首先 ，你应该知道邮件的一些基本礼仪和要求 ，不要在工作的邮件中 ，使用不恰当的词汇和表达 方式。当然 ，邮件礼仪这个太大 ，不在这里细讲。 其次 ，你应该确定 ，这个问题需不需要自己的Leader知晓和跟进。在进行重要的跨部门沟通的时候 ，我提倡抄送双方的Leader ，方便 Leader掌握自己项目的进展和这个过程中遇到的问题。不过也需 要分情况来讨论 ，你如果要求别人做事情遭到拒绝 ，而将这些邮件抄送给对方Leader的话 ，可能会 引起别人的反感 ，不利于今后的进一步协作。 再者 ，如果不知道问题该向谁反馈 ，可以咨询自己的Leader ，如果问题的层级比较高 ，可以交 由Leader去跟进。不太可取的一个方法就 是