需求,是我们在产品工作中接触最多的词语。不管是来自用户、业务还是老板,产品经理总会收到各种各样的需求。
需求,不是一个单纯的名词。在需求被提出时,对于提出方是结束,但对于产品经理是工作的开始,需要打出一套组合拳来承接。
产品经理需要在接到需求时辨别真伪、在迭代时排好优先级、在开发时做好需求变更、在上线后分析数据给出反馈。在这一系列过程中,都需要产品经理做好需求管理工作。
在管理需求时,产品经理首先要对不同的渠道进行管理。因为需求来源不同,后续的做法完全不同。
需求的渠道大致可以分为五方:用户、老板、业务、客户、自身。那么,这几方的需求产品经理应当如何妥善处理呢?
01
用户的需求看问题
产品是给用户使用的。那么产品是否符合用户预期、使用过程是否顺畅、是否帮助用户解决了问题或达到了目的,就需要产品经理时刻保持关注。
长链接是保持关注用户需求的常用方式。建立长链接需要找到快速触达用户的方式,可以是收集用户反馈、做用户调研访谈、客服跟进或直接混迹在用户群体中。
但具体链接形式不太重要,核心在于能够听到用户的真实表达。比如在访谈时,不要预设有引导性的问题。
用户一般不会主动提出需求或者表达想要什么功能,尤其是产品流程相对完善后,用户基本就不会提出建议了,更多是发牢骚和吐槽。
在产品发展的前期要产品经理要找到和关注KOL,在需求上听从他们的建议,根据他们的反馈做产品流程优化,使得产品快速从0到1。
有区别的是,在产品发展的上升期和稳定期,要谨慎对待KOL的需求,他们毕竟只代表小部分用户,大部分用户都是小白,可能用不到KOL的专业诉求。
那这时候用户的需求体现在什么地方呢?更多的体现在观察用户的使用感受上,从他们的牢骚和吐槽中定位到背后的真实问题,根据他们的实际反馈来不断的调整力度,完善产品。
02
老板的需求看目的
老板,是需求的另一来源。
大部分情况是,老板提了一个需求,让产品经理去执行。这个时候就要采用对用户完全不同的做法了。我们可以用两个明确来完成老板的需求。
第一个明确:老板不会突然提出需求,肯定会有前因后果。
产品经理在接到老板需求时,第一件要事就是弄清楚前因后果。老板有比产品经理更多的信息源,有些他不能说,有些他以为产品经理应该知道。
前因后果决定了需求提出的背景,了解背景对后续的工作至关重要。一是因为不知道背景在执行上可能跑偏;二是产品经理要根据背景有自己的思考。
第二个明确:老板有想要的结果。
老板要的永远都是结果,而不是具体做某件事情。因此只要能拿到结果,原则上哪种做法都是老板可以接受的。
那么在拿到结果的前提下,产品经理要思考:
不通过产品手段能验证吗?不要忘了产品经理有自己的节奏,这突如其来的需求,是否会打乱自己的版本计划。
怎么轻量化的尝试?在必须要用产品来实现时,轻量化、少打扰的拿到结果总是好的。
拿到结果,证明可行或者不可行,给出后续的计划和建议,就是对老板需求的好答复。
03
业务的需求看配合
业务,是指公司内部同事提出的需求,可能来自业务、市场、运营、客服等兄弟部门。
同事也不会平白无故的提出需求,他们最大的可能是因为产品对他的工作造成了影响,突然加大了工作量,因此提出需求期望产品经理去解决。
产品的完美上线需要各部门的紧密配合。产品经理要耐心的听完同事的抱怨,要清楚明白他们是产品的协作部门,不要硬刚、要哄。
对于可能对同事造成影响的产品需求上线,产品经理前期要思考透彻,提前告知:影响多大、影响多久、后期是否会改善,让他们有心里预期,做好充足准备。当资源不足时,也要配合同事积极申请资源。
同时,要跟同事画饼。讲清楚产品规划,现在的痛苦都是暂时的,当前只能通过配合一起完成。站在未来的角度打现在,无往不利。
不过若遇到大面积爆发问题,就要加紧改正、紧急上线,做到让同事满意。
让同事配合的舒服,他们提的需求自然也就少了。
04
客户的需求看业务
客户是 to B 的客户,客户的需求就是 B 端的需求。
B 端需求在于要清楚了解业务情况。客户提的需求是实际的流程需要,是线下流程的线上化。这时候要一切以业务为主。
但 B 端产品的阶段不同,需求的优先级完全不同。产品经理要准确的判断,比如在推广期缺少某个需求,可能就无法拓展客户使用。这个时候要以BD需求为第一优先级。
B端产品的收费方式不同,也决定需求的处理方式不同。免费、收费、不同等级的定制化,就有不同的需求对接方式。用户付费越多,响应需求的速度就需要越及时。
当客户大批量且个性化要求较多时,就需要用中台的概念承载,支持客户自定义,灵活可配置。
客户的需求来源于业务,产品经理就需要扎根于业务。用互联网的方式提升业务效率,才是客户需求的处理之道。
05
自身的需求看规划
还有,就是产品经理自身的需求。
产品经理在迭代的过程中,最重要、也是最容易忽略的就是自身的需求。
产品是产品经理的孩子,我们对产品有着怎样的规划,要以怎样的节奏拿到期望的结果呢?
自身的需求来自于产品目标,来源于季度规划,来源于 OKR 中的 O。目标拆解,规划好每个版本的功能以及进度节点,就是自身的产品节奏。
同时,在每次版本中都预留一些位置,插入可能出现的用户、老板、同事等各方面的需求。
这样就能在处理好新增需求的同时,做好版本把控,保证产品朝着自己期望的目标前进。
需求从各方来源汇集于产品经理,但迭代的版本只能一期一期的推进,每个版本能做的需求就那么几个,这时管理各方对需求的预期就非常重要。
预期管理的核心在于及时同步。在收到一方的需求后,就需要认真负责起来,需求的每一个进度节点都要同步给需求方。
需求做不做、什么时候做、做了效果如何?不做要明确的告知理由和可代替的方式,做了给出预计的上线时间和上线后的分析结果。
如此,我们的产品规划才有落地的可能。
最后
产品经理,不是需求粉碎机。
不一味的承接需求,不一味的专断独行,产品工作本就是决策权衡的过程。
需求不重要,问题才重要。没有谁的需求是第一优先级,有的是此刻当下最需要解决的问题。
毕竟,产品经理的定义就是解决问题,
- END -
欢迎关注公众号
持续输出产品经理干货文章
↓↓↓↓↓↓