pm是什么意思(作为PM如何沟通)

pm是什么意思？(作为PM如何沟通)沟通有助于消除误解，建立相互信任的人际关系。在实际工作中，一个人的沟通协调能力非常重要。善于沟通会让人在工作中迅速打开局面，大大提高工作效率。沟通是双向的。一方面，你必须获得对方的真实信息，另一方面，你必须向对方传达你的真实信息。作为PM，真的能沟通吗？

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

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

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

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

1.什么是沟通

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

1.1沟通的本质

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

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

送朋友有目的吗？

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

没有人在向周围传递信息时急于被否定，除非我们的初衷是被否定，这本身就是目的。

1.2沟通的基本要素

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

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

(通信)接收器:一个或多个被动通信接收器；

信息:包括发起方生成的原始信息和通过信息媒介处理后发送给接收方的处理信息；

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

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

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

传输信息:将原始信息转化为通信接收方可以通过媒介获得的处理信息；

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

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

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

通信信息流

例如:我给我的同事a发了一封电子邮件，通知我2021-09-29 下午4点开会，所以:

发起者——我自己；

接收者——同事a；

原始(处理)信息-2021-09-29 下午4点开会；

目的(意图)-同事A2021-09-29 下午4点准时参加会议。

1.3沟通的常见问题

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

1.3.1无效信息启动(目的–>:>;原始信息)

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

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

1.3.2无效信息传输(原始信息–>:>;加工信息)

信息失真是比较常见的沟通问题。发起方构造的原始信息与接收方经过传输介质处理后接收到的处理后的信息有一定的偏差。疫情期间的火力缩放是一种适用于多对多的高效通信媒介。

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

时效性；举个例子，我告诉小明昨天下雨了，所以我现在出去的时候忍不住帮小明决定要不要带伞。

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

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

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

无效的信息内容意味着信息的发端者根本没有考虑到接收者的感受，强行将自己的目的附加到接收者身上，所以这种信息传递方式注定是低效的。这一点在后面PM的日常工作中会详细描述。

2.如何高效沟通

作为项目经理，我们需要处理项目团队的多重角色，并作为项目领导者的角色促进整个产品的进化和迭代。正是我们工作的特殊性，要求PM学会高效、有目的的沟通。

下面我们根据不同的沟通角色介绍常见的沟通技巧和方法。

2.1领导者

对于大多数人来说，他们很难相互交流。因为我们总是在不同的位置叠加太多不必要的刻板印象。考虑一个人超越岗位本身的职能是不合理的。

上下层产品之间的沟通更多的是需求拆卸的承担，PM在大多数情况下是信息的接受者。此时，沟通的焦点在信息流的末端——我们是否已经将收到的信息转化为领导者的预期行为？

与项目经理领导沟通的信息流

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

这样的反复沟通和纠正，可以使发起方和接受方始终确认是否有约定的行为预期。而且这样的“复述”要始终贯穿于版本周期，不断向领导反馈与预期不符的行为和结果，及时确认后期调整策略。

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

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

2.2发展

与发展沟通是PM的硬技能，我们珠三角是产品与技术沟通的典范。如果开发不能理解你的珠三角，这种需求就很有可能发生偏差。

在这种典型角色的沟通中，PM往往充当着传递自身需求的发起者，所以此时的重点是需求沟通的中后期，PM需要确认开发学员收到了正确的信息，并转化为自己预期的行为。

信息流通与发展

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

2.2.1版本开发

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

2.2.1.1需要审查

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

然而，答案总是“没有银弹”。每个公司，甚至每个项目组，都有自己的工作模式和方法，很难给所有PMs一套完整的标准和标准的PRD模板。

但我们可以根据传播的信息流，把珠三角的关键要素拆解开来，这样就可以明确定义什么是有效传播(PRD)应该是什么样的。

例如，我们希望开发一个注册功能:

引发剂——PM；

接收机-一线开发；

原始信息-用户注册功能要求描述(prd)。

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

处理信息-用户库表设计描述、用户库表更新界面描述等。(发展文件)；

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

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

在整个通信(www.isoyu.com原创版权)信息流中，最容易产生偏差的是从原始信息到接收信息的转换过程。

不管我们的珠三角有多长多详细，都要落到一线发展生的具体发展文件里。因此，高效的PRD必须从发展学生的角度来描述需求。尤其是涉及到函数和运算逻辑的极端情况，一定要尽量用开发能理解的语言来表达。

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

