两种常见的需求优先级的排序方法

1. 两种常见的需求优先级的排序方法

两种常见的需求优先级的排序方法。一种是基于四象限法则，另一种则是基于KANO模型。
  
 四象限法则一般需求的重要程度很难量化，尤其在来源复杂的情况下。营销部门着急要我们配合做活动，不做就少赚好多钱，业务部门着急要我们配合做一套自动化结账工具，做了能节省很多成本。。。有时抉择会很痛苦，要权衡各种利弊，考虑最合理并且能说服别人的理由。最常用的判断方法是Stephen Covey提出的紧急重要四象限法则。
                                          
 四象限法则我们要把紧急且重要的需求排在最前，不紧急但重要的需求其次，紧急不重要的需求再次，最后是不紧急不重要的需求。
  
 而在判断是否重要时，可以参考这样的排序（重要程度由强到弱）：
  
 • 不做，会造成严重的问题和恶劣的影响
  
 • 做了，会产生巨大好处和极佳效果
  
 • 跟核心用户利益有关
  
 • 跟大部分用户权益有关
  
 • 跟效率或成本有关
  
 • 跟用户体验有关判断是否紧急，可以参考以下排序（紧急程度由强到弱）：
  
 • 不做，错误会持续发生并造成严重影响
  
 • 在一定时间内可控但长期会有糟糕的影响
  
 • 做了，立刻能解决很多问题、产生正面的影响
  
 • 做了，在一段时间后可以有良好的效果
  
 
  
  
 KANO模型另外一种很常用的方法是东京理工大学教授狩野纪昭（Noriaki Kano）提出的KANO模型。
                                          
 简化版KANO模型作为一个需求对应的功能，“行”描述的是“如果有的话”，用户会“开心”、“无所谓”还是“不开心”;“列”描述的是“如果没有的话”的情况。具体分析如下。
  
 矛盾：如果用户觉得功能存在和不存在都很开心，或者都不开心，显然是有问题的，这种矛盾的情况是存在逻辑问题的，不予考虑。
  
 错误：如果功能不存在让用户很开心，或者功能存在让用户不开心，那么这个功能显然是错误的功能，不予考虑。
  
 无关：如果功能存在和不存在，用户都觉得无所谓，那功能也就无关紧要了，同样不予考虑。
  
 最重要的就是以下三类需求：
  
 必要：如果功能存在，用户并没有特别的感觉，但功能不存在，用户会不开心。这说明这个功能是要满足基本需求的，也就是大家常说的“痛点”。期待：如果功能存在用户很开心，功能不存在用户很不开心，这就是满足用户最直接、最明显的需求了，因为在用户内心已经有所期待。
  
 惊喜：如果功能不存在的时候用户并没有感觉，说明对这个功能，用户之前没有预期，但功能存在用户很开心，也就是说达到了惊喜的效果。能够超预期满足用户。
  
 任何需求对应的功能都可以分为“惊喜型”、“期待型”和“必要型”。考虑需求的价值，就要基于这三种类型来做判断。很多公司和产品利用的产品运营手法就是在满足后两种类型需求的同时，不断用第一种类型需求激活用户的热情，促使用户传播。基于四象限法则或者KANO模型，可以完成优先级的标注。通常我们会用P1、P2、P3、P4来标注不同优先级的需求，P1优先级最高，P4优先级最低。

2. 需求优先级排列技巧

3. 如何定义需求的优先级

在日常生活中，处理任务的优先级有四种情况：重要且紧急；重要不紧急；紧急不重要；不紧急不重要。这四种情况也是我们处理需求优先级的原则，即重要性+紧急性。把需求的重要性+紧急性统称为商业价值原则。

需求那么多，一些理论的东西百度里有很多。说说我自己的理解
当然是根据用户的需要啊！你做这个产品之前你肯定想过你这个产品的定位，人群是哪些。根据你产品的功能，需求是跟着产品的使用情况来不断更改。（当然，产品做很久没人用自然也谈不到需求增加的情况）比如微信定位就是移动社交，那最主要的需求肯定是聊天。当聊天做的多了发现用户有分享的需求，于是接着做了朋友圈。需求和功能是相辅相成不断成长的。

