怎样做好产品需求管理?(做好产品需求管理的3大方法)

qinzhiqiang 12-21 16:09 2次浏览

 “在相对成熟、处于发展期的团队,需求管理就是产品经理的核心工作之一。就像长途驾车既要保证方向正确、目标清晰,也要保证在驾驶中的平稳、安全不出差错”。——《从点子到产品》

一、产品经理要对每个需求了如指掌

需求可以理解为是用户在一定时期内未经满足的需要,如果已经满足了,不是需求而是已经成型的方案或产品。需求的来源往往十分广泛,可能来自老板、产品经理、业务、客服、用户等与产品相关的任何一个人。

对于产品经理来说,需求是工作的开始。包含问题梳理、可行性分析、方案选择和具体执行四个方面。从想法到形成需求,再到可以落地的功能,需要过关斩将,经历各类评审和研讨。产品经理在需求方和有限的研发资源之间纠结,不仅考验沟通协调能力,更加考验对需求本身的把握程度。

1、产品需求的来源

需求从来源渠道上大致可以分为用户、老板、同事以及产品经理自己四个类别。

1.1来源于用户的产品需求

产品是提供给用户使用的。产品是否符合用户需求、使用过程是否顺畅、是否帮助用户解决了问题或达到了目的,需要产品经理时刻保持关注。可以通过收集用户反馈、做用户调研访谈、客服跟进或直接混迹在用户群体等方式,收集用户心声。从他们的牢骚和吐槽中,定位到背后的真实问题,并不断完善产品。

1.2来源于上级领导的产品需求

上级提了一个需求,让产品经理去执行。这个时候就要采用对用户完全不同的做法了。产品经理在接到领导需求时,第一件要事就是弄清楚前因后果。领导有比产品经理更多的信息源,有些可能领导以为产品经理应该知道。如果双方信息不对称,产品经理不知道背景,在执行上可能跑偏。

其次,上级领导想要的是结果,而不是具体做某件事情。因此产品经理在接到任务时要思考:有无更好的实现方案、能否进行轻量化尝试、需要用产品来实现时,轻量化、少打扰的拿到结果总是好的。拿到结果,证明可行或者不可行,给出后续的计划和建议,就是最好的答复。

1.3来源于相关业务同事的产品需求

运营、客服等相关业务部门同事,会根据实操过程中遇到的问题提出需求。

对于此类产品需求上线,产品经理前期要思考资源是否充足、是否能解决目前的业务问题,是否还有更好的解决方案。只有和同事配合顺畅,才能够实现产品良性发展。

1.4 来源于产品经理自身的需求

产品经理在迭代的过程中,最重要、也是最容易忽略的就是自身的需求。产品经理要掌握自己对于产品的目标及规划。可以通过对OKRs的目标拆解,来明确自身需求,规划好每个版本的功能以及进度节点,掌握自身产品节奏。同时,在每次版本中都预留一些位置,插入可能出现的用户、老板、同事等各方面的需求。这样就能在处理好新增需求的同时,也做好版本把控,保证产品朝着自己期望的目标前进。

二、需求评审时需要传达什么信息

需求评审要传递的信息,主要包括产品的价值、功能及实现。“价值”即为什么要做这个需求,上线之后的价值是什么。“功能”指为了支撑这个价值,需求包含了哪些功能呢。“实现”即针对每一个功能,该怎么实现。

比如,产品经理做一个预约票功能,价值就是使得旅客在票量紧张的时候,能够第一时间收到余票信息通知。功能是需要呈现A、B、C等三个维度的信息采集。实现就是每个数据的口径是什么,在前端如何展现,以什么样的形式通知到旅客。

需求本身大致可以分为:功能优化,功能拓展,新项目。不同类别的需求,在评审会上传递的信息重点不太一样。功能优化重点在讲清楚如何做。功能拓展重点在讲清楚是什么,与原有功能的联系是什么,可能要单独组会。新项目重点在讲清楚为什么要立这个项目,项目包括哪些模块,模块间的联系是什么,每个模块的功能及实现。

