1.输入力
用户诉求
电话调研，问卷调研，日常体验（多使用，多听周边人使用意见，zhuang老师经常做），出差调研
产品/业务/技术逻辑
为了保证公司其他人的效率，应该先在内网上检索相关的wiki。小的项目看10+个，大的项目甚至要看20-30个wiki，带着问题找到自己想要的wiki然后进行学习。
学习wiki的时候重点带着下面「要求通彻到」的思考，然后把自己困惑的问题列成1234567点（这很重要，任何一个需求基本上你认真的研究个几个小时都能想透，然后你再带着问题去找人聊，真的花不了多久），通过wiki上面的名字打电话甚至当面和这些人聊。请记住：能先问产品的，不要问rd，产品的视角一般都比较大，还会给你输入一些业务的背景。但是如果还是想深入到技术逻辑的话，那么可以找相关的rd亲自咨询。
全知全能
全知全能的意思是说，不仅要知道你做的需求为什么做怎么做，还要知道其他人的需求怎么做为什么做。获取其他人或者其他业务线信息的渠道就很重要了：
邮件
多翻翻邮件，从战略层或者一个需求的规划层去思考一下，看看别人遇到什么问题怎么解决的，对自己有什么借鉴意义
战略会
多听听老板们的战略会，在战略会上，老板一般会规划一个大的项目后续完整的节奏。还会分析一些公司宏观的数据，可以让自己对业务有很深入的认知和理解，知道现在部门在做什么，从而让自己的需求都能够自上而下的打通，自己执行起来也动力十足。
周会与组内评审
周会和组内评审一般都是自己产品组内的同学一起交流的，这时候可以从产品部的角度了解大家都在做什么，可以以后在执行的时候能够瞬间找对人而且也有产品部分工的全局视角。
要求通彻到（基本所有的需求，无论大小，你只要这个都懂了，基本上没有人能battle过你）：
基于什么背景下决定要做这件事？==>从公司目标及大背景拆解，要知道做某款产品的根源是什么。
基于什么需求开始的？==>挖掘的是什么需求，打的是用户的哪个点，怎么保证这个需求是确实存在的？用户调研结果是什么？市场调研的分析是怎样的？精品是怎样的？
收益是什么？==>天花板有多高？解决的是哪个指标？我们投入的成本是怎样的？
是怎么通过产品逻辑解决用户问题的？==>产品逻辑是怎样的？理论能跑通么？
是怎么通过产品逻辑来完成背景目标的？==>我们如何定义这个款产品是成功的？产品的预期终态是什么？后期的规划是怎样的？定义产品的指标的具体口径是什么（口径得找各方在上线前刨根问底，全部拉齐）？终极目标（核心目标）是怎么逐步的拆解成阶段目标的？每个阶段的mde是什么？后期的节奏是怎样的？我们遇到xx的情况之后应该走什么路？
效果是怎样的？遇到了什么问题？==>根据之前的规划，现在效果如何？我们达到了mde么？哪些指标不ok？我们下一步怎么操作？
怎么迭代的？==>别人是遇到了什么情况？是怎么解决的？解决的效果如何？
现状是什么？==>看一下现在的数据，评估一下现在是什么水平什么情况（与当初的预期收益比，与其他的竞品比，与市场的天花板比）。
2.决策力
不唯上
你要清楚的认识到，老板给你分的需求，在他分给你之前很可能自己只是感觉可以做。老板分给你的意思有两个：
1.看看要不要做；不做的话输入给我一些信息，说服我
2.要做的话就好好的做一下，之后给我看看效果。
第一条很重要，你要有自己的判断能力，然后给老板成型的输入。假如能做的话，那就二话不说最好在不问老板要资源（不提问，不要人）的情况下自己迅速落地解决。
成功率10%就已经很高了
这条道理也很重要，你要知道任何一个产品经理，他对于非100%成功需求的把握都不会很高，当你拿不定的时候，大概率其他人也拿不定，不要慌，先试一试再说。
多输入其他产品『前世今生』
输入的渠道可以是公司内网也可以是偌大的互联网，自己想研究什么，那就完完整整的把自己感兴趣的需求分析透彻了。然后最好能够写一些分析，打造自己的知识库。
留意生活中所有的决策点
决策不止发生在互联网的产品中。一个综艺的设定与场地的选择还有嘉宾的邀请都是有一定的理由的；观察一下综艺节目的字幕假如在互联网中，文案水平如何；认知一下好莱坞电影很多细节的深度，为什么他们这么在乎细节？如果是你，这个片段你会怎么处理，你会投入这么大的精力去布局场景么？
《对赌》
认真的读完之后，产出一些核心的结论，然后在工作中决策的时候尽量的去使用他们。甚至你需要配合结论，先从理论上分析一下自己输入的各种各样的项目。
3.推进力-短时，高效，高质
组织架构
产品经理是用来解决问题的，相比技术来讲，产品要解决的事情大多是人的事儿，而技术解决的大多是代码的事。两者的明显区别就是，当你想找代码玩的时候，随时随地都可以，但是当你想求人办事的时候，效率的高低往往有很大的程度是取决于对方的主观意愿的。大公司如社会，各个部门其实如同社会中的不同公司，只是在同一套公司体系下，这些不同的公司有义务辅助你完成工作而已。产品经理就是在这个社会中摸爬滚打完成老板意愿以及产品诉求的人，因此先理清周边的资源以及各个模块的负责人才能在自己想做什么事情的时候能够找到对的人办对的事情。而且明确各个部门的工作职责和负责人可以为自己推动项目提供有力的抓手。
因此任何一个产品经理，有义务先搞清楚公司的体系架构以及各个模块的从属关系对之后的信息抓取与评审都有重要的意义。
分责分工
分责分工是两件事情。分责主要用来解决配合方态度消极或者拒绝为自己提供某些更深度的支持的问题，分责的精髓在于让对方承认“我已尽力，由于我导致的信息不全从而产生的问题我来承担”，当然表达不能这么直白。逻辑很简单，自己评估一下这个信息是否十分必要，必须对方给，在不十分必要的情况下，反复核实几次后，重述对方的搪塞话语，然后问“你这边已经确定只能是这样了哈？”，对方回答“确定”甩锅即成功。后续产生什么问题，由于你已经本着尽职尽责的态度去逼问了几次了，对方还是表达了确定，那自己责任其实就不大了。原理很简单，我已经表达了获取这个信息的作用和意义，而且也向你提出了强烈获取信息的请求，之后由于这个信息不全造成的问题，都应该属于你没有尽职尽责提供给我的责任。
但是也不能每次遇到对方搪塞都这样操作，很多事情还是搞清楚的好，不然会影响自己后续项目的推进而且容易造成很大的风险，具体情况还是得自己评估，必要时还是得刨根问底！这只是一个对方实在不配合自己实在搞不定情况下的一个兜底甩锅策略。
分工具体指的是，能够合理的推活儿。
沟通技巧
拉会：
在刚接到一个新的需求的时候，大多数的信息很有可能都是分散在很多人那里的。可能是客服，可能是rd，可能是产品也可能是业务，自己点对点的去沟通没有问题，也可以达到获取信息然后去决策的目的。但是大多时候，由于历史原因或者交接问题，点对点的沟通需要确认的点太多，需要频繁的在这群人之间来回跑，而且单个反复沟通反复约时间对他人体验也不是很好，导致效率很低。那么此时拉会就可以解决问题，拉会主要的目的有两个：
把大家都找齐，全量的信息一起对，省去自己点对点沟通时的跑来跑去。
拉大家过来，引起大家重视，开会的这段时间内，与会方完全属于这个需求，可以大大的提高项目推进的效率。
当别人打到你没有care到的点的时候：
先不要解释，先diss back“有什么问题嘛”，先让对方把自己的观点阐述清楚，这段时间也可以先自己思考一下。然后逐步击破他的点。常用的，没有care到的点被问到，就说我们同步在做。
示例：yunshuo的预估价展示在非拼车上，但是预估价可能不准，有的用户点开后写的打表计价，然后自己付的钱还和预估价有出入。yunshuo解释的点是说：1.预估价会展示仅供参考，而且法务也会在里面的h5上解释打表计价。2.出租车预估价的准确度在逐步的完善，都同步在做。
协作流程
首先明确一点，每个大公司，由于业务繁杂事情太多，所以就有了「需求」这个概念。每个公司就是通过需求来流转的，需求的产生可以是任何人，接下来就是找到周围的资源来完成某个人的需求完成某个人的意愿。对于产品相关的需求，那么就由产品去找到公司相关的资源然后去推进，如果是业务的需求，那么一般来讲业务的需求最后大多会落地成为一个产品需求，因此其实公司大多的需求都是产品来做的，公司的运转也大比例是产品驱动的。
由于每个人都会有一些不同的需求，但是需求的配合方并不是都是认可的，所以就有了需求评审制度。这个制度就是来评价公司每天各种各样的需求要不要做的，只有通过层层筛选的需求才可能最终落地。
之前也提到过，每个公司的不同的部门，不同的技术模块都是独立的， 在没有需求分到他们的时候，他们很可能不会自驱动做事。因此，pm的一个重要职责就是整合周围的资源，把需求落地实施。这个价值是巨大的，越大的公司，这个整合资源落地需求的过程的价值就越大，并不是每个人都可以做到的。
接下来就遇到了一些问题，pm在判断一个需求要不要做之前都会去找相关的人先获取一些信息用来判断，但是获取信息很可能别人不会全心全意的配合，毕竟需求没评审通过之前大家都害怕自己提供了很多支持最后没有产出，白忙活一场。那么就有了一个bp的概念，每个技术模块或者部门（如pr或者法务）都会分给每个事业部一个bp（businessPartner），用来直接对接这个事业部需要的支持。我们在推进一个事情的时候可以找我们事业部的bp他们就会尽心尽力的释放信息配合
4.定力
核心的总结，一些原则，要保证心态平稳
5.基础力
数据分析
sql,数据指标的平台（如滴滴的tabluea，数易等）
多变量分析
查case
获取各种信息的渠道（查订单，查司机，查车辆，查补款，查工单等等）