而且你只是说“你有自己的想法”，需求需要调研和做画像的。但像上面说的，不同产品需求不同你的策略也要不同。比如猿题库，他的定位人群很准确也 很好定。而且功能也相对简单。所以在用户体验上下功夫就好~再如陌陌，定位是社交。市面上已经有微信他如何竞争和定位？于是抓住了隐私性降低的陌生人距离社交，这也是需求啊。

所以我的结论是，不同产品不同策略方式。这种问题没有最优解，所以需要PM非常强的市场敏锐度和策略方案。想一想用户为什么用你的产品，粘度从哪而来，解决了用户的什么问题。

4. 需求优先级排定的八个维度

因为工作需要，我查阅了网络上常规的几种需求优先级排序方法结合实际工作经验，选取了比较重要的8个维度。理论上8个维度已经非常充足，真实使用中不必完全使用。可以选取重要的维度进行判断，通过新的权重分配，得到最后的优先级评估结果。
  
 以下所有评估默认五分制进行，在通过加权求得最后的需求优先级评估值。评估值越大，优先级越高。为了降低模型的主观因素，建议每个维度由多人进行打分，取平均分会有更好的效果。最后，由于模型是线性的，仅起到参考作用，还是需要产品经理做出最终决策。
  
  1. 目标契合度（20%） 
  
 目标对需求优先级的影响非常关键，因为目标体现了需求实现的最终价值。我们需要结合产品当前阶段和Roadmap，进行需求契合程度的判断。
  
  2. 需求价值（10%） 
                                          
 需求价值分为用户价值，公司价值两块来分析，使用四象限法进行分数指标的确定。在不同的产品类型侧重的价值方向不同，所以究竟是用户价值更重要还是公司价值更重要是需要通过自己判断的。但如果两者都体现了很好的价值，那么评分自然可以较高。
  
  3. Kano模型（10%） 
                                          
 Kano模型是非常经典的判断模型，包含基本型需求>期望型需求>兴奋型需求
  
 实际运用中需要根据现有需求的分布情况进行综合判断，有时期望形的需求可以比必须需求更重要。因为必须需求也要看用户群范围，如果必须需求的用户群并不大，或者现有产品阶段的必须需求覆盖面已经较广时，期望需求评分可以更高。
  
  4. 重要紧急程度（10%） 
                                          
 重要紧急程度的分析可以运用在众多领域，包含重要且紧急>重要不紧急>紧急不重要>不重要也不紧急。比较简单，不做赘述。
  
  5. ROI投入产出比（20%） 
  
 投入产出建议将投入分两部分进行分析，投入包含产品设计和产品实现两个阶段，这两个阶段有时并不会等价。产出也需要进行细致分析，因为通常而言，产出和时间的关系非常大，有些产品的长尾效应非常严重。
  
  6. 需求来源（10%） 
  
 需求来源也是一个参考维度，因为谁提的需求可以用来判断需求的真实场景和缘由。其中老板的需求，或者是用户直接的被验真的需求是最高分，但一定是要经过细致的需求分析，确认是真实需求的需求。其余像产品规划，用户非直接需求的分数相对较低。
  
  7. 需求依赖（约束）（10%） 
  
 这里的需求依赖主要指的是本需要求是否是其他需求的前置需求，或后置需求。这体现了开发中的前后排期关系，非常重要。一般包含前置需求的优先级  ＞ 后置需求的优先级；前置需求的重要性和紧迫性  ＞ 后置需求的重要性和紧迫性。
  
  8. 技术风险（10%） 
  
 开发的难度，可能出现的开发风险程度。注意工期过长，也会导致风险增加，所以只要开发上的不确定因素越多（如服务器资源，开源系统性能等），此值越低。
  
 
  
  
 
  
    
 链接：https://www.jianshu.com/p/93c4dca33058

5. 产品管理中的需求优先级如何排序？

