需求优先级评估

需求排期的两大坑

团队常见的失败模式有两个：一是凭感觉给功能排序，评审会上谁嗓门大谁的需求先做；二是把所有需求都标成"紧急"，结果真正解决用户痛点的功能被无限期搁置。这两种方式的共同问题是没有把判断标准显式化——每个人心里有一把尺，最后只能靠拍脑袋或政治博弈达成一致。

框架驱动的评估流程

这个技能的核心是引入一套可复用的评估框架，而不是直接给你一个"正确答案"：

• Opportunity Score：Importance × (1 − Satisfaction)，归一化到 0–1。它把"先选问题、再想方案"这个原则量化：高重要性、低满意度的领域才是机会区。
• ICE：Impact × Confidence × Ease，适合需要快速打分、快速收敛的场景。
• RICE：在 ICE 基础上拆出 Reach 维度，适合需要按用户规模加权的大团队。

执行时它会先确认你的产品目标与成功指标（比如"把首周留存从 35% 提升到 50%"），再逐项评估每个候选功能在 Impact、Effort、Risk、战略匹配度 四个维度上的表现，最后给出 Top 5 排序，并附上每条选择的理由、关键权衡、以及被降级项的原因。如果输入材料足够，结果会整理成一张优先级表格，方便直接拿到评审会上用。

使用边界

几个需要注意的点：

• Opportunity Score 依赖用户调研数据，没有数据时只能做定性判断，不要硬凑数值；
• 该技能是决策辅助，不会自动执行外部写入、部署、付款等操作，涉及这类动作时会先向你确认；
• 排名结果受输入质量影响很大，输入的目标和候选清单越具体，输出越可靠。