pm是什么意思？(作为PM如何沟通)沟通有助于消除彼此之间的误解，建立信任的人际关系。在实际工作中，一个人的沟通协调能力很重要。善于沟通往往会使人在工作中迅速打开局面，大大提高工作效率。交流是双向的。一方面你要得到对方的真实信息，另一方面你要把你的真实信息传达给对方。作为一个PM，真的能沟通吗？

调研、需求拆解、逻辑思维、数据分析、交互设计…在市场上所有常见的PM核心能力中，最少被提及的是沟通能力。

其实沟通能力才是PM的核心基础能力。

有一句话描述了PM的职位性质——“没有管理权力的管理职位”。我们从来不是真正的“管理者”，而是产品的“代言人”。

因此，具备良好的沟通能力可以保证PM顺利开展产品工作。如果说逻辑能力决定了一个PM的能力上限，那么沟通能力决定了一个PM的能力下限。

1.什么是沟通？

人是群居动物，交流占据了我们日常的大部分时间。工作会议是交流，日常聊天是交流，交朋友也是交流。我们一直都是主动发起沟通，同时也接受多方发起的被动沟通。

1.1沟通的本质

其实沟通的本质总结得很好:有目的的信息传递，无论是一对一还是一对多的沟通，我们都是在传递特定的信息，以直接或间接达到某种目的。

每个人都可能很容易理解工作中的沟通，因为我们总是与他人合作来实现我们的工作撷英目标。但是生活交流，比如朋友间聊天，或者发朋友圈，真的是交流吗？我真的是出于某种目的在交流吗？

发朋友圈有目的吗？

回答:是的。无论是朋友间的聊天，还是朋友圈，我们都在运行着自己的“个人设定”，一句不经意的话也是价值观的输出。我们渴望朋友的认可和“赞美”，期待对方认同自己的想法和行为。

没有人在传递信息的时候渴望被否定，除非我们的初衷是被否定。然而，这本身就是目的。

1.2沟通的基本要素

沟通的内容和方法多种多样，但有效的沟通必须包括四个基本要素:

(通信)发起者:每个通信都会有一个活动的发起者；

收件人:通信的被动收件人；

信息:包括发起方产生的原始信息和通过信息媒介传递给接收方的经过处理的信息；

目的/意愿:所有的沟通都是由发起者的目的驱动的，发起者的目的需要转化为接受者的行动意愿。

这四个基本要素的相互转化将涉及五个基本转化过程:

发起通信:通信发起者生成原始信息；

信息传递:将原始信息转化为传播接受者可以通过媒介获得的经过处理的信息；

接受通信:通信接收方成功接收处理后的信息；

采取行动:根据接收到的处理信息，通知接收方采取一定的行动；

得到反馈:沟通发起者观察接受者的行为，判断是否达到目的来决定是否继续沟通。

通信信息流

比如:我给同事A发邮件通知我明天下午4点开会，所以:

发起者——我自己；

接收者——同事A；

原始(加工)信息——明天下午4点开会；

目的(意向)——同事A明天下午4点准时参加会议。

1.3常见沟通问题

评价传播效果的标准很简单:发起者的目的是否达到。那么无效沟通的常见类型有哪些呢？

1.3.1无效消息发起(目的-> >原始消息)

传播的第一步是发起者把自己的“目的”转化为“原始信息”。

而完整清晰的信息表达是沟通的基石。如果发起者自己不能准确地把自己的目的翻译成清晰的语言结构，那么这种沟通极有可能是无效的。

1.3.2无效信息传输(原始信息-> >处理信息)

信息失真是一个比较常见的通信问题，发起方构建的原始信息和接收方接收到的经过传输介质处理后的处理信息之间往往存在一定的偏差。Zoom是疫情期间适用于多对多的高效沟通媒介。

无效的信息传递主要发生在两个方面:

时效性；比如天气信息，我跟小明说昨天下雨了，但是不能帮小明决定现在出门要不要带伞。

准确性；比如跨语言交流，我对不懂中文的迈克尔说了一句古诗。无论他用什么翻译软件，都很难理解。

1.3.3无效信息内容(处理信息-> >行动意愿)