有这样一个问题，题目是：假设现在你负责一个产品的设计，请注意这个前提，现在有若干个需求列在这里，请排一下顺序。
　　A、市场合作伙伴给你提供的需求，要求你产品做某种改进以便他们推广，这样可以给你带来每天不少的流量，对用户的影响未知；　　B、销售部门给你的需求，要求产品做某种改进以满足广告主的期望，对用户可能会有少许不利影响；
　　C、某个知名的产品设计大师，行业内公认的领袖级人物，在公开的博客或私下里跟你说的，他认为用户所需要的功能；
　　E、客户服务反馈过来的信息，很多用户提出的一种需要。
　　F、市场调研公司发出的报告，通过调查问卷获得的用户需求。
　　产品经理工作中打交道最多的就是需求了。每天的纷杂事务中，大多数工作都是在处理各种各样的需求。当我们面对纷繁复杂的世界，我们要想使自己更清醒，更加超然脱俗的把事情做好，就必须要做出取舍。产品管理中，我们需要同样的道理，来对待它。
　　产品是一整套固化的解决方案，其本质就是用来解决目标用户的需求。在互联网产品管理过程中，对待需求优先级的判定和管理，个人认为有如下三个原则。
　　1、客户需求优先级高于用户需求。从某种角度来看，客户是一种特殊的用户类型。这种“用户”他为产品买单，在产品应用上，有更大的话语权。利用自身的资源、技术和竞争优势，满足客户更多的需求，以实现互联网产品的增值，这本身就是互联网产品经营的方向。因此客户需求的优先级是要高于普通用户需求的。当然有一种情况需要特别说明，当客户需求和用户需求产生冲突的时候，我们要考虑的就不仅仅是优先级的问题了，而是在满足需求和解决矛盾的过程中，产品的价值是否得到了体现，是否是一个可持续发展的选择。
　　2、确定的需求优先级高于不确定的需求。一个需求的提出，其背后往往代表了若干人等的产品诉求。对于这样的诉求，我们是否清楚来龙去脉，是否有足够的调研数据以证明其真实性，是否符合产品的战略发展规划，是否有潜在的风险尚未考虑到...当一个需求的方方面面都是确定的，都有初步的论证和思考之后，才是动手去响应的好时机。俗话说，谋定而后动，就是这个理。当然也有人说互联网讲究的是兵贵神速，什么都考虑清楚了，黄花菜都凉了。这话也是有道理的，做互联网产品必须是小布快跑，否则肯定落后，但是这与要做明确的需求并不矛盾，只是对产品经理有了更高的要求--既要准，也要快！
　　3、响应需求必须考虑投入产出比，算成本帐。在有限的资源条件下，要优先处理投入少，收益大的需求。而对于响应代价太大，而效果评估不高的需求，要敢于舍弃。只有这样，才能轻装上阵，在有限的条件下，做出出色的产品来。
　　结合上述三个原则，回头再看这道题，答案就应该清晰不少。
　　需求A、B都属于不确定的需求，哪怕再诱人，都不能轻举妄动。要“发回重审”或协助完善需求，把需求明确了再来谈优先级。
　　需求C貌似金玉良言，不过再知名的产品专家，也不能一下子就能洞悉先机。毛泽东同志说过，没有调查就没有发言权。因此，需求C也是不确定的需求，听听就好了，千万别盲目崇拜。
　　需求E是确定的客户需求，这是毫无疑问的。
　　需求F是基本确定的用户需求，前提是该调查问卷时针对产品做的有效调查问卷。

6. 需求管理之需求优先级

