十个模型，总结产品经理沟通方法论|产品经理|金字塔原理|非暴力沟通

“作为一名产品经理，你真的懂得沟通吗？”

诶，先别急着回答，看完文章，再重新思考下这个问题。

产品经理在日常工作当中，不夸张地说，沟通几乎是占据了40%的工作内容，与运营沟通，与开发沟通，与用户沟通，与领导沟通等。

学会如何更高效率地沟通，能够使事情事半功倍，也能够有效地推动产品项目的运转。

同时，我们沟通时，会运用到一些方式方法，通常我们会听到“结论先行”“数据佐证”“说清背景”等等的一些方式。

而这些具体的出处、来源又是哪里？

作为产品经理，在什么样的场景需要运用什么样的沟通方法？

这么一问，你是否对自己过往的沟通方式开始产生怀疑？究竟是随心而出，还是有一定的方法？

但并不是掌握了方法，就能够沟通无阻，毕竟沟通主要核心是内容，掌握了合适的方法只能够提升效率。

我将会先从沟通对于产品经理的作用引入，继而阐述市面上较为科学的沟通模型，再带入产品经理日常工作的沟通对象，与模型相论证，达到“方法+事例”的结合。

另附上本文导图框架，节约时间。若您感兴趣，可继续深入阅读；若不感兴趣，感谢光临。

为什么要学会沟通

很多朋友会觉得，不就是沟通吗？每个人都会。

其实不是的。

学会说话不难，学会好好说话很重要，简单谈下为什么要“学会沟通”。

1、好的沟通方式能够节省很多时间。

2、作为团队的“润滑剂”，恰当的沟通方式能够避免许多不必要的冲突

3、有效率的沟通能够提高项目的运转效率。

另外，推荐几本书，不一定有用，但蛮看看总没错。《非暴力沟通》、《金字塔原理》、《影响力》、《关键对话》......

但有一点说在前面，沟通的本质还是在于内容，不论是文章中提到的模型还是沟通实例，仅仅是抛砖引玉，套路永远都没办法凌驾于优质的内容之上，愿谨记。

当然，如果你是长着一张跟吴彦祖一样好看的脸那就另说了，当这篇文章说的都是废话即可

沟通模型

在市面上有很多关于沟通的方法及模型，我挑选出在产品经理日常工作/面试中会运用到的模型，总结了几个，供大家平时运用学习。

产品经理工作当中，主要沟通核心在于“结构化表达”、“说服他人”、“沟通效率”、“沟通逻辑性”、“讲故事的方法”，所选的例子也均为这些类型的模型。

要注意的是，仅在该部分列举模型的内容，并不多加展开，在第三部分：产品经理沟通实例在通过具体引用的模型来展开可使用在哪些场景中。

1、PREP原则（结论先行）

P代指Point-结论，R代指Reason-依据，E代指Example-事例，最后一个P还是point-重述结论。

Point-结论，结论先行，是沟通当中的黄金法则。不论沟通对象是谁，双方在进行沟通之前，都不一定有明确的背景，而此时，抛出自身明确的观点/结论至关重要，能够让对方清楚接下来的内容是围绕哪个观点来展开。

Reason-依据，在抛出结论之后，通过有效的数据，有力的事实验证结论的可靠性。通常我们在阐述依据的时候，往往会采用“我觉得”“我认为”“可能”“应该”这类不确定性且个人主观意愿很强的词语来阐述我们的论据，这是站不住脚的，同时也无法使得结论具有信服力。

减少形容词、副词的使用，通过数据、定理、模型等可靠的信息才能够作为可靠的依据。

Examle-事例，通过阐述可靠性的依据，较为枯燥。人脑对于形象的故事、场景类的描述接受度是较高的，通过事例，引起被沟通者的共情及想象。

Point-重述结论，通过事例，引起被沟通者的共情及想象。

通常PREP原则使用在书面沟通、语言沟通中。

2、FIRE模型

总体来看，是注意到一些事实，并且对事实进行解读，根据解读的结果，经历情绪反应，期望得到我们想要的结果。

