编辑导语：产品经理在进行产品规划设计前、在产品设计中、在产品落地后迭代等阶段，都会接触到“需求”，此时产品经理要如何对接好需求，做好需求沟通？本篇文章里，作者总结了产品经理需求沟通技能的相关事项，一起来看一下。

这里有一份需求沟通的清单，和一份需求沟通全流程避坑贴士（附需求方心灵按摩指南）。

产品经理作为需求的出口，会有很多人给你提需求跟需求方沟通需求，是产品经理工作中高频，重要（处理不好会产生一定后果），且复杂（不仅要做好事，还要处理好人）的一环，这个环节需要智慧和技巧，每个PM都应该好好花时间搞定这项技能。

接下来我们从“事”和“人”两方面来说。

一、做正确的事

1. 一份要随身携带的需求沟通清单

需求沟通主要的核心点都在这个清单里，随身携带，每次沟通打开填空一样去完善表格中的问题就可以了。可以释放我们大脑的算力哈哈。

接下来展开讲讲：

1）需求背景

• WHAT：抽丝剥茧，聊清楚一定要在这个时间点做这个需求的理由。聊不清楚的话就被需求方牵着鼻子走了。
• WHY：帮助我们判断需求是否合理，以及紧急程度。
• HOW：变身十万个为什么，直到找到最核心的原因。

2）业务指标提升

① WHAT

本次需求预期提升的关键业务指标。对于互联网C端产品来说，一般是为了拉新，促活，变现：

• 拉新指标：一般是新用户的访问量。
• 促活指标：上线后的用户留存，功能的参与率等。
• 变现指标：营收的提升。

② WHY

需求是无穷无尽的，对眼前的目标也就是关键业务指标有提升才有做的可能，其他的都靠边。这是一个最简单最清晰的，判断需求是不是要做的工具。说其他的反而变复杂了，只需要问这一句，就能明确需求的价值。

另一方面也可以让需求方对于自己的需求负责，如果这次没达到预期数据，下次再提需求是不是就不好意思再随便扯扯了。

③ HOW

数字指标形式呈现，提升n%，绝对值相对值都可以。对方给了指标提升以后，我们还需要判断这个指标预估是否合理，这个指标提升是否过低，过低的话也没有做的必要。

3）方案评估

① WHAT

很多业务方提需求会直接带着方案来，例如很常见的，看到了竞品做的某些功能，自己也像做。这时候我们要评估方案是否合理，是否可以达到提升指标的作用。

② HOW

下面提供3个步骤和2个工具。

评估方案本身是否有足够多的用户参与，是否可以达到指标提升预期。

工具一：用户动力流程图。

这是我常用的一个很好用的工具。产品机制设计完成后，想要用户能使用起来，用户采取每一步行动都需要有一定的动力，用户动力流程图就可以把用户动力具像化，让我们看到这个流程设计中的问题。

画法就是把设计的产品功能流程图画出来，逐步标记用户的动力并评估动力是否足够即可。

举个?：双减之前，我曾经接到一个业务老大提的需求，要做一个校内公立校教师和校外辅导机构的联动生态，我当时就画了一个动力流程图，发现其中的关键环节的动力不够，生态必然流转不起来。截取其中的一个环节给大家示意一下：

工具二：用户体验地图，也是用来分析用户在产品历程中的行为的，可以帮我们发现方案设计的问题。这个工具可以搜索了解，大家讲的比较多。

1. 基于这个目标这个解决方案是不是最好的，是否有更好的解决方案。
2. 最小化上线，本次只验证核心点，哪些功能可以简化或者本次不做的。

4）紧迫性评估

① WHAT

基于需求的紧迫性和重要性，看需求方的时间预期是否合理。

② HOW