有经验的产品经理都会建立一个需求池，通过需求池对需求进行管理。我把需求管理分为三个关键部分：需求分析、需求优先级排序、需求落地推进。第一是需求分析，需求分析旨在将接收到的业务需求or用户需求转化为产品需求，这个在上一篇文章 《需求分析：从业务需求到产品需求》  中已抛了小砖。完成需求分析后，产品需求将进入第二部分，需求优先级级排序，这将是本文重点阐述的内容。需求优化级排好序之后，则将进入真正的需求推进、落地执行的阶段，后续另起文章进行说明。
  
 关于产品需求优化级排序，理论上来说是根据需求的轻重缓急，将需求定义为重要且紧急、重要但不紧急、紧急但不重要、不重要也不紧急，然后划分为四象限进行管理。这也是通用的时间管理方式。但在实际操作过程中就会发现，大前提是需要明确的定义出大家都认可的何为重要，何为紧急；而且在一个象限中也存在多个需求需要重新PK，需要再次划分的情况。另外一个问题就是，当产品经理负责的是整条产品线甚至多条产品线，涉及跨业务部门的时候，通常会遇到每个业务部门都认为自己提出的需求是最重要最紧急的，应该得到第一排序，这时候产品经理通常需要花费较多时间去沟通协调，去让一些人作出让步，毕竟人力跟时间是有限的。还有一种情况，在创业型公司呆过的产品经理就会了解，很多需求其实是直接来自老板，产品经理会基于某种你懂的的考虑，将老板提出的，实际可能又不是太靠谱的需求排在最前面。这样一来，综合上看，整个需求优化级排序就充满了人情味，可能太过于感性了。这对于产品本身的发展而言，不一定是好事。毕竟互联网产品的时间窗口是极其重要的。
  
 所以我在思考有没有相对理性科学的方法，后来发现多维度打分法也许更合理。
  
 多维度打分法也符合SMART原则。从1.产品阶段目标契合度；2.用户期望；3.业务期望；4.需求难度；5.开发难度；6.老板需求这六个维度综合考虑，每个维度相互独立，只是权重不同；通过各自打分及加权，最终得出需求优先级综合得分，得分越高，则优先级越高。
  
 具体如下：
                                          
 具体案例：
                                          
 几点说明：
  
 1. 多维度的出发点是最大程度保障需求优先级的合理性，不单方面依靠老板、用户、业务方、产品人员、开发人员的决策，虽然每一项打分也有可能偏感性，但综合起来会比一言堂好很多。
  
 2. 其中，阶段目标契合度是基于阶段目标进行考虑，这就要求产品经理必须清楚所负责产品的发展路径，绘制出产品的roadmap，且经常review，在各里程碑节点及时刷新得分。
  
 3. 有条件的情况下，阶段目标契合度、用户期望、需求难度、老板需求由产品经理打分，业务期望、开发难度由相对应团队leader打分；没条件的情况下，则都由产品经理打分，前提是产品经理对业务、对系统、对技术要有相当程度的熟悉。
  
 4. 每个公司的情况不同，故各维度的权重也会有所不同，这个可以根据所在公司情况进行相对应的调整。
  
 欢迎关注作者公众号[第五堂课 (No5_Class)]

7. 如何确定产品需求优先级

