


作者 / 李东林 · 编辑 / Jenny
当一个产品的MVP版本上线之后,产品经理每天都需要和新的需求打交道(如果要了解MVP的定义方式,可以参考往期文章《如何定义B端产品的MVP》点击标题即可阅读),需求可能来自于各种渠道,从客户,从销售部门,从运营部门,从老板以及内部规划的需求。
在面对这些纷繁复杂的需求的时候,产品经理日常工作的很大一部分就是判断需求的优先级,做与不做,什么时候做等。需求优先级的判断是产品经理日常面临的最大挑战之一。在需求优先级判断的时候,一些常见错误如下:
1. 谁话语权大就听谁的
很多时候产品经理很难有充足的理由去拒绝一个需求,毕竟那是实实在在的需求,拒绝意味着得罪人。于是一些产品经理就根据需求方的话语权来进行优先级判断。这也是在中国为什么很多人说最大的产品经理就是老板的原因,如果老板不懂产品,天马行空的想法往往会毁了一个产品。
因为产品的逻辑和线下的业务逻辑是有很大差别的,跟线下业务恰恰相反,产品逻辑需要极其严谨,但是灵活度很低,线下很简单的一个需求如果要搬到线上来的话,可能成本代价特别大,所以一些没有固化还在摸索的业务内容搬到产品上面来,会极大的浪费公司的产品技术资源以及限制业务的灵活度。
在我看来,产品经理最大的痛苦在于跟不懂产品和技术的人解释线上实现的难度,以及从更全面的角度评估功能PK业务部门相对片面的角度。
2. 跟着竞品来走
竞品有什么我们也必须有什么。实际上不同的公司阶段对于功能优先级的判断肯定是不一样的,比如说一个成熟的公司提供的功能,如果你现在都还没有什么客户,一些极其低频发生的业务前期根本没有必要支持,先把主线功能做好做极致就行,不要追求面面俱到,前期追求面面俱到最多就是一个中庸的产品,很难有出彩的地方。
3. 根据行业里面的风向来判断需求的优先级
行业的风向经常在变,很多都是没有验证的东西,如果没有自己的主线,跟着风向走,就会疲于奔命,失去焦点以及自己产品的定位。
做产品经理为什么那么难,因为做产品是没有标准答案的,做产品每天都做做取舍,做产品做任何的决定都可能得罪一部分人。需求优先级的判断也是没有标准答案的,需要考虑的变量因素非常非常多,产品的阶段,公司的阶段,团队的阶段,人员的情况,都有可能导致需求的优先级发生变化,我们在判断需求优先级的需要考虑的几个常见因素如下:
□ 产品的长期战略以及短期战略。这里提醒一点,产品负责人建议在每个季度的时候都要定义产品的目标,这个目标需要在公司层面形成一致,后面如果需求偏离的时候很容易有准绳,否则没有一个基准线,在做需求判断和外部沟通的时候会浪费很多时间。
□ 需求的用户价值。需求的用户价值,一般基于对单个用户的价值乘以需要的客户数量,功能对单个用户的价值可以根据操作的高低频,以及这个功能涉及到的业务对客户的重要度来进行计算。
□ 开发的成本周期。需求方的人一般对产品和技术是没有概念的,所以需求的开发周期评估是很重要的优先级判断的基准。
□ 功能成功的可能性。除非已经被市场证明的功能,对一个行业进行探索的时候,很多功能开发的效果是有未知性的,功能成功的把握也是优先级判断的一个重要基准。这里有一个小建议,为了避免业务部门只是从自身利益,不是公司长期发展角度来提需求,可以将功能上线之后对业务部门反向评估功能的价值产生情况,从而来避免业务部门随意的提需求。

有时候优先级判断比较复杂,很难用简单的二维图来解决问题,这个时候RICE就是一个很好的打分判断优先级的方式,这里的R就是Reach, Reach指的是多少客户在固定期间内会被这个功能影响到,这个数据可以用一个季度内使用的客户数,或者一个月内客户操作的次数来衡量。
I 就是Impact,Impact就是这个功能对产品目标以及战略的影响,可以用1,2,3分数来评估,分数越高,影响越大;
C 就是confidence,就是有多大的把握这个功能会成功,100%表示很大把握,80%表示适中,50%表示比较低;

1. 产品的战略以及整体的路线图要经常思考,所有的需求的判断要以这个为核心和基础。
2. 记住少就是多,不要盲目的增加需求以及开发新功能,保持产品的简洁易用至关重要。
---------
欢迎大家在文末 “留言区” 互动交流

推荐阅读
点击图片即可阅读



转载/投稿/内容合作/寻求报道
请联系微信:qifuxiaozhushou3W

