产品经理如何定义需求优先级？

总的来说，定义需求优先级暂时有这七个方法：

KANO模型法：基本型需求>期望型需求>兴奋型需求

矩阵分析法：重要且紧急>重要不紧急>紧急不重要>不重要也不紧急

经济收益法：经济收益高且紧迫的功能需求   ＞ 经济收益高但不紧迫的功能需求   ＞ 紧迫但经济收益不高的功能需求   ＞ 不紧迫且经济收益不高的功能需求

前/后置需求分析法：前置需求的优先级   ＞ 后置需求的优先级；前置需求的重要性和紧迫性   ＞ 后置需求的重要性和紧迫性

满足核心用户需求的优先（二八原则）

满足核心业务的需求优先（资源**化利用）

满足核心业务的投入产出比**的需求优先（ROI**化）

下面为你一一道来。

方法一：KANO模型法：基本型需求>期望型需求>兴奋型需求

KANO模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的一种工具。

通俗地讲，人的需求可以分为三种，包括基本型需求，期望型需求和兴奋型需求。

以我们平时坐车上班为例，坐公交坐地铁是基本型需求，打的是期望型需求，每天有人接送上下班则是兴奋型需求。很容易理解吧。

所以，显而易见，基本型需求的优先级应当排在**位，期望型需求排在第二位，而兴奋型需求则排在*后。在互联网产品的设计研发过程中，我们可以按照这个顺序来排定需求优先级。

方法二：矩阵分析法：重要且紧急>重要不紧急>紧急不重要>不重要也不紧急

矩阵分析法，也叫四象限法则，把一个二维的横竖坐标分成四个象限，横坐标是重要性，纵坐标是紧急性。**象限为重要且紧急，第二象限为紧急不重要，第三象限为不重要也不紧急，第四象限为重要不紧急。

在工作当中，我们可以根据当前实际情况，把手头上的所有工作根据四象限法则进行重要性与紧急性的分析定义，然后把这些工作一一放进相应的象限当中，*后再按照矩阵分析法的顺序来完成工作。

举个例子，你现在手头有四件事情需要处理。**件事情是你女朋友明天生日，而你还没准备好礼物。第二件事情是运营部本月15号要做一个活动，今天是3号，运营部期望*晚14号要完成内测，确保能够在15号按时上线。第三件事是开发说需求文档里有个地方表述有点问题，怕理解错误，希望你在下班前跟他讲解一下。第四件事是周末有个聚会，大家让你推荐个地儿。

根据矩阵分析法，你应该按照事情一>事情二>事情三>事情四的顺序来依次完成。

方法三：经济收益法：经济收益高且紧迫的功能需求   ＞ 经济收益高但不紧迫的功能需求   ＞ 紧迫但经济收益不高的功能需求   ＞ 不紧迫且经济收益不高的功能需求

这个方法其实跟矩阵分析法道理是一样的。同样是把一个二维坐标轴分成一个矩阵（四个象限），横坐标是经济收益，纵坐标是紧迫度。**象限是经济收益高且紧迫度高，第二象限是紧迫度高但经济收益不高，第三象限是紧迫度低且经济收益不高，第四象限是经济收益高但紧迫度低。

那么同理可得，我们在进行用户需求分析，排需求优先级的时候，也可以按照这个方法来处理。对于经济收益高且紧迫的需求，我们就应当列在 P1 优先级里。而对于经济收益低又不紧迫的需求，我们就应当列在 P3 优先级里。（注：P1，P2表示优先级的高低，P1>P2>P3）

方法四：前/后置需求分析法：前置需求的优先级   ＞ 后置需求的优先级；前置需求的重要性和紧迫性   ＞ 后置需求的重要性和紧迫性

所谓前/后置需求分析法，是指在一款产品的开发过程中，有的需求是必须要提前开发的，而有些需求是可以放在项目后期开发的。

比如电商网站中，注册登录、选品加购、下单结算和支付这些是必须要优先开发完毕的，否则用户根本无法顺畅地完成一个完整的购物流程。