• 需求方作出这样的项目，是否可以拆解多个里程碑上线；
• 最后对于上线时时间预期的原因是什么；
• 是否真的需要这么紧急；
• 是否节日类活动需求：大促等，有固定时间要求；
• 是否有产品功能配套的运营活动，有的话需求方侧对这个活动的行动计划方案是怎样的，让产品先行太多也是一种资源浪费；例如配合地推的功能，产品上线后，地推迟迟不行动起来，产品功能没人用，就是一种浪费；
• 对于时间紧急的间，不要轻易承诺，一切都需要等需求评审后才能给出较为准确的时间预估。

最后，一定一定要发会议记录。

做会议纪要是一个很好的工作习惯，对于产品经理来说就更加的，尤其的重要，和必要。

上面沟通清单中的问题沟通达成一致后，以邮件的形式发给所有与会人员，也可以抄送给必要的人员，待交付的在会上要问清楚交付时间。之后大家就可以按照时间表来跟进处理，非常清晰，也很拉好感哦。

二、“人”的问题也很重要

产品经理是公司授权的可以支配开发资源的人，但如果做了不必要的需求，浪费了开发人力，也是产品经理的责任。所以不要怕被需求方背后吐槽脸黑严格之类的，我们要坚持做对的事情。要保证做性价比最高的需求，也就是我们常说的，“能实现目标的最小化的产品开发”。

我们要像“雁过拔毛”一样地，检视经手的所有需求，看哪里是可以砍掉的。所以需求方真的会从产品经理这里接收到很多条拒绝消息。

试问一个坚强的需求爸爸能承受多少拒绝，为了需求的正义，产品经理就只能在无情无义/孤家寡人的路上越走越远了哈哈。

所以在这样一个大型拒绝现场，对于业务方们的心理按摩是非常必要的。以下是我总结出来的屡试好用的需求方全流程：

首先我们要抱着一个“就事论事，坦诚清晰，为了需求的一切，一切为了需求”的态度。

在沟通之前先跟需求方明确需求的标准，呈现自己认真专业的态度，后面的需求沟通过程就容易不落入“人身攻击”的范畴：

可以在需求方提需求之前可以给对方一个文档，告知提需求的格式标准等，文档可以包括以下内容：

1）提需求需要提供的内容

2）沟通流程：需求方先讲解需求——>产品提问——>产品建议——>最终定稿。

3）需求评估原则：评估后对于关键业务指标有提升的需求一定会做。

注意事项

1）责任的区分

近几年行业内开始流行要有一个项目主O，也就是主要负责人，开始有一种声音是：“别人主O的话，我是不是可以不管不问，听吩咐做事”。

我的建议是最好不要，理论上来说我们每个人手里经手的工作都有做好的责任。尤其是主O不是产品的时候，如果产品不发挥好作用，后续出现问题还是有很大可能被问责的。

如果主O的做法有问题，向上反馈并做好记录就可以（可以反馈给你的上级，或者直接反馈给主O）。否则默默按照错误的方式做了，是要背锅的，因为说到底，产品没有起到应有的作用。

2）不要总是接紧急需求

产品经理的精力要多用来思考产品的长期规划，这对个人和公司都是好事。遇到总喜欢提紧急需求的业务方要多做管理，沟通和制定规则，形成健康的合作方式。

三、总结

产品经理拿到需求以后抽丝剥茧，找到真需求，这是对需求负责，对团队负责。否则也会面临下游环节的质问，导致扯皮、返工等，非常低效。

前期需求沟通做好了，很容易帮我们在团队中建立良好的口碑和影响力。做不好，会导致自己一边被牵着鼻子走，一边填坑，非常被动，而且也有可能导致甩锅、追责等，所以聊需求对产品经理来说是一项值得刻意练习的能力。

但这里小声补充一下：以上是基于需求的正义而提炼的流程。如果面对巨牛需求方，你直接强势整一套组合拳，有可能被脾气不好的需求方打哈，还是要注意服务态度哈哈。

但话又说回来，毕竟我们是在做正确的事情。做正确的事情永远有理，这也许是互联网时代带给我们的福祉之一吧。

本文由 @芋圆同学 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。