产品经理的沟通与合作

先说结论

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

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

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

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

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

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

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

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

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

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

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

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

先听再说

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

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

少撕一点

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

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

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

勇于认错

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

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

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

目的手段

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

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

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

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

本文作者 @像西泽一样 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！