产品经理 · 需求分析 - 深度专业内容
产品经理的日常工作中最容易被低估的一件事是「说『不』的能力」——当一个需求池中有30条待处理需求但你只有5人周的开发资源时，哪些做哪些不做哪些以后再说——这个排序决策的质量直接决定了你产品的迭代效率和用户价值的增长斜率。凭直觉排序的风险在于「谁声音大谁的需求先做」——老板在群里提了一个想法你不敢推、销售说客户抱怨了某个功能你不敢拒、运营给你列了10条PPT里写得特别漂亮的「紧急需求」。如果没有一个结构化的优先级排序框架，你的产品路线图很快就会从「用户价值驱动」变成「组织政治驱动」。
KANO模型将需求分为五类：基本型需求（做了用户不会更满意但不做用户会极度不满——如电商App的支付功能不能崩）、期望型需求（做得越好用户越满意——如搜索速度越快越好）、兴奋型需求（做了用户会惊喜但没做用户也不会抱怨——如一个巧妙的微小互动动效）、无差异需求（做不做用户的态度没有变化）和反向需求（做了反而降低满意度——如下线了某个用户喜欢的旧功能）。KANO模型的适用场景是「新产品或新功能的早期规划阶段」——你还没有足够的数据来量化每个需求的价值，但你急需一个「定性框架」来判断哪些需求是「做了是应该的（基本型）所以优先级中不必排最高」，哪些是「不做会死（也是基本型）所以必须排第一」。KANO的局限是无法量化——它告诉你需求属于哪一类但不告诉你「这个期望型需求值多少用户增长」。
RICE = Reach（覆盖多少用户）× Impact（对用户的核心行为有多大影响）× Confidence（你的判断有多大把握）÷ Effort（需要多少人周开发资源）。RICE的得分是一个具体的数字——你可以对所有需求「按分数排队」直接得到优先级顺序。RICE的适用场景是「进入成长期且已有用户数据积累的产品」——你的Reach和Impact不再需要全靠猜测，可以从数据看板和A/B测试结果中获取。RICE的局限是「Confidence的赋值非常主观」——如果两个需求在Reach和Impact上不相上下，Confidence的一个0.5和0.8的差异就能完全翻转排序结果——而Confidence恰恰是四个参数中最容易被个人偏见和「政治因素」歪曲的。
MoSCoW = Must have（必须在这个版本完成否则延期）、Should have（应该做但如果确实来不及可以移到下个版本）、Could have（锦上添花做不做主要看资源剩余）、Won't have（这个版本明确不做）。MoSCoW的适用场景是「发布日期已经确定（大促和App Store推荐位和老板在全员大会上公开承诺了）」的强deadline项目。这种情况下你不需要「哪个需求ROI最高」的判断，你需要的是「哪些是底线」的绝对判断。MoSCoW的局限是过于「二元化」——Must和Should之间的边界在很多团队中是模糊的，需要产品经理具备强大的「敢于划清边界」的沟通能力。
这三套框架不是互斥的，它们可以在同一个需求管理流程中组合使用。推荐的三步流程：第一步（KANO筛选）——把所有需求按KANO模型分类，剔除掉无差异和反向需求，确保资源不会花在「做了等于没做」的事情上。第二步（RICE排序）——把KANO筛过的需求用RICE量化排序，得到一个「数据驱动的优先级序列」。第三步（MoSCoW定版）——在版本规划时把RICE排名最高的需求按MoSCoW做最后的版本取舍（因为RICE排名靠前但可能有依赖关系或技术风险导致本版本做不了）。
优先级排序框架的价值不在于「让排名变得客观」——完全客观的排名在真实的产品工作中是不存在的，因为有太多不确定性——而在于「让排名的讨论过程结构化」。「KANO说这个是基本型我们不做会死」——这比「我感觉这个很重要」更有说服力。「RICE评分显示这个需求的投入产出比只有0.3远低于平均值的2.5」——这比「我觉得这事儿不太靠谱」更难以被反驳。框架是你的沟通工具，不是你的决策替代品。
更多深度内容，请关注微信公众号：
abc6789122
每日更新，不错过任何精彩内容