在对用户调研、挖掘用户需求后，就是要将用户需求转为产品功能并判断优先级。下面细分如何确立需求优先级（模糊并列了产品功能优先级）。
  
 （1）时间紧。对于互联网企业来说，时间紧迫，加上互联网瞬息万变，很多公司都在加快步伐，快速占领市场。在对用户需求进行调研和挖掘后，会梳理出很多需求，那这些需求做还是不做，什么时候做（优先级），就需要产品经理想清楚、定下来。
  
 （2）资源有限。对互联网企业来说，资源总是有限的。在有限的资源下，只能是开发有限的产品功能。如果产品功能过多，必然会导致项目复杂，资源消耗过大，使得项目变得不可控。集中资源，专注某几个点，是互联网企业的必然选择。
  
 所以，大部分互联网企业都是以“小步快跑，快速迭代”的产品开发方式，在产品发展的每个阶段，只选择最重要的产品需求进行开发，力争以最快的速度完成产品更新并投入市场。通过这种方式，利用市场来检验产品需求，不断的优化完善产品。为了确保企业能在产品的每个阶段只开发最重要的产品需求，就需要产品经理对产品需求进行优先级排序，来进行过滤取舍。
  
 在对需求排序之前，还先要了解需求有哪些分类，哪些是重点？
  
 （1）分类：基础功能（必不可少的功能）、期望功能（用户表述出来的需求）、亮点功能（带给用户惊喜的功能）、无差别功能（做不做对用户没有差别）、反向功能（功能引起用户讨厌）。
  
 （2）分别对待：基本功能必做、期望功能按性价比排序、实现个别低成本的亮点（大公司做法不同，可展开）、无差别功能别做（无差别功能的低成本判断方法，可展开）、反向功能权衡利弊（往往是多目标的冲突处理，可展开）。
  
 确定产品需求优先级排序，主要从这几个方面去考虑：
  
 1、需求的投入产出比
  
 2、需求的紧急程度、重要程度
  
 3、需求的复杂性
  
 一般情况下，判断产品需求优先级的主要依据是需求的投入产出比（ROI），即产品需求的投入成本与产出价值之间的比例。投入产出比越低，说明产品的效益越大，产品需求就越值得我们开发。反之，则放弃开发。
  
 投入产出比 = 投入成本 / 产出价值* 100%
  
 产品需求的价值包括用户价值、公司价值和商业价值三个方面。作为企业，最终看中的还是商业价值。一般产品的用户价值越高，它的商业价值也越高。
  
  ①  用户价值。 是指这个需求能够影响多少用户数，能让多少用户更多使用产品。如果是商业产品，还可以计算出如果满足这个需求，可以从每用户那里获得多少收入。即需要考虑需求的潜在用户数、单个用户价值、需求频度等。
  
  ②公司价值。 是指这个需求对公司的战略目标有什么影响。比如：与产品定位不符的需求，即使投入产出比很低，也要选择放弃。每个阶段推出的产品功能，一定要符合这个阶段的产品目标，并不是一下子推出所有功能才是最好的，分布上线，快速迭代才是正道。通常公司目标也是产品目标可以是量化的，比如DAU达到10万，可以是关键结果，比如“建立个性化推荐机制”，那么如果某个需求的实现能够进一步帮助公司实现目标，它的价值也就更高。
  
  ③商业价值。 就是指这个需求实现了能带来多少收入，或者如果不实现，会损失多少。对于内容类产品，主要体现就是原生广告的新形态需求。基本就是有单子就一定要做的。而对于商业化产品，通常就是那些能刺激用户的付费的各种促销手段，这些的优先级一般都是比较高的。
  
 产品经理在做产品需求价值评估时，要综合这三方面，通常是以公司价值为主，兼顾考虑用户价值和商业价值，以半定量方法，从1-5评分，得出一个平均值，平均值高的价值也就高，判断出产品需求价值的等级大小。
  
 产品需求的成本就是实现产品需求时需要投入多少的成本，包括开发人力成本、维持产品正常运行的硬件成本、后期的维护成本以及日常运营成本等。
  
 一般情况下，对产品需求成本的评估只需要考虑开发资源的投入即可。产品经理可以根据经验大致估算一下开发成本，也可以与开发团队共同评估。这个成本值只是一个大概值，因为此时的需求细节还不明确，但是这个估算值对投入产出比也有着非常大的参考价值了。
  
 根据需求的紧急程度，我们也可以确定产品需求优先级。这就是我们常用的四象限法则：P0紧急重要、P1紧急不重要、P2不紧急重要、P3不紧急不重要。
                                          
                                                              四象限法则
  
 
  
  
 一般我们可以用（预计）工作时长来表示该需求的复杂性。但在考虑复杂性的时候还需要考虑实际可调配的资源情况。比如：这个功能是否需要投入较高的运营费用？是否拥有足够的人力去支持该需求的运营？最后，还需要去考虑该项目的风险程度。开发小伙伴是否有能力完成，该需求是否会对已有的其它功能产生影响？
  
 因此，可以总结为“需求复杂性=时间+资源可调配情况+风险程度”，当然时间、资源可调配情况和风险程度是需要根据项目组的实际加权处理的，在不同的项目中，不同影响因素在复杂性确定中占据不同的权重。
  
 
  
  
 综上，可以看出，产品需求的优先级排序很多时候需要综合考虑多个因素，可以首先基于经济价值和成本之间的关系，对所有功能进行一个初始排序，尽早开始价值成本比高的主题。在此基础上，结合对紧急程度和风险的考虑，产品负责人也可以结合团队的评估来进行调整。

8. 产品经理该如何做需求优先级排序

