对于产品需求池中各个功能的优先级排期本就是一个复杂、繁琐、多变的事情，希望我们能通过一些合理的方法做出相对正确的决策。同时决策力不仅是善于做决策，更要勇于做决策，勇于承担决策所带来的结果。本文作者对产品的优先级排序进行了分析，一起来看一下吧。

随着产品经理的逐渐成长，“决策力”会逐渐变成一项重要的能力。

我们如何在日常工作中多方评估、全面分析，最终做出相对正确的决策，带领产品朝着更有价值、更合理的方向前行，是需要刻意培养和练习的能力之一。

以产品迭代中各个功能的优先级排序为例，无论是在大版本需求池筛选，还是在小问题中多方案抉择，都需要我们具备良好的决策力来推进事件的执行。

最近我也在梳理明年的产品迭代需求池和迭代计划，对于各项需求的优先级排列经常会陷入两难，所以借此总结这个过程中可以辅助我们进行判断的方法，希望能对有幸读到的你带来一些帮助。

因为很多观点和方法我也在探索中，所以也非常希望能够得到你的反馈和建议。

01 需求来源与需求池维护

首先，我认为需求池来源于日常工作的积累，并不是需要时临时刻意想出来的。

• 有些是产品规划中后续需要增加的场景；
• 有些是市场调研、用户使用过程中提出的优化或使用问题；
• 还有在市场竞争和发展中需要随之变化的功能、基于竞争对手带来的新功能；
• 也有很多曾经在研发过程中因为时间、团队构成、业务不熟悉等原因导致的遗留问题；
• 包括很多MVP的功能模块需要再向外完善；
• 可能还会有一些领导突发奇想或者未来想要布局的功能等等。

需求池无论采用哪种表现形式，一定要随时记录，定期整理，否则真正到准备中长期计划时，我们会遗忘、会遗漏很多关键内容。

而且我建议采用可协同的形式进行需求池维护，能够动态拖拽就更好了，这样可以很方便的让我们进行优先级调整和功能分类

在此，我推荐共享文档中的思维导图、板栗看板两个工具供大家选择：

02 需求池内容分类拆解

其次，我们可以将需求池中上述提到的内容换一个角度，大体区分为以下几类：

1. 交付过程缺失的标准化功能

基于项目交付制的产品研发，更大的意义在于标准化功能的快速开发和快速复制，产品成熟度越高，交付效率越高。所以从愿景来看，研发版本应该至少超出交付版本两个以上的版本号。

但在实际工作中，尤其是产品孵化初期、或者产品迅速成长期，研发版本经常会落后于交付版本。而且因为交付在面对大量定制化客户时，还会有很多新需求，这些新需求可以作为产品标准化功能的模块，最好由研发团队统一设计开发，以便后续的版本把控。

即便由于多种原因最终由交付团队在定制化版本中完成了新功能的开发，也需要研发团队将此功能合并到研发版本并进行合理的标准化适配。

因此需求池中就会存在很多客户迫切需要的功能，交付团队在等着研发发布新版本，在这期间交付团队会经常受到客户方的压力，从而将压力转嫁到产品和研发团队中。

2. 售前客户可预见的功能

产品在市场推广阶段，会经常收到客户的新思路或新要求，当客户方发布了一个相关产品新功能的交流公告，研发团队要不要配合市场进行响应？在招投标之前客户想要看一下系统的成熟度，或者进行标准化版本的预测试，研发团队、产品团队是否需要积极配合？

一个客户提了A诉求，又一个客户提了A诉求，A场景不断在市场上被提起，这时作为产品团队是否要积极寻求更优质的解决方案？

同时一旦这个项目有幸中标，且客户新增的功能恰好属于产品后续可迭代的标准化功能，情况又会转变成第一种—>交付过程缺失的标准化功能。

而这里面会存在一个比较矛盾的现象，因为售前客户的新需求可能是非常多的，我们是否需要逐个响应？是否有能力逐个响应？

所以这些情况所产生的需求池也需要我们从产品角度快速甄别筛选，对于需要响应的功能尽快设计方案并排期执行。

3. 合作方催办的功能

现在我们的很多产品都不是独立的应用，需要和很多第三方系统集成、合作，其中不乏一些多方合作的模块，合作方经常催促我们尽快进行优化升级。当然也会遇到我们急需合作方配合改造升级的功能，这种情况下我们会更加被动。

