需求的优先级是产品经理工作中常被提及的，那么在产品工作中，要如何去评估需求的优先级呢？
在产品经理的工作中，需求优先级是经常被提及的事情。毕竟资源总是有限的，需求是无限的，想利用有限的资源来做无限的需求是不现实的，所以需要给需求排优先级。只是这个优先级怎么定义，一直是个问题，下面我来讲讲我的理解。
首先，需求来源于我们的目标用户，我们的需求是用来解决用户遇到的摩擦。所以，优先级定义的第一个维度就是摩擦的强烈程度。举个例子：对温饱的需求的强烈程度会远远高于文化生活的需求。
其次，用户的摩擦，存在一定的发生频率，频率可能从“时时刻刻”到“百年一见”，很明显，如果频率越高，那么用户这个需求就越迫切。
最后，需求的满足都是需要一定的成本的，产品经理需要对自己的投入产出比有一定的衡量。
所以总结一下，需求优先级可以暂时定义为：
一、重要程度
对于重要程度，需要时刻考虑两个维度：用户的维度和公司的维度。
我们需要为用户考虑，因为他是我们需求的直接来源；我们需要为公司考虑，是因为我们本质上是为了公司服务的。在产品生命周期的初始阶段，我们需要多为用户考虑多一点，这样产品才能成长起来；在生命周期进入稳定期时，这时候就需要多为公司考虑，从而达到盈利的目的。
由于公司的维度和用户维度大多时候都是冲突，所以我想先从用户层面来剖析需求，最后引入到公司的维度。用户的维度而言，有一种经典的模型：卡诺模型。它将需求分为以下几种，我用统一的“如果有……就；如果没有……就”这种句式做统一的解读：
必备型需求：如果有这个功能，用户满意度不会提升；如果没有，用户满意度会降低；
期望型需求：如果有这个功能，用户满意度会提升；如果没有，用户满意度会降低；
魅力型需求：如果有这个功能，用户满意度会提升；如果没有，用户满意度不会降低；
无差异需求：如果有这个功能，用户满意度不会变化；如果没有，用户满意度也不会变化；
反向型需求：如果有这个功能，用户满意度会下降；如果没有，用户满意度不会变化。
这五类可以用下面的图来展示，为了方便理解，我把线条都画成直线或者折线。
对于这5种需求的分类中，有些人会把发生频率也纳入到评估体系中，但是严格来讲，这是不对，这5种需求划分应该只跟产品的定位有关系。
举个简单的例子：
对于网盘，它的定位是一个“在线存储”的产品。其最基础的功能应该是：增、删、改功能，所以这三个是作为必备型的需求。
接着，如果文件越来越多，那么就会有管理的需求，这时候需要有文件夹分类、移动文件和复制文件等功能，所以这些会作为期望型的需求。
如果网盘能提供高达1T的存储空间，那么这个功能就作为一个魅力型需求。
如果网盘提供一个功能：用户可以选择让文件大小显示精确到小数点后10位的功能，这个对于大部分用户来讲是无感知的，那么这就是一个无差异需求。
这5种需求里在产品的生命周期的不同阶段，优先级各不相同。初期是必备型需求占优，第一个版本需要做出一个最小的可用产品，才能投入到市场里。在后续迭代里，需要稳步地加入期望型功能，然后每个迭代版本加入一两个魅力型功能，也就是传说中的“亮点”功能，用以配合产品的宣传。大部分的无差异需求和反向型需求是不会被安排的，除非对于公司来讲，这些需求有其他方面的价值。
比如：某手机厂商之前标榜的后盖的弧度打磨经过了xx个版本。这种弧度的差异接近于无差异功能。但是为什么还要做这个事情呢？因为这可以作为一个营销的亮点，打造“匠心公司”的一种品牌形象。
再比如，反向型的需求常见于各种商业化的需求，不管是广告、还是增值服务、道具收费等，这些都可能阴气用户反感，但是可以增加公司营收，所以这些需求在最后产品稳定期，都会作为重点去坐。
总结一下，需求重要程度的评估既需要考虑对于用户的价值，还需要考虑对于公司的价值，以及考虑所在的产品周期。
二、频率
频率这个词比较好理解，这是一个比较客观的标准，大家对这个词也很熟悉。只是，我有一个有趣的想法想跟大家分享一下：摩擦的发生频率不仅仅是存在于实际遇到的时候，也存在于用户自己的想象中。
举个简单的例子，对于闹钟，一开始大家都习惯于“周中”的闹钟，即周一到周五的闹钟。因为大多数的情况下，我们都是这5天需要上班上学。但是，大部分的国家都有一个叫做法定节假日的东西，所以就有可能出现周六或者周日上班的情况。
如果，只从“周中”和“周末”这两个概念来说，是没办法满足用户的需求的。这时候，就需要引入一个“工作日闹钟”的概念。产品会自动判别今天是不是需要上班，从而智能地提醒。
这个现在基本都是闹钟产品的标配了，但是，我思考的是这个需求的发生频率。理论上节假日都是少数，大部分情况下，只选“周中”也是可以满足用户的诉求的。但是，如果用户在设置之后，都需要一直担心“明天会不会响”这种事情，那么我认为这个需求的摩擦就一直都存在的。
可能用户设置完之后没有感知，但是如果发生第一次、第二次调休迟到之后，这个担心就会一直困扰着用户。虽然实际上节假日是少数，但是在用户的想象中，这确实是一个“每天担心的事情”，所以从这一点而言，我觉得这个是一个“高频”的场景，而不是“低频”的场景。
三、成本
产品经理这个岗位，一直都有一种“管理”的属性，因为产品经理需要协调好设计、开发和测试同学，共同地完成自己的设想。对于管理者而言，成本的评估一直都是不可绕过的一环。
最基础的成本，也就是开发成本，开发成本是所有成本里最主要的成本，而开发成本最直接的指标就是开发时间。除此之外，如果涉及到比较复杂的场景，那么交互设计的成本也是明显增加。如果涉及到比较复杂的动画，那么视觉设计的成本也比较高。最后，还有测试的人力成本。
你以为这就完了吗？
其实并不是，产品经理自身梳理逻辑以及撰写文档也是需要时间成本。这是最常规的成本。有些需求可能还会涉及到商务、法务甚至三方公司，涉及到方面越多，成本就越高。
最后这些零零总总加起来，才是总的成本。提出成本这个概念最重要的一条就是：希望产品经理在评估成本的时候，也要把自己考虑进去。
以上，就是我对于需求优先级评估这件事情上的心得，分享给大家。这种评估方法适用于大部分的需求，除了“老板的需求”。老板需求的存在不可以用常理来衡量，如果老板比较讲道理（理想情况下），你可以拿这套优先级评估的方法跟他沟通。如果不行，那么老板的需求优先级直接就提到最高了，而不需要经过任何评估。