因为之前一直从事的都是toB的企业，因此以下的分析都是源于对toB行业的理解
  
  在现在的toB互联网企业里，主要的需求来源有以下几个： 
  
 1. 销售人员
  
 2. 售后人员
  
 3. 项目团队内部
  
 4. 客户爸爸
  
 5. 公司战略
  
 
  
  
  那需求这么多，到底我们该如何排优先级呢？ 
  
 销售人员提出需求，最大的出发点在于打单，即打动客户，赢下订单。而这些销售人员收集到这些需求的渠道无非以下几个：
  
 1. 客户在现场的反馈
  
 2. 竞品的压力
  
 3. 自身在使用过程中遇到的明显问题或者天马行空的想法
  
 所以总的来说， 销售同学提出产品需求，目的在于开拓市场 
  
 
  
    
 1.  客户反馈
  
 2.  自身在客户运营过程中的遇到的问题
  
 3.  自身的一些产品改进想法
  
 所以总的来说，售后同学提出的需求，目的在于 更好的服务客户，以及提升客户运营效率 
  
 
  
  
 项目团队内部，产品的开发和运营团队，一般提出需求的场景有：
  
 1.  通过运营数据发现产品问题，进而提出优化需求
  
 2. 发现线上缺陷，进而提出修复需求
  
 3. 通过竞品分析，为赶超竞品而提出相关需求
  
 4. 通过产品规划制定，为实践规划提出细化的产品需求
  
 项目团队提出需求的目的更多的在于 提高产品的市场竞争力（优化自有产品体验，超越竞品体验，打造领先优势） 
  
 
  
  
 客户爸爸在使用的过程中，自然会提出一堆的需求，一般提出需求的场景包含以下几个：
  
 1. 使用过程中遇到了bug
  
 2. 希望我们能够优化某个功能
  
 3. 希望我们能够新增某个功能
  
 总的来说，客户爸爸提出的需求的目的在于 更加好的产品使用体验 
  
 
  
  
 公司高层掌握了更多的信息，同时对公司的发展负责，会对公司各个产品线提出整体的需求，以实现公司战略的执行。而提出这些公司战略的场景一般包含以下情况：
  
 1. 根据公司定位，完成公司产品矩阵的打造
  
 2. 增加公司的收入来源
  
 3. 对比竞品建立自身的竞争优势
  
 4. 根据市场现状对产品做出相应调整
  
 总的来说，公司战略的出发点一般在于 公司层面的市场竞争力 
  
 
  
  
 
  
  
 所有的需求来源都梳理完了，那到底这么多的需求，对于一条产品线的产品经理来说，该如何去做优先级排序呢？
  
 
  
  
 有些产品，由于违法或者踩在了灰色地带，公司意识到危险或者收到控告后，则该砍产品线就砍产品线！该砍功能的就砍功能！该整改的就整改！所有需求往后排！只有公司在，才有希望，无论产品线负责人多么不舍，这都必须是最高优先级的需求！
  
 核心业务流程受阻，这样的产品根本无法使用！根本不能实现产品的定位！根本不能满足用户使用这个产品的初衷！这样的缺陷必须马上修复！马上！
  
 公司层面的战略调整，这个应该是正常迭代中最高优先级的需求了。公司为了实现公司的战略目标（例如商业模式或者价格体系的调整，或者产品线之间的整合与配合），会相应的投入较多的资源，各个产品线会以最高优先级去做响应，作为产品线负责人，这时候把公司层面的战略调整放在日常迭代的最高优先级没有任何毛病。而且公司的战略调整一般会提前公布，留有的时间一般比较充足，但任务一般也很艰巨（公司层面一动就是大动）。
  
  这两类需求的优先级和产品所属的阶段有关 ：产品现在是在快速扩张期，还是成熟迭代期。
  
  若是快速扩张期 ，这时候的市场远未饱和，市场瞬息万变，正是开疆拓土的好时机啊，这个阶段的迭代 一般以满足市场开拓而做的产品调整为主 。
  
 若是产品处于 成熟迭代期 ，这时候市场成熟，用户接受度高，此时的产品迭代就 以优化现有的产品体验为主 了。
  
 例如， 同样是为了开拓市场而提的两个需求，哪个的市场需求更加迫切，那肯定就是先做哪个的 。至于如何判断哪个市场需求更加迫切，则需要结合客户的业务需求以及竞品的压力，综合考虑后，才能够做出决定——而这就要求你需要去掌握更多的信息。
  
 至于 现有产品的优化迭代，则需要衡量哪个需求是对用户体验最大的优化 ，这个一方面可以通过运营数据来衡量，另一方面也可以通过用户的主动反馈次数来衡量，而所有的这些都只是产品负责人做决策前的参考信息
  
 而真正的实践中，一般会在新功能的迭代中夹带一些功能的优化，又或者是在优化迭代中夹杂一些新功能的开发，中间都有一个度，但每个版本一般都会有其主要目的：是以优化为主，还是以新增功能为主。
  
 以上是我在这几年的从业生涯中所总结的需求管理经验，或对或错，望能对你有所裨益，愿我们同在产品的道路上共同进步。