产品经理高效生存指南:掌握沟通的本质,提高做事效率

2 评论 4705 浏览 33 收藏 25 分钟

产品经理的日常工作中,会遇到很多沟通场景:调研客户、合作方谈判、与运营沟通需求、和技术推进项目、向领导做汇报等。那面对这么多复杂的沟通对象和沟通场景,如何做可以帮助我们提升沟通效率呢?

一、沟通的种类和本质

总结归纳起来分二种情况:找别人沟通和别人找你。

1. 找别人沟通

当我们有事情找别人沟通,无论是找主管协助,还是找技术确认可行性,还是咨询运营策略打法,都要带着明确的目的去,并且做好充足的准备。

举个例子,背景如下:产品经理小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。

其次他做足了准备:为什么做本次分析?为什么现在要做?分析之后后续动作是什么?可能遇到的问题是什么?哪些问题自己可以解决?具体要老板解决什么?只有做到目标清晰,准备充分,我们主动找别人沟通后才能更容易达到目标,而且更易获得助力。

2. 别人找你沟通

这种情况会复杂点,要求产品经理有更好的沟通力,因为不是每一个表达者都可以简明扼要的阐述清楚自己的观点,我们要透过表面问题,通过合理的沟通引导抓到真正的根源问题,然后再组织好自己的信息,让对方消化掉。

举个例子,某运营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都可以主动站出来,或者联合起来一起去推进解决。这里遇到的数据问题其实是最难解决的问题,这里的难不是指技术上的实现的难度,而是意识上的难度。

  • 第一个原因是互联网里的数据,只要能有参考作用,能帮助业务做判断,存在一定的误差是可以接受的,没必要投入非常大的资源保证到非常准确,尤其是行为类的数据。
  • 第二,数据会涉及到埋点、采集、分析、处理,涉及的团队非常多,不是靠一个技术团队就能解决掉的,作为单一技术,要求他们能推动多方排查也是挺难的。在这样的意识下,我们如何推进?

1. 判断必要性

作为产品经理,我们还是要先衡量当前数据的可用性。

如果目前的数据虽有误差,但是足以作为业务判断之用,那么这件事就是重要但不紧急的,没有必要当下就推动很多技术去把数据做的很精细。

但如果数据没有参考价值了,业务无法用来做判断了,那么就是重要紧急的,这一点是需要提前进行拿捏的并且和使用方达成一致。

2. 解决驱动力的问题

有了判断之后,下面就是要解决配合方(这个案例里主要是技术同学)的自驱动意识。

这件事的本质就是通过产品经理的有效沟通,让配合方和你建立共情,让大家意识到目前的数据差异带来的影响有多大。

你可以拉上运营同学助力,让技术感同身受。如果这样具体负责的技术理解不了无法共情,那么产品经理必须要开始借力了,找你的主管和技术主管一起参与,毕竟主管站的位置和具体开发的技术还是不同的,在这样的情况下和技术主管理解重要性,建立共情,然后自上而下驱动。

3. 产品经理发挥拆解问题的能力

必要性和动力都有了,下面就是产品经理发挥自己特长的时候了。

这个案例里,问题的表象在于报表有问题,但实际数据的获取可以分为“埋点——采集——报表“三个主要过程,需要分解开来看。

  • 埋点方面,是否埋了如何验证?不同的版本是否有埋了?上报数据是否存在问题等?
  • 采集方面,采集的数据是否有遗漏?技术是怎么判断没有遗漏的?
  • 报表方面是用的什么数据源进行产出的?这个数据源采集的同学是否确认过?报表产出的逻辑大家是否review过?

经历了上述的拆解,可以把问题分到各个技术上,逐个检查排解。

4. 凡事要落实必有计划

在导向结果的沟通里,最后一定要产出计划,保障落地性。如果没有计划,一些细节会丢失,也会存在不知道谁做什么事情,最后导致之前的努力大打折扣。

好的计划需要明确下面几个要素:具体事项,谁来解决,反馈时间。

首先,每个人要跟进的事项要具体。模糊的表述是没法作为事情去跟进的,只有问题具体,结果才可控。

其次,负责人最好只有一个。如果存在协同配合的跟进人,也要明确一个负责人,为这件事负责,多人跟进极易导致没人跟进。

再者,每个事项需要责任人给反馈时间。如果当场给不了时间的,可以要求责任人给出“什么时候能给反馈时间”,以保障计划可跟进。如果要落实的事项比较多,产品经理可以可以制定一张跟进表,拉个群,定期和大家复盘进展。

就本案例而言,可以参考如下跟进表:

拿到每一件事的结果是产品经理未来的核心价值,不管是和技术排查问题,还是和业务共同推进找增长点,我们把为过程负责转向为结果负责。

四、结构化表达

好的沟通是要让对方理解我们表达的意思。口若悬河、滔滔不绝往往并不能帮助我们达到目的。产品经理在传递信息时,秀逻辑不是我们的目的,让别人理解我们的逻辑才是重要的。

在上一节里提到的数据报表问题,我们就把解决问题的思路结构化的分为了三个部分,分别是埋点的排查、采集的排查、报表的排查。沟通的时候是这样的:

P:数据报表目前不准确,我们根据之前的了解,客户端和数据这边都自查没问题,但是结果是不对的,所以我们把这个问题拆开看看,然后我们各自对下是否有遗漏。
技术们:OK,好的
P:之前和大家了解下来,数据报表其实分3个部分,分别是客户端埋点,数据中台进行采集、数据分析组进行报表产出对吧?这个大流程是这样的吗?
技术们:对的
P:那我们先一部分一部分的看?
技术们:好
P:我们先一起来看埋点部分吧,待会再讨论采集和报表端。埋点这边主要是看客户端是否埋了,我这边看来核心要检查三个方面:1、活动的埋点是不是否埋了?2、扩展字段是否都带了?3、不同的版本是否都带了。这3个大家看怎么去检查,如果都没问题的话,埋点这趴就可以过了
客户端技术:对的,主要是这三块
P:那下面会后,客户端的同学去检查下,然后给个反馈?其他人有补充吗?
客户端技术:OK。
其他技术:没什么补充
P:好的,那么再看下采集端怎么排查?
技术们:好

后面详细的过程就不再赘述了,主要的沟通思路把复杂的问题进行结构化的拆解,一部分一部分的聊透,可以边聊的时候板书如下,便于大家核对和补充:

五、沟通的状态

大家工作中有没有遇到过这样的场景,新来的技术再问一个产品老人的时候,有时候这个产品老人声音大点,语气硬点,这个技术就没怎么再问了。

类似的情况发生在产品经理身上也有,我团队里有个小伙伴有业务疑问的时候喜欢瞎琢磨,实在琢磨不出来会去找平时熟悉的几个运营专员去了解,然后也没有得到自己想要的答案,就是不敢去问运营的负责人。虽然现在大部分互联网公司都是扁平化在管理,但是还有相当一部分的产品经理有这样的心态问题。

其实大可不必,我们之所以去沟通,核心还是为了了解到我们想要的信息,平常心对待,不管是面对什么样的角色——面对上级,做好数据准备、做好要问问题、客观描述客观回答。面对新人,不敷衍,多有些细心和耐心。不要用有色眼镜看待沟通对象和需求。

 

作者:归归类;公众号:归归类,微信号:gglei666

本文由@归归类 原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. v

    回复
  2. 5WHYS和结构思维法用得挺好!

    来自广东 回复