3. 业务问题定义与优先级
MVP 的核心不是功能，而是对业务问题的精准切割。本章帮助你从用户访谈获得的大量原始反馈中，提炼出可验证的问题陈述，提出价值假设，并用影响力/可行性矩阵对问题优先级做出结构化决策。
3.1 问题陈述：从症状到根因
用户访谈往往收集到的是“功能欲望”而非“真正问题”。我们需要把用户说的“我想要一个仪表盘”转化为可观测、可度量的业务问题。
问题陈述模板："谁 在 什么场景 下，因为 什么限制，无法达成 什么目标，导致 什么后果（可量化）。"
以在线教育平台为例，访谈收集到的原始需求与转化后的问题陈述对比：
| 原始用户反馈 | 转化后的问题陈述 |
|---|---|
| "我希望有个学习进度提醒" | 学员在每周学习规划场景下，因缺少自动提醒，无法按计划完成课程，导致完课率仅 35% |
| "老师评分太慢了" | 讲师在批改 50+ 份作业时，因手动复制粘贴评语，每份耗时 8 分钟，导致作业反馈延迟超过 48 小时 |
| "我想知道同学学得怎样" | 学员在学习社群场景下，因缺少匿名横向对比数据，无法定位自身水平，导致学习动力不足 |
🔑 关键检查点：问题陈述必须包含可测量的指标（如完课率 35%、每份 8 分钟、延迟 48 小时），否则无法作为后续验证的基础。
3.2 价值假设：我们赌什么是对的
每个问题陈述都隐含一个价值假设——即“如果我们解决这个问题，用户会因此改变行为，业务会获得可量化的价值”。价值假设必须可证伪。
常见价值假设类型：
- 效率假设：新方案能节省用户 X 分钟/次 → 用户愿意改用
- 体验假设：新方案降低认知负荷 Y% → 用户留存提升
- 收入假设：新方案让付费转化率提升 Z% → 业务收入增长
- 行为假设：增加某触发器 → 用户每周登录频次从 1 次变为 3 次
⚠️ 避免模糊假设。"用户会更喜欢"、"体验会更好" 这类表述无法验证。必须写成："如果我们在用户开始学习 24 小时后未完成第一课，则发送一条包含课程亮点和学友数量的推送，预计当日完课率从 35% 提升至 50%。"
3.3 影响力 / 可行性矩阵
当多个问题陈述和价值假设并存时，使用二维矩阵进行优先级排序：
- 影响力（Impact）：解决问题的潜在业务回报（用户数 × 频次 × 价值量）
- 可行性（Feasibility）：团队在当前资源/技术/数据条件下实现该方案的难度
四分位决策规则：
- 高影响 + 高可行 → 立即纳入 MVP（P0）
- 高影响 + 低可行 → 标记为“战略储备”，投入调研降低可行性障碍
- 低影响 + 高可行 → 快速实验验证，若验证失败果断关闭
- 低影响 + 低可行 → 停止投入
3.4 定义验收标准与交付物模板
对于进入 MVP 的问题，需输出以下验收物：
| 交付物 | 内容要求 |
|---|---|
| 问题陈述卡片 | 包含用户角色、场景、痛点、当前指标 |
| 价值假设看板 | 假设描述 + 验证指标 + 成功/失败阈值 |
| 影响/可行矩阵 | 四个象限至少各有一个问题点，标清优先级 |
| MVP 问题清单 | 不超过 3 个 P0 问题，附验收标准 |
📋 实战建议：在第一个 Sprint 开始前，团队必须对齐每个 P0 问题的“成功指标”（如：完课率从 35% 提升至 50%）和“最小可观测时间”（如：上线后 2 周内）。如果 2 周后指标未达预期，该问题应降级或替换。
3.5 本章要点总结
- 问题陈述必须包含角色 + 场景 + 量化后果，避免泛泛的需求描述。
- 价值假设要可证伪，并指定成功/失败阈值。
- 影响力/可行性矩阵是优先级决策的核心工具，MVP 只聚焦高影响+高可行。
- 每个问题必须附带验收标准，用以在 MVP 交付后判断是否真正解决了问题。