开篇三件套 —— 产品概述、用户角色、问题场景

本课导读

PRD 的前三个部分——产品概述、用户角色、问题场景——加起来往往不到一页，却决定了整份文档的命运：读者（尤其是工程师）就是在这一页里决定"这事值不值得做、我信不信这个作者"。写好它们的共同心法只有一句：证据先于方案。本课逐个拆解写法，每个都给出"病句 vs 好句"对照。预计 35 分钟。

产品概述：三句话让读者上车

产品概述（Product overview）的职责：说明这个功能的目的，以及它如何支撑更大的产品目标。注意后半句——孤立地描述功能人人会写，把功能挂到产品大目标上才是概述的价值。推荐三句话结构：

1. 现状：用户/业务现在卡在哪（一句话，可引用数据）
2. 方案：我们打算做什么（一句话，说行为不说实现）
3. 挂钩：它推进哪个产品级目标/指标（一句话，最好能点名战略层的成功指标）

病句 vs 好句：

• ❌ "本需求为笔记模块增加导出功能，支持多种格式。"——只有方案，没有现状和挂钩，读者的内心弹幕是"所以呢？"
• ✅ "内测用户整理季度笔记时只能逐篇复制（近两周 3 人反馈）。本功能提供一键批量导出 zip，消除数据被锁死的顾虑——直接支撑'数据逃生舱'原则与留存目标。"

用户角色：谁会碰这个功能

用户角色（User personas or actors）的职责：识别功能服务谁、他们怎样与它交互。两个写作要点：

要点一：角色（actor）不只是"人"

图里用了"personas or actors"这个措辞，值得较真：与功能交互的不只有终端用户。一个"批量导出"功能的完整角色清单可能是：

• 学习者（主角色）：发起导出、下载文件
• 管理员/站长（次角色）：关注导出对服务器负载的影响
• 笔记服务（系统角色）：被调用方——它的接口能力直接约束本功能

漏写系统角色是新手 PRD 的高发事故：只写了"用户点导出"，没写"导出要调用谁"，依赖部分（第 4 课）自然也就跟着漏。

要点二：写"与本功能的关系"，不是贴通用画像

PRD 里的角色描述要围绕本功能裁剪。通用画像（"张伟，32 岁，喜欢摄影"）放战略文档可以，放 PRD 是噪音。PRD 需要的是：这个角色多久用一次本功能、在什么情境下用、用它完成什么、技术熟练度如何（决定容错设计的力度）。

• ❌ "目标用户：热爱学习的年轻人。"
• ✅ "学习者（主角色）：每 1-3 个月集中整理一次笔记，通常在深夜非高峰时段；期望一次操作拿走全部数据；对 zip/Markdown 有基本认知，无需引导教育。"

问题场景：让读者亲眼看见那个卡点

问题场景（Problem scenarios）的职责：描述用户工作流中这个功能要解决的具体情境。关键词是"工作流中"——问题不是悬空的抱怨，是嵌在一连串真实动作里的卡点。推荐三段式写法：

1. 情境：谁、什么时候、正在做什么（把读者放进现场）
2. 卡点：他在哪一步卡住、现在只能怎么将就（将就方案是需求强度的最硬证据——用户宁可逐篇复制三小时，说明痛是真的）
3. 期望：他希望世界变成什么样（说结果，不说功能——"希望十分钟内拿走全部笔记"，而不是"希望有个导出按钮"）

• ❌ "用户需要导出功能。"——这是结论，不是场景；没有证据，无法排优先级
• ✅ "小周备考转行面试，想把三个月的 47 篇课程笔记导入自己的复习工具。目前唯一的办法是逐篇打开、全选、复制——她上周实际花了一晚上，中途漏了 6 篇。她希望十分钟内把全部笔记以通用格式拿走。"

第二版让每个读者都"看见"了那个晚上——具体性就是说服力。还记得战略层那句话吗：用户是问题专家，不是方案专家。问题场景就是把用户的"问题专长"原汁原味搬进文档，把"方案专长"留给团队。

