需求池对于产品经理有多重要?
每个项目都会有一个需求池,你的项目应该也不例外吧。技术开发的速度,感觉总赶不上需求池增长的速度,身有体会吧。做不完的需求,清不空的需求池。每次版本迭代的源头,也许不是来自需求池;可是消化不了的需求,总是倒入了需求池。别再让你的需求池成为需求的垃圾堆,说说需求池的那些事儿。
一、需求池的定义
需求池:不在本次开发版本范围内的所有需求。严格来说,即使是下一个开发版本的需求,也可以算作是需求池的范围。需求池中的需求,有些可能只是一个想法,有些还需要调研,有些还需要讨论,总之,需求池中的需求和实际交付给开发的需求还是有一定距离。
二、需求池的由来
“好记性不如烂笔头”,一句话而概之,需求池的由来。你还记得上个月第二周的产品讨论会上xxx提出的想法吗?赶紧打开需求池看看吧。别让你的好想法就这样溜走,快点记下来吧。
三、需求池的作用
- 记录暂时无法消化的需求;
- 头脑风暴的源头;
- 版本规划的源头。
当你没有产品灵感的时候,需求池很可能会帮你一把。
四、需求池的优先级
需求有优先级,需求池自然也有优先级。优先级是个很难划定的东西,经常被人提到的“四象限法”:对需求进行归类,重大问题修复、重要体验优化、重要的新功能…这种比较主观的归类,每个版本都需要进行一次主观的优先级判断,相对来说太消耗时间了。有些需求或优化由于影响了正常的使用和核心功能,这样的需求优先级高,大家很容易达成共识。对于一些新功能和产品规划的方向性问题上,优先级的确定很可能会演变成一声拉距战,最后就是谁的级别高听谁的。
是否还有更优的确定优先级方法呢?当然有。优先级最好能够量化,减少主观判断,形成一个可视化的数学计算方法,而且让大家达成共识,也很重要。
试试从这几个纬度去考虑优先级
- 阶段性目标是什么?
- 需求服务的用户数量是多少?
- 投入产出比是否合适?
加入这几个纬度的考虑,很容易过滤掉一大半的需求,抓住重点,让大家共识重点。看似简单的东西,可是当时为了优先级争得面红耳赤的时候,谁还会记得它呢?基于这几个纬度,可以进一步对需求进行纬度细分和权重细分,讨论出一个优先级计算公式。以后优先级的讨论只要套用这个公式就行,一劳永逸。
五、需求池的细分项有哪些?
需求标题、需求描述、产品线、提交人、提交时间、功能模块、优先级、需求状态等,便于需求的追述、调研、细化,最终快速形成可以交付给开发的需求。无法满足这些选项的需求,也就没有必要进入需求池了,对待需求也需要一个严谨的态度。不是你的随便一个想法都能进入需求池的,这个idea满足了我们用户的什么需求?如果提交人回答不知道,我想就没有必要进入需求池了吧。需求池的细分项,让需求更立体化,更清晰,过滤那些想都没有想清楚的需求吧。
小结
是时候该优化一下你的需求池了,清理那些没有价值和无法细化的需求,制定好大家认可的优先级公式,让重要的需求池动起来吧。
本文由 @jxwsina 原创发布于人人都是产品经理 ,未经许可,禁止转载。
“需求池:不在本次开发版本范围内的所有需求”,看到这个定义我就退出了你的文章
量化需求优先级的思路挺赞的
我觉得是有借鉴意义,但是细节上怎么来计算并没有说的很清楚~~也很想了解一下~~希望作者能给到详细描述
不错,学习了
我以前是做程序的,现在想转产品了,不知道前途怎么样?
慎重吧,现在的产品岗已经不是你有好想法你热爱就可以做的,大部分的公司更需要有一定经验的,或者是熟悉相关业务的人。0level的基本机会会比较少,薪水方面也会比较低。研发的话,你踏踏实的干,深入下去,薪资会稳步上升,转行的话一方面薪水会有落差,另一方面产品岗位也会有产品岗位的挑战和压力,你可能花在研究需求的时间和各个部门沟通的时间一半一半,用户量、用户活跃是你的KPI,需要承担用户不活跃的风险,等等。
往管理层走吧,做产品其实也可以,如果你喜欢的话,也是OK的,不少产品经理是从研发转型过来的。不过刚开始会有一定的落差。
我做产品,做的心很累,我还有必要坚持下去吗
需求列表其实更符合实际
🙂
多维度考虑需求优先级很有借鉴意义。四象限有点主观和模糊。