产品经理在工作中，最避不开的就是与团队成员、开发、设计、运营、老板之间展开一系列交流，而在沟通中也要避开各类引发撕逼或者是误解的点，确保沟通成果能有效解决项目问题。

在日常生活和工作中，只要能见到人的场合，总要与人说句话，沟通也是必不可少的。

互联网产品经理，作为团队中有名无实的leader，本身没有任何权力，又要调动很多资源做事情。大部分时间在做协调和沟通的工作，所有想做好这个角色，就要习得见人说人话，见鬼说鬼话的沟通能力。下面讲述在产品狗视角下，应如何与其他角色进行沟通。

一、与开发沟通 1. 沟通的侧重点表达需求所处的背景、为了达到什么样的目的，实现后带来的意义如何

主要是在需求评审的开场时重点讲述，把背景、目的和意义解释清楚，目的是让所有的参会人员能理解并达成一致。这一步能做好后，再去讲解逻辑、流程和功能，会顺畅很多。不仅如此，实际开发阶段，“因为某某需求实现难度较大，开发人员比理解为什么要这么做，找产品去撕逼”，这样的争吵也会少很多，项目推进起来更顺畅。

2. 表达问题比表达方案更重要

这段时间由于公司人员变动，接手了一个处于开发前期的V1.0.0版本的项目（一款超短期的保险产品），在梳理原有功能和逻辑时，发现缺失一个优先级较高的功能（续保）。这个时候需要加功能，怎么办？

我是先把遇到的问题想好怎么说，重点去聊问题，简单提一下解决方案，注意避免陷入技术细节讨论。

对话如下：

产品（我）：在梳理产品现有功能逻辑的时遇到了一个问题（笑嘻嘻.jpg）。市面上的大部分保险产品都是长期保障型，付费的话要么是一次性结清，要么是一年一结，连续好几年交完。用户购买此类保险产品，对续保的需求比较小，而且对续保功能的使用频率比较低。

开发大佬：嗯……（警惕性的点点头.jpg）

产品（我）：我们产品的特点就是超短期保险，一天即可投保，最多也就三十天，所以用户对于续保的需求是非常高的。目前产品功能只实现了“浏览—填写保单—支付—保单生成”，这是一个单线程投保流程。添加续保功能，一方面可以让投保流程形成闭环，另一方面也减少用户在续保时的障碍。

开发大佬：昂   (有点道理的点点头.jpg)

产品（我）：当然了续保功能也可以在当前版本上线之后，紧急迭代一版。但是你也知道，咱们在产品上线之后，开发都会投入到另外一个项目中，未来一个月的时间是没有开发资源的。

开发大佬：是的，这个完了还有新的任务。

产品（我）：所以续保功能这个版本就要上，要实现的功能是XXX，具体的会在文档上写明，评估一下开发时间。更好是不影响项目进度，如果说因为这个功能，会晚上线半天，这样的也可以向上申请，风险呢我也是可以承担的。

开发大佬：行吧，这样实现起来并不难，应该不会影响项目进度。

二、 与设计师沟通 1. 说明用户场景和用户问题

因为团队一直都是UI不参与评审，根据原型出设计图，这样的协作模式就要求产品把场景和问题都与UI交代清楚。刚进入团队时，没有这样的意识，把原型上传后通知一下UI，结果做出来的设计图与我预想的有差异，又要去改一些东西。

所在现在原型出来后，都会向UI介绍用户使用场景和问题，用户使用的流程，每个页面信息的优先级，按钮的权重如何。不用花太长时间，只要能让UI理解即可，设计图产出之后基本符合预期。

2. 尊重专业，不干预设计细节，不要“我觉得该怎么怎么样”

把之一点做好之后，如果设计图出现按钮位置调换，信息位置变化等等。可以适当性的问下，出于什么原因这么设计的，能不能通过专业的角度解释一下，也是进一步确认UI理解的用户场景和问题与产品设想的有没有偏差。

三、与运营沟通 1. 问：“你的问题是什么？”

工作中总会与运营和业务人员打交道，很多时候都是主动过来，能不能给我们做个什么功能，因为活动要用，或者我们需要通过这个功能来促活、拉新、留存等等吧。

这个时候：

问：你为什么要做这个功能，是遇到什么问题了吗？

答：我们干什么的过程中，遇到A问题…….

问：A问题的具体情况，怎么样的呀？

答：XXXXX

……….

（连续追问4-5次，就能比较清楚的了解，运营真正想表达什么）

2. 避免为解决方案做需求