逻辑本身没有问题，但这里有两个明显的细节:

我知道很多经前综合症患者认为，“这是非常基本的。光标移出输入框不是常见的交互逻辑吗？邮箱的有效性应该是行业的基本常识。我为什么要浪费时间解释具体的验证规则？”

但是当我们站在发展的角度时，我们会发现我们的理解已经完全不同了:

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

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

回头想想，这样的沟通是不是效率很低？

存在预期的不一致的功能细节，以及需要二次确认的实现方法。当然，辩证地看这个例子，我们的珠三角是不是需要面面俱到，每件事都提得很详细？当然不是。

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

如果是合作多年的团队，尤其是核心成员没有变化的团队，或者是项目团队内部的交互组件和通用功能逻辑已经标准化，那么就没有必要长篇大论的描述了。

记住，珠三角的重点永远是高效沟通，而不是刻意雕琢细节。

2.2.1.2需求发展

理想情况下，在需求开发过程中，PM不应该经常与开发和百特网科沟通。由于前一步已经完成了信息传递的工作，PM只需要在测试时确认其需求是否已经完全实现。

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

当然，我们交流的目的不变，但交流的形式值得我们关注。因为和一线发展生的沟通往往没有需求评估那么正规。

所以要做到:所有关键的沟通都可以追溯。此时，我们需要选择一种可靠的通信媒介。口头沟通确实更方便，但每次沟通后通过即时聊天工具或电子邮件通知对方第二次确认是更好的选择。

2.2.1.3的紧急需求

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

然而，商业环境通常不允许我们的产品完全按照计划迭代，所以项目经理必须拥抱变化。遇到紧急情况，要有自己的沟通套路，而不是简单的传达命令。记住，所有的交流都是有目的的，而不是简单的传递信息。

“这个需求是老板想做的”“这个功能是大客户急需的”“临时加一个班，新功能2021-09-29 上线”...

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

这时候PM需要用它的同理心来拓展传递信息的维度，不要因为时间紧迫而只谈功能。产品的愿景和价值也是发展的动力，可以更好地保证发展学生理解需求，并将其转化为更合适的行动。

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

2.2.2日常问题

2.2.2.1线上的Bug

产品本身无法解决bug，所以及时与开发沟通，协助开发解决bug是我们的重点。在这种特殊的场景下，我们需要特别注意信息传输的质量。

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

很多PMs忽略了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客户服务(CSM)

这个角色的作用是支持和协助已经使用过产品的用户。c端产品一般叫客服，B端产品把这个角色定义为客户成功经理(CSM)。下面我们都用客服来指这个角色。

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

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

另外，对于B端产品，PM也需要经常做沟通的发起者，定期培训CSM团队，分享最佳实践。

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

与客户服务沟通的信息流

2.4.1接收通信

在这个场景中，重点是选择合适的媒体，探索传播的真正目的。

优秀的客服，算是半个产品经理。他们可以理解和推测客户提问的动机，并可以有效地推动PM重新检查他们的路线图是否合理。

然而，在现实中，大多数客服只把自己定位为代言人。所以，即使PM只是沟通的接收者，也要努力提高整体沟通效率，真正解决客户的问题。

2.4.1.1选择了正确的媒介

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

除了内部订单传递工作流程外，还必须建立工作订单升级机制，确保客服有多个渠道到达PM，至少要在客服和PM之间建立即时沟通模式。

2.4.1.2挖掘了交流的真正目的

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

你只需要注意客户服务必须提供上下文，你需要从客户那里得到原始的或者记录的反馈。避免信息失真是挖掘真实目的的基础。

2.4.2发起沟通

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

另外，我们需要明确，我们沟通的目的不是单纯的培训客服团队，而是提高客服质量。培训客服只是我们实现这个目标的一种方式。我们还可以建立在线自助教程，指导客户自学和回答问题。

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

3.结论

我们每天都在以多种形式进行交流，但往往忽略了交流的重点——目的。

作为沟通的发起者，要达成目标，作为沟通的接受者，要了解对方的目标。PM不用太追求沟通技巧。我们工作的核心永远在于投机。如果我们想清楚沟通的目的，沟通接受者的作用，自然可以不劳而获。