产品经理:达成共同的目标,才是有效沟通的关键

6 评论 3525 浏览 22 收藏 13 分钟

身为产品经理,沟通是一项必备的基础技能,因为你不仅需要与业务人员、测试人员、运营人员、研发人员、设计师等人沟通,你还不想要与老板或者领导沟通。

本人曾经与一些做产品的朋友同事聊过,偶尔会问到一个问题:

“作为一名产品经理,最关键的一项技能,你觉得是什么?”、

大部分人不假思索的都会答到是“沟通”。沟通能力且不说是不是最关键,但绝对是成为一名合格产品经理的基础技能。作为一名产品负责人,频繁与之沟通的对象如下:

达成共同的目标,才是有效沟通的关键

有人说产品经理在团队中发挥的作用就好比胶水,把人粘在一起,把各项资源粘在一起。那要保证团队的凝聚力,自然要建立起有效的沟通,但不同的沟通对象,沟通方式自然也不同。

老板/领导

与公司的老板/领导沟通,往往沟通的内容大都是产品战略层面问题,以及老板对于行业、市场、人性、商机等方方面面的洞察。那老板与我沟通的目标,自然是为了让我了解他的想法,从而完善一个可执行方案。所以,完成方案即是我与老板的共同目标,与老板的沟通更多是围绕这个目标展开的。具体如何落地方案,不是本文的重点,在此只介绍一些沟通的关键点:

1. 在接受老板的想法时,遇到不靠谱的创意,不要急于否认。先接受这个创意,随后提出自己的疑惑、顾虑。互联网产品的优势就是快速迭代,反复试错,一切要等产品上线后看效果,不要妄下定论。

2. 要善于填补老板的思维空缺。公司老板都是比较忙碌的,作为产品负责人要抓住老板想法的关键点,随后更完善、更系统的思考。将老板考虑不到(没时间考虑的)整理好,并且提炼,能用图表的尽量用图表汇报,言简意赅。一个产品、一个项目、一个功能的完成时间,在老板心里,向来都是以上线的时间为标准的,方案能够及早的确认通过,这将会为后续设计、研发、测试、上线等赢的更多时间。

3. 要掌控沟通(汇报)的节奏。主动沟通往往要比被动沟通效果要好,在组织会议沟通之前,尽可能与参会其他人员(运营人员、业务人员)私下建立沟通,并将需要确定问题一并梳理,随后组织会议沟通(汇报),切记,不要让老板追着自己要进度。

业务人员

隔行如隔山,本人之前一直从事的是互联网电商、社交行业,随后进入了现在这家互联网金融公司。初入公司可谓对业务并不了解,而刚入职我的第一个任务就是要做公司进件系统、风控审核系统、贷后管理系统等。

记得第一次与业务人员开会,对一些专业名词“T+0”、“三证合一”、“详版征信”、“简版征信”、“仲裁”等等完全没有概念。与业务人员的沟通,我感觉自己像个记者,不停的采访各个业务人员,了解他们的需求,挖掘他们的痛点。随着对业务的深入了解以及对功能的不断完善,与业务人员间的沟通问题越来越多了。

不同业务人员的需求点是有矛盾的,例如:

进件人员(销售):尽可能少的提交进件资料,从而让第一步变得高效。

风控审核人员:尽可能全的让进件人员收集资料,从而保证审核期间资料完善。

不仅不同业务人员的需求是矛盾的,系统在流程设计上也有矛盾的地方,比如流程设计的严谨则必然不够灵活高效,管理层更希望流程严谨,而执行人员则更希望灵活,这样更贴合实际。以上种种问题,造成了与业务人员沟通极不顺畅。随后,我重新梳理了下各自的目标:

进件人员(销售)目标:报件方便,快速的得到风控审核结果,拿到销售提成,完成销售业绩。

风控审核人员目标:审核效率高,避免错审、漏审引起绩效扣分。 系统目标:提升协同工作效率,业务数据积累。

有了共同目标,随后的沟通中,我更加能够站在各业务人员的角度去看问题,同时原本沟通的话术也变了,一些产品层面的专业词汇很少用了,更多的是用他们能听懂的简单表达。原本他们不懂也不愿意多问,到现在每次都有好多问题需要同他们解答。

由于业务复杂,我不可能让每个业务人员都能了解系统每个环节的设计细节,但是可以找到不同业务人员的目标,通过建立共同的目标去解决他们的痛点,从而达到整个设计系统的平衡。

运营人员

与运营人员的沟通,往往是和产品营销结合的需求沟通。运营大部分的需求无非围绕于拉新、促活、提升品牌知名度等。运营人员的目标很明确且一致,也有人说产品即运营,所以按理说与运营人员的沟通应该是最没有障碍可言的,但本人觉得与运营人员沟通是最困难的。

运营人员最频繁的需求应该是专题活动了,尤其是活动密集期。专题页的转化率无疑是运营人员最最核心的目标,但是我发现许多活动策划人员作出的方案完全没有一个预期,导致活动结束后查看运营数据,都不太好衡量此次活动是否算的上成功,同时也没有总结复盘的时间,因为下一个活动方案已经要提交确认了。