当接收者准确及时地接收到信息，并不意味着发起者的目的已经达到。接受者能否产生相应的行动将取决于信息本身对接受者是否有价值。

无效的信息内容意味着信息的发出者没有考虑到接受者的感受，强行把自己的目的附加在接受者身上，六种造字方法举例所以这种信息传递方式注定是低效的。这将在稍后PM的日常工作开始时详细描述。

2.如何高效沟通

作为PM，我们需要处理项目团队的多重角色，作为项目负责人推动整个产品的演进和迭代。正是我们工作的特殊性，也要求PM要学会高效、有目的的沟通。

下面根据不同的沟通角色，介绍一些常用的沟通技巧和方式。

2.1领导者

对于大多数人来说，上下级之间很难沟通。因为我们总是在不同的立场上叠加太多不必要的刻板印象。超越岗位本身的功能去考虑一个人，是一件非常不合理的事情。

产品的上下级之间的沟通更多的是需求拆解的承担，PM在大多数情况下是信息的接受者。这时候沟通的重点就在信息流的末端——我们是否已经把接收到的信息翻译成了领导者的预期行为。

与项目经理沟通的信息流

这里推荐你通过“复述”建立一套反馈机制，把你对任务的理解和计划用文字传达给领导。

这样的反复沟通和修改，会让发起者和接受者始终确认双方是否达成了约定的行为预期。而且这样的“复述”要始终贯穿版本周期，不断向领导反馈与预期不符的行为和结果，及时确认后期的调整策略。

很多新人PM对于原来的任务总是不敢问自己的问题，只知道埋头完成领导布置的任务。

其实这不叫高效工作。PM的效率从来不是用工作量来评价的。“做正确的事”比“把事情做好”更重要。所以这里的沟通强调反馈，不断修正内部团队的期望。

2.2发展

与开发沟通是项目经理的硬技能，而我们的PRD是产品和技术沟通的典范。如果开发看不懂你的PRD，这个需求实现起来有很大概率会有偏差。

在与这个典型角色的沟通中，PM往往作为发起者传递自己的需求，所以此时的重点是需求沟通的中后期。PM需要确认发展学生收到了正确的信息，并将其转化为他们预期的行为。

交流与发展的信息流

下面，我们将把与开发的沟通分解成具体的业务场景进行分析:

版本开发

高效的沟通是敏捷开发的必要条件。PM必须不断提高自己的信息质量，减少信息传递的失真，确保发展学生充分理解要求，并在合理的时间内实现。

2.2.1.1需要审查

复习的前提是一个完整的珠三角，那么什么是好的珠三角呢？这个问题和PM是否需要懂技术一样，在各种论坛上被反复提及。

然而，答案总是“没有灵丹妙药”。每个公司，甚至每个项目组都有自己的工作模式和方法，很难给所有PM一套完整的标准和规范的PRD速记法模板。

但是我们可以根据沟通的信息流来拆解PRD的关键要素，这样就可以清晰地定义有效沟通(PRD)应该是什么样子。

例如，我们想开发一个注册函数:

发起者-PM；

接收器-前线开发；

原始信息-用户注册功能需求规范(PRD)；

媒体-电子文档和内部通信工具；

处理信息——用户库表设计说明、用户库表更新接口说明等等(开发文档)；

目的-提供用户注册功能，扩大用户数量；

愿意-实现开发文档的功能细节。

在交流的整个信息流中，最有可能产生偏差的是从原始信息到接收信息的转换过程。

不管我们的PRD写得多长多详细，都会落到具体的开发文档里，给一线的开发同学看。因此，有效的PRD必须从发展学生的角度描述需求。尤其是涉及到函数和运算逻辑的极端情况，一定要尽量用易懂的语言表达出来。

或者用注册的例子。比如我们想表达注册时需要检查邮箱的有效性。主PM的描述可能是“注册时需要检查邮箱的有效性，如果有效……………………”。

逻辑本身没有错，但有两个明显的细节:

我知道许多首相认为，“这都是非常基本的。检查光标移出输入框不是通用的交互逻辑吗？邮件的过敏性鼻炎用药有效性应该是业内的基础知识。我为什么要浪费时间解释具体的验证规则？”

但是当我们站在发展的角度，我们会发现我们的理解变得完全不同:

