时间: 2021-07-30 11:28:36 人气: 9 评论: 0
产品经理的日常工作中，**遇到很多沟通场景：调研客户、合作方谈判、与运营沟通需求、和技术推进项目、向领导做汇报等。那面对这么多复杂的沟通对象和沟通场景，如何做可以帮助我们提升沟通效率呢？
总结归纳起来分二种情况：找别人沟通和别人找你。
当我们有事情找别人沟通，无论是找主管协助，还是找技术确认可行性，还是咨询运营策略打法，都要带着明确的目的去，并且做好充足的准备。
举个例子，背景如下：产品经理小P需要找主管借分析师B帮助分析业务，然而B正在做另一个case，如果要来做P的需求，B需要老板拍板同意才愿意做。
P：老板，我要借分析师B帮我做高端客户的流失原因分析。
老板：哦，为什么要做这个？
P：上个月GMV掉的很厉害，我们发现主要的付费客户流失了20%，这些人在前一个月能贡献35%的GMV。
老板：嗯，这个挺重要。需要我做什么？
P：B正在做用户加购物车的行为分析，是运营总监O要的。
老板：哦，那BI那边有冲突啊。你的要怎么做？
P：希望下周就开始，一周内分析出结果，这样距离下次月促我们还有半个月的时间针对性的做运营活动，但运营输出策略必须得有分析结果才能有方案。
老板：下周弄完的话，O的数据什么时候完成？
P：B说大概晚个三天的样子。我和O已经聊过了，O可以接受，而且他也是为了下次月促才做的。
老板：那可以结合一起分析。
P：是的，现在B那边需要您同意这个事情。
老板：好的，我去说。分析结果同步给我，另外有问题找我。
在这个主动寻求帮助的案例中，产品经理P是非常自信能争取到资源的。
首先他的目标很明确：借分析师B做一周分析，目的是帮助运营在下次月促时通过拉回高端客户从而拉GMV。
其次他做足了准备：为什么做本次分析？为什么现在要做？分析之后后续动作是什么？可能遇到的问题是什么？哪些问题自己可以解决？具体要老板解决什么？只有做到目标清晰，准备充分，我们主动找别人沟通后才能更容易达到目标，而且更易获得助力。
这种情况**复杂点，要求产品经理有更好的沟通力，因为不是每一个表达者都可以简明扼要的阐述清楚自己的观点，我们要透过表面问题，通过合理的沟通引导抓到真正的根源问题，然后再组织好自己的信息，让对方消化掉。
举个例子，某运营O负责活动管理，每天要审核供应商报名的商品，要到的操作界面如下，找到产品经理P吐槽 ：
O：“活动审核表格太长，能不能弄短点，把重要的信息聚焦一下？”
P：“具体是哪些信息呢？”
O：“类目、品牌这些我都不需要、近7天最低价要明显一点，放在前面”
P：“哦，你等等，我记一下”
如果产品经理P不去深挖的话，可能对话到这里就结束了，运营O也开开心心的回去了。但如果要做的更好， P还**继续沟通：
P：我知道了。目前表格里些信息都有用到对吧？
O：能用到，就是看起来太麻烦，不聚焦。
P：你看这个活动里面的第一个商品，你现在要审它，是怎么审的？
O：你看，这个商品售后率还不错，但是CTR(搜索曝光点击率)一般，如果价格搞了我就不要了。现在看活动价199块还是很有竞争力的，但是他有恶意抬价的行为，最近报了个238，这次活动我需要做量，所以还是给过，但是**警告供应商。
P：嗯，大致明白了。你能告诉我为什么要把刚才那几个放前面吗？
O：肯定的啊，价格是第一要素，价格不好都是白搭，价格要放最前面的。至于商家服务要看情况，如果价格差不多，我就选服务好的。
P：所以，价格第一，商家服务第二是吗？
O：是的，因为特别离谱的商家我们就直接不让报名的。
P：这样，我可以帮你把价格过高、近期有涨价的商品单独分类分出来，异常情况说明好。然后再把你刚提的核心信息靠前摆，方便你审核。
O：这样就更好了。
这样下来， P通过沟通挖掘到了商品审核时的决策依据。这样P就可以围绕 “哪些价格因素决定了商品是否被拒绝？”这个问题进行更深入的挖掘，做出更易用的审核页面。那有没有可能挖的更深？：
P：价格现在都是人肉审，每天要花费多久？
O：像天天特卖这样的，每天2个小时吧。
P：这样2个小时花在刚才哪些问题上？
O：是的。如果刚才那些点都优化好了，这2小时能节省下来。
P：为什么你们现在主要看价格？如果供应商服务特别差，你们也让过？
O：这个要看情况的，我们**和供应商沟通
P：这样？？那我们不就变成了一个价格战的平台了？
O：我的KPI是活动GMV哦，先要有量的
P：好的，我知道了
其实聊到这里，产品经理P先透过表象确定了核心目的是要提升审核效率，然后通过沟通找到了决定审核决策的关键点，再基于这个点提出了更优解。
到后面，在较强的商业意识驱动下，产品经理P发现了目前活动导向了一个不健康的平台生态。接下来他可以就现状和运营负责人去沟通了解，在更高维度学习到一个健康的平台生态是如何构建的，以及要根据哪些要素决定当下是否要构建等等。
先看一个案例，背景是平台上已经有了好几个抽奖工具：跑马灯、翻牌、砸金蛋等，运营O又来找产品经理P提需求了：
O：我想做一个大转**，我们有这个功能吗？
P：抽奖用的？
O：是的，能开发这个吗，复杂吗？
P：不是已经有好几个抽奖工具了吗？怎么还要做？
O：那些效果不太好。
P：那你凭什么觉得大转**好呢？
O：这次我们投入了20万的营销成本，自媒体都**造势，力度比之前大，我们要用新的玩法吸引用户的眼球啊。
P：把跑马灯UI效果改一下不是一样的？
O：我这个大转**方案老板已经通过了，活动页的UI效果图都出完了，大转**放在最上面，你看下，老板觉得不错。
P：我……
这是个很真实的案例，我们还是先接上一节的话题先找到本质问题：
P：嗯，挺好看，这次活动期望的效果是什么？
O：是这样的，核心是拉DAU。
P：准备怎么投放呢？
O：主要是对上个月没下单的用户进行重点投放，公众号短信APP消息都**发。
P：哦，沉默激活是吧。目标大约能做多少？
O：如果流失客户能激活20%，我们能拉到500万DAU。
P：那召回他们的抓手是什么？肯定不是大转**这样的形式对吧？
O：嗯对，大转**不是主要的，主要是还是这次的优惠力度大，以及我们要把触达他们的效率做起来。
P：是的，我也是这么认为的。
这个时候已经抓到实际的问题点了，而且顺着P的沟通，可以让O觉得你们是站在一起做业务。可以继续往下：
P：所以我们核心要把触达用户的通道建好，以及在抽奖页面做好转化对吧？
O：是的。
P：对的，这里面我觉得更重要的是要召回的这部分用户，他们对什么感兴趣。
O：是的。
P：我待**帮你取个数据，一起分析下这里面用户的行为特征。
O：好啊好啊。
P：转化方面，你为啥觉得大转**好啊？
O：想新鲜一点，而且UED那边做好了
P：我觉得是不是转**当下不重要，先把这部分用户的特征弄清楚。如果他们都是对优惠**很敏感，我们在页面上把满减信息强化一些。在公众号、短信文案上把优惠幅度作为利益点透出。但是首先我们得先分析下。
O：好的啊，那你把数据发我，我也看看。
相信大家看到这个案例，可以体**到共情的核心点是什么了。
在前一部分的沟通中，运营O的 目的是：“我要说服产品经理接这个需求”；产品经理P的目的是：“这个需求不合理，我要拒绝掉！”。
但到后面，是否做大转**这样的工具已经不重要。因为通过有效沟通，大家聚焦目标，聚焦了实现目标的策略，产品针对性的给出支持，后面再讨论方案都**顺利很多。
“共情”是产品经理沟通的核心思维之一，也是非常的难的一部分。
大部分的产品经理都要面对不同的客户，可能是直接用户、可能是合作伙伴、也可能是公司的运营、采购、客服、市场、财务或销售，我们要做到理解对方的目标才能提出建立共情的问题。
所以大家在平时的工作中，如果有机**接触到不是自己直接负责的产品，也建议大家投一部分时间去了解。当有一天你遇到能负责更大**子产品的机**时，你已经准备的差不多了不是吗？
这里引用前辈之前告诫我的一句话：产品经理不要输给自己的屁股。我们把屁股挪开，看别的产品怎么做的，看运营怎么做的，看销售怎么卖的，看客服怎么处理的，看财务怎么做报表的，产品经理的空间才**更大。
上一节提到，产品经理需要和沟通对象视角保持一致，聚焦到共同的目标上进行沟通讨论，做到这点后，接下来就要朝着如何达到这个目标来继续深入交流了。
就刚才的例子，其实产品经理已经做到了导向解决问题的沟通，产品经理P和运营O围绕如何抓住即将流失的客户做转化，从而提升DAU这个话题去讨论如何数据分析，如何制定运营策略，这样的配合方式很容易拿到更好的结果。
导向解决问题的关键是，大家要为了结果去出谋划策。当我们遇到设计不合理，运营策略不合理，技术总是出bug的时候，一昧的吐槽或者抱怨只是图了一时口快，对公司于个人成长都是无益的。产品经理要往前走，就得在朝着解决问题的方向努力，驱动业务、驱动技术，驱动设计。
举个例子：
A是负责活动的产品经理，但是近几周活动数据报表里的数据总是有异常，已经影响到了运营的日常分析。
A调研下来，发现可能是APP的发版问题导致的，于是把问题交给负责APP的产品经理B跟进。
B经过数据对比发现的确是有问题，于是找APP客户端技术C，C排查发现说我这边埋点都是OK的，也验证给了B确认，建议B找数据技术那边确认，于是B找到数据技术D，D说我这边接受到的数据就是这样的，建议B找客户端技术去确认埋点。
来回几次后，B失去了耐心，认为技术不负责任，解决不了问题还推脱。当A找到B时，有下面的对话：
A：问题找到了吗？
B：是技术的问题，但是他们太不靠谱了。
A：怎么回事？
B：客户端说是数据的问题，数据说可能是客户端的问题，都解决不了
A：那现在结论什么样的？
B：他们太不靠谱了…
A：技术就是bug多，遇到问题还解决不了
B：是啊，服了，这样的事情出了好几次了
A：那怎么办呢？这数据不对啊
B：我再找他们去，不行就投诉了
A：好吧，唉…
这样类似的情况在互联网公司正不断的发生，不仅仅在产品技术之间，其他部门之间的配合也**遇到类似的情况。当问题来的时候，人类本能**先排除自己的问题，然后把皮球踢走。这个时候，作为新时代的产品经理，从解决问题的角度出发，我们要发挥好团队的融合剂的作用，义不容辞的站出来搞定它！
就这个案例，产品经理A或者B都可以主动站出来，或者联合起来一起去推进解决。这里遇到的数据问题其实是最难解决的问题，这里的难不是指技术上的实现的难度，而是意识上的难度。
作为产品经理，我们还是要先衡量当前数据的可用性。
如果目前的数据虽有误差，但是足以作为业务判断之用，那么这件事就是重要但不紧急的，没有必要当下就推动很多技术去把数据做的很精细。
但如果数据没有参考价值了，业务无法用来做判断了，那么就是重要紧急的，这一点是需要提前进行拿捏的并且和使用方达成一致。
有了判断之后，下面就是要解决配合方（这个案例里主要是技术同学）的自驱动意识。
这件事的本质就是通过产品经理的有效沟通，让配合方和你建立共情，让大家意识到目前的数据差异带来的影响有多大。
你可以拉上运营同学助力，让技术感同身受。如果这样具体负责的技术理解不了无法共情，那么产品经理必须要开始借力了，找你的主管和技术主管一起参与，毕竟主管站的位置和具体开发的技术还是不同的，在这样的情况下和技术主管理解重要性，建立共情，然后自上而下驱动。
必要性和动力都有了，下面就是产品经理发挥自己特长的时候了。
这个案例里，问题的表象在于报表有问题，但实际数据的获取可以分为“埋点——采集——报表“三个主要过程，需要分解开来看。
经历了上述的拆解，可以把问题分到各个技术上，逐个检查排解。
在导向结果的沟通里，最后一定要产出计划，保障落地性。如果没有计划，一些细节**丢失，也**存在不知道谁做什么事情，最后导致之前的努力大打折扣。
好的计划需要明确下面几个要素：具体事项，谁来解决，反馈时间。
首先，每个人要跟进的事项要具体。模糊的表述是没法作为事情去跟进的，只有问题具体，结果才可控。
其次，负责人最好只有一个。如果存在协同配合的跟进人，也要明确一个负责人，为这件事负责，多人跟进极易导致没人跟进。
再者，每个事项需要责任人给反馈时间。如果当场给不了时间的，可以要求责任人给出“什么时候能给反馈时间”，以保障计划可跟进。如果要落实的事项比较多，产品经理可以可以制定一张跟进表，拉个群，定期和大家复**进展。
就本案例而言，可以参考如下跟进表：
拿到每一件事的结果是产品经理未来的核心价值，不管是和技术排查问题，还是和业务共同推进找增长点，我们把为过程负责转向为结果负责。
好的沟通是要让对方理解我们表达的意思。口若悬河、滔滔不绝往往并不能帮助我们达到目的。产品经理在传递信息时，秀逻辑不是我们的目的，让别人理解我们的逻辑才是重要的。
在上一节里提到的数据报表问题，我们就把解决问题的思路结构化的分为了三个部分，分别是埋点的排查、采集的排查、报表的排查。沟通的时候是这样的：
P：数据报表目前不准确，我们根据之前的了解，客户端和数据这边都自查没问题，但是结果是不对的，所以我们把这个问题拆开看看，然后我们各自对下是否有遗漏。
技术们：OK，好的
P：之前和大家了解下来，数据报表其实分3个部分，分别是客户端埋点，数据中台进行采集、数据分析组进行报表产出对吧？这个大流程是这样的吗？
技术们：对的
P：那我们先一部分一部分的看？
技术们：好
P：我们先一起来看埋点部分吧，待**再讨论采集和报表端。埋点这边主要是看客户端是否埋了，我这边看来核心要检查三个方面：1、活动的埋点是不是否埋了？2、扩展字段是否都带了？3、不同的版本是否都带了。这3个大家看怎么去检查，如果都没问题的话，埋点这趴就可以过了
客户端技术：对的，主要是这三块
P：那下面**后，客户端的同学去检查下，然后给个反馈？其他人有补充吗？
客户端技术：OK。
其他技术：没什么补充
P：好的，那么再看下采集端怎么排查？
技术们：好
后面详细的过程就不再赘述了，主要的沟通思路把复杂的问题进行结构化的拆解，一部分一部分的聊透，可以边聊的时候板书如下，便于大家核对和补充：
大家工作中有没有遇到过这样的场景，新来的技术再问一个产品老人的时候，有时候这个产品老人声音大点，语气硬点，这个技术就没怎么再问了。
类似的情况发生在产品经理身上也有，我团队里有个小伙伴有业务疑问的时候喜欢瞎琢磨，实在琢磨不出来**去找平时熟悉的几个运营专员去了解，然后也没有得到自己想要的答案，就是不敢去问运营的负责人。虽然现在大部分互联网公司都是扁平化在管理，但是还有相当一部分的产品经理有这样的心态问题。
其实大可不必，我们之所以去沟通，核心还是为了了解到我们想要的信息，平常心对待，不管是面对什么样的角色——面对上级，做好数据准备、做好要问问题、客观描述客观回答。面对新人，不敷衍，多有些细心和耐心。不要用有色眼镜看待沟通对象和需求。
作者：归归类；公众号：归归类，微信号：gglei666
本文由@归归类 原创发布于人人都是产品经理，未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