Facts（事实）：事实是确实存在或发生的事情。它具有五个特点：具体、公正、客观、不带感情色彩和及时。事实是真实谈话的基础，通过事实，保持双方冷静，排除负面情绪所带来的影响。

Interpretation（解读）：事件发生时，我们会对事实进行解读，从而得出这一事实的目的或意义。这些解读建立在个人的经验和知识上。有时它会迎合我们的喜好，有时它是带偏见的解释。因为事实和解读之间的差异，大脑不会总能察觉。

Reaction（反应）：根据解读结果，我们会产生相应的情绪反应。

Ends（结果）：经历情绪反应后，我们就会期望某种结果。

FIRE模型能帮助我们认清哪些是事实，哪些是主观想法。它最大的好处就是，当你听到一个难以入耳的反馈时，它能帮助你平静理性地展开分析，从而得到一个有效的解决方案。

为了更好地聚焦事实，我们脑海中需要有一张完整的FIRE模型，假设有一个表格，包括事实、解读、反应、结果。你看到和听到什么，就填在事实这一栏；对于这些事实，你是怎么想的，填在解读这一栏；你有什么情绪或感受，填在反应这一栏；你需要什么，或者你希望得到什么，就填在结果这一栏。

3、STAR法则

Situation（情景）是所发生的事情的背景，在所阐述的事实中所发生的背景情况；

Tast（任务）是在背景环境下所承担的角色及所执行的任务，及要达成的目标；

Action（行动）是在任务当中如何去操作与执行任务的，重点是行动过程；

Result（结果）是付诸行动，完成任务后所达到的效果，一般是可量化的指标；

STAR模型代表着一个完整事件的四要素，也是基于此，通常在阐述事情的时候会使用，更注重行为，统筹帷幄，应对情景，是结构化叙事的原则。

通常使用在行为性问题和情境性问题的回答上。往往在面试、写简历等方面都会使用到。

eg：在什么背景(时间，场所Situation)做过什么样的工作/项目 (Task), 这个工作/项目最好与所应聘工作相关，怎么做的，和谁一起做的，自己在团队中的角色（Action)，最后的结果（Result)。

注：把「STAR 法则」当做一种核心思想，不追求生硬的表达，只追求在关键的时候，可以灵活运用

4、RIDE说服模型

RIDE说服模型是指R（risk）风险、I（interest）利益、D（differences）差异、E（effece）影响，通过暴露风险，阐述利益，继而引入差异性及影响，来说服他人，即为RIDE模型。

R（risk）风险：不采纳方案会带来的风险。根据从人的失去心理入手，心理学家卡尼曼提出了“前景理论”：大多数人在面临获得的时候是风险规避的；也就偏保守的选择，而另外不同的是，大多数人在面临损失的时候是风险偏爱的，愿意为此冒险；人们对损失比对获得更敏感。基于此，需要将风险暴露给对方。

I（interest）利益：采纳你的方案会带来的利益。从之前的抛出风险，降低对方心理阈值，继而引入利益点，提高预期，会使对方更好地接受。

D（Differences）差异：自身建议与其他方案的差异之处。与众不同的点能够让对方眼前一亮。

E（Effece）影响：方案本身所能带来的负面影响。太完美的东西反而不真实，小缺点但瑕不掩瑜。

在这个过程中，也有几个注意点：

阐述风险时，可适当放大风险，但切莫过于夸张；

而在利益引诱时，稍微点出采纳了方案可获得的利益即可，让对方自己去对比，无需将利益说的过于肯定，因为此时有了风险与利益的强烈对比，表达便具有了冲击力；

在谈论到建议时，尽量结合事实，增加说服力；

而最后一步，瑕疵是为了避免太过于完美，为了增强信任度，也别阐述太多瑕疵。

还有一些加分要点：例如阐述观点前先认同对方观点；对话时助于多放在“你”上面；创造第三者引述别人观点等等，这里就不再展开了。

整体来说，RIDE说服模型是利用人们心理“趋利避害”的天然潜意识，再加以对比的方式，使得更有说服效果。

5、SCRTV表达模型

