广告

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

需求侧改革(需求层次理论)插图

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

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

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

一、做正确的事

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

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

需求侧改革(需求层次理论)插图1

接下来展开讲讲:

1)需求背景

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

2)业务指标提升

① WHAT

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

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

② WHY

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

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

③ HOW

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

3)方案评估

① WHAT

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

② HOW

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

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

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

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

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

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

需求侧改革(需求层次理论)插图2

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

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

4)紧迫性评估

① WHAT

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

② HOW

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

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

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

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

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

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

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

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

所以在这样一个大型拒绝现场,对于业务方们的心理按摩是非常必要的。以下是我总结出来的屡试好用的需求方全套按摩服务,请各位技师们勤加操练:

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

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

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

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

需求侧改革(需求层次理论)插图3

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

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

注意事项

1)责任的区分

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

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

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

2)不要总是接紧急需求

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

三、总结

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

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

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

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

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

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

广告