同时一些活动策划人员,过于关注与产品的表现层,页面上一个按钮放左边,还是放右边,是圆角,还是矩形,对于转化率的影响真的没有想象中的那么大(有时争论不休,还建议要做a/b测试,在时间紧,任务重,热点稍纵即逝的情况下,研发根本没有时间完成a/b测试的工作)。

虽然有着共同的目标,但是沟通过程并不令人满意。我尝试着进一步去量化运营人员的目标,比如本次活动投放的用户群是什么?用户肖像特征是什么?本次活动打动他们的条款有哪些?类似的活动案例有没有?引流后的转化大致能达到多少等,将以上这些问题梳理清楚之后,再与其沟通本次活动要达到什么目标时,发现他们已不再过于关注页面的按钮,而是更加精雕细琢的去修改文案,精简活动流程。同时在策划案中,也增加了好多案例,以及对各个案例优缺点汇总梳理。

研发人员

记得以前看过一片文章,讨论的是产品经理到底要不要懂技术。有的人觉得产品经理不要懂技术,这样不会被技术所限制,可以更好的发挥自己创意;有的人觉得产品经理要懂技术,这样更有利于和研发人员沟通。

当时看到这个帖子,自己还暗自窃喜,因为之前有多年的研发经验,与技术人员的沟通向来是没有太大障碍的。同时也喜欢与技术同事们一起研究一些新的工具,讨论一些技术架构、表结构设计等。但是这不代表与研发人员沟通就完全没有问题。

本人接触到的研发人员70后、80后、90后都有,研发人员大部分性格都属于比较谦虚好沟通的。每次有些棘手的问题或无从下手的问题给到研发人员,多数情况下都会得到的回答是“我等下网上搜搜,看能不能解决。”所以产品经理不管懂不懂技术,只要需求合理,一般研发人员都是会尽力配合的。与研发沟通需求过程当中,一定不要说:“XXXX功能很简单啊,你看,XXX产品都实现了。”这种话既不会给研发人员增加自信,也不会降低问题在他心中复杂程度,除了引发争吵,毫无作用。

如果遇到研发人员并不清楚自己能否实现该功能,同时这个功能你又特别希望他能够帮你尝试并实现,你会怎么做?记得一次做PC端的一款C/S产品,无意间看到了猎豹浏览器的安装与卸载页面,我当时就被那个酷炫的交互动效吸引了,正巧也在做我们软件的安装、卸载界面改版,就演示给设计师看。然后很快他就设计了一款我们都很满意的效果图,给领导看后,领导也十分满意。之后就给研发人员看,看到效果图后,他眉头紧锁,我就知道完了,不太好实现。随后我就跟他说,没关系先尝试下,真不行就算了,这个当飞机稿重新再设计一个。

由于当时我们研发实力不强,新版上线时间迫在眉睫,我最后放弃了这个方案。过了没几天,研发的同事突然告诉我,他实现了!我还很莫名,原来他也喜欢最初的效果图,也知道大家都更喜欢这个效果,所以他觉得因为自己做不出来,从而完不成目标,不是他的风格,他一定要想办法实现。

设计、测试

与设计、测试人员的沟通之所以放在一起说,是因为与他们沟通,相对来说较为顺畅。设计的工作从来都不是按照原型图填充颜色那么简单,也不参是考别人的产品比葫芦画瓢。

测试人员亦是如此,不单单是验证产品的功能、性能,还应当帮助研发人员定位问题,寻找产品漏洞等。与他们的有效沟通更多是帮助他们进步,使他们成为触类旁通的的“T”字形人才。

 

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 受益匪浅啊,尤其是策划那段,了不起了不起

    来自上海 回复
    1. 谢谢

      回复
  2. 吵架也是沟通的一种方式,不过吵架还是不要形成一种惯用方式,伤身体……自信的人更容易得到别人的信任。

    回复
  3. 文章从各个岗位沟通思维做了讲述,给我很多启发,从一个理性的视角去看每个岗位的沟通需求,有利于更好完成工作任务。唯一遗憾是设计岗内容并不丰富,希望不要厚此薄彼,也分享下。谢谢

    回复
    1. 谢谢,由于我的环境跟设计沟通较为畅快,设计岗在我们的团队中赋能较大,更多时候我更认为她们不是单纯的做视觉、交互,而是名产品设计师。

      回复
  4. 想起之前和朋友的讨论,我的想法是:为什么产品一定要会吵架就是有狼性,如果口才足够好、足够硬气,不一定需要吵架就能解决问题。在还没走到那一步的时候,问题就已经被解决了。一切的目的都是做成,吵架就是过程,无论哪种沟通方式,都是为了寻找和优化成最合理的方案,说服他人是非必要的。如果就是意见不合,那就以结果为证。所以,产品的品质不在于狼性,而在于合理的自信。

    来自北京 回复