第3章 业务问题定位与描述
PRD 的价值起点不是「我们要做什么功能」，而是「我们为什么要解决这个问题」。业务问题定位不准，后续所有需求拆解、方案设计、验收标准都会偏离真实用户场景。本章提供可套用的问题陈述模板、影响范围分析框架和价值假设验证方法，帮助你在动笔写 PRD 之前先把「问题」定义清楚。
3.1 问题陈述模板
问题陈述是 PRD 的「北极星」——它用一句话说清楚当前业务在什么场景下、遇到了什么阻碍、造成了什么损失。一个合格的问题陈述必须包含以下四个要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 用户 / 角色 | 明确问题的主体是谁（谁遇到了麻烦） | 跨境电商平台的中小卖家 |
| 场景 / 触发条件 | 在什么操作或时间节点下出现问题 | 在海外仓备货时，因库存数据延迟导致超卖 |
| 阻碍 / 痛点 | 具体无法完成的目标或体验障碍 | 无法实时查看 FBA 仓实际可用库存，只能依赖 T+1 报表 |
| 影响 / 损失 | 问题持续存在带来的可量化后果 | 每月平均因超卖产生 12% 的取消订单，损失约 ¥8 万 / 月 |
问题陈述标准句式：
「[用户/角色] 在 [场景/触发条件] 时，因为 [阻碍/痛点]，导致 [影响/损失]。」
「[用户/角色] 在 [场景/触发条件] 时，因为 [阻碍/痛点]，导致 [影响/损失]。」
使用这个句式重写上面的示例：
「跨境电商平台的中小卖家在海外仓备货时，因无法实时查看 FBA 仓实际可用库存（依赖 T+1 报表），导致每月平均产生 12% 的超卖取消订单，损失约 ¥8 万 / 月。」
实操检查点：写完问题陈述后，问自己 3 个问题——① 这句话去掉后 PRD 还能看懂吗？② 读者能立刻判断「该不该做」吗？③ 损失数据是否来自真实业务统计而非估算？
3.2 影响范围分析
影响范围分析回答「这个问题波及多少人、多少流程、多少系统」。它帮你判断问题的优先级，也决定了 PRD 的边界。从以下四个维度展开分析：
| 维度 | 分析内容 | 评估方式 |
|---|---|---|
| 用户规模 | 受影响的用户角色及预估数量 | 从后台拉取活跃用户数 + 客服投诉量交叉验证 |
| 业务流程 | 从触发到结束涉及哪些业务环节 | 绘制当前泳道图，标注信息断点和人工补偿操作 |
| 系统模块 | 需要改动或新增的后端 / 前端模块 | 与技术架构师评审调用链路和数据依赖 |
| 商业指标 | 问题对收入、成本、转化率等核心指标的影响 | 取 2-4 周历史数据计算波动幅度和趋势 |
常见避坑：不要只写「影响范围很大」。必须给出具体数字（用户量 / 订单量 / 金额）和对应数据来源。没有数据支撑的影响范围分析，在评审会上会被轻易挑战。
3.3 价值假设验证
价值假设验证是业务问题定位的「试金石」——在投入研发资源之前，用最小成本证明「解决了这个问题确实能带来预期的业务价值」。验证方法分为三步：
- 提出假设：用「如果……那么……」句式写出价值关联。
示例：如果卖家能实时查看 FBA 仓库存，那么超卖取消订单率将从 12% 降至 3% 以内。 - 设计验证实验：选择 MVP 或数据回溯方式。
示例：用过去 3 个月的历史数据做回测，模拟「实时库存」场景下超卖订单的挽救率。 - 设定通过标准：明确什么数据结果代表假设成立。
示例：回测显示模拟实时库存可挽回 ≥70% 的超卖订单，则假设通过。
为什么要在 PRD 阶段做价值假设验证？
因为一旦进入开发，沟通成本、技术债务、上线风险都会指数级上升。在「问题定位」阶段用 1–2 天验证假设，可以避免投入数周做出一个「正确解决了错误问题」的功能。
因为一旦进入开发，沟通成本、技术债务、上线风险都会指数级上升。在「问题定位」阶段用 1–2 天验证假设，可以避免投入数周做出一个「正确解决了错误问题」的功能。
将上述三个环节串联起来，就构成了业务问题定位的完整闭环——从定义问题到评估影响再到验证价值，每一步都为 PRD 的后续章节提供坚实输入。
章节交付物：本章完成后，你应该产出三份文档草稿——① 一份使用标准句式的问题陈述；② 一份包含四个维度的影响范围分析表（附数据来源）；③ 一份价值假设验证实验方案（含假设、实验设计、通过标准）。这三份草稿将直接作为 PRD 第 1–2 节的输入内容。