PM的自我修养 -- 沟通与逻辑
目录：
1、工作沟通 ---- 思考方式
1.1 如何向上沟通
1.2 如何和团队内部同事沟通
1.3 如何跨团队沟通
2、思考逻辑 ---- 行事能力
2.1 逻辑的定义
2.2 逻辑思维的三个要素
2.3 思考逻辑的最佳实战
3、总结回顾与个人成长
3.1 日报与周报
3.2 阶段性工作总结 与 知识面回顾
3.3 借助其他同事力量共同成长
4、阅读涉猎
---前言-----
产品工作在初
一个产品做新规划的产品还好，被喷的概率不高，毕竟是新业务，大家都是靠碰撞来定，但是一个已经成熟的产品，如果没考虑好被喷是分分钟的事儿。
（如何做，能够提高沟通效率，至少可以减少被喷）
产品在沟通中的方法论：
•先抛论点，后说论据
•准备足够充分的资料
•区分不同场合和时间
•有情绪的沟通很危险
•一万句理由不如一句“这是我的责任”
常见误区：重要的不是你想表达什么？
结论：而是对方理解成什么
举个例子：过需求评审会
看下面的原型及其说明：
好的，你认为开发为什么会喷你不？
通过两张图的对比，发现什么问题没？看清楚，我说的是在会议上，如果不想被所有人嫌弃，一个需求在发起讨论前，产品经理该做这些事儿：
1、发起需求前的准备
发起需求前先有个清晰的目的，比如是为了优化功能提高留存，还是为了新业务做公关，然后去理解自己的业务，比如有些业务只能在PC端做的，移动端场景不合适做那就别死磕，去做能给公司带来立竿见影效果的功能，这样大家都买账。这里的用研或者需求调研 就需要沟通，这里是向上沟通；
•(事前)确定目标
•(事前)圈出可能引发争议的关键点及备选方案
•(事前)化整为零
•(事后)发送和更新会议记录
Explain: 重要产品的方案很难在一次会议里完全close，而80%的时间消耗在20%的功能讨论；很多在后期引发争议的产品方案往往发生会议后期的改动里
2、找到关键人核对需求准确性
我的习惯是这样的：
2-1、先和产品部门的同事讨论，觉得OK了我在Axure画个原型标上说明；
2-2、找开发了解情况，比如实现难度和时间，还有是否有兄弟产品有做这个规划或者是也需要这个规划；
2-3、争取到领导的同意去拉数据来验证一些设计预期（我建议先口头沟通然后邮件发起啦数据的需求，并抄送自己的领导）；
2-4、验证完了后在完善自己的方案，输出。
•追本溯源
•有自己的观点
•严禁“好像/应该/可能/大概/估计/据说”等含糊的词汇
•确认目标、时间和优先级
•提供可供对方参考的信息
•定期和重要进展主动沟通
3、争取直属Leader同意和修改意见
和直属Leader沟通，一般我是口头沟通+发邮件，我有个上限，比如2天不回复我的我就会去直接催，我觉得产品经理最主要的特质之一是主动沟通，直到拿到结果。
话术：
我想花10分钟跟你确认一下某某项目的排期，这关系到明天技术资源是否进入，你看现在有空吗？
我再确认一下你的意思是……？
4、和负责的运营先私底下过一遍
争取到同意和修改完了后，找这个业务核心点的运营促膝长谈、长时间沟通，以小白用户来跟他们沟通，争取取得一致的认可，然后把功能能够产生的价值和对方沟通清楚，这个时候可以发起会议了。
5、发起会议该做些什么？
5-1、发起会议需要避讳的地方是不要把不相干的人邀请在会议里面，会造成浪费别人的时间或者是噪音多，会议跑偏等情况；
5-2、开会前一定要说明白会议主题，如果中途出现几个同事之间扯别的问题，就打断下告诉对方下一个会议或者私下讨论；
5-3、开会达成一致的结论一定要在结束的时候自己重申，比如今天的结论是：A、商城推荐排序的算法修改成XX；B、搜索算法结果套装推荐；如果大家没有疑问，那么我们就按照这个做，有疑问的请在XX时间内提出来讨论，过后的就坚决执行。
6、立项告知 & 排期开始
首先是邮件必须的了，其次是大家围一圈开个简单的小会议，就站着开，算是个里程碑的启动，聊完各自干活，心里有个底。
7、上线后输出物跟进
7-1、功能质量和符合要求的程度，只有产品经理去扣啦，其他岗位的伙伴由于工种的原因不会太去在意细节滴，如果输出物差，死的就是产品了，另外这个对公司和用户都不负责对吧；
7-2、功能做成功了，一定一定要和该功能运营的小伙伴过一遍，比如做了哪些，情况是什么的都演示一下讨论下，我碰见的情况是功能做完了，运营的小伙伴一脸懵逼的不知道还有这么些功能，以为只能怎么样怎么样的。
结语：不吹牛逼、科学的做事儿以及认真的态度才是产品经理的标签，我个人认为产品经理需要的就是不停不停的去沉淀自己的、正确的方法的过程，真正的产品经理是个积累和总结的过程，不是跟对个idea或者老板就能成功的，踏踏实实解决好各方需求才是正道。
二、 逻辑
一个高水准的产品经理，总是能够很清晰的梳理出产品线、明确的知道当前最该做什么，抓到问题的核心所在。那么他们是如何分析问题的？今天我分享下我的方法，我称为“链式拆分法”，可以帮助大家明确产品思路，更重要的是让PM们理解自己真正的定位！我们以叫车软件为例，实例分析一下。
我之前学到的 产品的 一般做事流程分为： 撘框架 、 定流程、抠细节
撘框架一般是定流程的先决条件，撘框架一般是指明确目标是什么，用户是谁，解决什么需求、需要做哪些端、
