pm(作为PM)是什么职位？
编辑导语：沟通有利于消除误解，建立相互信任的人际关系。在实际工作中，一个人的沟通协调能力很重要。善于沟通往往会使人在工作中迅速打开局面，大大提高工作效率。交流是双向的。一方面你要得到对方的真实信息，另一方面你要把你的真实信息传达给对方。作为一个PM，真的能沟通吗？
用户调研、需求拆解、逻辑思维、数据分析、交互设计.在市场上所有常见的PM核心能力中，沟通能力是最少被提及的。
其实沟通能力才是PM的核心基础能力。
有一句话描述了PM —— & quot没有管理权力的管理岗位& quot。我们从来没有真正的& quot经理& quot但是一个& quot发言人& quot对于产品。
因此，具备良好的沟通能力可以保证PM顺利开展产品工作。如果说逻辑能力决定了一个PM的能力上限，那么沟通能力决定了一个PM的能力下限。
1.什么是沟通？人是群居动物。沟通占据了我们每天大部分的时间。工作会议是交流，日常聊天是交流，交朋友是交流。我们无时无刻不在主动发起沟通，同时也接受多方发起的被动沟通。
1.1沟通的本质其实沟通的本质总结的很好：有目的的信息传递，无论是一对一还是一对多的沟通，我们都是在传递特定的信息，以直接或间接达到自己的某种目的。
你可能很理解工作中的沟通，因为我们总是在和别人合作实现我们的工作目标。但是真的是为了生活交流而交流吗，比如朋友之间聊天，或者发朋友圈？我真的是出于某种目的在交流吗？
发朋友圈有目的吗？
回答：是的。无论是朋友之间聊天，还是朋友圈，我们都在经营自己& quot个人设计& quot，而不经意的一句话也是我们价值观的输出。我们渴望朋友的认可和& quot赞& quot，并期望对方认同自己的想法和行为。
没有人在向周围发送信息时渴望被否定，除非我们的初衷是被否定，这本身就是目的。
1.2沟通的基本要素沟通的内容和方式多种多样，但有效的沟通必须包括四个基本要素：
发起者：每个通信都有一个活动的发起者；接受者：传播的被动接受者；信息：包括发起方产生的原始信息和由信息媒介处理后传送给接收方的处理信息；目的/意愿：所有的沟通都是由发起者的目的驱动的，发起者的目的需要转化为接受者的行动意愿。这四个基本要素的相互转化将涉及五个基本转化过程：
发起通信：通信发起者生成原始信息；信息的传递：将原始信息通过媒介转化为通信接收者可以获得的处理信息；接收通信：通信接收方成功接收处理后的信息；采取行动：根据接收到的处理信息，与接收方沟通采取一定的行动；得到反馈：沟通发起者观察接受者的行为，判断目的是否达到，决定是否继续沟通。通信信息流
比如：我给同事A发邮件通知我明天下午4点开会，所以：
发起者——本人；接收者——同事a；原(处理)信息——明天下午4点开会；目的(意愿)——同事A明天下午4点准时参加会议。1.3沟通常见问题评价沟通有效性的标准很简单：发起者的目的是否达到。那么无效沟通的常见类型有哪些呢？
1.3.1无效的信息发起（目的原始信息）
沟通的第一步是发起者转换他的& quot目的& quot变成& quot原始信息& quot。
完整清晰地表达信息是沟通的基石。如果发起者自己不能准确地
信息失真是一种比较常见的传播问题，发起方构建的原始信息经过传输介质的处理后，与接收方接收到的处理信息之间往往存在一定的偏差。Zoom，疫情期间的一把火，是一种适用于多对多情况的高效传播媒介。
无效的信息传递主要发生在两个方面：
时效性；比如天气信息，我告诉小明昨天下雨了，不能帮小明决定现在出门要不要带伞。准确性；比如跨语言交流，我对不懂中文的迈克尔说了一句古诗。无论他用什么翻译软件，都很难理解。1.3.2无效的信息传递（原始信息加工信息）
当接收者准确及时地接收到信息，并不意味着发起者的目的已经达到。接受者能否产生相应的行动意愿，取决于信息本身对接受者是否有价值。
无效的信息内容意味着信息的发出者已经完全无视了接受者的感受，强行将自己的目的附加在接受者身上，所以这种信息传递方式注定是低效的。这一点会在后面PM的日常工作中详细介绍。
2.如何高效沟通作为一个PM，我们需要处理好项目团队的多重角色，同时以项目负责人的角色推动整个产品的进化和迭代。是我们工作的特殊性要求PM要学会高效有目的的沟通。
下面根据不同的沟通角色，介绍一下常用的沟通技巧和方法。
iao-origin="h3">2.1Leader对大多数人来说，上下级沟通是一件比较难的事情。因为我们总是给不同的职位叠加了太多不必要的刻板印象。超越岗位本身的职能去考量一个人，本身就是一件事情很不合理的事情。
产品的上下级沟通更多是需求拆解的承接，大多数情况下PM是作为信息的接收者。这时沟通的重点在信息流转的末段——我们有没有将接收到的信息转化成Leader预期的行为。
与PMLead沟通的信息流
这里我推荐大家采用“复述”的方式建立一套反馈机制，把自己对任务的理解和计划，用语言传达给Leader。
这样反复不断的沟通和修正，能让发起者和接收者始终确认双方有没有达成一致的行为预期。而且这样的“复述”应该始终贯穿在版本周期中，不断将与预期不一致的行为和结果反馈给Leader，并及时确认后期的调整策略。
很多新人PM总是不敢提出自己对原始任务的疑问，只知道埋头把Leader布置的任务做完。
其实这样并不叫高效工作，PM的高效从来都不是通过工作量来评定的，“做对的事情”比“把事情做好”要更重要。所以这里的沟通更强调反馈，强调不断修正内部团队的预期。
与开发沟通是PM的硬技能，我们的PRD就是产品和技术沟通的范本，如果开发都看不懂你的PRD，那么大概率这个需求会实现地有偏差。
在和这个典型角色的沟通中，PM往往是作为发起者将自己的需求传递出去，所以这个时候的重点在需求沟通的中后段，PM需要确认开发同学收到了正确的信息，并转化为自己预期的行为。
与开发沟通的信息流
下面我们将和开发的沟通拆解到具体的业务场景中来分析：
2.2.1版本开发
高效沟通是敏捷开发的必要条件，PM必须不断提高自己的信息质量，减少信息传递的失真，确保开发同学充分理解需求并以合理的时间实现出来。
2.2.1.1需求评审
需求评审的前提是一份完备的PRD，那么什么是好的PRD？这个问题就和PM是否需要懂技术一样，在各个论坛上反复被提及。
然而答案永远都是”nosilverbullet”.每个公司，甚至每个项目组都有自己的工作模式和方法，很难给一套完全标准和规范的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懂技术，才能让双方尽可能地站在同一个维度沟通问题。
产品的工作就是不停地和技术打交道，和技术的沟通难度也是最大的。所以一定要学会如何和技术沟通，做真正的沟通发起者，而不只是信息的传递媒介。
一般B端产品的PM会频繁和销售沟通，特别是大型B端产品，有时销售代表也会参与Roadmap的讨论和制定。考虑到PM往往是作为接收者介入到和销售的沟通流程中，所以PM必须把握住销售的真正目的，才能制定出合理的Roadmap。
与销售沟通的信息流
销售主动发起的沟通都是围绕产品功能展开：
我们有没有这个功能；我们什么时候有这个功能；我们能不能尽快开发这个功能？1）和2）适用于销售售卖产品给中小型客户；这类沟通的目的十分明确，本身并不存在太多的技巧性可言。但是如果这类沟通频繁地发生在PM的日常工作中，则说明整个项目的信息流转机制是有问题的。
这里不再延展讨论如何去提升企业内部的信息流转效率，但是就这类沟通而言，PM应该尝试建立自动化的反馈机制，在销售发起沟通之前就更快速的响应销售的目的。
比如建立内部的knowledgebase，加强对销售人员的培训，以及产品roadmap的及时同步等。
3）适用于销售售卖产品给大型客户；大部分PM都比较抗拒这类沟通，因为销售的目的是改变PM的原有计划，PM容易站在产品的长期愿景出发，本能地排斥这类需求。
但是产品在不同的生命周期，有着不同的商业目标，PM也更应该综合商业价值去考量销售提出功能的价值。
实际的沟通中，销售往往喜欢比较强势地发起沟通，PM接收到的信息往往是非A即B的选择，所以这时PM得主动要求提升信息的质量，无论是信息本身的广度还是深度，都会更有利于PM作出对应的决策。
如果PM评估需求有价值，决定调整既定的Roadmap，除了积极地回复销售结论，最好能尝试缩短信息的传递路径，直接向客户确认可交付的产品和预期时间，避免信息传递失真带来的无价值损耗。
如果PM评估需求价值不高，决定不做任何调整，一定要站在销售的角度去反馈结论。
比如我们认为当前产品的重点是中小型客户，目前产品的服务能力还不足以支撑大客；那么除了解释当前产品的不足以外，还要解释我们集中资源服务中小型客户能方便销售在该目标群体地售卖。
和销售沟通一定要敢于说“NO”，要明确整个公司的大方向是一致的，从长远来看PM也是在帮销售提升获得更多佣金的机会。
这个角色的职能是对已经使用产品的用户进行支持和协助。C端产品一般叫客服，B端产品大多已经将这个角色定义为客户成功经理（CSM）。下面我们都用客服代指这个角色。
与客服沟通和销售有一定的相似性，因为他们都在代表真实的客户向我们反馈意见（大多是功能建议）。
区别在于客服的反馈往往没有那么激烈，除非产品初始的售卖对象不对，否则和客服沟通都不太会发生逼着PM改Roadmap的场景。
另外对于B端产品而言，PM也会需要经常成为沟通发起者，定期对CSM团队培训功能，以及分享最佳实践方案（BestPractice）。
所以真实的沟通场景中，PM有时会是发起者，有时会是接收者。
与客服沟通的信息流
2.4.1接收沟通
这个场景下的重点是选择合适的媒介和挖掘沟通的真实目的。
优秀的客服可以当做半个产品经理，他们能理解和推测客户提出疑问的动机，能够有效的PushPM重新审视自己的Roadmap是否合理。
然而实际情况下，大部分客服只把自己定位为一个传声筒的角色。所以即使PM只是沟通的接收者，也要尝试去提升整体的沟通效率，真实地解决客户的问题。
2.4.1.1选择合适的媒介
大部分客户问题都会被客服拦截，所以更要确保需要流转给PM的单，及时高效地传递给了我们。
除了企业内部的转单工作流程，也必须建立起工单升级的机制，确保客服有多种渠道触达PM，至少在客服和PM间建立一种即时通讯方式。
2.4.1.2挖掘沟通的真实目的
客户都很难表达清楚自己的需求，更不要说经过客服处理过的信息了。网上已经有很多讨论如何挖掘客户真实需求的文章了，这里也不再赘述。
大家只需要注意，一定要让客服提供上下文，需要拿到客户真实的反馈原文或录音，避免信息失真是挖掘真实目的的基础。
2.4.2发起沟通
PM主动发起的沟通都是关于产品功能的培训或则运营策略的调整，需要注意的是这类沟通一般是1对多的形式。所以存档我们的培训视频和文档，是保证PM持续触达客服同学的最佳媒介。
另外，需要明确我们的沟通目的并不是单纯为了培训客服团队，真实的目的应该是提升客户服务质量，培训客服只是我们达到这个目的一种方式，我们也可以建立线上自助教程，引导客户自己去学习和答疑。
所以这类沟通一定要有反馈，PM需要去监控甚至考核每次培训后的效果，用目的去考量每次沟通（培训）是否有效，而不是将发起沟通这件事本身作为目的。
我们每天都会通过很多形式沟通，却往往忽视了沟通的重点————目的。
作为沟通发起者我们要达成目的，作为沟通接收者我们要理解对方的目的。PM也不用过分追求沟通的技巧，我们的工作核心始终在于思辨，想清楚沟通的目的和沟通接受者的角色，自然能以无招胜有招。
本文由@One原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Pexels，基于CC0协议
下一篇：宝马i3纯电动车需要保养的吗