一、 需求的优先级怎么定义？
很多产品经理，包括我，一定都会遇到这样的场景：“ 需求堆如山，什么都想做 ”。
面对各种各样、来自各个渠道的需求，产品经理的工作职责之一，就是梳理需求的优先级。我们不可能毫无选择、毫无优先级地挨个实现所有需求，因为无论公司规模大小，时间资源和开发资源往往是有限的。任何事情，都讲ROI（投入产出比），追求效率利益最大化的公司，更是如此。因此我们需要筛选出价值最大、影响面最广、正收益最大的需求来实现，这就要对需求进行优先级排列。
要对优先级进行排序 --> 就不可避免地要对其进行量化
要对其量化 --> 就要搞清楚影响优先级的因素有哪些1. 影响面
首先，这个功能预估会影响多少用户，很大程度上决定了这个功能的影响面。覆盖用户数量越大，重要程度也越大。其次，用户的使用频率，在另一个维度上决定了影响面的大小。影响面 = 覆盖用户数 x 用户日使用频次
例如一个影响500人的功能，每人每天使用10次，与一个影响1000人的功能，每人每天只使用1次，前者影响面可以简单的计算为500 x 10 = 5000，后者为1000 x 1 =1000。虽然前者覆盖用户数量只有后者的一半，但前者的影响面却要比后者大。2. 体验提升度
要获知体验提升度，就需要按照具体需求类型来看，需求一般大体可以分为：新增功能模块（如：新增想法Tab，用户可以分享交流想法）、优化功能（如：多步骤流程，通过预填写抓取字段来降低用户的输入成本）、完善功能点（如: 为用户的收藏夹提供分类标签的功能，以便于用户管理数量较大的收藏内容）
体验提升度的评估一般由产品、用户调研来估算。
值得注意的是，这里的“提升度”是一个相对差值，因为在开发某项功能之前，用户可能已经找到其他的替代方案了，当你开发了一个新的功能后，一定会带来额外的成本，包括：学习成本（取决于功能在理解层面的复杂程度）、迁移成本（用户从原有的习惯迁移到新的需要额外付出的成本）、机会成本（例如在收集表单时，预填字段大概率能节省用户的时间，但是也有可能会给用户带来额外成本，当预填字段与用户想要输入的内容不符，用户需要手动删除，这就是机会成本）。3. 研发成本
有些需求是可以单纯客户端 / 前端就可以完成的，实现成本一般较低，灵活度低（需要发版），例如：将图片的尺寸放大、缓存记录用户的近期输入数据等；还有一些是需要服务端与前端配合，不需要发版，这种需求相对来说实现成本中等，灵活度适中，例如想要在原生App内嵌套的H5页面进行优化，不需要发版本，相对灵活，但可能需要服务端的配合；还有一些功能开发需要全端配合，服务端甚至要开单独的表来写入读取数据，这种就需求开发成本大，灵活度低。
除此之外，还要考虑到后续的维护成本、运营成本，这些都是衡量一个需求的研发成本的重要指标。
我们可以简单抽象为一个公式，来衡量一个需求的收益：
收益（Return） = 待解决问题影响面 x 解决问题后体验提升度 - 研发成本
二、 对优先级进行排列
有了上面的公式，是不是就代表，我们按照收益得分倒序排列，然后就可以交给开发，依次从上到下实现所有收集到的需求了呢？答案是否定的。
要知道，很多需求，尽管收益得分非常高，但大概率开发成本也是巨大的，甚至需要几个大版本、数十人的开发团队，数月的工作才能实现。如果我们将这类需求放置于开发列表的第一条，那就太不划算了，这就好比，在一场时间有限的考试中，拿到试卷专挑分数最高，但难度也最大的压轴大题开始下手，啃了半天，时间过去了，会做的题目也没有时间作答了，这是很不经济的。
为了解决这个问题，我们创建一个二维图表，横轴代表需要投入的成本，纵轴代表预估收益，我们可以将这个二维图表分成四个部分：

1.Quick wins：属于投入低、收益高的需求，我们应该尽可能地多发掘这类需求，尽可能多开发实现这类需求；2. Major projects：属于投入高、收益也高的需求，这类需求意味着投入开发成本会比较高；3. Fill ins：投入低、收益低的需求，有多余资源就做；4. Thankless tasks：投入高、收益低的需求，对于此类需求，我们应该尽可能避免，因为它们会浪费大量的开发资源，却无法获得良好的收益。
参考阅读：The Action Priority Matrix