SCRTV表达模型是指Scene（情景）、Conflict（冲突）、Reason（原因）、Tractics（策略）、Value（价值）；

穿起来则是：表情境-爆冲突-找原因-定策略-塑价值。

Scene：明确问题—是什么？

Conflict：提出疑问—怎么了？

Reason：分析原因—为什么？

Tactics：进行决策—怎么办？

Value：创造价值—成为什么？

通常我们在使用SCRTV模型时，符合人对于事情的体验路径：感观-情感-思考-行为-识别；

而人的思考路径是：是什么-怎么了-为什么-怎么办-成为什么？

思考之后，执行的路径是：分析-判断-推理-决策-评估。

而执行的路径，与SCRTV表达模型的契合度极高，这也就是为什么用SCRTV模型，在汇报工作、讲述方案的时候可以更有条理、更有逻辑叙述的原因。

6、SCQA表达模型

SCQA模型是一个“结构化表达”工具，是麦肯锡资询顾问芭芭拉·明托在《金字塔原理》中提出的。

S（Situation）情景：由大家都熟悉的情景、事实引入。

C（Complication）冲突：实际情况往往和我们的要求有冲突。

Q（Question）疑问：怎么办？

A（Answer）回答：我们的解决方案是什么？

通过陈述场景，由大家熟悉且认同的事，引导大家产生共鸣及代入感，然后引出冲突的内容（往往实际情况与我们的诉求有所冲突及不符），继而从冲突方面提出大家所关心的问题，最后阐述解决方案。

我们在日常使用SCQA中，并不一定非要严格按照“S情景（背景）——C冲突——Q疑问——A回答（解决方案）”结构来进行表达，各个结构是可以调换顺序以显出不同的表达风格和情绪，一般可以分为以下4种模式：

标准式：（SCA）背景-冲突-答案

开门见山式：（ASC）答案-背景-冲突

突出忧虑式（CSA）冲突-背景-答案

突出信心式：（QSCA）疑问-背景-冲突-答案

这边对于这几种方式不过多赘述，有兴趣的可以看看《金字塔原理》这本书。

7、沟通漏斗

沟通漏斗是，心里所想的是100%，由于沟通方式，所表达出来的只有80%，由于过程中的干扰因素，别人听到的只有60%，由于每个人理解能力不同，听懂的只有40%，由于执行力不同，行动的只有20%。

最终，当我们想得到100%的结果，最终实行的结果只有20%。

这也诠释了，沟通保证不失真的重要性。

而我们也可以通过一定的方法保证失真的最小化。

在第一个20%，源于没有记住表达内容的重点，条理混乱等，由此我们需要理清自身所想阐述的内容，无一遗漏且结构性有条理地表达。

第二个20%，源于阐述时有外界干扰，内容过长等，由此需要在这个过程中逐步记录，避免干扰。

第三个20%，源于个人理解能力不同，由此需要不时向对方确认是否听懂，是否有其他想法等，引发对方思考从而得知是否完全理解。

第四个20%，源于没有对过程进行监督，导致执行力无法达到预期值，由此需要建立监督体系，把控任务进度。

8、乔哈里视窗

乔哈里视窗，是由乔瑟夫和哈里在20世纪50年代提出的，是用来改善自我认知与组内个体之间的相互理解。将沟通的信息比作一个窗子，它被分为4个区域：公开区、隐蔽区、盲目区、未知区，人的有效沟通就是这四个区域的有机融合。

公开区：自己知道，他人不知道；往往关系越近、共同信息知晓越多的两个人公开区域会越大。

盲点区：自己不知道，他人知道；在很多情况下，我们都会有盲点区，自身的学识、所出的环境等等都会造成我们与对方所了解的信息不对等。

隐秘区：自己知道，他人不知道；造成隐蔽区的原因在于我们不好意思跟其他人说、忘了对其他人说、没沟通清楚造成误解、误以为别人知道等等原因。

未知区：自己不知道，他人不知道；也被称为“潜能象限”，每个人都有未知的区域等待被发掘。

在这四个区域当中，往往在产品经理岗位中能够得到比较大的启示则是“盲点区”、“隐蔽区”与“公开区”的转化关系。

