产品经理的沟通与合作

本文跟大家谈一谈产品经理在工作中的沟通与合作,看用怎样的沟通技巧能够解决职场中的沟通问题。

产品经理的沟通与合作

先说结论

在和同事沟通的过程中,无论对方是产品、研发还是业务方,如何听懂对方的问题和表达清楚自己的想法,是有效沟通的本质。一个重要的原则是:先说结论,也就是先告诉对方自己要做什么或希望对方做什么,然后再说为什么要这样做,也即背景介绍,并且注意条理,分出一二三四。

我的同事里,不乏一些伶牙俐齿的人。但有些在和我沟通的过程中,常常会出现说了一大段话之后,我仍然一头雾水,不知道对方想表达什么。也许对方很清楚自己要做的事,但只是表述缺乏条理,甚至没有想过要先对自己的想法进行一番梳理,就一股脑儿地说了出来,结果就是想到哪儿说到哪儿。

其实表达清楚问题并不必须要口齿伶俐,关键在于有先有后,条理清晰。即使嘴巴不是那么利索,仍然可以通过清晰的表达方式,快速地让对方领会自己的意思。比如我在和团队里另一个小组的产品合作的过程中,就很好地体现了两种沟通方式的差别。

第一次,我找到那个小组的产品,希望他们配合实现一个需求。结果说了一通背景之后,对方仍然一脸疑惑,反问道:你到底希望我做什么?

这时候我才说出了结论,只是希望他们配合做一个很小的功能。后来我意识到了自己的沟通问题。同时,我想到了之前看过的《金字塔原理》,我没兴趣再去翻阅那本书,但在我印象里,那本书可以概括为:沟通时先说结论,然后解释;解释时纵向分层,横向分条。我开始有意地练习使用这个原则进行沟通。

又一次需要那个小组配合时,我找到同一位产品,直接说明了需要他们做什么。

“我们把这个字段拆成了两个字段,需要你们配合展示两个字段。”

为什么要拆成两个字段呢?因为一个字段满足不了两个团队的需求。

为什么满足不了两个团队的需求呢?因为这个字段,A团队是用来统计X数据的,B团队是用来和用户沟通过程中,作为参考信息的。如果以我之前的沟通方式,可能会是这样的。

“是这样,我们这边原来不是有个M字段么,是用来给A团队统计X数据的,后来B团队也用了这个字段,结果……”

这种先说背景的方式,如果问题简单还好,但如果问题复杂,则可能背景介绍占用了大段时间,对方却迟迟不知道你在说什么,最终总算明白了你的来意,却把前面的一大段背景介绍给忘掉了,还需要你重复一遍,这便是极其低效的沟通。而先说结论,既可以快速地让对方知道你的来意,又因为带着问题去听背景介绍,对方在沟通中也会和你有更多的互动,能让问题得到更加深入的讨论。

当然,需求评审的时候,还是要先介绍需求背景。以上所说,适用于平常的沟通。

先听再说

时常听到同事们在讨论问题时说,“让我说完”,“我先说完”,“等我说完”,“能不能让我把话说完”,有时候带着略微的恳求,有时候则是歇斯底里。互联网的节奏是高效快速,沟通似乎也不能慢条斯理,但很多时候欲速则不达,一味地求快,并不见得效果就好。在沟通问题时,听别人把话说完,比不断打断对方,只顾单方面地输出观点或者猜测对方意图,更能加快彼此的理解。

在听别人说的过程中,有些时候要顺着对方的思路去考虑问题,他为什么这么想,为什么这么说,原来是这个意思,原来是这个目的。这样才能更好地理解对方的意图,理解是为了更好地沟通,沟通是为了更好地解决问题。如果在缺乏理解的时候就一味地表达自己的观点,结果很可能是对方觉得受到冒犯的同时,沟通也迟迟没有结论。

少撕一点

特别反感一个字,“撕”,做了产品经理后,越发讨厌了。很多人形成了一种思维定式,觉得做产品就一定要随时做好吵架的准备,认为争吵是推动产品的必然产物。

我相信好的产品不是撕出来的,人们常说真理越辨越明,然而前提是谁来辨、怎么辨,无脑的人身攻击和恶语相向,并不能带来更好的结果。如果一开始就摆出一副战斗的姿态,对方很可能也会带着戒备之心。缺少平心静气的深入沟通,结果只会是沟通不足导致的产品缺陷,并进一步导致双方的不信任,由此进入恶性循环。

尽量去理解研发、业务方,多想想对方的难处、顾虑,为对方分忧,除非对方是蛮不讲理的人,一般会得到同样的对待。你希望别人如何对待你,你就如何对待别人。

勇于认错

甩锅常有,而认错不常有。我常常看到一些同事,在犯错的时候死不承认,极力甩锅,也极其尴尬。我也曾因为在和业务方沟通过程中,承认自己的错误,而被领导建议不要轻易认错。似乎认错就是承认自己能力的不足,认错就会失去别人的信任。

但我觉得,如果你总犯错,说明你的能力或态度一定有问题,大家对你一定有了基本的判断,甩不甩锅已经无所谓了。但如果你总体是靠谱的,只是偶尔犯错,认错并不会让你失去别人的信任,甚至反倒能够赢得信任,并且可以营造互相理解、勇于承担责任的团队氛围。当然,承认错误需要建立在合情合理的基础上。

不过,一些人甩锅并不是基于理性的考虑,更多是即时的反应,或者顾及自己的面子。而面对犯错的人,我们可以做的是,不要得理不饶人,以解决问题为目标,适当忽略锅的存在。

目的手段

产品人常说,要挖掘用户需求的本质。挖掘需求本质的关键,就是要区分目的和手段。

本人是做B端产品的,所以挖掘用户需求的方式,主要是和业务方直接沟通。我常发现这种情况,业务方会突然提出一个需求,需要改一个功能或者增加一个功能,有时候会觉得对方的需求无法反驳,觉得就该这么做。

但是聊着聊着,发现不对劲了,发现对方提出的实现方式有问题。其实业务方的目的是解决一个问题,但他们往往不是指出那个问题,而是直接给出功能修改建议,而功能只是解决问题的一种手段,可能还会有其它更好的手段——也即功能——来达到业务方的目的。

做产品如此,做人亦如此。

本文由 新媒体之家 作者: 像西泽一样 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
2

发表评论