编辑导读：沟通是门大学问，而每个人都是独一无二的，因此适合自己的才是最好的，没有所谓的“范式”。产品经理作为一个注重沟通交流的职位，每天都要和不同岗位的人打交道。本文作者围绕团队沟通写作展开分析，与你分享。
沟通是门大学问，而每个人都是独一无二的，因此适合自己的才是最好的，没有所谓的“范式”。
本文仅从个人角度浅显地表达对团队沟通的理解，如果能够引导大家的一些思考甚至带来些帮助，估计睡着也能笑醒。
此外，本文从PM（产品经理）视角出发，重点阐述三类协作角色的沟通，包括研发、业务/市场/运营、老板，阅历有限欢迎大家提供建议。
一、产品经理的核心技能
不知大家对于“什么是产品经理的核心技能”这道开放性命题有何想法，以下为网络上一些大拿的想法：
快速学习能力、逻辑思维能力、文档撰写能力、用户调研能力、产品规划/分析能力、有效沟通能力、资源整合能力等
由于产品经理岗位属于综合型岗位，“人人都是产品经理”，阐述的是产品经理的低门槛，但并没所有产品经理都是好的产品经理，需要各方面都出类拔萃。
本人心目中好的产品经理，至少同时扮演着以下角色：
- “创业者”：对自己的产品充满热情和创新，“想方设法”为产品成功负责
- “战略家”：谋定而后动，做好前期充足的调研和演练，时刻保持长远的产品战略
- “政客”：资源永远是紧缺的，不断进行布道，“游说”各方角色进行资源倾向
- “消防员”：承担责任（拿得起放得下），拒绝推卸，抓住核心问题
而如果从这些角色中提炼出一个核心技能的话，我的选择是“沟通能力”。
无论是哪个角色，都不可能是孤军奋战，而是“集团作战”，有效的沟通可以解决阻塞问题，协调各方资源达成最终的目标，即“产品成功”。
二、如何做好沟通
沟通是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅。
1. 对沟通的自我思考
以下是现阶段从个人角度整理的思考，并非静态的内容，会根据未来的经历进行动态更替。
?? 认识自我 – 找到自己的能力位
个体的不可替换性（“超级个体”），每个人都应该形成自己的工作节奏
日常产品工作中，会经常问自己的几个点：
- 在团队里，自己是否有不可替代的地方？
- 怎么样强化/保持自己的不可替代性？
自我的能力位和团队的关系是动态的，需要持续保持自我的竞争力。
?? 端到端 – 不限于自己的舒适圈
“Product people need to think end to end”
产品设计为产品成功负责，而不仅仅是交付产品，这样意味着需要考虑产品的业务模式、GTM策略（Go To Market）、财务模型等，学会不断跳出舒适圈，扩大自己的能力边界。
产品从哪来（市场）+到哪去（售卖）+怎么去（市场）
?? 换位思考 – 学会观察/倾听，培养同理心
“存在即合理”，任何观点和想法都不是凭空而来，都存在相应的背景信息，沟通过程中需要学会倾听
需要时刻考虑从沟通对方的角度思考问题，抓住核心的关注点（背后的KPI/OKR）
Case：比如之前刚接手一款产品时，业务一直吐槽产品难用，我会直接站在他们立场，“一期吐槽产品”，但通过这个过程建立和业务的信任，能够获取到更多背后的原因
划重点：换位思考（或者同理心）是个人认为沟通过程中最重要的点
?? 一些小技巧
- 学会说“不”以及学会如何说“不”：语言婉转+态度坚决+提供其他解决方案
- 话留三分，保持警惕：不要过度承诺，前期谨慎好过后期“火葬场”
- 软磨硬泡，不怕拒绝：为产品成功需要“不择手段”
- 适当学会“拖”字法：积极响应提供解决方案，承诺排期支持，但持续观察后续的紧迫性
- 找到建立好感的切入点：比如数据支持、功能小提效，建立信任有助于后续沟通
2. 跟研发站在统一战线
NO：产品设计跟研发“水火不容”，是经常吵架的对头，比如：产品设计经常修改需求，会打乱研发的进度，尤其临近上线的时候
Yes：我觉得产品设计和研发是利益共同体（站在同一战线），都是为了产品成功而努力
记住，研发团队是一群可爱专注的人，以下是个人与研发人员构建良好关系的方式：
?? 了解与你合作的研发（用户画像）
- 谨慎型 VS 开放共创型
- 主动型 VS 被动督促型
- 埋头苦干型 VS 期待表现型
如有机会，多了解研发对于“个人成功”的想法，比如对于前沿技术的钻研，一定要抓住提供场景支持，难免找到新的产品突破点
?? 建立信任关系并不断强化
越早建立信任关系，越助于后续工作的开展，可以采用以下几种方式：
找到共同语言，增加交流的认知感：B端产品需要具备基本技术思维（个人喜欢和研发打成一片）
Tips：B端产品需要能够了解数据库/CSS/架构等
- 非工作场景尽可能和研发成为朋友，融入圈子里面：最简单的方式一起吃吃饭
- 多请教多沟通：尊重研发的专业知识，涉及到成本预估的时候尽早involve研发
Tips：没有人能够逃脱“为人师表”的诱惑
及时反馈，共同荣辱：有好消息多考虑研发，让大家觉得跟着干没有错；如果是坏消息，坦诚认怂同步信息，鼓励大家继续前进
?? 巧妙应对需求变更
原则上，产品迭代过程中，需要严格控制产品边界，优化建议采用迭代方式进行支持。
但难免会遇到需求变更的情况，比如细节部分未考虑、领导要求难以驳回，可以考虑以下几点：
- 提前预知变更风险，并给团队打预防针
- 及时说明变更的原因、技术难度等客观或主观因素，寻求研发的建议反馈（统一战线）
- 求同存异，提前暴露分歧并控制不要扩大，让迭代验证替代“我觉得”
- 坚持核心环节不“侵犯”，细节逻辑允许研发可控范围“自由发挥”
3. 聆听业务/市场/运营的诉求
NO：业务、市场、运营都是“万恶”的需求方，还需要经常给他们做培训
YES：业务、市场、运营是支持产品推广的核心伙伴，要想方设法让他们“爽”，这样产品才能在市场上风生水起，得到用户的认知和认可
那么如何能够和业务/市场/运营等协作部门建立良好合作关系呢？
核心在于“换位思考”，帮助对方成功的同时可以促进产品成功。
?? 了解业务/市场/运营的画像
Question：大家觉得业务/市场/运营最关心的工作目标是什么？
- 业务/销售：?收入
- 市场：影响力+线索
- 运营：使用量
记住，“道路千万条”，产品是否成功只是他们目标中的非必要因素（除非自上而下要求）
了解工作目标之外，需要了解对方是怎么样的人？
- 谨慎型 VS 开放共创型
- 主动型 VS 被动督促型
- 埋头苦干型 VS 期待表现型
相较于研发同学，业务/市场/运营同学的背景可能和产品设计大相径庭，所以需要扩大自己的认知圈，了解和拥抱不同工作模式的同学
?? 建立信任互助关系，持续推动产品种草
建立信任互助关系三步走：
?♀️ 共情：站在业务/市场/运营角度思考产品
?♀️?♀️ 提供“援助”：解决日常阻塞大家工作的问题，建立产品能给“我”带来帮助的苗头
?♀️?♀️?♀️拉上“贼船”：产品目标和业务/市场/运营目标建立强关联，让大家目标层面发现“没产品不行”
抓住并尊重每一次机会进行产品种草：
- 需求开发前，贯彻产品核心要素和功能 — 告诉大家有货可以期待
- 积极让大家参与用户测试，引导大家多提意见 — 已经投入了精力
- 及时准备上线材料（记得感谢业务/市场/运营），上线后还是需要做好推广工作
- 上线后积极收集大家的产品反馈，并针对反馈提供反馈（闭环）
?? 提高自身能力，融入协作团队
- 不设边界，懂一些运营知识、销售手段以及市场推广策略等，便于平等对话
- 多问多请教，相互学习，没有人可以摆脱“为人师表”的魅力
- 如有需要以及精力，可以提出轮岗or替岗，有助于关系建立和工作支持
4. 向“老板”销售自己
NO：老板都是对的，安排的事情是第一优先级
YES：团队/组织的魅力在于乘法，老板核心关注的是战略和方向，对于产品细节本身的了解也是欠缺的（用户角色），要客观分析背后的思考，并想尽办法“用好”管理层的资源
PS：此处“老板”泛指管理层，上到CXO，小到直属汇报对象，但具有共同点：
- 掌握比下级多的资源
- 对细节没有执行者了解，持续期待向上反馈（提供不同的视角）
- 希望团队成功大于个人成功（组织对于管理的要求）
可见“老板们”会是推动产品成功道路上不可避免的资源，因此要学会向上管理，向“老板”销售自己
?? 了解老板的目标以及对产品的期待
记住组织是分层的，“老板们”核心关注的经常会更高维度，比如当我们关心这个版本产品的发布计划时，产品负责人（“老板”）会关注的是整体的产品战略，以及本次发布的结果带来的贡献。
因此需要学会“换位思考”，多往上层思考，多站在“老板们”的角度阐述产品的意义、市场需求、未来发展可能性、甚至盈利模式等。
Tips：及时关注/聆听老板们的思考和演讲（或者看看OKR），学会拆解和阐述
?? 打造个人形象，获取老板的信任
万事开头难，只有我们成为那个老板最值得信任的人，那一切问题都不是问题
以下几种方式“可能”可以获取老板的信任：「其实本人实践的也不够好」
- 专业性，建立知识体系，清晰阐述产品的来龙去脉以及思考，以防“突击拷问”
- 前瞻性，适当的“野心”，多些细分产品未来的思考，不要害怕错误，但一定要自圆其说
- 说“不”可能会有不一样的效果：学会有理有据地“拒绝”，要有自己的坚持
Tips：老板会希望我们提供可被论证的思路和想法，而不是“我以为”、“我觉得”
?? 如何处理日常遇到的冲突？
实际执行过程中遇到资源不足，如何向老板索要资源？
- 提前预知资源风险，会哭的孩子有糖吃
- 合理分析资源和目标，避免成为老板眼中的“麻烦制造者”
- 寻求老板的建议，提前参与决策及共创
- 充分的调研和数据反馈，客观结果好于主观判断
实际执行产品研发的过程中，老板介入项目而且不按照之前的设计进行又该如何处理呢？
- 了解老板在执行过程中的想法，明确背后逻辑及紧迫性
- 如果涉及到阻塞and?的问题，拥抱改变评估成本
- 视阶段而定，若已经进入项目尾声，优先继续执行原来的计划，多和老板沟通下，现在的计划进展情况，不能因为老板介入而影响计划，老板可以进行一些跟踪方面讨论
- 确定老板改变计划的原因，找到分歧的地方，进行用户测试&验证，评估改动的必要性
- 通过论据（数据，同类产品的功能做法）进行验证，分析利弊
- 得出一个初步的结论，根据结果再次给老板提出建议，给出不同方案的风险，最后让老板做决策
三、结语
呼应下开头“沟通是门大学问”，每个人都是“独一无二”的，任何人的观点都会成为“肥料”，最最核心的还是找到合适自己的沟通方式，并进行不断的迭代进步。
也希望未来自己的沟通方式可以不断演进，与协作的各方建立良性的循环，因此欢迎大家“批斗”，提供你的观点以及想法。