✍️ 练习

练习 1：病句门诊

改写下面这段 PRD 开篇（可自行合理虚构细节，但要标注哪些是假设）：

"为了提升用户体验，我们计划开发夜间模式。目标用户是所有用户。用户需要夜间模式。"

✅ 参考答案

• 概述："学习页面纯白背景在暗光环境下刺眼（假设：后台数据显示 41% 的学习时段在 21 点后）。本功能提供跟随系统的深色主题，降低晚间学习的视觉疲劳——支撑'每周学习时长稳定'这一核心指标。"
• 角色："晚间学习者（主角色）：下班后 21-24 点学习，多在卧室暗光环境，手机系统已开启深色模式；期望产品自动跟随，无需手动切换。"
• 场景："老李哄睡孩子后 22 点半打开课程，屏幕整片白光晃眼，他把亮度压到最低——代码块里的注释色几乎看不清了（将就方案），坚持二十分钟就放弃。他希望打开产品就是舒服的暗色，什么都不用设置。"

对照原文的三宗罪：目的空洞（"提升体验"）、角色偷懒（"所有用户"= 没研究过用户）、场景缺失（"需要"是结论不是证据）。

练习 2：给将就方案取证

选一个你工作里想推动的需求，只做一件事：找出目标用户现在的将就方案（他们此刻是怎么忍过去的），用两三句话写下来。如果发现根本没人将就——没人为这个问题付出过任何代价——请诚实地记下这个发现。

✅ 参考思路

将就方案是需求验证的试金石，三种结果三种含义：有笨重的将就方案（手工 Excel、逐篇复制、每周人肉汇总）→ 痛是真的，且将就方案本身就是你的竞品和设计参照；有轻巧的将就方案（顺手就绕过去了）→ 需求存在但强度低，进 Could；没有任何将就方案 → 高危信号——要么问题不存在，要么它根本不在用户的工作流里。把这个发现写进问题场景，比十句"用户强烈需要"都有分量。

📝 随堂测验

随堂测验0 / 5 题正确

1. 产品概述的三句话结构是？

A背景、意义、展望B现状（卡在哪）、方案（做什么行为）、挂钩（推进哪个产品级目标）C问题、分析、结论D人、货、场

2. PRD 的角色部分强调“personas or actors”，其中 actor 概念的价值是？

A听起来更专业B提醒你交互方不只有人——被调用的系统也是角色，漏写系统角色会连带漏掉依赖部分C方便招聘演员做用户测试Dactor 和 persona 完全同义

3. PRD 里的角色描述与战略层通用画像的区别是？

APRD 里的要写得更长BPRD 围绕本功能裁剪：使用频率、情境、目的、熟练度；通用生活细节（32 岁爱摄影）在这里是噪音C没有区别，直接复制画像DPRD 里不需要角色描述

4. 问题场景里“将就方案”（用户现在怎么忍的）之所以关键，是因为？

A可以嘲讽竞品B它是需求强度最硬的证据——用户愿意付出的将就成本，直接标定了痛的真实程度；没人将就是高危信号C方便估算开发工期D让文档显得生动

5. 开篇三件套的“说服链”指的是？

A文笔要有感染力B概述给结论 → 角色证明这样的人存在 → 场景证明痛是真的——证据先于方案，否则功能清单每条都会被评审会挑战C先说服老板再说服团队D把最难的需求放最前面

本课小结

• 心法一句话：证据先于方案——开篇三件套就是 PRD 的证据链
• 概述三句话：现状 → 方案（行为不是实现）→ 挂钩产品级目标；念给外人听测一次
• 角色两要点：actor 含系统方（漏了它就漏依赖）；围绕本功能裁剪，别贴通用画像
• 场景三段式：情境 → 卡点（将就方案是最硬证据）→ 期望（说结果不说功能）
• 具体性就是说服力："她上周花了一晚上漏了 6 篇" 胜过 "用户强烈需要"

下一课进入文档正文：功能需求与工作流/边界情况——PRD 里字数最多、也最考验"歧义清除力"的部分。