无论哪种情况，涉及到第三方合作的功能，尤其是基于双方签订了合作协议，有利益连接关系的合作场景，对于合作方催办的功能我们其实也很难把优先级往后排。

也许这个功能对于产品来说不是核心功能，但是受限于企业形象，或者领导层面、老板层面的舆情，也要尽力积极响应，并巧妙推进甚至“拖延”。

4. 产品使用过程中的阻力功能

这里所指的并不是MVP版本，或核心流程的阻断，因为这类阻断正常来讲都已经被及时解决了。更多的是因为存在某个功能的缺失，从而影响更大面积的产品推广或用户增值服务。

即现在能用，但是如果做了这个新功能，会对产品力创造较大的突破。

比如某个用户使用频次较高的功能产品只做了pc端，如果能够推出移动端对应功能，则能够快速提升移动端的访问量，同时吸引很多对移动应用场景有实际诉求的用户。

但这里也有一个经常在取舍时的矛盾点：虽然此功能有些缺失，此功能很重要，上线后能够带来一定效果，但0.5毕竟不是0，当有很多0功能需要你们优先解决时，0.5-1的升级优先级会竞争过0-1的升级吗？

至于哪个功能更重要，不同的业务模式和商业模式一定会有较大差异，在此我们不去评定到底哪个优先级更高，仅是为了说明其中的抉择关系。

5. 重要但不紧急的功能

比如为了后续的场景拓展，为了产品在用户价值或商业价值上能够更上一个台阶。

或者某个应用的功能架构升级，或者平台级或组件级的技术架构升级，为了能够更好的适应后续产品的发展。

这些都属于重要，但是不紧急的待办事项。一般这类功能都需要较大的工作量，而且很难拆分成多个升级版本，日拱一卒的慢慢推进。否则既然功能很重要，一定会适当的加塞一点点做起来。

所以这类功能，往往在最终决策时，就把优先级往后放了。同时结合下一条，这些重要但不紧急的功能什么时候能够开始动工，非常考验一个团队的“忍耐力”和“调配力”。

但是，一味地对重要但不紧急的任务延后，不仅会让产品迭代始终被紧急的事情牵着鼻子走，而且大概率会拖到“重要但不紧急的事情”变成“重要且紧急的事情”，从而不停的“恶性循环”。

仿佛产品迭代就像“救火队员”一样，哪里着急补哪里，哪里更着急先救哪里。犹如一列行驶的火车面对交叉路口，左边撞1头牛，右边撞2只狗一样，形成“饮鸩止渴”的负面结果，从而失去了产品本身的节奏。

甚至于到最后发现最紧急的事也做不过来了，团队一直处于持续高强度工作状态，可问题似乎越来越多。

上半年读的一本《时间管理大师》的书，其中所表达的最核心观点，在我看来就是“把重要但不紧急的事情优先级调高”，从而经过自己一段时间的坚持和努力下，扭转当下的“灭火困境”。

但说起来容易，做起来难呀！

但做起来再难，也不能不做呀！

6. 工作量这么大，做了它就做不了其他的功能

紧接着上一条，无论是重要但不紧急的大版本升级，或者因为其他因素产生的大工作量迭代，在一个迭代周期里，一旦我们接下了这个功能，意味着我们直接排除了其他功能。

在这种情况下，很多团队也会把这个功能优先级滞后，将这个大工作量功能置换成多个小工作量功能，从心理上，从实际接受程度上似乎更容易被认可。毕竟新版本发布的时候，它显得多呀~

可是这个大工作量的功能，什么时候才能开始呢？

或者我们可以延长版本迭代周期，将团队分成多个小组，每个小组负责一项关键任务，即便走得慢，也要多条腿走路。这种模式在一定条件下是可行的，但不知道有多少个团队能够接受迭代周期翻倍的版本发布呢？

7. 体验优化的功能

我是体验优化的外行，相对简单的将体验优化拆分为：UI优化、交互优化两类。

体验优化是我今年年初就想重点提升的能力，也希望能在工作中进行对应的尝试，可惜临近年底，我并没有向前迈出几步。

包括现阶段的市场环境，对于90%的B端产品而言，功能的优先级99%大于体验的优先级。

