1. 开篇案例
1.1 适用场景
本流程SOP适用于以下产品决策情境：
- 新产品立项/早期评估：在资源投入之前筛选数十个甚至上百个产品机会。
- 多项目优先级排序：公司同时有多个产品提案需要竞争开发资源。
- 团队共识对齐：决策团队之间存在较大意见分歧，需要基于同一框架进行理性讨论。
- 年度/季度产品规划：将产品战略与市场机会匹配，避免“老板拍脑袋”式决策。
1.2 前置条件
- 已经完成产品机会的初步收集和描述（至少包含产品名称、目标用户、核心价值主张）。
- 至少拥有3位以上具备行业经验的决策者（产品经理、技术负责人、业务负责人等）。
- 准备一份企业内部可用的市场数据/用户反馈记录（如竞品数据、用户访谈纪要）。
- 团队提前阅读并理解评分模型的基本维度定义（不要求理解算法细节）。
1.3 操作步骤
- 案例导入：由讲师分别展示“硬件净水器”和“SaaS B2B销售工具”的原始产品提案。
- 主观决策模拟：让团队按照传统方式（讨论、投票）对两个机会做决定。
- 揭示失败根源：复盘硬件案例为何失败（市场饱和、迭代周期长、供应链不匹配）。
- 演示评分模型应用：对SaaS案例使用《产品机会评分模型》的五个维度分别打分。
- 对比结果差异：展示评分模型如何发现被主观忽视的“客户验证信号”和“团队能力匹配”。
1.4 输入输出物
| 类别 | 输入物名称 | 输出物名称 |
|---|---|---|
| 初始信息 | 产品机会描述文档（包含用户画像、市场推测） | 评分对照表（主观决策结果 vs 模型评分结果） |
| 决策数据 | 团队投票记录、讨论纪要 | 各维度评分明细表（市场、技术、资源、时机、风险） |
| 验证材料 | 竞品分析报告、用户访谈记录 | 评分模型校验结果（一致性分析） |
1.5 责任边界
| 角色 | 职责 | 不负责 |
|---|---|---|
| 产品经理 | 提供真实案例背景，准备初始数据 | 主观替代评分模型，直接决定项目去留 |
| 技术总监 | 评估技术可行性维度（SaaS vs 硬件） | 仅凭技术判断就否定市场机会 |
| 业务负责人 | 提供市场体量和销售通路数据 | 忽视用户实际验证信号 |
| 课程讲师 | 控制讨论边界，引导模型标准化打分 | 代替团队做最终决策 |
1.6 记录材料
- 案例对比记录表：包含硬件与SaaS两个机会的原始描述、团队成员第一轮打分、评分模型终得分。
- 主观决策误区清单：列出本次练习中出现的常见偏见（如锚定效应、确认偏差、群体思维）。
- 评分模型原始分数表：每一个维度的独立打分，用于后续异常分析。
讲师提示：记录材料是后续章节（第2-5章）的原始数据来源，请确保表格完整、可回溯。建议使用在线协作文档实时记录。
1.7 异常处理
| 异常现象 | 可能原因 | 处理方案 |
|---|---|---|
| 团队成员对案例数据产生争议 | 案例背景信息不足或理解偏差 | 暂停评分，由讲师补充关键用户验证数据，每人重读后继续 |
| 主观投票结果与模型评分完全相反 | 评分模型维度权重设置不合理或团队陷入极端偏见 | 重新检查各维度得分，并引入外部专家做盲审 |
| 讨论时间超出限定（30min） | 过度纠结于案例细节而非评分框架 | 讲师强制进入下一环节，用剩余时间做快速对照组 |
1.8 验收标准
- 每位参与者都能清晰说出硬件案例失败的两个核心原因。
- 每位参与者都能指出SaaS案例在“用户验证信号”维度的高分原因。
- 团队至少总结出3条评分模型比主观决策更可靠的理由。
- 完成一份“机会评分案例摘要”，包含原始数据、打分过程和复盘结论。
质量门禁：如果团队无法达成至少3条模型超越主观的共识，视为本章验收未通过，需重新复盘案例数据或补充用户访谈记录。
1.9 本章知识结构图
以下SVG展示了两个案例的决策路径对比，以及评分模型如何修正主观偏见：
核心发现：在传统主观决策中，硬件净水器因为“市场大”和“CEO喜欢”获得了资源倾斜；而评分模型揭示了“供应链不可控”和“用户不需要”两个致命扣分点，从而避免了失败。SaaS案例虽然在传统讨论中并不突出，但评分模型发现了“已有付费意向用户”这一强信号，让团队重新分配资源。