需求太多?1个思考流程,C端产品轻松规划优先级

“总是做迫在眉睫的事情,会让人丧失目标”

引用《B端产品经理必修课》书中的一句话,简明扼要的说明了需求管理的目标和意义。

需求规划的意义,是通过需求筛选的方法选择出可以在恰当的时间开发上线的需求,使产品团队工作更条例,最大化利用开发资源,同时帮助个人、团队或公司产生间接价值。

产品经理日常工作每天接触大量的需求,成熟一点的团队、公司,也都有针对自己产品需求的管理方法,甚至从需求挖掘、筛选、规划优先级都也自己的一套方法论。

C端产品从0到1的时候,通常专注做MVP,这时产品的需求量其实并不大,只围绕产品目标和核心体验来发掘和规划需求。随着产品发展,有些产品改变了定位,不再满足做一个单纯的工具类产品,而是拓展成一个用户服务平台,通过各种功能来满足广大的各类用户群体。

功能越多,服务的用户也就越多,收到的需求反馈自然也就越多,当同时面对上百个、甚至上千个需求,如何快速进行优先级规划,自然就需要一些高效的方法了。

通用方法论并非万能

需求管理通识性的方法论,产品经理们应该大多都比较清楚,但是这些方法论,都多多少少会带有主观意愿。

比如运用SWOT分析需求的优缺点和竞争力时,对于这个需求,哪个优缺点才是客观的?又或者哪些点是真正有竞争力的?

在运用波士顿矩阵来对需求进行分类时,仅通过用户体验、公司战略两个维度,似乎又缺乏客观判断。再比如KANO模型可以对产品需求进行分类,有必备型、期望型、兴奋型、无差异型、反向型等需求类别,正常在需求管理时,可以根据这些分类再加上紧急重要程度来判断优先级即可……

有些方法论工具,为了强调需求规划的客观性,还会基于模型规划的需求进行打分评级策略,试图将这些需求的规划尽可能具备科学性、合理性。

产品经理,产品经理网站

运用波士顿矩阵规划需求

但是,每个人的专业认知和想法都不同,一千个产品面对一千个需求就会有一千个观点,方法论模型没问题,只是运用模型的人要对产品的定位、目标用户相当熟悉甚至可以深刻洞察,才可以基于模型对需求进行准确的分类。就算是这样,往往也抵不过老板的一句话:“我不要你认为,我要我认为…”

当同时面对需求清单里的上百、上千个需求,想要对这些需求进行快速优先级规划。

试想一下,哪怕一个有着丰富经验的产品团队,直接套用以上方法论,再加上打分评级的步骤,或许可以完成,但也还是需要比较大的时间成本,更不用说那些只有一个产品经理的公司。对于他们的工作来讲,除了要考虑工作效率,还要考虑需求管理的方法是不是很科学。

总之,这项看似基础的工作并不轻松。

需求优先级规划层级

产品开发流程里面有一个“门径管理流程”,通过设置多个阶段和多个筛选关口,将最初收集的产品创意通过层层筛选把控,在最后开发上市阶段,最大程度降低产品项目风险。

此处引用这个思路,通过以下优先级规划层级,可帮助产品团队成员快速、准确的筛选出可行性需求,并根据客观判断依据,对需求进行优先级排序,提高工作效率和产出价值。

产品经理,产品经理网站

需求优先级规划层级

根据需求优先级规划流程,可迅速筛选出符合产品定位和公司规划的需求,并通过判断需求类型、价值,来决定需求的策划优先级,同时为产品开发团队输送高质量的产品需求。

通过需求优先级规划层级,可以为自己建立一个系统的需求规划方法,对于专业的产品团队,又可以让团队成员按照标准化的思路来进行需求管理。同时根据需求优先级的规划思路,方便产品团队成员可以根据产品特性来选择相应的方法。

如何快速运用

1. 需求定位

收集用户需求后,先搞清楚用户等级以及产品的使用程度,明确当前需求方是否为产品核心用户群体,保证需求的真实性。如果是产品内部发掘的需求,可直接明确需求的目标是否与产品目标一致,以及该需求是否未开发,即确保当前需求的真实有效性。

进行基础判断后,再识别该需求属于前台需求还是后台需求,通常直接将需求单纯的进行优先级规划是不太准确的。而是需要将该需求放到具体的频道或模块下,关联产品模块去整体思考要不要做。

2. 需求价值

该层面可以通过多个方面来体现需求的价值:

结合产品规划,判断该需求是否与现有版本规划同步,或该需求相关功能模块是否在规划内,通常符合规划的需求更容易被开发,也更容易进行需求验证;

同时围绕整体产品生命周期来判断这个需求的价值,同样的功能在产品不同运营阶段上线,产生的产品价值自然也不一样。还可以把当前需求放到产品的使用流程上,思考是想要完善体验来提升用户价值,还是修复bug来保证产品功能的完整性。

3. 可行性判断

将可行性判断放到价值考量之后,是为了促进产品的价值导向,从长期角度来看,更有利于通过开发更多有价值而不是比较容易的需求,来获得用户价值和产品价值。

经过上述判断,已经筛选了一类需求,当把既符合产品规划,又对当前产品有价值的需求筛选出来后,那么就要进一步思考这些需求的可行性。

该层面可通过宏观环境去判断当前需求的竞争力和投入产出比,同时判断这个需求如果开发上线后,有多大的影响面,可满足多少用户的核心利益,可对多少用户产生价值。

4. 需求分类

确定可行性后,就要对筛选出来的可行需求进行优先级排序,可先将需求分类,如紧急BUG解决、功能体验完善、新增亮点、未来规划,分别对应KANO模型中的必备、期望、兴奋、无差异、反向类需求。

通常紧急的产品BUG是最先需要解决的,同时因为是产品的必备型功能,对于用户来讲功能体验完善类的需求也是最应该解决的。新增的亮点可以满足用户的期望型需求,未来规划对于大多数用户来讲是无感知的,因此按照产品规划的节奏即可。

这个阶段需要特别注意无差异需求和反向需求,尤其对无差异需求的判断要谨慎认真,否则会不知不觉耗费大量的精力开发这种没有太大价值,且性价比低的需求。

最后分类出来的需求,还需要结合重要程度判断优先级,为保证客观准确,可针对同一级别、同一类型的需求进行打分,再次细分需求优先级。

5. 需求级别

判断出优先级后,就需要分别给需求进行标注级别,提供两种需求级别:P0-P3,P1-P10。

常规优先级级别是P0-P3,但是在目前实际操作中需求清单中需求太多,需求级别太少无法将需求分层细化,故还可以采用P1-P10。但同时缺点也比较明显,优先级层级较多时,就会导致越靠后的优先级定义越模糊。

如果给需求评级时没有清晰的优先级定义,那在具体执行时就比较费劲。因此建议可以采用优先级别较少的方法,如同一级别的需求较多,还可以按照以上方法再次分解,直至拆分出最小迭代单位。

总结

C端产品的规划思路是围绕核心路径打造极致产品体验,需求收集后,一个需求从确认到原型策划之前,需要经历需求甄别、筛选、判断、优先级排序等阶段,产品需求管理的工作基础但极具价值。

任何方法论模型都无法保证适应每种产品的需求规划,如何能让自己高效的进行需求管理,还需要在工作中不断地实践、融合、举一反三。

此篇文章希望通过建立一个需求规划层级,帮助我们在平时进行需求优先级分析时,可以有一个完善的、系统的思考方式,让产品工作更有序。

 

本文作者 @王曙

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部