产品经理们的前车之鉴

　　首先分享的是黄赞志老师从自身经历出发总结的干货：
　　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、用户体验这种东西来忽悠别人。
　　最后，与所有的产品经理和有志于产品的同学们共勉！
　　其次是马双阳老师@多玩分享的干货
　　1. 你不是在弄一个物件儿,你是在做一件事情,物件儿在于形态和构造,事情在于梳理组织关系和核心矛盾;
　　一定弄清楚自己要到达一个什么结果,这件事情最坏的结果是什么?在达到事情目的最短路径是什么?事情的轻重缓急是什么？很多时候这个结果并非是通过产品设计和策划去实现的,他可能来自传播学或市场营销的知识.比如我自己手头有个游戏网站的产品是多玩旗下的快快游戏网，目前首页面临改版的问题，我们的目标是做国内最权威的游戏评测类媒体。
　　我做过数据分析结论是改版后跳出率会降低，用户周回访率会提升，但是80%用户着陆的入口根本不在首页，重要的是想清楚用户在哪里来？他们在什么时机和什么地方看到这些内容。
　　我把用户来源分成4类 ：1. 内部资源转化 2. 合作换量 3. 内容传播和口碑 4. 搜索引擎。 从最终的提高用户浏览量来看首页改版所带来的跳出率和留存率的改变不会对数据全局有根本影响，（1）那么从紧急来说内部资源转化是最短路径（2）内容怎么传播和寻找外部入口是最重要的，媒体的内容如何想办法主动流动起来，而不是静态的内容布局结构摆在那里等着人来（3）那是不是说首页改版不重要，不是，首页告诉用户的是你根本上是个什么产品，用户好方便知道来你这能获得什么服务。但这是长远的，用户才好告诉别人你想分享知识和见解就来知乎吧。
　　2. 不顾一切活下去比什么都重要
　　我刚接触产品的时候想着自己做得产品一定是高端大气上档次，用户体验闪闪发亮。这取决于我的交互设计教育背景的思维惯性;很多中途转行做产品或者年轻产品在想产品问题的时候也偏爱拿体验细节说事，盯着局部交互细节不放，我以前也是这样，但是我明白在敏捷开发节奏中,即便是你再注意细节我保证研发的实际完成度也达不到理想状态的70%，所以体验细节够你优化个一年半载的。于是你先要学会如何生存下去，因为最后大家都只看结果，你或许可以说好产品必然是有过程的要懂得坚持，但是在一个商业团队中你能跟boss说你等我一年我跟你看最终结果吗？
　　3. 明白团队其它岗位的工作流程和思考问题的角度，简单说叫换位思考
　　作为产品你不是要把自己的意志强加在别人身上，这样只会带来矛盾，因为角色不同所以利益和角度肯定不一致，所以你只能自己去搞清楚，尽量避免因为自己的任性而增加别人工作量，同时也才能发现别人是怎么忽悠你的，尤其是研发如何合理利用规则来忽悠你。
　　4. 别乱说话，多看多聆听，在合适的时机表达你想说的
　　一个人不可能在任何时候的看法和判断都是正确的，所以在你没想清楚前尽量不要开口，并非想法最多的人就是最合适干产品的人。清楚一件事情该怎么干，如何直接明了的表达你要达到的目前和各阶段的实现手段。说的越多，越容易暴露缺陷。
　　5. 不要成为C罗，PM应该更具有杰拉德，厄齐尔和斯内德的气质
　　在一个团队里不要试图扮演实力强劲的角色，年轻气盛，急功近利，怀揣热情想大干一番的情怀谁都有。做好组织者的角色保证团队最大输出，至于球是谁踢进去的别太在意。
　　6. 用户不一定都是对的