互联网产品经理每天都会面对各种各样的需求，分别来自不同的角色，包括用户、老板、同事等。可是团队资源有限，面对需求池中如此多的需求，如何确定优先级呢？这是很多产品新人面对的困扰。通过和产品组同事一起小圆桌交流讨论，结合自己实际项目经验总结，现将其沉淀下来，并方法论化。

1. 为什么需要优先级排序

首先，每个公司或者团队资源是有限的，不控制需求的优先级，产品可能永远无法封闭，得不到想要的产出。就好比我每天下班，希望早点到家，但公司离地铁站有点远。回家的方案有走路或骑共享单车到地铁站，然后坐地铁回家。也可以直接打车回家。每种方式的成本和效益都不一样。

其次，需求是经常变更。没有哪个产品是完全按照预设出来的。中间总会因为各种原因导致无法按照预期步骤进行。可能市场环境变了，可能领导想法变了，可能…..这也是为什么互联网产品快速迭代不断试错。

2. 现有需求优先级排序理论

2.1 KANO模型

定义：KANO模型是对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

KANO模型最初并非用于互联网产品需求优先级排序，而是提高企业服务的方法论，后由于与互联网产品经理日常工作非常契合，开始逐步被大家熟知，并被广泛应用。

KANO模型将用户需求分为5个维度：基本需求，期望需求，兴奋需求，无差异需求，反向需求。

具体每种类型需求的定义不累述，百度一下就有详细的概念，通过上图基本能够理解。KANO模型的基本思想：通过用户调研，测量每个用户对于每个需求功能点进行评价，然后进行无差异化的满意系数计算，得到一个优先级排序。KANO模型优点是量化明确，从用户角度出发，相对合理。不足之处在于，依赖用户调研样本，及调研过程中各种可能的差异。因此，实际工作中，这些用研结果仅作为一个需求优先级参考，与实际产品数据结合来运用。

2.2 波士顿矩阵（瘦狗金牛）

定义：波士顿矩阵又称市场增长率-相对市场份额矩阵、波士顿咨询集团法、四象限分析法、产品系列结构管理法等。

波士顿矩阵也并非最开始用于互联网产品需求优先级排序，而是企业如何选择更有前景的产品市场。将原有坐标进行更改，以适用于产品需求优先级判断。如下图：

波士顿矩阵方法在《产品视角》书中也有提及，大家可以阅读了解。瘦狗金牛方法运用类比手法，也将需求进行分类，包括4类：问题型需求、明星需求、金牛需求和瘦狗需求。瘦狗金牛方法的核心思想：瘦狗需求需要过滤掉，明星需求优先级最高，金牛需求和问题需求则根据产品生命周期及产品定位等因素有先后。相对于KANO模型定量分析，瘦狗金牛方法则是一种定性的分析。

3. 实战中需求优先级排序

实际工作中，上述理论并无法完全支撑需求优先级排序。不是说上述理论无用，而是由于各种条件限制，导致的一种无序状态，让产品经理在实操过程中非常抓狂。我总结了以下思考的维度：

3.1 产品生命周期阶段

谈产品的生命周期，从《用户体验要素》中的5个层次来讲，就是战略层的思考。产品处于不同阶段，侧重点是不同的。处于引入期，能带来新增的功能优先级较高。新增达到一定量级的成长期，留存变得更重要。成熟期的产品，商业化变现逐渐重要起来。这主要是从产品的定位来考虑。有些产品从一出现开始，就是为了大量变现的，洗一波用户就撤的。

3.2 影响范围

需求的影响范围是衡量优先级的重要因素。直接影响产品的绝大部分核心目标用户一定是优先级高的需求，这是产品的基石。对于一个toC线上产品而言，核心功能至多2-3个，解决用户的核心痛点。功能日活跃渗透率是个很好的衡量指标。

3.3 影响程度

痛点需求一般情况大于痒点需求。只有因为难用而死掉的产品，没有因为难看而死掉的产品。A功能影响用户基本使用，B功能能够基本达到用户要求，孰轻孰重？

3.4 投入产出比

投入产出比主要考量效益和成本。效益可以包含直接收入，运营效率及推广成本，用户的效益等。成本主要是人力成本、时间成本和金钱成本等。潜在风险有时候也是未来的一种成本。较小的成本获取较高收益的需求一般优先级较高。

3.5 老板需求

老板需求是产品经理无法避免的，而且一般优先级较高。这主要是从需求来源的维度去考虑，有同事、用户、老板…..为什么收老板需求优先级高？首先，老板的经验和思考高度一般是高于一般产品经理的。其次，老板是直接为产品最终结果买单和负责的。最后，不按照老板需求来，产品经理可以滚蛋了……这里讨论的老板需求，不讨论老板需求的正确性。如果已经说服老板调整需求优先级，就不存在该问题。而是老板就是要提高某个需求的情况下，且态度较明确。

3.6 目的明确，版本封闭

无论需求的优先级多么高，产品迭代的版本必须封闭。目前互联网产品主要通过快速迭代方式进行，周期一般1-2周时间。一个版本开发周期越长，功能越多，延期风险越大，且问题是成倍的出现。一般情况下，对于影响重大，实时性非常强的需求才可临时加入当前版本，否则加入下个版本。需求未能按时完成，为了按期版本封闭，常用方法为砍需求。

以上，通过现象，到理论，再到实战中思考维度来说明如何确定需求的优先级。最后，说了再多方法论，不如自己踩过的坑。

作者：慕杨俊俊，微信公众号：互联网视角（www_shijiao），产品汪一枚。

本文由 @慕杨俊俊 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议