而简单地说，从乔哈里视窗看来，也有几个在PM沟通中能遇到的问题。

“你所阐述的内容，和别人听到/理解的，很可能不一样”

“增加公开区的面积，学会向上管理，更好的利用资源”

“工作中减少隐蔽区，避免信息不对等”

9、电梯演讲

电梯演讲源于麦肯锡公司检验陈述报告的方法之一，而麦肯锡认为，一般情况下人们记得住一二三，记不住四五六，所以凡事要归纳在3条以内。

而三个步骤分别是：Hook吸引→Mutual Benefit给利→Call to Action收网。

Hook吸引：通过现状、存在问题、现状产生原因、解决方案等吸引对方注意力；

Mutual Benefit给利：提出具体解决方案，让对方意识到你的价值存在；

Call to Action收网：指出上述方法的依据及理由，并留下联系方式；

这是在众多商界当中流传的三个主要步骤

要注意的是，这框架并不是固定的，有典型的“提出问题-产品价值阐述-产品解决方案”的三段式，也有“痛点-解决方案-商业计划”的电梯演讲。

而对于产品经理，在介绍自身的产品，为了说清楚产品本身的价值，有更完整的方式。

为了[目标用户]，他们的[痛点或者问题]，我们的[产品名称]是一个[产品类型]，它能够[产品价值]，不同于[竞争对手]，我们的产品[竞争优势]。

10、GROW模型

在部分产品经理领域当中，当我们“一不小心”当上了领导，往往在于下属沟通的时候，会不自觉用命令、说教的方式去沟通，反而会得到适得其反的结果。而辅导沟通的方式之一是“用提问代替说教”，这样可以引导对方自己找到问题的解决方法，有效的避免对方产生抵触情绪，达到沟通顺畅，辅导有效的结果。

那么，该如何提问呢？可以采用GROW模型来进行提问。

GROW模型分为四部分，Goal（目标）、Reality（现实）、Option（方案选择）、Will（确认行动）。

Goal（目标）：通过提问，探索对方的目标，通过对方的思考跟表达，让对方也清楚自身的目标。因为往往很多人在做事情之前，由于种种原因（思考，岗位，精力等）仅停留在执行层面，没有办法清晰条理地思考。

常见的问题有：这件事/你的目标是什么？如何衡量达到了这个目标？什么时候可以达到这个目标？

题外话：至于目标的阐述，可以采用SMART模型，这边不再过多赘述。

Reality（现实）：通过阐述事实情况，了解达到目标/完成事情需要遇到的阻碍及困难点。

常见的提问有：现实情况如何？目前的背景涉及到哪些干系人，有什么态度？目前我们是怎么处理的？

Option（方案选择）：通过提问，引导对方自己想办法，通过思考，提出自身的解决方案。相反，不建议直接提建议，对方可能产生抵触情绪，在潜意识容易丢弃解决问题的责任。这个阶段最重要的倾听，需要多加评判，引导对方多思考几个方法。

常见的提问有：要解决这个问题，你觉得如何做呢？还有别的方法吗？这个方案有没有什么优缺点？

Will（确认）：最后一步是确认行动，根据前三步的铺垫，已经寻找到了解决方案，但由于种种原因，可能没有办法保证100%的执行。

常见的提问有：你选择哪个上述哪个方案呢？这个方案的时间、目标、准确执行是如何？目标中产生的困难有理清了吗？

由此，通过GROW能够使辅导沟通更加顺畅。切记，抛弃说教，与对方同一角度思考。

产品经理沟通实例

首先，了解了产品经理当中我们可以看到，日常要沟通的角色包含但不仅限于运营、技术、测试、客户、老板、下属等，沟通的角色之多，也难免“沟通能力”作为一个软技能，被视为如此重要。

下面就从几个沟通实例，来阐述下与各角色的沟通方式。

注：并不包含所有的场景，仅列举几个高频的沟通场景，再阐述该场景下的相应沟通方式；朋友们可举一反三进行深究。

1、与运营沟通

在于运营沟通的时候，会遇到的问题是：

