实战中,如何管理产品需求优先级

Home » 产品思维 » 实战中,如何管理产品需求优先级

「小密圈朋友提问: 在实战当中,如何确定需求优先级? 」

答:

运用KANO 模型管理用户需求,很多著名培训机构的产品经理课程均有讲解;在实际的工作中,这个理论有效么?请看下文

1.需求优先级存在的意义

Hozin说过:如果不考虑成本,用【梯子嫁接梯子】的方式也可以实现登月(成本极高)。
无论巨型公司还是小微公司,都会存在需求优先级,因为研发资源总是有限的,研发成本永远需要控制。

合理利用开发资源,实现【好钢用在刀刃上】,追求ROI最大化,是每个公司的追求。

2.需求体系是如何建立的

产品一旦启动,负责人(CEO、产品总监、产品经理)会事先牵头,产品、研发、运营、市场团队协商一致,拟定一个产品优先级;这种时序叫RoadMap(产品线路图),如果不发生意外,产品设计和研发团队会按照这个线路走下去。

3.需求优先级总是意外变更

然并卵,几乎没有任何RoadMap能严格执行下去,或许刚刚制定,马上就发生变化。

引起变化的原因很多,说几个常见的:

A.领导(CEO、投资人)的一句话,于是就变了。领导一定站的比你高,望的比你远,这个没错;

B.竞争对手逼着你改变,后续产品计划可能被竞品抢先上线,于是就变了;

C.市场资源、运营资源发生变化,本来公司打算做个蛋炒饭,但运营找到了做鱼汤的方法,结果产品目标就要从盘子换成盆;

D.研发成本突变,本以为简单的关键技术,实践后发现难度太高,需求必须进行妥协;

E.试错验证,原计划的产品价值根本不存在,商业模式走不通,需要进行颠覆调整;

4.产品人员是【需求过滤器】

产品狗,真的会咬人。实战中,每天会有大量反馈和各种【需求】扔到面前,通常产品人员会做这么几件事儿:

A .过滤那些伪需求

a1)有些用户天天喊饿,喂越饱他越饿,因为他是糖尿病,食物是伪需求,真需求是胰岛素;

a2)绝对不为1%的用户实现100%的功能,不是普遍的需求,不提供解决方案;

a3)有些需求通过运营手段能够解决,并不需要变更产品功能;

a4)一些需求的确能见到【蝇头小利】,但会损失未来更巨大的核心利益;

B .扔进需求池,搞清楚成本与风险

b1)一些看上去简单的需求,可能涉及到巨大的开发量,比如核心算法改变,引起数据统计系统的偏差;

b2)功能可逆,数据不可逆;某些需求一旦上线就无法回滚,比如积分体系,要搞清楚风险;

b3)需求的变更,可能与正在开发提测的需求是相互矛盾的,废弃进行中的开发,代价几何;

b4)有些需求需要新开产品线,不仅仅是一个简单的研发问题,评估需求本身的成本就非常高;

C .了解并确认研发资源

c1)有几个研发小组?正在开发什么?即将完成的有哪些?提测的有哪些?

c2)目前正在提测的需求有多少bug是没有关闭的?何时能上线?

c3)新的需求需要开发多久,能争取到资源么?(越大的公司,争取资源越难)

c4)开发人员是否近期有离职异动,新需求能否争取到靠谱的开发人员?(别笑,这真是个大问题)

D.需求封闭机制

为了避免需求变化,很多研发团队是有需求封闭机制的,塞进去新需求很难,要分批次的等待。


以上,看完产品人员如何过滤需求,明白狗存在的意义。

5.对于创业型公司,通常Hozin对正在进行中的需求有如下排序:

A.最高优先级00:威胁到线上产品正常使用的
阻断式的bug,闪退,系统崩溃,明显的低级错误,存在安全隐患,泄露用户隐私

B.高优先级01:当前转化相关,开发代价较小
只需要简单调整就可能带来巨大转化提升

C.优先级02:营收转化较好,开发代价较大
当前转化率较高,能带来营业收入,再提升转化需要付出巨大成本

D.中优先级03:数据统计类需求
使用现状反馈,对转化趋势判断的相关统计功能,帮助公司合理决策

E.中优先级04:运营效率需求
提升内部工作效率的各类后台产品功能,帮助公司节约运营成本

F.中优先级05:新产品线(新转化)的前置需求
比如打算新增一个视频播客的功能,无论如何是要先把后台数据搭建起来的,总有一些通用功能需要先搭建

G.低优先级06:新产品线(新转化)的试错
A/B测试类的产品功能,虽然开发量不多,但需要周密筹划,在需求阶段仔细推敲

H.低优先级07:所谓战略型需求
可能带来巨大营收,但运营没有准备好,市场也缺乏教育

I.低优先级08:没有转化参照物的需求
当前转化率一般,并且即便提升转化率,也不能马上带来营收

此优先级方法不一定适合所有公司,不一定适合所有人,仅作参考。

原创文章不容易,各位高抬贵手,未经授权,谢绝转载

大家的支持,是内容更新的动力,让我们科学治疗懒癌吧。

标签: 产品管理, 需求优先级, 需求管理

添加新评论