需求的优先级是产品经理工作中常被提及的，那么在产品工作中，要如何去评估需求的优先级呢？
产品经理可以算作是需求管理工程师，跟进需求可能不算个难事，但是作为产品新人排优先级却很可能是个头疼的活，你如何评定重要性和紧急程度呢，是凭经验凭直觉，还是群策群力，又或者看业务数据，还是听老板的意愿？
其实排优先级是个很艺术的活，也是个很考验人的活，小到业务细节的理解，大到产品战略的安排，它是产品经理的核心能力之一。
好的产品是公司调度大局的枢纽宝藏，就算是个产品新人，也万不可不动脑只听领导的，或者只听业务的，慢慢的你作为产品会越来越没有话语权，所以今天来和大家讨论一下最科学的评定需求优先级的标准。
一、需求池管理
作为产品经理，最好针对负责的产品建立一个需求池，平时不管是来自业务的老板的需求，还是客户需求观察竞品看到的机会都记录进去，并对需求池进行滚动式管理。比如这样：
有个需求池还不够，我们还得根据自己的分析建立需求优先级坐标轴，每周的产品会上拿出来和大家讨论（以前研究过产品会议上参会人对需求逐一打分的模式，这样虽然看起来公平但是因为太费时费力被放弃了）。
需求收集方法论大概可以按两种形式分类，一种是新旧论——现有功能优化和新功能增加，另一种是内外论，内部部门需求和外部用户需求。下文的结构是以第二种形式进行讨论的。
为什么要有后一种讨论形式呢，因为第一讨论形式下的新功能增加有时并不是个很重要的方面，现有功能优化常态化都是比增加新功能要更重要的，在我看来，不管负责的产品处于何种发展阶段（是成长期或是成熟期），作为产品经理最应当关注的应该是必备需求和期望需求的的优化优化再优化。
90%的人打开支付宝就是为了付款，打开饿了么就是点外卖，将产品将用户的一个需求的满足做到登峰造极，何愁没有用户没有增长呢。所以第一种切分也就显得不科学了。
记得有句企业家的名言“永远不要给我一个点子，而要告诉我现在的问题”。
的确，产品的工作以解决问题为主，以增光添彩为辅。为什么这么说呢？现有的问题一定是经过事实验证待调整且必调整的， 而全新添加型的需求一来其必要性难以自证，是否符合当下的发展阶段需要战略性的俯瞰与讨论，二来客群对标程度需要实验，有大量的市场和用户调研要填补，因此问题性需求远比增加型需求更关键。
二、内部需求管理
来自内部的主要是公司各部门春笋般砸过来的需求，比如你是手淘的产品经理，闲鱼的产品过来说小范啊我这要上个新活动你给我引流做个配合吧，比如商务过来说某个模块的合作紧急停止了，你下版迭代把模块給下线了吧，这些需求有些很紧急，有些令人懵逼，作为产品我要怎么有条理又有理有据地进行安排呢。
首先，要明确这些公司内部需求的优先级并清楚影响优先级的因素。
先給需求影响力定义一个公式；
提出方即是谁提出的这个需求？是老板是业务还是运营，或者是用户反馈过来的。我们可以給不同来源方以不同的权重，比如我们是做pugc的，来自用户的需求权重給0.9，来自KOL的需求給0.8，来自运营的需求給0.5，来自老板的需求給0.7。
困难时效即困难是短期冲突性压力还是会长期存在的弊病？ 这个参数以时间维度去量化。
提出频次即同一个需求可能被不同部门或不同人或不同会议上反馈，一般来说一个需求提出的频次越高，证明它的影响面越广，越应该予以重视。
影响受众即困难方，就是需求给谁造成阻碍了？此参数可以按影响受众的数量*其重要性，一般来说可以按C端用户，B端用户，新用户老用户，普通用户还是会员或者大客户。
阻碍程度可以分为A完全无法使用 B很难使用 C可曲线解决但形成障碍 D稍影响体验去打出分值。
综上可以得出一个需求的影响力因子，并且在产品优先级的评级会议上阐述的有理有据。
按上述方法得到每个需求的影响力因子。然而会议上可能还会有人质疑你！小范啊，这些都是以公司内部需求为视角进行的观测，我们做产品的还是要有用户思维啊！
为避免被此种鸡汤型绵里藏针的建议否定，我们在做优先级平定时还要参考用户的反馈。用户是什么？用户是产品最有力的论据和武器，谁说谁感觉都不好使，用户说用户感觉就是王道！尤其是在新增功能和去掉某功能这种谁说都不好使的艰难时刻，这个必杀技必须拿出来献礼。
那哪里去找用户感觉呢？用户问卷这种成本低简单可行又方向鲜明有力的东西，作为鸡贼的PM咱哪能放过它，但是怎么搞功能问卷呢。
第一步：组织问卷内容，形式如图
第二步：发放问卷
可以线下和线上结合的，且以由内向外的圈层方法辐射向外：
首先线上一是要放在自己的官网/公众号/APP，面向自己的用户、会员和关注者；
二是找对标客群进行发放，去XX社群XX垂直论坛去找目标用户，比如女性消费群体就找小红书，甚至竞品客群啊，触达形式也多种多样了按性价比去挑吧，邮件push短信站内信广告banner弹屏等等；
最后记得给些奖励哦，亚马逊问卷调查一般都是会送免费代金券的呢。
第三步：统计结果，拿结果建立坐标轴
我的坐标轴是按照功能满意度和功能具备程度两个维度去圈定的，没有按市面上比较流通的那个按紧急程度和重要程度为象限轴去划分。
先来看一下市面上常用的分类方法：
要说明一下为什么没有选择市面上常用的以紧急程度作为坐标轴呢，有两个考虑：
第一，最最紧急的线上问题往往会采取回滚、重新发版的形式，轮到我们记录进需求池的需求大概率都不是啥火烧眉毛的需求；
第二，紧急程度、重要程度这两个考量维度全部都难以量化啊有没有，你说以什么为考核依据呢？业务着急就是紧急还是老板着急就是紧急？Emmmm至于客户着急吧，重要的客户的需求那不就是火烧眉毛的吗，不重要的稳当隔需求池里按期迭代✌️所以我就采用下图的方法对需求进行分类。
这个比对维度好就好在满意度和具备程度这都是可量化的，满意度就是上文问卷调查得出的用户调研结果，可以拿过来直接用。
其实不管是问卷调查还是一对一的用户走访访谈，按反馈的结果统计就行。再者app内部的意见反馈、公众号和appstore的用户留言、高投诉率的客服内容这种现成的feedback你得收集起来啊（显得你是个多么有同理心和用户情怀的PM～)
OK通过坐标轴上的不同类别的需求线把需求按用户心智统计起来！
优先级排序：
举个例子拿微信来说：
必备功能：没有满意度就降低，有的话满意度不会提升。聊天功能
期望功能：没有满意度会降低，有的话满意度会提升。群聊功能，朋友圈功能
魅力功能：没有满意度不会降低，有的画满意度会提升。微信公众号的打赏功能
无差异功能：没有满意度不降低，有满意度不提升。比如看天气功能