所有的行为都有一个触发条件:“注册时检查”——那么我应该只在点击注册按钮时检查。不是每个开发都有UE经验，PM想当然的交互逻辑一般都是有偏差的实现。

所有的判断都有一套操作规则:“邮箱有效性”——我是需要检查第三方邮件服务来确认邮箱的存在，还是只判断邮箱格式(@ jiawenshehe。)?

回过头来看，这个苟家文社的百科是不是效率很低？

存在预期的不一致的功能细节，以及需要重新确认的实现方法。当然，辩证地看这个例子，我们珠三角是不是需要面面俱到，面面俱到？当然不是。

前面说过，每个公司，每个团队都不一样，我们的重点是从开发的角度看需求。

如果是合作多年的团队，尤其是核心成员没有变化的团队，或者交互组件和常用功能逻辑在项目团队内部已经标准化，就不需要赘述了。

请记住，PRD的重点始终是高效的沟通，而不是细节。

2.2.1.2需求发展

理想情况下，PM在需求开发的过程中，不要和开发同学频繁交流。因为上一步已经完成了信息的传递，所以PM在这个阶段只需要确认其要求是否已经完全实现。

然而，理想的情况毕竟是少数。比如需求评审涉及的技术一般不直接参与需求开发，所以PM在这个阶段会遇到与不同接收人的反复沟通。

当然，我们交流的目的不变，但交流的形式值得我们关注。因为和一线开发同学交流的时候，往往没有需求评审那么正式。

因此，我们应该做到:所有的关键通信都可以追溯。这时候就要求我们选择一个可靠的通信媒介。口头沟通确实更方便，但每次沟通后，用即时聊天或邮件的方式通知对方二次确认是更好的选择。

2.2.1.3的迫切需求

没有人喜欢急用，大家更愿意做有准备的事情。

但是商业环境经常不允许我们的产品完全按照计划迭代，所以PM必须拥抱变化。你应该有自己的紧急情况沟通程序，而不是简单地传递命令。记住，所有的交流都是有目的的，不仅仅是传递信息。

“这个需求是老板需要做的”，“这个功能是大客户急需的”，“加个临时班，明天推出这个新功能”…

没有人会喜欢这种交流方式。在这种情况下，发展出来的行动意愿只是来自工作职能的强制性要求，接受者并不真正具有主观的行动意愿。这种沟通一定是不通畅的，低效的，难怪大家都讨厌急用。

这时候PM就需要利用自己的同理心来拓展传递信息的维度。不要因为时间紧迫就只讲功能。产品的愿景和价值也是对开发的激励，它可以更好地确保开发学生了解需求，并将其转化为更好的行动。

当然，如果你连这种迫切需要的目的都不知道，那么你就无法保证在之后的所有沟通中是否会达到真正的目的，因为你只是沟通信息流中的媒介，而不是发起者。

日常问题

2.2.2.1在线Bug

产品本身解决不了bug，及时与开发者沟通，协助开发者解决bug是我们的重点。在这种特殊情况下，我们需要特别注意信息传递的质量。

2.2.2.1.1提高信息本身的质量:PM需要准确描述如何重现bug，以及它的影响范围和优先级。

很多PM会忽略bug的范围，但是这个条件往往决定了我们如何确定bug的优先级。而且，如果产品能够给出准确的影响范围，而不是简单的“最高”描述，也会让开发生更加清楚自己面临的是怎样的服务压力，时间的紧迫感也会更强。

注意，并不是所有的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端产品，有时候会有销售代表参与路线图的讨论和制定。考虑到PM经常以接收者的身份参与到与销售的沟通过程中，PM必须掌握销售的真正目的，才能制定出合理的路线图。

与销售沟通的信息流

销售发起的沟通都是关于产品功能的:

我们有这个功能吗；

我们什么时候有这个功能；

能不能尽快开发这个功能？

1)和2)适合向中小客户销售产品；这种交流的目的很明确，本身没有太大的技巧。但如果这种沟通在PM的日常工作中频繁发生，说明整个项目的信息流机制是有问题的。

这里不讨论如何提高企业内部的信息流效率，但就这种沟通而言，PM应该在销售发起沟通之前，尝试建立自动反馈机制，更快地响应销售的目的。

