你和一个人的交谈，实际上是六个人在交谈。你以为的你，真实的你，他以为的你；他以为的他，真实的他，你以为的他。
01
产品经理 60% 的工作是沟通，有效的沟通是产品工作的第一步。但很多时候，对方想说的和对方讲出来的不一定一致。
比如：你问一个研发小哥，某个旧功能点的现状，他告诉你说，“这个地方线上应该没问题”。他可能只是在说：“这个功能用得比较少，我不太熟，我印象中是OK的”。具体有没有问题其实不太确定。
再深入一点，你为什么要问这件事？因为你要做优化，你可能要了解一下，这个位置需不需要改。所以你需要了解的，是这个功能的现状的具体一点是怎么处理的，逻辑是什么。你可能得了解到它原本的样子，再做判断。那最好找到有效的研发文档，或者当初开发的人，或者请研发帮忙翻一下线上代码。（迭代超过2年的系统，可能文档和大家的记忆都不够用，只好一起看代码 *^* ）
你的用户，你的需求方，他们的要求可能是主观的，可能是片面的。他们可能非常缜密地在使用一套你完全不熟悉的逻辑在思考，然后用他们熟悉的方式，简洁地表述自己的想法和建议：”这里能不能加个xxx页面“——是不是很熟悉？
在C端，我们都知道，产品不能照着用户反馈做需求，用户的看法可能是片面的。但是在后台，你的用户可能就当着你的面来提需求，或者还会直接向老板提需求然后转给你。这种场景下如果用户要求：”在xxx位置加个xxx页面，用来做xxx功能，实现xxx效果“，产品经理很容易就直接照做了。
但如果真的照做，上线后反馈可能是：这跟我想的不一样啊！你可以反驳：你当初就是这么说的呀！他会补充一大堆来解释你不知道的背景和诉求，同时指出你做的和他想要的差在哪，为什么。那一大堆解释，他以为你知道，你不问他他就默认你全部知道。而你的反驳毫无意义，因为问题没解决，你得继续做。
上面是一个”说“的例子，反过来，听的人会遇到一样的问题。你在听的时候，你的大脑也会调用自己的知识结构、自己的思维方式，去处理听到的信息，然后存储为”你认为你听到的“。
”他认为他说的“和”你认为你听到的“，中间可能隔着东非大裂谷。
这就是沟通要解决的问题。
02
有趣的是，有时候你的用户解释了一大堆，其实并不完全符合事实，而事实不一定是大家想要的。这怎么判断呢？还是要相互沟通，相互理解。前置沟通清楚，好过上线后改正。通过沟通把大家的自我认知、和客观事实都搞清楚，补上彼此间的认知偏差，你们大概也就知道你们需要什么了。
特别地，当你收到老板的需求的时候。老板可能没空跟产品聊那么多。但也别就这样就去做了。仔细思考一下，与同事讨论一下，与需求的关联人聊一聊，出一版方案给老板过目，如果有难处提前向老板或者上司讲一讲……主动沟通，也许沟通完会找到更简单的解决问题的办法。不要在上线后，等老板来问”这为什么跟我想的不一样“，也不要等老板问进度的时候才说有困难。
产品经理要跟很多人沟通。每个人的语言能力不同，思维方式不一致，沟通起来也不一样。想要提高沟通效率，产品可以主动去适应大家。比如：注意多听，多问，多引导。从对方的角度去沟通，忘掉你产品逻辑的那一套，先去接受对方的逻辑、理解对方的表达，再按对方逻辑表述你的想法。就像开头那段引用，你和一个人交谈，实际是在和六个人交谈。但你可以先找到”他以为的他“，再向他介绍”他以为的你“，六个人就变成了两个人，事半功倍。
我在工作中遇到过各种各样的沟通误会，忍不住想，有没有可能大家都做到客观的表达？但后来我开始怀疑：所谓”客观的表达“，是存在的吗？我现在觉得它不存在，它也不重要。比起客观的描述，我们更需要多数人的共识。在很多时候，多数人的共识，基本就是客观事实（社科领域尤其如此）。
最后的最后，认知偏差也不全是阻碍，某些也可以被利用来达到沟通效果。有些营销增长的逻辑，也是这样来的（营销某种程度上就是商家与客户之间的沟通）。
但产品经理最终的目的是解决问题。我们需要的不是别人说了什么，而是通过沟通了解需求本质，然后把需求转化成方案，一步一步推进落地。”说“终究是为了”做“。
总而言之，言而总之。做产品，沟通是个体力活，且一定不能省。但还是可以找到一些方法可以主动练习，提高一些效率，少一些撕逼。
祝各位产品，评审顺利。
这篇本来应该写沟通、决策、项目管理。但”沟通“写完已经挺长，后面两个下一篇吧。
讲沟通的帖子挺多的，我自己也看过不止一遍。当初读的时候感觉看懂了，实际却直到我自己一步一个脚印地试过了，反思了，总结了，我才觉得自己真的明白了。
但也不敢说就全明白了。知易行难，不外如是。共勉。
作者：Conan Sze，微信公众号：Conan产品研习社，我的产品笔记，走过的路，踩过的坑，遇到的朋友们。
