第1章 B端需求优先级排序概述
1.1 适用场景
B端需求优先级排序并非所有团队所有阶段都适用，它主要解决资源约束下的决策冲突。典型适用场景包括：
- 多项目并行、研发产能严重不足——只能从10个候选需求中选择3个进入迭代。
- 业务方与产研团队对“做什么”存在反复争议——缺少统一客观的评判标准。
- 客户成功反馈的需求重复且矛盾——需要按客户价值收敛。
- 季度/半年度产品路标制定——需要结构化方法评估长期投入与短期收益。
- 管理层要求“数据驱动而非感觉驱动”的决策——必须用可量化的指标来排序。
提示：如果团队规模极小（如3人以下）或需求总数极少（每周新增<5条），建议直接采用“讨论+共识”的轻量方法，不必全流程套用本课程。本课程适合需求池达到50条以上、涉及3个以上跨部门利益方的中大型B端产品团队。
1.2 核心目标
优先级排序的终极目标不是“排出顺序”，而是在有限资源下做对业务影响最大的决策。具体分解为三个子目标：
- 最大化客户价值——确保最痛点、最广泛的需求先被满足。
- 提升投入产出比——用最小的研发成本撬动最大的商业或用户价值。
- 减少决策偏差——用结构化流程替代“谁嗓门大谁优先”或“最急但不重要”的短视选择。
1.3 前置条件
在执行正式排序之前，必须具备以下条件，否则排序过程会陷入无休止的争论：
| 前置条件 | 详细说明 |
|---|---|
| 统一的需求描述模板 | 每条需求至少包含客户场景、用户故事（As a… I want… So that…）、预期收益、初步工作量估算。 |
| 明确的产品/业务目标 | 当前周期（季度/半年度）最关心的1～3个北极星指标，例如：续费率、新签客户数、客服工单减少率。 |
| 相对稳定的评分标准 | 至少定义2～3个评分维度（如影响范围、频次、紧急度、成本），并对每个维度给出0～5分的定义。 |
| 排序决策会议室与授权 | 决策者（产品负责人/VP）应在场，否则排出的结果可能被事后推翻。 |
1.4 操作步骤（概述级）
本课程将在后续章节逐一拆解每个步骤的详细SOP，此处先给出完整流程的概览：
- 收集与清洗需求——从多渠道汇总需求，去重、补全信息。
- 维度打分——按既定维度对每条需求独立评分。
- 权重计算与排序——加权求和得出初始排序。
- 利益方复核——业务方与技术方确认是否有隐形成本或政治因素。
- 发布排序结果——将优先级列表同步给所有干系人，作为迭代规划的依据。
关键提醒：排序不是一次性的活动，而是每轮迭代之前的固定环节。建议每2周或每迭代重新执行一次轻量排序。
1.5 输入输出物
| 类别 | 具体内容 |
|---|---|
| 输入物 | 需求池（每条需求带基础字段）、产品北极星目标、年度/季度路标、研发资源容量（人天/迭代） |
| 输出物 | 排序后的优先级列表（含评分明细）、排序说明文档（解释Top 5的决策理由）、待丢弃/搁置的需求清单 |
1.6 责任角色划分
明确的责任边界可以防止各部门互相推诿或越权决策。下表定义了三种核心角色及其职责范围：
| 角色 | 职责范围 | 非责范围 |
|---|---|---|
| 产品经理（PM） | 维护需求池、组织打分会议、输出排序初稿、推动干系人确认 | 直接否决业务方需求、单方面改变权重 |
| 技术负责人（Tech Lead） | 提供工作量估算、识别技术风险（依赖、架构改造）、评估可维护性 | 决定业务价值分值、决定需求是否上线 |
| 业务方/客户成功 | 提供客户使用场景、反馈紧急程度、确认业务收益数据 | 要求跳过排序直接开发、否决技术评估 |
| 决策者（产品总监/VP） | 最终拍板排序结果、对异常争议做仲裁、审批资源调配 | 事无巨细参与每条需求打分 |
1.7 异常处理
优先级排序流程中常见的异常情况及应对策略：
- 所有需求都是P0（紧急）——要求业务方强制按“如果不做，客户一定会流失”的维度重新评分，区分“必须做”和“最好做”。
- 需求信息严重缺失——退回需求发起人补充完整，评分时在该维度标记为0分，并在备注说明。
- 部门间打分差异巨大（如技术评2分、业务评5分）——组织面对面讨论，列出双方未共享的信息，校准认知后再评分。
- 排序结果与战略目标冲突——以战略目标为最高权重，人工调整与战略无关但得分高的需求，并记录调整原因。
1.8 验收标准
一次成功的优先级排序，应当满足以下全部标准：
- 所有参与方对排序结果没有重大异议，或异议有正式的裁决记录。
- 排序列表可直接用于下一迭代规划，无需再次返工打分。
- 评分维度与权重的选择有书面说明，便于后续复盘优化。
- 输出物中包含至少3条“弃置/搁置”的需求及决策理由。