比如建立内部知识库，加强销售人员的培训，及时同步产品路线图等。

3)适合向大客户销售产品；大部分PM对这种沟通比较抵触，因为销售的目的是改变PM原来的计划。PM容易站在产品的长远眼光上，本能地拒绝这种需求。

但产品在不同的生命周期有不同的商业目标，PM也要通过整合商业价值来考虑销售促进功能的价值。

在实际沟通中，销售往往喜欢相对强烈地主动沟通，PM收到的信息往往是非A即B的选择，所以PM不得不主动要求提高信息的质量，无论是信息本身的广度还是深度，都会更有利于PM做出相应的决策。

如果PM用价值评估需求，它决定调整已建立的路线图。除了积极回复销售结论，最好尽量缩短信息的传递路径，直接与客户确认可交付的产品和预期时间，避免信息传递失真带来的无价值损失。

如果PM评估需求值不高，决定不做任何调整，就必须从销售的角度反馈结论。

比如我们认为当前产品的重点是中小客户，当前产品的服务能力不足以支撑大客户；那么除了说明目前产品的不足之外，还要说明我们集中资源服务于中小客户，可以方便在这个目标群体的销售。

和销售沟通的时候一定要敢于说“不”，明确整个公司的大方向是一致的。从长远来看，PM也是一个有助于提高销售额和获得更多佣金的机会。

2.4客户服务

这个角色的功能是支持和帮助使用过文佳社会百科全书产品的用户。c端产品一般被称为客户服务，B端产品大多将这个角色定义为客户成功经理(CSM)。下面我们都用客服来指代这个角色。

和客服沟通、销售有一定的相似性，因为他们都是代表真实客户给我们反馈(大多是功能性建议)。

不同的是，客服的反馈往往没有那么强烈。除非产品最初的销售对象是错误的，否则与客服的沟通不太可能迫使PM更改路线图。

此外，对于B端产品，PM还需要经常担任沟通发起者，定期对CSM团队进行职能培训，并分享最佳实践。

所以在真实的通信场景中，PM有时可以是发起者，有时可以是接收者。

与客服沟通的信息流

接收通信

在这种情况下，重点是选择适当的媒体，并探索传播的真正目的。

优秀的客服可以作为半个产品经理，能够理解和推测客户提问的动机，能够有效推动PM重新审视自己的路线图是否合理。

然而现实中，大部分客服只把自己定位为传声筒。所以，即使PM只是沟通的接受者，也要努力提高整体沟通效率，真正解决客户的问题。

在2.4.1.1选择合适的媒体。

大部分客户的问题都会被客服拦截，所以更重要的是保证需要转给PM的订单及时高效的送到我们这里。

除了企业内部的订单流转工作流程，还需要建立工单升级的机制，保证客服有多个渠道到达PM，至少建立客服与PM的即时沟通模式。

2.4.1.2探索了交流的真正目的。

客户很难把自己的需求表达清楚，更不用说客服处理的信息了。网上已经有很多文章讨论如何挖掘客户的真实需求，这里就不赘述了。

你需要注意的是，一定要让客服提供脉络，你需要得到客户原始的或者录音的真实反馈。避免信息失真是挖掘真实目的的基础。

发起沟通

PM发起的沟通都是关于产品功能的培训或者运营策略的调整。需要注意的是，这种沟通一般是一对多的沟通形式。因此，将我们的培训视频和文档存档是确保PM能够持续接触到客户服务学员的最佳手段。

另外需要明确的是，我们沟通的目的不是单纯的培训客服团队，真正的目的应该是提升客服质量。培训客服只是我们实现这个目标的一个途径。我们还可以设置在线自助教程，指导客户自己学习和回答问题。

所以这种沟通一定要有反馈。PM需要在每次培训后监控甚至评估效果，用目的来考虑每次沟通(培训)是否有效，而不是以发起沟通本身为目的。

3.结论

我们每天都在用很多方式沟通，却往往忽略了沟通的关键点——目的。

作为沟通的发起者，我们要达到目的，作为沟通的接受者，我们要理解对方的目的。PM不必过于追求沟通技巧。我们工作的核心永远是投机。要想清楚传播的目的和传播接受者的作用，自然可以无招制胜。