用户调研、需求拆解、逻辑思维、数据分析、交互设计……所有市面上常见的PM核心能力中，最少被提及的就是沟通能力。
可事实上，沟通能力是PM最核心的基础能力。
有这样一句话形容PM的岗位性质——“没有管理权力的管理岗位”，我们从来都不是真正的“经理”，只是产品的“代言人”。
所以具备良好的沟通能力，才能保证PM顺利开展产品工作。如果逻辑能力决定了一个PM的能力上限，那么沟通能力就决定了一个PM的能力下限。
1. 什么是沟通
人是社群动物，沟通占据了我们每天的绝大部分时间，工作会议是沟通、日常闲聊是沟通、发朋友圈也是沟通。我们无时无刻不在主动发起沟通，也同时在接受多方发起给我们的被动沟通。
1.1 沟通的本质
其实沟通的本质很好概括：有目的性地信息传递，无论是一对一，还是一对多地沟通，我们都在传达特定的信息，以直接或间接地达到自己的某种目的。
大家可能很好理解工作中的沟通，因为我们总在不断和他人协作，以达到自己的工作目标。但是对于生活类的沟通，比如朋友间的闲聊，或则发个朋友圈真的算沟通吗？我真是为了某种目的在沟通吗？
发朋友圈有目的吗？
答案：是的。无论是朋友间的闲聊，还是一条朋友圈，我们都在经营自己的“人设”，随口的一句话也是我们的价值观输出。我们渴望朋友的认可和“点赞”，期望对方能够认同自己的观念和行为。
没有人向周围传递信息是渴望被否定的，除非我们的本意就是被否定，然而这本身就是目的了。
1.2 沟通的基本要素
沟通的内容和方式千罗万象，但是有效的沟通都必然包括4个基本要素：
- （沟通）发起者：每次沟通都会有一个主动发起方；
- （沟通）接收者：沟通的被动接收方（一个或多个）；
- 信息：包含发起者产生的原始信息和通过信息媒介加工后传递给接收者的加工信息；
- 目的/意愿：所有的沟通都由发起者的目的驱动，而发起者的目的需要转化为接收者的行动意愿来实现。
这4个基本要素的相互转化又会涉及到5个基本转化流程：
- 发起沟通：沟通发起者产生原始信息；
- 传递信息：原始信息经过媒介转化为沟通接收者可以获得的加工信息；
- 接受沟通：沟通接收者成功接收加工后的信息；
- 采取行动：沟通接收者根据接收到的加工信息采取一定行动；
- 获得反馈：沟通发起者观测接收者的行为，判断目的是否达成以决定否继续沟通。
沟通的信息流
举个例子：我给同事A发邮件通知明天下午4点开会，那么：
- 发起者——我自己；
- 接收者——同事A；
- 原始（加工）信息——明天下午4点开会；
- 目的（意愿）——同事A明天下午4点按时出席会议。
1.3 沟通的常见问题
评价沟通是否有效的标准非常简单：发起者的目的是否达成。那么常见的无效沟通都有哪几类呢？
1.3.1 无效的信息发起（目的–>>原始信息）
沟通的第一步是发起者将自己的“目的”转换为“原始信息”。
完整且清晰地表达信息是沟通的基石，如果发起者本身都无法准确的将自己的目的转化成清晰的语言结构，那么这次沟通大概率是无效的。
1.3.2 无效的信息传递（原始信息–>>加工信息）
信息失真是一种相对常见的沟通问题，发起者构建的原始信息与接收者收到的加工信息经过传递媒介处理后往往存在一定偏差。疫情期间大火的Zoom就是一种适合多对多的高效沟通媒介。
无效的信息传递主要发生在两个方面：
- 时效性；比如天气信息，我告诉小明昨天下雨了，是无法帮助小明决策现在出门是否要带伞的。
- 准确性；比如跨语言沟通，我对不懂中文的Michael说一段古诗，无论他用什么翻译软件都很难理解。
1.3.3 无效的信息内容（加工信息–>>行动意愿）
当接收者准确及时地收到信息时并不意味着发起者的目就达成了，接收者是否能产生相应的行动意愿依赖于信息本身对接收者是否有价值。
无效的信息内容意味着信息发起者完全没有考虑过接收者的感受，强行把自己的目的附加给接收者，所以这种信息传递方式注定是低效的。后面在展开PM的日常工作时会详细介绍这点。
2. 如何高效沟通
作为PM，我们需要跟项目组的多个角色打交道，同时以项目负责人的角色去推进整个产品的演进和迭代。正是我们工作内容的特殊性，也要求PM学会高效且有目的性地沟通。
下面我们根据不同的沟通角色，介绍下常见的沟通技巧和方式。
2.1 Leader
对大多数人来说，上下级沟通是一件比较难的事情。因为我们总是给不同的职位叠加了太多不必要的刻板印象。超越岗位本身的职能去考量一个人，本身就是一件事情很不合理的事情。
产品的上下级沟通更多是需求拆解的承接，大多数情况下PM是作为信息的接收者。这时沟通的重点在信息流转的末段——我们有没有将接收到的信息转化成Leader预期的行为。
与PM Lead沟通的信息流
这里我推荐大家采用“复述”的方式建立一套反馈机制，把自己对任务的理解和计划，用语言传达给Leader。
这样反复不断的沟通和修正，能让发起者和接收者始终确认双方有没有达成一致的行为预期。而且这样的“复述”应该始终贯穿在版本周期中，不断将与预期不一致的行为和结果反馈给Leader，并及时确认后期的调整策略。
很多新人PM总是不敢提出自己对原始任务的疑问，只知道埋头把Leader布置的任务做完。
其实这样并不叫高效工作，PM的高效从来都不是通过工作量来评定的，“做对的事情”比“把事情做好”要更重要。所以这里的沟通更强调反馈，强调不断修正内部团队的预期。
2.2 开发
与开发沟通是PM的硬技能，我们的PRD就是产品和技术沟通的范本，如果开发都看不懂你的PRD，那么大概率这个需求会实现地有偏差。
在和这个典型角色的沟通中，PM往往是作为发起者将自己的需求传递出去，所以这个时候的重点在需求沟通的中后段，PM需要确认开发同学收到了正确的信息，并转化为自己预期的行为。
与开发沟通的信息流
下面我们将和开发的沟通拆解到具体的业务场景中来分析：
2.2.1 版本开发
高效沟通是敏捷开发的必要条件，PM必须不断提高自己的信息质量，减少信息传递的失真，确保开发同学充分理解需求并以合理的时间实现出来。
2.2.1.1 需求评审
需求评审的前提是一份完备的PRD，那么什么是好的PRD？这个问题就和PM是否需要懂技术一样，在各个论坛上反复被提及。
然而答案永远都是”no silver bullet”. 每个公司，甚至每个项目组都有自己的工作模式和方法，很难给一套完全标准和规范的PRD模板给所有PM。
但是我们可以按照沟通的信息流拆解出PRD的关键要素，这样可以清晰地定义出高效的沟通（PRD）应该是什么样子的。
举个例子，我们想开发一个注册的功能：
- 发起者——PM；
- 接收者——一线开发；
- 原始信息——用户注册功能需求说明（PRD）；
- 媒介——电子文档和企业内部沟通工具；
- 加工信息——用户库表设计说明，用户库表更新接口说明，等等（开发文档）；
- 目的——提供用户注册功能，扩大用户量；
- 意愿——实现开发文档的功能细节。
整个沟通的信息流中，最容易出现偏差的就是原始信息到接受信息的转换过程。
我们的PRD写得再长，再详细，对一线的开发同学而言都要落到具体的开发文档。所以高效的PRD必然站在开发同学的角度去描述需求。特别是涉及到功能的极端情况和运转逻辑时，一定要尽量用开发可以理解的语言来表述。
还是用注册的例子，比如我们想表达注册时需要校验邮箱的有效性。初级PM的描述可能就是“注册时需要校验邮箱有效性，有效则……无效则……”。
这里的逻辑本身没有什么问题，但是这里有两个很明显的细节问题：
- 什么时候校验？
- 什么是有效？
我知道很多PM都觉得，“这都很基础啊，光标移出输入框校验不是很通用的交互逻辑吗？邮箱的有效性应该是业内的基础常识了，我为什么还要浪费时间去说明具体的校验规则呢？”
可是当我们站在开发的角度，就会发现自己的理解变得完全不一样了：
- 所有的行为都有触发条件：“注册时校验”——那我应该只用在点击注册按钮的时候校验了。不是每个开发都有UE经验，PM想当然的交互逻辑一般都实现得有偏差。
- 所有的判断都有一套运转规则：“邮箱有效性”——那我是需要调第三方邮件服务确认邮箱真实存在，还是只用判断邮箱格式（@和.）?
回过头来看，这次的沟通是不是很低效呢？
有预期不一致功能细节，还有需要二次确认的实现方式。当然，辩证地看这个例子，我们的PRD是不是需要面面俱到，事无巨细都提到呢？当然不是。
就像前面提的，每个公司，每个团队都是不一样的，我们的重点是站在开发的角度看待需求。
如果是合作多年的团队，特别是核心组员没有变化过的团队，或则项目组内部对交互组件和常见的功能逻辑已经有了规范的情况下，都是没必要长篇累牍地描述的。
记住了PRD的重点始终是高效沟通，而不是刻意雕琢细节。
2.2.1.2 需求开发
理想状态下，在需求开发的过程中，PM是不应该频繁地和开发同学沟通的。因为信息传递的工作已经在前一个步骤完成，这个阶段PM只需在提测时确认自己的需求是否被完全实现。
然而理想情况毕竟是少数，比如参与需求评审的技术一般不直接参与需求开发，所以PM在这个阶段也会遇到给不同的接受者反复沟通的情况。
当然我们的沟通目的仍然没有任何变化，但是沟通的形式值得我们注意。因为和一线开发同学沟通时，往往不像需求评审那么正式。
所以我们要做到：所有的重点沟通都可追溯，这个时候就要求我们选择一个可靠的沟通媒介。口头交流的确更为方便，但是每次沟通结束后，通过即时聊天工具或则邮件通知对方二次确认是一个更好的选择。
2.2.1.3 紧急需求
没有人会喜欢紧急需求，大家都更愿意做有准备的事情。
但是商业环境往往不允许我们的产品完全按照计划迭代，所以PM一定要拥抱变化。对于紧急情况得有自己的沟通套路，而不是单纯的传达命令。记住，所有的沟通都是有目的的，而不是单纯的传达信息。
“这个需求是老板要做的”、“这个功能是大客户加急要的”、“临时加个班，明天上线这个新功能”……
没有人会喜欢这样的沟通方式，这种情况下开发的行动意愿只来源于工作职能的强制要求，接收者并没有真正地产生主观行动意愿。这样的沟通一定是不顺畅，而且低效的，也难怪大家都会讨厌紧急需求了。
这个时候PM需要运用自己的同理心，扩展传递信息的维度，不要因为时间紧急就只说功能。产品的愿景和价值对开发也是一种激励，而且可以更好的确保开发同学理解需求，转换为更为妥善的行动。
当然如果连你自己也不清楚这个紧急需求的目的，那么所有后续的沟通中你都无法保证真实的目的是否达成，因为你只是沟通信息流中的媒介，不是发起者。
2.2.2 日常问题
2.2.2.1 线上Bug
产品自身是无法解决bug的，所以及时和开发沟通，辅助开发解决bug才是我们的重点。这种特殊场景下，我们需要格外注意信息传递的质量。
2.2.2.1.1 提高信息本身的质量：PM需要准确地描述如何复现bug，以及bug的影响范围和优先级。
很多PM会忽视bug的影响范围，但这个条件往往决定了我们如何判定bug的优先级。而且如果产品能给出准确的影响范围而不是简单的“highest”描述，也更能让开发同学意识到自己面临的是什么样的服务压力，时间的紧迫感会更强烈。
注意并不是所有的bug都是最高优先级，有些bug影响范围非常有限，而且需要占用极大的开发资源来修复，这个时候PM需要站在更高的角度看待这个问题，在沟通前有取舍的做前置判断。
2.2.2.1.2 选择合适的传递媒介：不要留言、不要留言、不要留言。
对于已经判定为高优先级的bug，一定要确保接收者及时地收到信息。能够当面沟通，就不要用即时聊天工具。同样的信息用不同的媒介传达，接收者的感知是完全不一样。
无法当面沟通，一定要打电话（包括语音电话）。有些新人PM会因为非工作时间或则职位上的差异，不敢直接联系对应的开发同学。这样一定是大错特错的，不要把事情的重要性交给其他人去决定，还是那句话：沟通是有目的的，不是单纯的传递信息，沟通就结束了。
2.2.2.2 技术咨询
技术咨询是PM日常工作中的常规内容：提前论证设计方案的可行性；新的技术（比如AI）趋势对产品功能的影响；合作产品接口文档的具体实现功能，等等……既然是咨询技术问题，那么就一定要求PM学会用技术语言沟通。
这些场景也同时在回答业内的一个经典问题——产品经理需要懂技术吗？答案——需要。
如果PM完全不懂技术，PM发起的原始信息和开发理解的接收信息就有着巨大的鸿沟，这样的沟通必然低效。因为这意味着开发需要理解PM的业务知识来将信息转化为行为。所以只有PM懂技术，才能让双方尽可能地站在同一个维度沟通问题。
产品的工作就是不停地和技术打交道，和技术的沟通难度也是最大的。所以一定要学会如何和技术沟通，做真正的沟通发起者，而不只是信息的传递媒介。
2.3 销售
一般B端产品的PM会频繁和销售沟通，特别是大型B端产品，有时销售代表也会参与Roadmap的讨论和制定。考虑到PM往往是作为接收者介入到和销售的沟通流程中，所以PM必须把握住销售的真正目的，才能制定出合理的Roadmap。
与销售沟通的信息流
销售主动发起的沟通都是围绕产品功能展开：
- 我们有没有这个功能；
- 我们什么时候有这个功能；
- 我们能不能尽快开发这个功能？
1）和2）适用于销售售卖产品给中小型客户；这类沟通的目的十分明确，本身并不存在太多的技巧性可言。但是如果这类沟通频繁地发生在PM的日常工作中，则说明整个项目的信息流转机制是有问题的。
这里不再延展讨论如何去提升企业内部的信息流转效率，但是就这类沟通而言，PM应该尝试建立自动化的反馈机制，在销售发起沟通之前就更快速的响应销售的目的。
比如建立内部的knowledge base，加强对销售人员的培训，以及产品roadmap的及时同步等。
3）适用于销售售卖产品给大型客户；大部分PM都比较抗拒这类沟通，因为销售的目的是改变PM的原有计划，PM容易站在产品的长期愿景出发，本能地排斥这类需求。
但是产品在不同的生命周期，有着不同的商业目标，PM也更应该综合商业价值去考量销售提出功能的价值。
实际的沟通中，销售往往喜欢比较强势地发起沟通，PM接收到的信息往往是非A即B的选择，所以这时PM得主动要求提升信息的质量，无论是信息本身的广度还是深度，都会更有利于PM作出对应的决策。
如果PM评估需求有价值，决定调整既定的Roadmap，除了积极地回复销售结论，最好能尝试缩短信息的传递路径，直接向客户确认可交付的产品和预期时间，避免信息传递失真带来的无价值损耗。
如果PM评估需求价值不高，决定不做任何调整，一定要站在销售的角度去反馈结论。
比如我们认为当前产品的重点是中小型客户，目前产品的服务能力还不足以支撑大客；那么除了解释当前产品的不足以外，还要解释我们集中资源服务中小型客户能方便销售在该目标群体地售卖。
和销售沟通一定要敢于说“NO”，要明确整个公司的大方向是一致的，从长远来看PM也是在帮销售提升获得更多佣金的机会。
2.4 客服（CSM）
这个角色的职能是对已经使用产品的用户进行支持和协助。C端产品一般叫客服，B端产品大多已经将这个角色定义为客户成功经理（CSM）。下面我们都用客服代指这个角色。
与客服沟通和销售有一定的相似性，因为他们都在代表真实的客户向我们反馈意见（大多是功能建议）。
区别在于客服的反馈往往没有那么激烈，除非产品初始的售卖对象不对，否则和客服沟通都不太会发生逼着PM改Roadmap的场景。
另外对于B端产品而言，PM也会需要经常成为沟通发起者，定期对CSM团队培训功能，以及分享最佳实践方案（Best Practice）。
所以真实的沟通场景中，PM有时会是发起者，有时会是接收者。
与客服沟通的信息流
2.4.1 接收沟通
这个场景下的重点是选择合适的媒介和挖掘沟通的真实目的。
优秀的客服可以当做半个产品经理，他们能理解和推测客户提出疑问的动机，能够有效的Push PM重新审视自己的Roadmap是否合理。
然而实际情况下，大部分客服只把自己定位为一个传声筒的角色。所以即使PM只是沟通的接收者，也要尝试去提升整体的沟通效率，真实地解决客户的问题。
2.4.1.1 选择合适的媒介
大部分客户问题都会被客服拦截，所以更要确保需要流转给PM的单，及时高效地传递给了我们。
除了企业内部的转单工作流程，也必须建立起工单升级的机制，确保客服有多种渠道触达PM，至少在客服和PM间建立一种即时通讯方式。
2.4.1.2 挖掘沟通的真实目的
客户都很难表达清楚自己的需求，更不要说经过客服处理过的信息了。网上已经有很多讨论如何挖掘客户真实需求的文章了，这里也不再赘述。
大家只需要注意，一定要让客服提供上下文，需要拿到客户真实的反馈原文或录音，避免信息失真是挖掘真实目的的基础。
2.4.2 发起沟通
PM主动发起的沟通都是关于产品功能的培训或则运营策略的调整，需要注意的是这类沟通一般是1对多的形式。所以存档我们的培训视频和文档，是保证PM持续触达客服同学的最佳媒介。
另外，需要明确我们的沟通目的并不是单纯为了培训客服团队，真实的目的应该是提升客户服务质量，培训客服只是我们达到这个目的一种方式，我们也可以建立线上自助教程，引导客户自己去学习和答疑。
所以这类沟通一定要有反馈，PM需要去监控甚至考核每次培训后的效果，用目的去考量每次沟通（培训）是否有效，而不是将发起沟通这件事本身作为目的。
3. 结语
我们每天都会通过很多形式沟通，却往往忽视了沟通的重点————目的。
作为沟通发起者我们要达成目的，作为沟通接收者我们要理解对方的目的。PM也不用过分追求沟通的技巧，我们的工作核心始终在于思辨，想清楚沟通的目的和沟通接受者的角色，自然能以无招胜有招。