不过，为了使整个购物流程更闭环，我们可能需要增加评价模块，支持用户下单成功后可以评价商品，以此作为获取用户需求的一种通道；为了刺激和提高用户回流，我们可能需要在支付成功页增加个性化商品推荐模块和促销广告模块；为了引导用户进行购买决策，我们可能需要在分类列表页/商详页/活动页等各个页面增加一个促销标识、用户评价数、下单数等信息。后面说的这些，都是可以在完成*简单基础的MVP 电商网站之后再排期开发的。

或者任何一个需要前后端协作的需求，接到需求的时候，前端和后端可以同时开始，但由于工作量或其他原因，可能后端需要的时间久一些。但前端要写完这个功能必须用到后端接口，所以从理论上后端接口应当提前开发完毕，这样才能在 deadline 使前后端都完成这个功能的全部开发工作。

前/后置需求分析法也是日常工作中时常可以使用的，大家可以尝试下。

方法五：满足核心用户需求的优先（二八原则）

这个很好理解的。产品的用户有核心用户（可能 80% 左右），也有边缘用户（可能 20%   左右）。产品本身就是为那 80% 的核心用户开发的，不可能满足所有用户的所有需求。

所以，核心目标用户的需求永远是放在**位的，非核心的边缘用户的需求在分析的时候很顺其自然就会往后排，甚至排到你根本不想开发。

这是绝大部分公司的通用做法，可能只有类似鹅厂这样的公司才会稍微考虑点边缘用户的需求吧，比如会考虑和照顾残障人士的需求。

而在实际工作中，我们可能并不能很清晰地区分出谁是核心用户，谁又是边缘用户。那我们可以简单转换下思想——提出相同或者类似需求的用户体量有多少。提的人多咱就做（比如100个人里有70个人说要做。），提的人少咱就不做（比如10个人里就1个人说可以做。）

方法六：满足核心业务的需求优先（资源**化利用）

公司有自己的主营业务，一款产品也有自己重点发展的业务和需要满足的用户群。

比如我现在做餐饮软件，我重点参与的项目主要集中于“智慧门店”这块，那么围绕“智慧门店”的正餐、快餐业务、会员营销、门店的数据统计与分析等是我们的重点业务，所以在排定需求优先级时，我们就会把这方面的需求排在 P1 优先级里，把其他非核心业务的需求排得比较靠后。

方法七：满足核心业务的投入产出比**的需求优先（ROI**化）

按照方法六的说法，我们应当优先满足核心业务的需求，但核心业务的需求可能有很多，比如我刚才说的正餐业务需求，光说正餐业务其实是比较笼统而空泛的，因为整个正餐业务也许有几百上千个需求。

那么如何从这些需求当中找到优先级排**的需求呢，这时就可以参考方法七了——在所有能满足核心业务的需求里面，找到投入产出比**的需求优先开发。

举个例子，我们从整个正餐业务的需求里面抽出 20 个需求放入 P1 优先级需求池，那这 20   个需求到底先开发哪个呢，按照方法七，先开发投入产出比**的需求。从理论上讲，总的原则就是，花*少的时间、*少的资源、*少的预算开发完功能，尽可能快地赶在时间窗口，获取*多的用户，赚*多的钱。

当然，说了这么多，可能*终都敌不过老板那句话——来，咱们先做这个需求吧。听我说，这是大部分公司的常态，心态放好就ok。

不过，碰到这种情况，我们还是需要分析一下的。

首先，我们需要尝试站在老板角度思考问题，因为我们不是老板，站的高度没有老板高，看得也不如老板远，他对市场的判断可能比你更准确，要命的是也许比你还更懂产品。那么在这种情况下，如果我们跟老板的意见相左，我们可以提出自己的想法，但*终决策权交给老板。

但是，如果老板对产品啥也不懂，就知道瞎鸡巴乱指挥，今天让你先做 a 需求，明天就让你先做 b 需求了，反反复复没个定数。那么作为伟哥，能给你的建议只有一个——赶紧收拾东西跑路。恩，这也许是你 2018 年听到的*真诚的建议。

*后，不管你在工作中受到老板多大程度的牵制与干涉，作为产品经理，如何去排定需求的优先级，你自己心里要有一杆秤。