第4章：机会评分四大核心维度：从定性洞察到定量决策
在需求评审会上，我们经常陷入“两个需求看起来都很急，先做哪个？”的争论。机会评分模型就是为了终结这种“嗓门决定优先级”的混乱局面。它将用户访谈、业务分析和战略目标统一到一个量化框架中，让PRD的优先级排序有据可依。
4.1 为什么是这四个维度？
任何一个优秀的产品决策，都离不开四个核心问题的拷问：
- 市场规模： 这块蛋糕有多大？值不值得做？
- 用户痛苦度： 用户有多痛？不解决是否会被用户抛弃？
- 技术可行性： 以我们团队现在的技术储备，是否能在预算内交付？
- 战略匹配度： 做了这个功能，对我们的北极星指标或OKR有直接拉动作用吗？
这四个维度构成了机会评分模型的骨架，确保我们在需求评审时既看到了“机会”，也看到了“成本”和“战略一致性”。
4.2 市场规模（Market Size）
核心问题： 如果这个功能上线，能覆盖多少用户？能产生多大的商业价值？
用户场景关联： 在进行用户访谈时，如果发现某个需求在大量目标用户中反复出现，且用户愿意为此付费或改变工作流，这就是一个规模化的信号。
| 评分 | 评估标准 | PRD逻辑表述 |
|---|---|---|
| 5分 | 高增量市场（年增长>30%），覆盖大量潜在用户 | “该需求直接触达亿万级市场，是公司下一阶段增长的关键支点。” |
| 3分 | 存量市场，用户基数稳定 | “该需求能提升现有用户的客单价，属于存量深耕策略。” |
| 1分 | 小众需求，低频使用 | “该需求属于特定场景下的个性化功能，规模化天花板较低。” |
4.3 用户痛苦度（User Pain Level）
核心问题： 用户为了解决这个问题，目前正在付出什么代价？
用户访谈关联： 我们在访谈中需要识别“替代方案”。如果用户说“我现在只能用Excel手动做”，这代表痛苦度极高；如果说“没有这个功能也行，就是有点不方便”，则痛苦度很低。
4.4 技术可行性（Technical Feasibility）
核心问题： 我们的研发团队是否具备实现该需求的能力？是否需要在前期投入大量的基建成本？
需求拆解关联： 在评审前，我们需要将模糊的需求拆解为具体的技术模块（如涉及第三方API对接、算法模型训练、底层架构改造等），再评估可行性。
| 评分 | 评估标准 | 典型PRD备注 |
|---|---|---|
| 5分 | 有成熟组件，开箱即用 | “调用现有基础库，预估2人天。” |
| 3分 | 需要部分改造或适配 | “需要打通两个数据源，预估10人天。” |
| 1分 | 需重大技术攻关或预研 | “当前团队无AI算法储备，建议先做技术POC。” |
4.5 战略匹配度（Strategic Alignment）
核心问题： 这个需求上线后，预计能拉动哪个核心指标增长？
指标验证关联： 如果该需求不能直接关联到留存率、转化率或GMV，或者与当前季度的OKR无关，则战略匹配度较低。这是判断“伪需求”的利器。
- 5分： 直接驱动北极星指标或核心OKR。
- 3分： 辅助提升用户体验，间接影响核心指标。
- 1分： 战术性需求，不支撑战略目标（如“换肤功能”）。
4.6 加权评分模型与决策矩阵
通过设定不同的权重，我们可以根据公司现阶段的战略导向，灵活调整评分模型。例如，初创阶段应侧重用户痛苦度（验证PMF），成熟阶段应侧重战略匹配度（护航核心目标）。
机会总分 = (市场规模 × 20%) + (用户痛苦度 × 30%) + (技术可行性 × 20%) + (战略匹配度 × 30%)
下面这张SVG流程图展示了从用户需求输入到资源分配决策的完整评分链路：
4.7 交付物模板：机会评分卡
在PRD的“需求背景与优先级”章节中，附上这张评分卡，能让评审会直接从“为什么做这个”进入“怎么做”的正确节奏。
| 需求编号 | 用户故事摘要 | 市场规模 (1-5) | 用户痛苦度 (1-5) | 技术可行性 (1-5) | 战略匹配度 (1-5) | 加权总分 | 优先级 |
|---|---|---|---|---|---|---|---|
| REQ-001 | 批量导入历史交易数据 | 4 | 5 | 3 | 5 | 4.3 | P0 |
| REQ-002 | 仪表盘自定义报表 | 5 | 3 | 2 | 4 | 3.5 | P1 |
| REQ-003 | APP深色模式切换 | 2 | 2 | 5 | 1 | 2.3 | P2 |
通过第4章的学习，你已经完全掌握了机会评分的四个核心维度及其在PRD中的应用。接下来的章节，我们将逐一拆解每个评分维度的用户访谈技巧和需求拆解方法，帮助你构建更严谨的产品决策逻辑。