产品沟通三部曲：边界、灵活、超预期

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

作者：产品大峡谷

微信公众号：产品大峡谷

题图来自 Pexels ，基于 CC0 协议

全文共 3889 字，阅读需要 8 分钟

谎言验证不了谎言，魔法对抗不了魔法。

最近，我们产研团队压力都特别大，因为公司马上就要盛大举办十八周年司庆，据不愿意透漏姓名的人力张二狗同学所说，老板对此很在意，重视程度甚至超过其六十大寿，认为这是从一个辉煌走向另一个辉煌的关键节点。

因此，我们不仅要隆重地为公司办一场成人礼，还被要求登台献艺，各自从本职工作出发，有钱的捧个钱场，没钱的捧个人场。

于是，我们产品部喜提两个月需求，更令人兴奋的是：还被要求一个月内做完上线——因为姥姥说了，超过12点不吉利。

这下闹得，不光产品同学狂爆CPU，给开发同学整的也老刺激了，集体指责我们只顾一味地逢迎上意，不管民间死活，他们不加掩饰地把对产品的“敌视”都写成了bug，甚至还贴心地用敏感词汇做了注释。

其实在工作中，产品和开发是紧密的上下游关系，沟通最多，往往冲突也最多，但用魔法打败不了魔法，以暴制暴解决不了问题，更大的冲突只会带来雪崩，而每一片雪花都不是无辜的。

我们不能存在职场短视和发展盲区，也就意味着不能简单粗暴地表达：这个需求明天上线，怎么实现我不管？

怎么有效破局呢？

镜同学的经验大体是：原则为主、熟用技巧、灵活兼顾，这可能才是最理想的解决方案。

结合最近思考和案例，分享一些实战经验，希望对大家的职场沟通有启发。

来自功能定义的启发：

边界先搞清楚

作为产品同学，我们对「功能定义」并不陌生，但同时，镜同学也发现，很多小伙伴实际上对「功能定义」的理解并不透彻，尤其是对其思维价值并没有认识到位，更谈不上熟练应用。

先举个产品设计的例子：

我们最近在设计“商家入驻”的功能，为了搭建好平台的商家入口，我们产品同学也调研了诸如“京东平台”、“蚂蚁集团机构生态服务平台”等相关的主流平台设计。

但实际上，在产品需求评审时，我们和运营同学对于该功能是有明显分歧的：运营侧需要考虑转化的KPI指标，希望入驻越简单越好，甚至最好注册就算入驻，而产品则是借鉴更多主流成熟平台的设计，希望产品越合理越好。

问题的本质原因就在于：大家对于“入驻”的功能定义没有达成共识，没有完全搞清楚“注册”、“认证”、“订阅服务”的功能区别。

多说一句，这也是很多经验较少的产品同学常犯的错误之一，建议牢记：评审需求前，一定要先讲产品功能定义。

所以，解决问题还是要回归问题本质，于是，我们回过头来，重新共识下基本定义，有理有据，很快就解决了相关分歧。

商家入驻：入驻通常用于描述企业或个人加入到一个新的商业环境或平台中的过程，是指一系列动作，主要包括“注册”、“认证”（个人实名认证、企业认证）、“订阅服务”等三个功能。

事实上，从应用思维出发，功能定义的对外表达之一就是”边界感“，我们再举两个例子：

1. 版本规划是运营策略，怎么定价，运营说了算

我们在做版本规划相关设计时，运营主导出了一个表格，罗列了不同版本、套餐，包含产品功能和定价；在组织评审时，某产品同学就说：这个报价太贵了吧，我们做过竞品分析，市场上定价没有这么高，我建议调低点。

这样其实并不好，每个人都有自己的专业领域，运营策略也不仅仅是报价，还有其他相关的推广服务，该产品同学的出发点并不坏，但于沟通无益，用粗暴的直觉挑战了对方的专业，否认了对方的成果，也让自己更被动，其本质就在于对工作边界感得不敏感。

老话说：在其位、谋其政，不在其位，不谋其政，这就是边界感的表现之一；如果说和光同尘在某些职场环境下是主旋律，那边界感一定是必要前提。

2. 入驻年费是产品功能，年费设定多少，理应由运营来定义

前两天，我们在评审“商家入驻年费“的相关设计时，某运营同学提出来，现在产品设计的入驻年费是多少？

我还没说话，总裁就很谦虚地请教对方领导：我理解，入驻年费这个是产品功能，具体定价多少应该是运营策略吧？是不是这样，李总？

运营老大自然很明白工作边界，于是，赶紧反复强调是运营职责，并说，也已经制定了相关的定价策略。

边界感是稀缺的宝贵品质，对于职业发展支撑价值很大，更是避免和开发等部门发生冲突的护身符，我们要逐步培养与熟练应用，最可行的方法就是从认识事物的「功能定义」开始。

同理心会带来超预期：

别砍我，砍需求

作为产品同学，我们经常调侃：别砍需求，砍我。

需求是产品和研发的红娘，大家要学会利用这个连接器，而其中一点小经验就是要多一些同理心，多一些技术思维，想办法为可爱的研发宝宝战略性地创造超预期。

因为，据说超预期会催生多巴胺（别轻易申请提前转正）。