①运营思维与产品思维不一致，导致思考需求的方向点不同，各有各的立场

②有时候运营提需求无法完善，探讨需求效率较低

在互联网中项目中的各岗位，从乔哈里视窗来看，产品与运营的公开区的比重是比较大的，但仍然有部分的盲点区及隐蔽区。

而运营与产品通常与产品的沟通场景是需求沟通较多。

当两者需求沟通意见不一致时，产品经理往往需要让运营更好地接受我们这一侧的想法，可采用SCRTV表达模型。

同时，在运营提出需求时，也可引导其采用SCRTV表达模型来进行，从而更好地向产品经理阐述需求：表情境-爆冲突-找原因-定策略-塑价值。

通常更多的是了解对方遇到的问题，常用的沟通语言是：

“你的问题是什么？”

“你的这个方案要解决什么问题呢？”

“如果当前方案无法实行，那么你们是采用什么方式进行处理的？”

而当运营提出需求时，针对优先级、紧急程度、需求内容有对立意见时，产品经理并不是一昧地进行反驳，而是用事实，用数据说话，可采用FIRE模型。

2、与开发沟通

与开发沟通的过程中，高频的沟通场景是沟通需求，往往会遇到几个问题。

①与开发的思考方式不同，产品经理关注产品发展，开发关注实现方式

②开发说技术语言，产品经理说产品语言，导致理解不同

③需求变更时没有及时周知，导致信息遗漏或滞后

④产品觉得需求简单，开发觉得实现难，知识的不互通导致信息不对称

产品与开发这两个岗位是区别较大的，从沟通上来说，符合乔哈里视窗的盲点区与隐蔽区。产品经理与开发的知识域差别较多，容易造成“我理解，你不理解；我不理解，你理解”的这种情况。

为了避免盲点区的越来越大，产品经理应该多了解技术基础知识，但并不是了解技术细节，而是基本的技术点，为了更合理的设计产品产品，也更好地跟技术沟通，但不越俎代庖，干涉技术实现细节，毕竟术业有专攻。

而隐蔽区的形成，源于两者思维方式不同，平时沟通需求时，注意沟通的表达，明确双方所表述的内容是一致的意思。

同时，在跟开发沟通需求/bug的时候，通常我们需要结构化表达，采用SCQA表达模型中标准式（SCA）的沟通方式：背景（S）-冲突（C）-答案（A）；

eg：当前帖子加载速度过慢（S），但采用原生化比采用H5形式的成本更高（C），所以我们考虑从拆分接口的方式尝试下（A），你有没有什么更好的建议？我们探讨下

很多产品与技术沟通的时候直接抛出方案，而没有背景，虽然技术是执行者，但如此方式容易造成对方的抵触心理，同时要让开发从心理上认同做事情的价值。

而在抛出需求之后，往往产品经理觉得简单的需求，开发评估觉得难，这时候容易滋生矛盾。这个时候需要使用非暴力沟通的方式：观察-感受-需要-请求。表达感受，尽量不表达情绪跟想法，同时与开发聊需求的背景，优先级及重要程度，请求对方协助，以此达到解决问题的方式。

总结一下：

①减少个人盲点区的范围，多了解技术基础知识；针对于隐蔽区，注意双方沟通表达内容。

②结构化表达，采用SCQA表达模型，把开发当成伙伴而非技术实现工具，与开发探讨合适的方案。

③遇到问题及需求变更分析后再提交给开发，有需求变动及时周知及阐述背景。

④需求变更时，采用非暴力沟通的方式，达到解决问题的目的。

3、与交互/设计/测试沟通

在于交互、设计、测试这类角色的人员沟通时，首先要明确他们与产品经理的关系。

通常都是产品经理是交互、设计、测试的需求方，往往产品提出需求，交互出交互稿，设计出设计稿，测试进行测试功能等。

于是，如何更准确无误地提出需求、验收需求的沟通这两者就是比较高频的沟通场景。

在提出需求的时候，有的PM会直接提出方案让交互、设计师去执行，而不论是原型设计还是UI设计，都是离不开内容的，明确当前存在的用户问题及用户场景是更为重要的。

