2023年B端产品迭代优先级排序是一个复杂而艰难的抉择

B端产品迭代，优先级排序是一个复杂而艰难的抉择随着产品经理的渐渐成长，“决策力”会渐渐变成一项重要的力量。

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

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

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

由于许多观点和方法我也在探究中，所以也特别盼望能够得到你的反馈和建议。

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形成的数据沉淀进行下一步操作。虽然三个功能都是亟需的，但排期时的优先级也许率是ABC。

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

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

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

05写在最终

许多问题说起来简洁做起来很难，由于许多功能不是独立的，相互牵扯相互影响，有时已经排好的方案在经受外界的某个重大大事影响后，又要重新调整。

有时功能之间的相互制约加上多个客户方的施压，导致交付、研发、产品团队在版本排期上形成“死结”，一个个问题的梳理和解决都需要时间和人力，但这些