从信息量上来说,新项目的评审是密度最高的,也是最考验表达逻辑及评审效率的。高效评审,是向协作团队传达出了统一的项目价值,能够让他们理解彼此的角色,任务及需要落地的行动,最关键的,彼此角色之间的关联是什么。

人对新事物的信任感是相对低的。产品经理在需求评审会上最重要的任务,是帮助大家建立这种信任感,传递两个信号:这个事儿值得做;这个事儿能做。

1、用最直接的方式说明需求价值

不仅产品经理要了解需求价值,协作团队也需要了解需求价值。可以采用“量化指标,数字切入”的方式在最短的时间内传递信息。比如说在开发礼遇卡领卡端口,这个功能的价值也很多种描述方式:效率提升、提升旅客粘性,领导很关注等等,但这些不够直接。想在最短时间内说明这个重要很重要,就要用数字说话,例如预计能引流旅客xx人,经测算会带来增量收益xx万元。

2、说明为需求设计方案之前的准备工作

这一点经常会被忽略,但实际上很重要,尤其是对新项目的评审来说。人对新事物的信任感是相对低的,所以要让领导、同事了解产品经理为此做过的准备工作及相关的核心结论。例如做过哪些市场、竞品调研;公司战略层有一些什么指示;尝试过一些测试小体量案例及其核心结论。

这一步的重点不在于让需求变得更清晰,而在于提升协作团队对新需求的信任感。“我”作为产品经理,已经把可能存在的问题及应对方案尽量考虑周全了。

3、“逻辑+模块的表达方式

对内容密度较高新项目而言,会出现“听不懂+不知道现在讲到哪一步了”的负面效果。本质上都是因为,没有在听众脑中建立起逻辑主线。“逻辑+模块”思维其实类似于建立目录,先看目录,再看细节,遇到不懂的问题再回到目录来,渐渐地就搞懂了。逻辑链通畅,需求评审就成功了一大半。

4、上帝视角与用户视角的结合

关于产品有两个常用的视角,上帝视角和用户视角。前者是产品经理在设计方案时常用到的,后者是用户从进入产品到退出所经历的完整过程。只说上帝视角,不容易理解,别人理解起来困难;只说用户视角,太零碎,不容易记住主线。

5、学会区分听众的提问

在短时间内完全讲清楚一个新项目,几乎是不可能的,听众也一定消化不了。当领导同事提问时需要学会判断,什么样的问题该当场解答,什么样的问题下来私聊。高效的需求评审不是解决100%的问题,而是在1个小时的时间里解决最重要的问题。以下两类最好能够当场回答:(1)关乎价值,关乎为什么做;(2)关乎完整性,这个问题不解决,整个产品逻辑不通。

三、工具:WSJF模型

WSJF,即Weighted Shortest Job First,中文翻译是加权最短作业优先。WSJF是算出来的一个比值,分子是需求的价值,分母是实现的成本,也就是说,经过WSJF模型计算后,先做的需求,都是价值高且成本低的。

在实际操作中可以把所有被插需求、被压紧急需求、已排期需求被调整优先级的理由进行整理,然后聚类分析。会发现无外乎是之后发现,无非是决策层、战略、商业、体验等维度。可以根据业务需求,拆解各类影响因素并进行打分,如:

“决策分:从高到低10分满,权重为5;

战略分:从高到低10分满,权重为3;

商业分:从高到低10分满,权重为2;

体验分:从高到低10分满,权重为1。”

权重比值的计算可以用过往需求来估算,一般不需要特别精确,只要符合目前公司的价值观即可(如果是体验第一,那就体验权重高;如果是推重点项目,那就战略权重高)。

分母的计算相对标准且简单,通常考虑完成时间及成本。比如A功能价值100万(每个月)需10个月完成,另一个B功能价值20万(每个月)需1个月完成。通过WSJF模型计算,前者每个月价值是10万,后者每个月价值是20万。如果先做第一个,意味着我们只能在10个月后,拿到20万的收益,那么开发A功能的成本要计算上延期B带来的价值损失。

一个好的需求价值评估模型,能够帮助产品团队省掉扯皮,也能让整个产品良性发展,研发资源利用率更高。但最好的方法和模型,永远是根据自己所处的条件分析改造得来的,而不是用已有的成型方法。