第2章 适用场景与前置条件
适用场景
机会评分并非万金油，只有在特定的产品场景下才能发挥最大效用。以下五类场景是机会评分的高价值域：
| 场景编号 | 典型情境 | 核心判别词 |
|---|---|---|
| S1 | 产品从0到1探索期，需在大量机会中锁定首轮验证方向 | 蓝海、不确定性高、资源极度有限 |
| S2 | 平台型产品进入成熟期，需从用户侧挖掘增量功能或服务 | 存量优化、北极星指标、长期留存 |
| S3 | 多产品线并行，需要跨团队统一机会优先级排序 | 横向拉齐、研发瓶颈、季度规划 |
| S4 | 数据基础设施弱或刚刚建立，需要结构化评估降低决策风险 | 数据孤岛、经验主义、试错成本 |
| S5 | 企业内部孵化创新项目，需快速筛选可投入的试点方向 | 创新沙盒、内部创业、VOC |
实战建议：如果团队当前处于“每天被大量想法淹没、但没人能说清哪个最该做”的状态，请优先将机会评分引入日常发现流程。
前置条件
团队成熟度要求
- 至少具备产品发现基本习惯：已建立用户研究、问题访谈、数据分析等能力的团队，上手最快；纯“接收需求-开发-上线”型团队需先接受1~2轮引导。
- 决策者参与意愿：产品经理、技术负责人、业务方主要负责人必须承认“机会评分可作为优先级决策的一个输入”，避免评分结果被直接跳过。
- 跨角色协作经验：评分需要产品、设计、数据、技术至少3个角色共同完成，单角色主导的评分往往偏离实际。
避坑提醒：当团队内部对“什么是好机会”存在根本性的定义冲突时，先做一次价值对齐工作坊，再引入评分体系，否则评分维度的选择会沦为权力博弈工具。
数据基础
| 数据类型 | 最低要求 | 理想状态 |
|---|---|---|
| 用户行为数据 | 可获取最近3个月的核心漏斗转化率 | 全链路事件埋点 + 用户分群 |
| 问题反馈数据 | 过去1年内的用户访谈记录或NPS原始文本 | 结构化问题库 + 情绪标签 |
| 市场/竞争数据 | 能查到的公开市场规模报告 | 内部竞品跟踪面板 + 分析师二次加工 |
| 成本/资源数据 | 按人天估算的开发、运营成本 | 财务模型 + 历史项目成本校准 |
关键原则：数据不必完美，但必须可引用。评分过程中的“数据置信度”本身就是评分权重的一部分，不依赖“完美数据”是落地的前提。
参与角色
- 产品经理：发起评分活动、定义评分维度、主持讨论。
- 数据分析师（或数据工程师）：提供客观数据支撑，修正认知偏差。
- 技术负责人（TL/架构师）：评估技术可行性与实现成本。
- 用户研究员（或一线客服/运营）：提供用户侧感知与情景还原。
- 业务决策者（可选）：在战略优先级矛盾时提供最终方向性意见。
操作步骤：判断是否适用机会评分的快速检查
在正式启动机会评分前，按以下三步完成前置条件审查：
- 场景匹配：将当前工作阶段与上述S1~S5场景比对，至少匹配一项即可进入下一步；若完全不匹配，考虑放弃评分，改用其他方法（如MVP直接验证）。
- 资源与数据自检：对照表格确认可获取的最低数据要求是否满足；若不满足，标记为“低数据置信度”，并策略性降低该维度的权重。
- 角色召集：确认上述5个角色中至少3个到位，且产品经理担任评分主持人。
小技巧：将检查结果记录在《机会评分前置条件清单》中，作为后续评分报告的附件。若检查不通过，应安排2~5天的数据补齐冲刺或角色沟通。
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 场景判断 | 当前产品路线图、近期用户研究简报 | 场景匹配结论（S1~S5/不适用） |
| 数据基础 | 数据仓库访问权限、历史留存报告 | 数据置信度标签（高/中/低） |
| 团队资源 | 团队成员工位表、项目排期表 | 角色到位确认书（邮件/IM记录） |
责任边界
- 产品经理：确保前置条件检查过程不被跳过，对“误用机会评分”的场景负主要解释责任。
- 数据分析师：诚实标注数据缺失或置信度不足，不得为迎合评分而粉饰数据。
- 技术负责人：拒绝在角色未齐备情况下的强行评分请求，保护团队精力。
记录材料
建议使用以下模板在共用Wiki或协作文档中建立章节页：
# 机会评分前置条件检查表
- 项目名称：__________
- 检查日期：__________
- 场景匹配（S1~S5）：[ ] 匹配 匹配编号____ [ ] 不匹配
- 数据基础：用户行为[ ]有[ ]无 ｜ 问题反馈[ ]有[ ]无 ｜ 市场数据[ ]有[ ]无
- 角色到位：PM[ ] DA[ ] TL[ ] UR[ ] BD[ ] (≥3个✓通过)
- 结论： [ ] 合格，可启动机会评分
[ ] 暂缓，需补齐________异常处理
| 异常情况 | 处理方案 |
|---|---|
| 场景完全不匹配 | 停止启动机会评分，改为竞品分析或快速原型验证 |
| 数据基础严重缺失（无任何行为数据） | 先执行2周最小化用户访谈，收集定性证据后再评估是否启动简化版评分 |
| 关键角色无法参与（如技术负责人长期缺席） | 由产品经理代行技术判断，但必须在评分表中明确标注“技术评估为代理估算” |
| 团队内对“是否应该做机会评分”产生分歧 | 召集20分钟决策对齐会，由业务决策者裁定，若仍无法达成共识则推迟1周，使用候补方法 |
验收标准
满足以下全部条件时，前置条件检查视为“通过”，可以进入第3章（评分维度设计）：
- 明确匹配S1~S5中至少一个场景，且输出文档中记录了匹配编号及理由。
- 数据基础自检表至少有两类数据被标记为“有”，且不存在“三类都无”的情况。
- 参与角色到位≥3个，且产品经理已在记录材料中签字（或留名）。
- 异常处理表为空，或已对每个异常项指定明确的处理方案与责任人。
本章小结：前置条件是机会评分落地的“安全阀”。跳过本章检查直接进入评分，极易导致评分结果与团队真实能力脱节、后续执行乏力。请将本章内容作为内部启动前的固定环节，形成组织记忆。