4. 业务问题定义与目标对齐：问题陈述、业务目标、成功标准
产品需求文档的核心驱动力，并非功能列表，而是对“为什么做”的清晰回答。在进入功能设计之前，必须完成三项对齐工作：问题陈述以凝聚共识，业务目标以衡量价值，成功标准以定义完成。本章提供这三项要素的结构化方法，并通过一张对齐视图串联全流程。
核心原则： 一个优秀的PRD，其问题定义应能让所有干系人在5分钟内说出“我们要解决什么问题，做到什么程度算成功”。
4.1 问题陈述：从现象到本质
问题陈述不是用户抱怨的简单记录，而是经过归因分析后的业务差距描述。一个标准的问题陈述包含三个元素：
- 现状（痛点）：当前用户或业务正承受的具体不良状态，需包含可观测的行为或数据。
- 标准（期望）：在理想状态下，业务或用户本应达到的正常状态。
- 后果（影响）：若不解决该差距，将对公司战略、用户留存或收入产生的可量化损失。
问题陈述模板示例：
作为[业务角色]，在[特定场景]下，由于[当前系统/流程的限制]，导致[具体的负面结果]，这直接影响了[核心业务指标]，预期每季度造成[可量化损失]。
作为[业务角色]，在[特定场景]下，由于[当前系统/流程的限制]，导致[具体的负面结果]，这直接影响了[核心业务指标]，预期每季度造成[可量化损失]。
4.2 业务目标与产品目标
业务目标和产品目标常被混用，但二者在层级和时效性上存在明显区别。下表梳理了二者的核心差异：
| 维度 | 业务目标 | 产品目标 |
|---|---|---|
| 关注层级 | 公司经营 / 部门业绩 | 产品特性 / 用户体验 |
| 典型周期 | 季度 / 年度 | 版本 / 项目周期 |
| 示例 | “本季度电商转化率提升15%” | “新结账流程的完成率提升至80%” |
| 归因模糊性 | 受市场、运营等多因素影响 | 因果链相对清晰 |
对齐策略：将一项大的业务目标向下拆解为多个产品目标，确保每一个产品功能的交付都能为业务目标提供可追溯的贡献。
4.3 成功标准：SMART 原则
成功标准是问题是否被解决的“裁判规则”。使用SMART原则撰写，可以避免主观判断。
- S (Specific 具体的)：明确谁、在何种条件下、做什么。
- M (Measurable 可衡量的)：有明确的数值，如时间、金额、比率。
- A (Achievable 可实现的)：基于现有技术和资源评估，非空想。
- R (Relevant 相关的)：与问题陈述中的业务差距直接相关。
- T (Time-bound 有时限的)：何时达成，是版本发布后1个月还是3个月。
常见陷阱：避免将“功能上线”直接当作成功标准。功能上线只是手段，用户行为改变或业务指标改善才是真正成功。例如，不应写“上线一键下单按钮”，而应写“上线后，由商品详情页到支付完成的转化率提升10%”。
4.4 三者对齐：一张图可视化
将问题陈述、业务目标、成功标准放在同一逻辑流中检验，可以发现破绽。下面这张SVG图展示了从问题输入到目标定义，再到成功标准评估的闭环。
4.5 案例：一次性在PRD中落地
以一个具体的“客户差评预警”需求为例，说明上述三要素的完整写法：
| 要素 | 具体内容 |
|---|---|
| 问题陈述 | 客服团队每周需手动检索各平台差评，平均耗时10小时/周，导致差评响应平均延迟48小时，差评修复率不足20%，每月造成约5万元品牌口碑直接损失。 |
| 业务目标 | Q3将全渠道差评的主动发现率提升至80%，将平均响应时间压缩至4小时内。 |
| 成功标准 |
M：系统上线1个月后，自动捕获的差评数量达到人工发现量的90%以上。 R：成功标准的变化直接降低了客服手动标注工时。 T：以上标准在项目发布后的第30天进行首轮评估。 |
实操建议：在PRD正文中，将问题陈述、业务目标和成功标准写在一个名为“1. 项目背景与目标”的独立章节内。如果业务目标较多，使用表格进行逐条映射，确保每个产品功能都能找到其对应的业务价值。