比如，在产品设计时，我们尽可能设计完整，用系统方法论和设计规范来支撑产品设计，但在需求评审时，对于某些可以删减的需求，我们要主动对开发讲：因为时间比较紧，这个功能点咱们可以放到后续再实现。

再比如，我们每个月有两个迭代，月初和月中我都会和开发负责人对迭代范围做沟通；我一般也会把「需求清单」预先安排的相对饱满，但再沟通评审时会主动或假意被动地删减，于是，会后我俩都收获满满。

在我看来，同理心是重要的产品思维，更是一种态度；而对于同理心思维、用户思维，我们产品同学从来都不缺乏，只是会习惯地忘记最熟悉的开发同学也是我们的用户而已。

我也经常发现，身边有些员工的工作能力不算太优秀，但工作态度绝对是number one，每次遇到问题都是虚心请教，发生工作疏忽也总是表现的很自责，流水衙门，他们始终都在。

所以，多些同理心、多思考、多去创造预期，这对于和开发沟通会很有帮助。

严谨表达、灵活转移话题

众所周知，产品经理是日常沟通的焦点，不仅需要和开发沟通，还需要应对各种复杂的沟通场景，这需要搭建以「沟通技巧」为核心的能力体系。

其实，关于沟通技巧，我在知识星球和小报童也做过一些分享，尤其是，我觉得产品同学务必要养成“说话严谨”的职业习惯，同时要学会灵活应对，简单摘取一些小片段，供大家参考：

前段时间，我们公司技术委员会组织了和产品经理的沟通座谈会，蓝色的PPT背景主题鲜明地写着“坚持产品核心、高效支撑业务”，讲的是深化以产品为驱动的发展战略，强调产品对业务支撑的重要作用，开会主要就是讨论产品设计如何高效支撑业务发展。

中间自由讨论、交流环节时，当技术委员会询问产品经理有什么要求和建议时，有个产品同学就说道：希望能增加产品设计时间。

客观上说，很多业务需求给的时间的确太紧，他讲的也是实情，但这个简短的表达却很不严谨，犯了两个职场错误：

1. 没搞清形势

这次开会的背景说白了就是为了高效支撑业务，因为市场同事向上反馈很多业务需求上线时间太长，不利于业务拓展，为了更高效地支撑业务，公司指派技术委员会分部门逐个沟通讨论，寻求有效地解决方案。

虽然，有些业务需求给的时间确实很少，甚至忽略了客观规律，但这个同学在会上这样说很容易被误解为抵触改进，你想啊，这边想着怎么缩短时间，你却说要增加时间。

实际上，这种情况在职场中非常常见，不少同学缺乏对基本形势的有效判断，很多时候没有搞清楚组织意志就贸然开口，结果一开口就选错了队。

2. 缺乏表达技巧，用语不准确

这个同学刚说完，我就心说不妙，果然，技术委员会开始集中发难，众说纷纭，但总的意思是说他没有大局观，不懂的产品支撑业务发展的重要性。

我看形势不对，就找机会接过话头，我说：

各位领导的担心和嘱咐都很必要，产品是业务的载体，高效支撑业务也一直是产品部门所秉持的法则，也是产品经理的天职，尤其是当下业务快速爬坡的阶段，要求我们支撑的效率更高。

这个同学可能没表达清楚，他想表达的，不是说要增加产品设计时间，而是要加大产品设计力度，产品设计只有深度理解业务，才能真正解决用户需求，不至于后期频繁变更业务流程，错过宝贵的市场窗口。

另外呢，从业务需求落地到产品上线需要各部门通力协作，产品设计是上游，我们设计越是规范、越是正规，就越有利于下游理解，降低他们的理解成本，减少后期变更的沉默成本，产品研发要算整体账，很多时候，产品设计多花两天来加大设计深度，项目整体周期却能缩短一周。

而我化解这个危机，使用了两个表达小技巧：

① 先肯定对方表达，再转移话题、偷换概念。

我先认可对方的表达，稳住他们情绪，而后择机突击，比如，本来讨论的是关于产品设计时间，我却转移到了产品设计力度上，强调设计深度对业务的好处，这引起大家共鸣的同时，也无意识地转移了观众视线。

② 重新聚焦在“对自己有利的表达”上。

等到语境形势稳定之后，观众情绪不再被点燃，我便设法将表达重点重新聚焦在「产品多花时间，其实是为公司整体负责」的观点上。

果然，很快获得了大家的认可，事情也得到了圆满的结束：大家认可产品设计的重要性，认可加深产品设计力度，认可前期多投入一些时间。

到这里，我们简单复盘一下：

其实我和这个同学想要争取的都是「增加产品设计时间」，他直接说的，talk straight，却被误会；而我却说「加大产品设计力度」，曲线救国，却反而达到了很好效果。

增加产品设计时间 VS 加大产品设计力度，用心仔细推敲，完全是两个概念，传递出来的信息差别自然很大。

说了这么多，其实，沟通是个历久弥新、见仁见智的话题，同时，我们也要强调，所有沟通技巧的底层逻辑应该是「正大光明」，即便是灵活应对，也一定是在阳光下的变通。

最后，也希望大家都能成为沟通专家。