B端产品怎么判断需求优先级？.docxVIP

B端产品怎么判断需求优先级？ 产品经理的日常工作基本是围绕需求展开的，而面对不同角色给出的各类需求，产品经理该如何判断需求的优先级呢？怎么找到判断标准与关键呢？针对这样的疑惑，笔者给出了一系列分析与解答。 一、判断一个需求的优先级的常见错误 当一个产品的MVP版本上线之后，产品经理每天都需要和新的需求打交道（如果要了解MVP的定义方式，可以参考原来的一篇文章《 怎样定义B端产品的MVP》），需求可能来自于各种渠道，从客户、从销售部门、从运营部门、从老板以及内部规划的需求。 在面对这些纷繁复杂的需求的时候，产品经理的一些日常工作就是判断需求的优先级，做与不做，什么时候做，需要进行高密度的判断。 需求优先级的判断是产品经理日常面临的最大挑战之一。在需求优先级判断的时候，一些常见错误如下： 01 谁话语权大就听谁的 很多时候产品经理很难有充足的理由去拒绝一个需求，毕竟那是实实在在的需求，拒绝意味着得罪人，于是一些产品经理就根据需求方的话语权来进行优先级判断。 这也是在中国为什么很多人说最大的产品经理就是老板的原因——如果老板不懂产品，天马行空的想法往往会毁了一个产品。 因为产品的逻辑和线下的业务逻辑是有很大差别的，跟线下业务恰恰相反，产品逻辑需要极其严谨，但是灵活度很低，线下很简单的一个需求如果要搬到线上来的话，可能成本代价特别大。所以一些没有固化还在摸索的业务内容搬到产品上面来，会极大的浪费公司的产品技术资源以及限制业务的灵活度。 在笔者看来，产品经理最大的痛苦在于跟不懂产品和技术的人解释线上实现的难度，以及从更全面的角度评估功能PK业务部门相对片面的角度评估。 02 跟着竞品来走，竞品有什么我们也必须有什么。 实际上不同的公司阶段对于功能优先级的判断肯定是不一样的，比如说一个成熟的公司提供的功能，如果你现在都还没有什么客户，一些极其低频发生的业务前期根本没有必要支持，先把主线功能做好做极致就行,不要追求面面俱到，前期追求面面俱到最多就是一个中庸的产品，很难有出彩的地方。 03 根据行业里面的风向来判断需求的优先级 行业的风向经常在变，很多都是没有验证的东西，如果没有自己的主线，跟着风向走，就会疲于奔命，失去焦点以及自己产品的定位。 做产品经理为什么那么难，因为做产品是没有标准答案的，做产品每天都做做取舍，做产品做任何的决定都可能得罪一部分人。 需求优先级的判断也是没有标准答案的，需要考虑的变量因素非常非常多——产品的阶段、公司的阶段、团队的阶段、人员的情况，都有可能导致需求的优先级发生变化，我们在判断需求优先级的需要考虑的几个常见因素如下： 产品的长期战略以及短期战略。这里提醒一点，产品负责人建议在每个季度的时候都要定义产品的目标，这个目标需要在公司层面形成一致，后面如果需求偏离的时候很容易有准绳，否则没有一个基准线，在做需求判断和外部沟通的时候会浪费很多时间。 需求的用户价值，需求的用户价值。一般基于对单个用户的价值乘以需要的客户数量，功能对单个用户的价值可以根据操作的高低频，以及这个功能涉及到的业务对客户的重要度来进行计算。 开发的成本周期。需求方的人一般对产品和技术是没有概念的，所以需求的开发周期评估是很重要的优先级判断的基准。 功能成功的可能性。除非已经被市场证明的功能，对一个行业进行探索的时候，很多功能开发的效果是有未知性的，功能成功的把握也是优先级判断的一个重要基准。这里有一个小建议，为了避免业务部门只是从自身利益，不是公司长期发展角度来提需求，可以将功能上线之后对业务部门反向评估功能的价值产生情况，从而来避免业务部门随意的提需求。 所以说，从单个维度去判断需求的优先级肯定会出问题的，需要从综合全局的角度来判断一个需求的优先级。我今天在这里介绍几种需求优先级判断的原则，希望在大家判断优先级以及和业务部门沟通需求的时候起到帮助： 二、需求优先级判断的原则 01 用户价值／实现成本 第一种比较简单的判断方法就是根据用户价值以及工作量，简单用一个二维的图显示如下： ?我们首先要找到的就是价值最高，但是工作量最小的需求，先把好摘的价值比较大的果子摘了，然后再去摘工作量中等一些，但是价值也比较大的果子。 类似这样的思路，整个评估的过程中可以让团队来参与，工作量的评估，用户价值的评估，让团队参与练习，形成优先级判断的观念以及形成统一的意见，团队也有参与感。 02 RICE方式 有时候判断比较复杂，很难用简单的二维图来解决问题，这个时候RICE就是一个很好的打分判断优先级的方式。 R就是Reach，?Reach指的是多少客户在固定期间内会被这个功能影响到，这个数据可以用一个季度内使用的客户数，或者一个月内客户操作的次数来衡量。 I就是Impact，Impact就是这个功能对产品目标以及战略的影响，可以用1，2，3分数来评估，分