这也是现阶段B端产品体验升级的困境。在之前的日更内容中我也粗略的写过一些。

当然对于这类体验优化的功能，什么时候能够提高优先级呢？大概率是此类问题融入到交付过程、客户反馈、合同额、老板的命令等方面时，因为这些更重要的价值而附带出来体验升级的落地。

话说这些更重要的价值附带到任何功能之上，几乎都是可以把优先级置顶的吧~

也许按照这种筛选标准和实际情况，那句“先这样做，后面再优化吧”岂不成了“伪命题”？

因为优化类的需求，一定会被你排到最后呢~

03 初步排列

相信每个团队针对各自的实际情况都会有不同的排序方式，我第一版的排列顺序是1、4、2、3、6、5、7。而且每一个大类都会涉及到很多小功能，有些小功能又属于“复杂综合型”，所以真正的排序过程比这里的描述存在更多的变化。

但是思考一番之后，又调整成了1、5、4、6、2、3、7，也许明天又变了，或者向领导汇报之后，优先级还会调整，但每次排序，都会有自己的理由和权衡在其中。

还有很多功能，可能即便在需求池里很久了，你也不会评估它的优先级，可能当时就是突发奇想做了个记录罢了，可能未来几年都不会做这个功能。

而且我们客观的知道，随着产品的不断发展，会有越来越多的高优先级任务落到池子里，所以当需求池达到一定数量时，该删的删，该合并的合并，“断舍离”也是我们排期过程中的一个哲学问题。

04 再度排除

随着我们一系列的分析，可能初步汇集出很多优先级高的内容，那下一个版本我们做哪些呢？哪些是可以放到下下个版本再去考虑的呢？

虽然需要在高优先级中寻找更高，但很有可能我们发现这些功能似乎都挺重要的，一时不知道怎么评判。这时可以采用“排除法”。

以下几个问题帮你排除错误选项：

• 不做这个功能会引起什么问题？这个问题现在能否承受——两者权衡取其重
• 这个功能的deadline是什么时候，能否再延长？——你不试试，怎么知道对方的底线呢~
• 其他团队的伙伴能否帮忙分担——该刷脸就刷脸，请些“外援”来协助
• 这个需求有简化的可能性吗？——传说中的MVP中P
• 各个功能之间是否存在关联度和先后顺序

前面几个很好理解，重点解释一下最后一个。

比如现在有ABC三个功能都很重要，但是A是规则类配置，B是应用A配置后的规则进行场景应用，C是通过B形成的数据沉淀进行下一步操作。虽然三个功能都是亟需的，但排期时的优先级大概率是A>B>C。

当然，小部分概率也会遇到，有些特殊场景下，客户或交付团队对于B更迫切，A的规则设置比较简单，但B能够为其带来显著的市场价值，则研发团队直接进行B功能的开发，但前提是快速分析A功能，并手动初始化一些常见规则供B进行使用。

最后，如果我们筛选的下一版本范围，研发团队评估后仍然无法按期交付，那就是要么大家卷起来，要么叫上领导再砍一刀。

当然也可能随着研发团队的人员补充、熟练度提高、管理规范越来越成熟，有些版本还是可以超额完成。同时我们也需要积极跟进研发进度，在每个版本过程中随时关注里程碑节点，根据实际情况再进行适度的增减需求。

05 写在最后

很多问题说起来简单做起来很难，因为很多功能不是独立的，相互牵扯相互影响，有时已经排好的计划在经受外界的某个重大事件影响后，又要重新调整。

有时功能之间的相互制约加上多个客户方的施压，导致交付、研发、产品团队在版本排期上形成“死结”，一个个问题的梳理和解决都需要时间和人力，但这些难题在产品孵化过程，以及产品裂变过程中势必会逐一遇到（今年上半年我就遇到了类似的情况，最终通过4个团队合力，2个多月的奋战最终渡过难关）。

扛过去，也许会拨云见日；扛过去，也许会有更大的山在等着你。

优先级排期本就是一个复杂、繁琐、多变的事情，当我们考虑问题更全面，思维角度和格局能更高一点时，做出的决策大概率不会很差。

决策力不仅是善于做决策，更要勇于做决策，勇于承担决策所带来的结果。

随着过程的积累，刻意的练习与复盘，相信我们都能做出越来越多相对正确的决策。