如何确定需求的优先级,是产品经理在面试中常常被提及的高频问题,这个问题在我昨天分享的“腾讯产品经理3面面经”中也有被提到,所以需求的优先级判断对于产品经理来说尤为重要。
任何一个需求实现都需要消耗资源成本,如何让这些成本获得最大化收益,考验着产品经理的决策能力。
一个惯常的思路是——我们投入了资源成本,对应地会带来收益或效率提升。只要关注投产比这个指标,自然能很轻松做出正确决策。
理论与实践的差距正在于此。绝大多数时候,投入和产出都是很难量化的东西。就算真正去量化,涉及很多拆解出来的细分项,也只能靠拍脑袋估算;少量的指标估算对结果的影响可控,一旦绝大多数指标都需要通过估算来完成,结果显然就不可靠了。
所以,进行需求优先级决策时,定性的分析尤为重要。
1、为什么需要优先级
首先,每个公司或者团队资源是有限的,不控制需求的优先级,产品可能永远无法封闭,得不到想要的产出。就好比我每天下班,希望早点到家,但公司离地铁站有点远。回家的方案有走路或骑共享单车到地铁站,然后坐地铁回家。也可以直接打车回家。每种方式的成本和效益都不一样。
其次,需求是经常变更。没有哪个产品是完全规划出来的。中间总会因为各种原因导致无法按照预期步骤进行。可能市场环境变了,可能领导想法变了,可能政策变了,也可能有其他种种原因…..这也是为什么互联网产品需要快速迭代,不断试错。
2、需求优先级排序理论
2.1 KANO模型
定义:KANO模型是对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系。
KANO模型最初并非用于互联网产品需求优先级排序,而是提高企业服务的方法论,后由于与互联网产品经理日常工作非常契合,开始逐步被大家熟知,并被广泛应用。
KANO模型将用户需求分为5个维度:基本需求,期望需求,兴奋需求,无差异需求,反向需求。
具体每种类型需求的定义不赘述,百度一下就有详细的概念,通过上图基本能够理解。
KANO模型的基本思想:通过用户调研,测量每个用户对于每个需求功能点进行评价,然后进行无差异化的满意系数计算,得到一个优先级排序。KANO模型优点是量化明确,从用户角度出发,相对合理。不足之处在于,依赖用户调研样本,及调研过程中各种可能的差异。因此,实际工作中,这些用研结果仅作为一个需求优先级参考,与实际产品数据结合来运用。
2.2 波士顿矩阵
定义:波士顿矩阵又称市场增长率-相对市场份额矩阵、波士顿咨询集团法、四象限分析法、产品系列结构管理法等。
波士顿矩阵也并非最开始用于互联网产品需求优先级排序,而是企业如何选择更有前景的产品市场。将原有坐标进行更改,以适用于产品需求优先级判断。如下图:
波士顿矩阵方法在《产品视角》书中也有提及,大家有兴趣可以去了解一下。瘦狗金牛方法运用类比手法,也将需求进行分类,包括4类:问题型需求、明星需求、金牛需求和瘦狗需求。
瘦狗金牛方法的核心思想:瘦狗需求需要过滤掉,明星需求优先级最高,金牛需求和问题需求则根据产品生命周期及产品定位等因素有先后。相对于KANO模型定量分析,瘦狗金牛方法则是一种定性的分析。
3、需求优先级排序实践
实际工作中,上述理论并无法完全支撑需求优先级排序。不是说上述理论无用,而是由于各种条件限制,导致的一种无序状态,让产品经理在实操过程中非常抓狂。我总结了以下思考的维度:
3.1 产品生命周期阶段
谈产品的生命周期,从《用户体验要素》中的5个层次来讲,就是战略层的思考。产品处于不同阶段,侧重点是不同的。处于引入期,能带来新增的功能优先级较高。新增达到一定量级的成长期,留存变得更重要。成熟期的产品,商业化变现逐渐重要起来。
这主要是从产品的定位来考虑。有些产品从一出现开始,就是为了大量变现的,洗一波用户就撤的。
3.2 影响范围
需求的影响范围是衡量优先级的重要因素。直接影响产品的绝大部分核心目标用户一定是优先级高的需求,这是产品的基石。对于一个to c线上产品而言,核心功能至多2-3个,解决用户的核心痛点。功能日活跃渗透率是个很好的衡量指标。
3.3 影响程度
痛点需求一般情况大于痒点需求。只有因为难用而失败的产品,没有因为难看而失败的产品。A功能影响用户基本使用,B功能能够基本达到用户要求,优先级谁高自然一目了然。
3.4 投入产出比
投入产出比主要考量效益和成本。效益可以包含直接收入,运营效率及推广成本,用户的效益等。成本主要是人力成本、时间成本和金钱成本等。潜在风险有时候也是未来的一种成本。较小的成本获取较高收益的需求一般优先级较高。
3.5 老板需求
老板需求是产品经理无法避免的,而且一般优先级较高。这主要是从需求来源的维度去考虑,有同事、用户、老板…..
为什么是老板需求优先级高?
首先,老板的经验和思考高度一般是高于一般产品经理的。其次,老板是直接为产品最终结果买单和负责的。最后,不按照老板需求来,产品经理可以跑路了……这里讨论的老板需求本身,不讨论老板需求的正确性。如果已经说服老板调整需求优先级,就不存在该问题。而是老板就是要提高某个需求的情况下,且态度较明确。
3.6 目的明确,版本封版
无论需求的优先级多么高,产品迭代的版本必须封版。目前互联网产品主要通过快速迭代方式进行,周期一般1-2周时间。一个版本开发周期越长,功能越多,延期风险越大,且问题是成倍的出现。
一般情况下,对于影响重大,实时性非常强的需求才可临时加入当前版本,否则加入下个版本。需求未能按时完成,为了按期版本封闭,常用方法为砍需求。
以上,是通过现象,到理论,再到实践3个维度来说明如何确定需求的优先级。
最后,说了再多方法论,都不如自己踩过的坑。产品经理的痛只有自己清楚,与各位产品共勉。