采用SCQA表达模型，不论是（SCA）背景-冲突-答案，还是（ASC）答案-背景-冲突都是合适的，最主要的是阐述当前存在的问题，用户场景，继而在引出我们个人的方案想法供交互、设计进行参考。

而在我们验收需求的时候，往往无法一次定稿，那么就需要修改。当我们作为外行的角度，进行验收内容时，切忌“外行指导内行”，记得尊重专业，同时可也阐述我们的想法，若想要说服对方，可采用RIDE说服模型，通过我们自身产品的敏锐度对于方案的评估，指出风险及方案的差异，从而阐述影响点，以引导设计师修改出合适的方案。

总结一下：

①提出需求，需结构化表达，从SCQA表达模型出发，阐述问题背景与用户场景，继而才是解决方案。

②针对于方案进行探讨时，尊重专业，也可采用RIDE说服模型，引导对方修改出合适的方案。

4、与老板/领导沟通

在与老板/领导沟通时，我们需要把握对方的预期，同时也会遇到一些问题

①汇报工作时，拖拖沓沓，讲了一大段，但不清楚主题，内容是什么，毫无重点

②讨论需求时，往往对方有自身的考虑及想法，无从下手去进行说服他们改变想法

通常在与领导/老板沟通的时候，我们会面临几个高频沟通场景：汇报工作、讨论产品需求、说服领导改变想法等，听我娓娓道来。

1）汇报工作

当我们在汇报工作时，通常采用PREP表达方式，也就是结论先行，不论是口头沟通还是书面表达，优先阐述结论，让对方了解事情概况，再通过依据、实例描述内容，最后重述结论。

eg：对于社区的优化，采用帖子新增话题的方案（P），通过数据来看，话题在其他模块的渗透率达到15%，互动情况也占据内容的10%（R），同时从竞品及用户调研来看，话题是用户较为关心的内容（E），所以最终考虑采用了帖子新增话题的方案（P）。

当然，不仅仅是用在与老板/领导沟通的时候，与其他角色沟通方案均可采用PREP表达方式。

2）说服老板/领导改变想法

老板/领导的决策也会有不确定的时候，而作为产品规划者，我们需要指出决策的错误，从而说服老板改变想法，此时可以采用RIDE说服模型与其沟通。

而RIDE说服模型是指通过暴露风险，阐述利益，继而引入差异性及影响，来说服领导。利用趋利避害的潜意识，加以对比提高说服的成功率。

eg：这个方案一的风险可能导致社区的留存率降低5%，用户也会因此大量流失，据评估，这可能导致产品收益降低8%（R），我们可以采用保守点的方案二，虽然无法提升社区的用户数，但可以保证留存率不降低，同时在这个基础上增长产品收益（I），方案二与方案一对比，用户体验会稍微差点，但是我这边有考虑了几个折中的方式可以看下（D），当然，方案二的时间成本也会较高，但影响不大。（E）

总结一下：

①采用PREP表达方式汇报工作，精准描述内容，思路清晰，重点明了

②通过RIDE说服模型与领导进行方案的沟通

5、与下属沟通

当我们摸爬滚打一段时间后，可能在产品团队中作为领导，就避免不了需要与下属长期反复的沟通。通常也是会遇到如下问题：

①领导做决策，下属接到任务及需求，做的不情不愿，一脸蒙圈

②布置任务时，没有背景，没有前因后果，缺少元素（内容，截止时间等），导致完成效果不如预期

③信息传递有递减，导致任务完成效率低

由于位置的不同，导致上下级思考的方式也不同。

而在与下属的相处中，布置任务、沟通工作是较为高频的沟通场景。

在引导下属去做某个任务时，避免单方面进行决策，而是与下属一起探讨，而为了有效沟通，我们可以采用GROW模型与下属进行沟通。

通过提问了解做需求/任务的目标，引发对方思考，从现实层面入手了解实施的困难点，再提出自身的解决方案，此时需要引导对方多进行方案的思考，最后商量一个合适的方案，进行确认方案的实施，保证有效地进行。