第1章 机会评分的业务价值：产品发现阶段的核心痛点、决策意义与方法区别
1.1 适用场景
机会评分不是万能的工具，它在以下具体场景中能发挥最大业务价值。团队若在错误场景使用，反而会拖慢发现节奏。
| 场景类型 | 具体表现 | 典型信号 |
|---|---|---|
| 需求混乱期 | 各角色提出的需求相互冲突，无法判断先做哪个 | “老板说A重要，用户说B急迫，技术说C成本低” |
| 资源竞争期 | 多个机会争抢同一个研发迭代资源 | “每个方向看起来都对，但人力只够做一件” |
| 方向摇摆期 | 团队频繁换方向，缺乏长期坚持的判断依据 | “这个季度做支付，下个季度做社交，再下个季度做工具” |
| 对齐缺失期 | 产品、设计、技术、业务对机会优先级认知不一致 | “评审会上各说各话，无法达成共识” |
1.2 前置条件
在开展机会评分之前，团队必须完成以下基础准备，否则评分结论会失真或不被采纳。
- 已完成初步用户探索：至少完成 5~8 场目标用户访谈或现场观察，产出原始需求素材。
- 已整理机会候选列表：将原始需求归类为 3~10 个清晰的“机会陈述”，每个机会包含用户、场景、痛点。
- 团队已对齐评分目的：所有参与成员理解评分是为了“排优先级”而非“证明谁对谁错”。
- 已选定评分维度：至少确定 3 个核心维度（如用户价值、商业价值、技术可行性），并定义每个维度的打分标准。
💡 经验提示：前置条件中“团队对齐评分目的”最容易被忽略。建议在评分开始前用 15 分钟做一次目的对齐演练，确保所有人对“评分输出将直接决定 Q 版本资源分配”无异议。
1.3 操作步骤：业务价值认知四步法
本步骤帮助团队系统化理解机会评分为什么能解决发现阶段的核心问题，从而建立对这套方法的信任。
- 第一步：痛点映射 —— 让团队每人写出自己在产品发现阶段遇到的最大决策困难，贴在白板上归类。常见痛点包括“需求来源太多无法过滤”“用户说的和做的不一致”“评审会变成辩论赛”。
- 第二步：价值对应 —— 将每个痛点与机会评分的功能对应起来。例如“需求来源太多”对应“评分维度提供统一过滤标准”；“评审会变成辩论赛”对应“评分数据成为客观决策依据”。
- 第三步：差异对比 —— 用表格对比机会评分与团队之前使用的评估方法（如直觉判断、需求评审、商业论证）在目的、时机、数据基础、输出结果上的本质区别。
- 第四步：共识确认 —— 以匿名投票方式确认团队是否认同“机会评分能解决我们当前的核心痛点”，投票结果 ≥80% 同意则进入正式评分环节；低于 80% 需返回第一步深入讨论。
1.4 输入输出物
| 类型 | 名称 | 内容说明 | 来源/去向 |
|---|---|---|---|
| 输入 | 机会候选列表 | 3~10 条机会陈述，每条包含目标用户、使用场景、核心痛点 | 用户探索阶段产出 |
| 输入 | 评分维度定义卡 | 每个维度的名称、权重、1~5 分的行为锚定描述 | 产品负责人预先准备 |
| 输出 | 业务价值对齐画布 | 一张 A3 画布，包含痛点、价值对应、差异对比、共识投票结果 | 进入后续评分环节的基础认知资产 |
| 输出 | 团队共识记录 | 投票结果截图、讨论关键结论、遗留分歧点 | 归档至产品知识库 |
1.5 责任边界
- 产品负责人（PO）：负责准备评分维度定义卡，主持“业务价值认知四步法”讨论，确保流程不被跳过；对评分框架的合理性负最终责任。
- 产品经理（PM）：负责整理机会候选列表，在痛点映射环节记录所有成员反馈，输出业务价值对齐画布。
- 技术代表：在差异对比环节提供“技术可行性”视角，帮助团队理解机会评分与纯技术评估的本质区别。
- 业务/运营代表：在共识确认环节从市场与用户视角验证评分维度的业务相关性。
- 团队全员：在痛点映射和共识确认环节必须真实表达个人观点，不得保留意见或随大流。
📌 责任边界硬规则：产品负责人不得在共识确认环节之前表达个人对某个机会的偏好，避免锚定效应影响团队判断。技术代表如果发现某个机会在技术实现上存在重大风险，应在差异对比环节明确提出，但不得直接否定机会本身。
1.6 记录材料
本章涉及的所有记录材料均需在讨论结束后 24 小时内归档，作为后续章节评分数据的上下文参考。
| 材料名称 | 格式 | 必填字段 | 保管人 |
|---|---|---|---|
| 痛点映射白板照片 | PNG/JPG | 每条痛点附所属人标签 | PM |
| 价值对应表 | Markdown / Notion | 痛点 → 评分功能 → 预期收益 | PM |
| 差异对比表 | 表格（本章 1.7 节样式） | 方法名称、对比维度、结论 | PO |
| 共识投票截图 | PNG/JPG | 投票人数、同意/反对/弃权比例 | PO |
1.7 异常处理
| 异常情形 | 典型表现 | 处理措施 | 升级路径 |
|---|---|---|---|
| 痛点过于分散 | 每人写出 10+ 条痛点，无法聚焦 | 用“同类合并 + 每人 3 票贴纸投票”收敛到 Top 5 | PO 判定是否需要增加一轮用户访谈 |
| 价值对应牵强 | 团队觉得某个评分维度与痛点不匹配 | 现场调整评分维度定义卡，替换或修改该维度的行为锚定 | PO 确认修改后版本，记录变更原因 |
| 共识投票未达 80% | 团队认为机会评分不解决实际问题 | 暂停进入正式评分，由 PO 引导“差异对比”环节的深度讨论，必要时邀请有经验的外部教练参与 | 升级至产品总监，决定是否推迟评分计划 |
| 技术代表缺席 | 技术视角在差异对比环节缺失 | 改为异步收集技术代表的书面意见，或推迟至技术代表可参加的时间 | PO 与研发主管协调时间 |
1.8 验收标准
完成本章内容后，团队需达到以下可测量标准，方可进入第 2 章“评分维度设计与校准”。
- ✅ 痛点收敛：原始痛点列表经合并投票后，最终保留 ≤5 条核心痛点，且每条都有明确的场景描述。
- ✅ 价值对应完整：每条核心痛点至少对应 1 个机会评分功能，并写出具体的预期收益（如“减少评审会时间 30%”）。
- ✅ 差异对比清晰：团队能口头说清机会评分与直觉判断、需求评审、商业论证在“目的、时机、数据基础、输出”四个维度上的区别。
- ✅ 共识达成：匿名投票显示 ≥80% 成员同意“机会评分能解决我们当前的核心痛点”，且无强烈反对意见。
- ✅ 材料归档：所有记录材料在 24 小时内上传至产品知识库，命名规范为“第1章_业务价值对齐_日期”。
⚠️ 常见验收失败原因：团队在“差异对比”环节容易混淆“机会评分”与“需求评审”。请记住核心区别——机会评分发生在需求评审之前，目的是“决定要不要做”，而需求评审发生在方案设计之后，目的是“决定做成什么样”。如果团队无法说清这个区别，请返回 1.3 节第三步重新对比。