第2章：PRD的核心要素
一、PRD的定义与价值
先说说PRD到底是什么。PRD，全称Product Requirements Document，产品需求文档。说白了，它就是产品经理和研发团队之间的"合同"。
我见过太多团队，产品经理口头说一句"这个功能很简单"，结果开发做出来完全不是那么回事。为什么会这样？因为没有一份清晰的PRD来约束双方的理解。
PRD的核心价值，我总结为三点：
- 对齐认知：让产品、设计、开发、测试对需求的理解完全一致
- 降低沟通成本：减少反复确认、来回扯皮的次数
- 提供追溯依据：出了问题可以回溯，是谁理解错了，一目了然
我个人的经验：有一次我们团队做支付模块，产品经理觉得"退款流程"很简单，口头说了两句就交给开发了。结果开发做出来的退款逻辑，跟产品想的完全不一样，最后返工花了整整两周。从那以后，我坚持所有需求必须写PRD，哪怕只是一个很小的功能点。
二、PRD的受众与阅读场景
一份PRD写出来，不是给自己看的。你得清楚谁会读它，他们在什么场景下读。
| 受众角色 | 关注点 | 阅读场景 |
|---|---|---|
| 产品经理（自己） | 需求完整性、逻辑自洽 | 写完后自查、迭代时回顾 |
| UI/UX设计师 | 交互流程、页面布局 | 设计阶段，需要明确每个页面的功能 |
| 开发工程师 | 功能逻辑、数据接口、异常处理 | 编码阶段，需要知道"怎么做" |
| 测试工程师 | 测试用例、边界条件、预期结果 | 测试阶段，需要知道"怎么验证" |
| 项目经理 | 时间节点、资源分配 | 排期阶段，需要评估工作量 |
你想想看，开发工程师拿到PRD，他最关心的是什么？是"这个功能到底怎么实现"，而不是"为什么要做这个功能"。所以PRD里要把逻辑讲清楚，伪代码、流程图、数据格式，能给的都给上。
避坑指南：我曾经见过一份PRD，写了整整30页"用户故事"，但没有任何技术细节。开发看完一脸懵，不知道该从哪里下手。后来我建议产品经理，PRD里至少要有20%的技术相关内容，比如接口定义、数据格式、异常处理逻辑。
三、PRD的黄金圈法则（Why-How-What）
黄金圈法则，是Simon Sinek提出来的。用在PRD上，就是三个层次：
- Why：为什么要做这个功能？解决什么用户痛点？
- How：怎么实现？用什么方案？
- What：具体要做什么？功能点是什么？
很多产品经理写PRD，上来就写"What"，直接列功能列表。但这样写出来的PRD，开发看完只知道"要做什么"，不知道"为什么这么做"。结果就是，开发可能会按照自己的理解去实现，跟产品初衷偏离。
我建议的写法是：先写Why，再写How，最后写What。这样层层递进，逻辑清晰。
3.1 Why：为什么要做？
这部分要回答几个问题：
- 用户遇到了什么问题？
- 这个问题的严重程度如何？
- 不做会有什么后果？
- 做了能带来什么价值？
举个例子：我们做"订单超时自动取消"功能。Why部分可以这样写：
"用户下单后长时间未支付，导致库存被占用，其他用户无法购买。目前每天有约200单超时未支付订单，占用了约5%的库存资源。如果不处理，会影响整体转化率约3%。"
3.2 How：怎么实现？
这部分是技术方案。不需要写得太细，但要有整体思路。
我记得有一次，产品经理写PRD，How部分只写了"用定时任务实现"。开发一看，以为是用简单的轮询，结果做出来性能很差。后来我建议，How部分至少要写清楚：
- 技术选型（比如用Redis的过期通知，还是用定时任务轮询）
- 数据流向（数据从哪里来，到哪里去）
- 异常处理（如果任务失败了怎么办）
3.3 What：具体做什么？
这部分是最具体的功能描述。包括：
- 功能列表（每个功能点是什么）
- 交互流程（用户怎么操作）
- 数据格式（输入输出是什么）
- 边界条件（异常情况怎么处理）
嗯，这里要注意，What部分不要写得太抽象。比如"优化用户体验"这种描述，开发看了等于没看。要写具体的，比如"将支付按钮从页面底部移到顶部，减少用户滑动操作"。
我曾经踩过的坑：有一次写PRD，What部分写了一个"支持多种支付方式"，但没有具体列出是哪几种。开发默认只做了微信支付和支付宝，结果上线后用户反馈说"为什么不能用银行卡支付？"——嗯，从那以后，我要求所有功能点必须列出具体的选项，不能有模糊描述。
四、黄金圈法则在PRD中的实际应用
下面我用一个实际的例子，展示黄金圈法则在PRD中的完整应用。
假设我们要做一个"用户签到"功能：
Why：为什么要做签到？
- 用户活跃度下降，日活从10万降到8万
- 竞品都有签到功能，用户反馈"为什么你们没有"
- 签到可以提升用户粘性，预计能提升日活5%-10%
How：怎么实现签到？
- 前端：在首页增加签到入口，点击后弹出签到弹窗
- 后端：记录用户签到记录，每天只能签到一次
- 数据：签到数据存储在Redis中，过期时间为7天
- 异常：如果Redis宕机，降级为MySQL存储
What：具体功能点
- 签到入口：首页右上角"签到"按钮
- 签到弹窗：显示今日签到奖励，点击"签到"按钮后签到
- 签到记录：显示最近7天的签到状态
- 连续签到奖励：连续签到7天额外奖励
- 异常处理：如果用户已经签到，提示"今日已签到"
我的建议：写PRD的时候，可以先用黄金圈法则搭框架，再填充细节。这样写出来的PRD，逻辑清晰，开发看了也容易理解。我一般会先写Why，让团队知道"为什么要做"，再写How，让开发知道"怎么做"，最后写What，让所有人知道"具体做什么"。
好了，这一章的内容就到这里。PRD的核心要素，说白了就是：定义清楚、受众明确、逻辑清晰。下一章我会讲PRD的详细结构，包括怎么写一份完整的PRD。