📚 课程目录第1章 PRD的受众与核心价值

1. PRD 的受众与核心价值：谁在看、为什么看、怎么看

许多产品经理把 PRD 当成“功能说明书”，写完就扔给研发，以为对方会逐字读完。结果往往是：研发只扫了几个标题就开始写代码，测试等到最后一刻才发现需求逻辑缺失，设计返工了至少三轮UI。

根本原因是：你没有搞清楚 PRD 到底给谁看，以及他们真正想从这份文档里得到什么。

常见误解：“PRD 越详细越好，所有人都应该从头到尾读完。”
事实是：不同角色只看自己关心的那几页。一份面向全部受众的 PRD，必须在结构上做到“各取所需”，而不是让每类读者在 60 页文档里自己挖信息。

1.1 五大读者群体与他们的阅读偏好

读者群体	核心关注点	阅读深度
研发工程师	业务规则、数据流转、接口定义、异常处理	只扫功能描述与逻辑分支，不关心商业背景
测试工程师	验收标准、边界条件、状态机、错误码	逐句检查，缺一条分支就算“需求不完整”
UI/UX 设计师	用户场景、交互流程、页面状态、文案规范	跳过后台逻辑，聚焦前台的流程与视觉
项目/项目经理	交付物清单、里程碑、依赖项、风险点	只看目录与验收清单，不读具体规则
业务/运营方	核心价值、用户收益、指标预期、权限规则	逐条核对“我的需求有没有被实现”

  避坑要点：不要默认所有人都会读懂你的业务术语。研发需要的是“如果...那么...”的逻辑，业务方需要的是“解决了什么问题、提升了什么指标”。同一段需求，要为不同受众提供不同视角的解读方式。

1.2 两个不可忽视的核心决策者

除了上述一线读者，还有两类决策者不会逐字读 PRD，但他们的意见直接决定 PRD 能否立项或上线：

技术负责人 / 架构师：关注技术可行性、性能指标、第三方依赖、数据安全。他们会在 PRD 里快速定位“系统交互图”和“非功能性需求”部分。
业务负责人 / 产品总监：关注投入产出比、核心指标（转化率/完成率/成本降低）、合规与风控。他们只看“目标与范围”和“验收指标”章节。

建议：在 PRD 第一章加上“决策者摘要”，用一段话概括：
① 这个功能帮谁解决了什么问题；
② 预期带来的业务指标变化；
③ 需要的开发周期与风险。
这样核心决策者不用翻页就能给出结论。

1.3 PRD 的三个核心沟通作用

一致性对齐：让所有参与方对“做什么、为什么做、做到什么程度”达成唯一共识，避免口头沟通带来的信息衰减。
决策记录：记录从用户访谈、需求评审到方案确认的完整决策链，方便后续追溯“为什么这样设计”。
验收依据：作为研发交付后的测试基准和验收凭证，避免“做完之后双方对需求的记忆不一致”。

避坑提示：不要把 PRD 当作“需求管理工具”。需求变更、优先级排序、版本规划应该放在 Jira、Notion 或类似系统中。PRD 的定位是“一次性共识文档”，不是“持续更新的需求数据库”。

1.4 常见误解一览

误解	真相
PRD 越厚越好	厚度不等于质量。冗余信息会稀释核心逻辑，增加阅读负担。
PRD 只要研发看懂	测试、设计、业务方都有不同的阅读视角，PRD 必须分层。
PRD 可以在开发过程中持续修改	PRD 在评审通过后应当锁定，后续变更走需求变更流程，不要在原 PRD 上直接覆盖。
写完 PRD 就完成需求阶段	PRD 只是“方案表达”的产物，前面的用户访谈、需求拆解才是关键。

1.5 PRD 受众与价值关系图

  本章小结：PRD 不是写给产品经理自己看的，也不是写给所有人看的。明确读者群体（五类一线读者 + 两类决策者），定位核心价值（对齐、记录、验收），破除常见误解（厚度、唯一性、变更习惯），才能在后续章节中写好每一段需求描述。

  从下一章开始，我们将进入真实的业务场景，用用户访谈与需求拆解，把“模糊想法”一步步转化成可执行、可验收的 PRD 内容。