← → 翻页 · B 静态 · ESC 索引
什么是 PRD · 产品需求文档入门
FIELD NOTE · 01 / 12
PRODUCT REQUIREMENTS · DOC 01

什么是 PRD

一份产品经理写给团队的产品需求文档——把脑子里的想法搬到纸上,让所有人对齐。
PM 新人 · 创业者 · 12 屏
→ swipe / arrow keys
Why Now · 为什么需要 PRD
02 / 12
WHY NOW · 02

脑子里的想法,
落地前要先经过纸。

01 · ALONE

想法 ≠ 共识

你以为自己说清楚了,别人听到的是另一个版本。PRD 是对齐的第一道工序。

99%
好想法停留在口头
02 · TEAM

不是一个人在做

一份产品要走过设计 / 研发 / 测试 / 运营 / 销售,平均 7 个角色看同一份材料。

7×
参与协作的角色
03 · ASYNC

文档是异步通讯

写一次,团队在不同时间各自看。减少会议、减少重复解释。

1×
写,胜过 10 次讲
Definition · 一句话定义
03 / 12
DEFINITION · 03

不是给老板的报告,
是给团队用的图纸

PRD = Product Requirements Document。它回答的不是「这个产品好不好」,而是「我们要做什么、为什么、做到什么程度」。
Structure · PRD 的 6 个核心模块
04 / 12
STRUCTURE · 04

一份 PRD 的 6 个核心模块

01 · WHY
背景与目标
为什么做这件事、要解决什么问题、衡量成功的指标是什么。
02 · WHO
用户与场景
谁会用、什么场景、他们现在怎么解决、为什么不够好。
03 · WHAT
功能需求
用户能做的具体动作,拆到最小可交付的功能点。
04 · HOW
业务流程
每一步怎么走通,从入口到出口的关键路径和分支。
05 · MEASURE
数据与指标
埋哪些点、看哪些数、什么样的数字算成功。
06 · RISK
风险与依赖
哪里可能卡住、需要谁配合、有没有兜底方案。
Value · PRD 的四个核心价值
05 / 12
VALUE · 05

写一份 PRD,
换来四个长期回报。

— 01 · ALIGN

让方向一致

设计、研发、运营看同一份材料,避免各做各的。

— 02 · ASYNC

让沟通异步

不需要每次都拉会议对齐,文档可以反复读。

— 03 · TRACE

让决策可追溯

三个月后为什么这么做?翻 PRD 就有答案。

— 04 · REUSE

让经验可复用

下一份 PRD 站在上一份的肩膀上,不用从零开始。

Process · 5 步写好 PRD
06 / 12
PROCESS · 06

写 PRD 不是一次写完,
是 5 个步骤来回走。

STEP 01 想清楚为什么 问题、用户、成功标准
STEP 02 描述用户场景 谁、什么场景、怎么用
STEP 03 列功能清单 拆到最小可交付单元
STEP 04 排优先级 P0 / P1 / P2
STEP 05 找团队评审 拉所有相关人,签字确认
Pitfalls · 6 个常见误区
07 / 12
PITFALLS · 07

PRD 写错的 6 种姿势。
你大概率踩过至少一种。

01
写成 PPT 风
散乱没主线,看完不知道下一步做什么。
02
抄模板不思考
模板是脚手架,不是答案。直接抄会失去针对场景的洞察。
03
没写用户故事
只写「做什么」,不写「为谁做、为什么」。开发不知道为谁服务。
04
不写验收标准
「做完」不等于「做对」。没有验收标准,完成定义模糊。
05
写完不发
躺在硬盘里没人看。文档不是写完就行,要让团队读到。
06
永不更新
PRD 是活文档。产品变了 PRD 没变,就是误导团队。
Principles · 3 个核心原则
08 / 12
PRINCIPLES · 08

写 PRD 的
3 条铁律。

3 IRON RULES
01

用户视角

写给人看的,不是给机器读的。先讲「谁在用、为什么用」,再讲「做什么」。

02

一句话能说清

如果开头两段你都说不清 PRD 要做什么,别人更看不懂。先用一句话概括整个产品。

03

每个需求都可验收

每个功能点都要回答「怎样算做好了」。没有验收标准的需求,等于没写。

Compare · 好 PRD vs 烂 PRD
09 / 12
COMPARE · 09

同一句需求,
两种 PRD,差距在哪?

01BAD

「做个登录」

一句话需求 + 一张截图。设计照着做,研发猜着做,测试不知道测什么。

  • 没有「为什么」
  • 没有用户场景
  • 没有验收标准
  • 没有异常处理
02GOOD

「为新用户做的登录流程」

五件事讲清楚:为什么做、为谁做、怎么走通、怎么算成功、出问题怎么办。

  • 背景与目标清晰
  • 用户场景具体
  • 验收标准明确
  • 异常路径有兜底
Checklist · 优秀 PRD 8 项清单
10 / 12
CHECKLIST · 10

一份 PRD 达标的 8 个钩子。
逐条打勾,8 / 8 才算合格。

01
用户故事清晰
02
验收标准明确
03
边界条件覆盖
04
优先级清晰
05
异常路径考虑
06
数据埋点设计
07
风险与依赖
08
迭代记录完整
100
SCORE
8 项全勾 = 满分 PRD
每一项各 12.5 分。少勾一项,问题就在那里等着被产品上线后翻车。
Mindset · PRD 是一种思维方式
11 / 12
MINDSET · 11

PRD 不只是一份文档。
它是一种把模糊
变成清晰的思维方式。

12 / 12
CLOSING
MANIFESTO

写一次,
省下无数次
解释

PRD 不是束缚,是给未来的自己和团队的一份礼物。
FIELD NOTE · 01
26.07.25
TAKEAWAYS
03 RULES
01

从一句话开始

先写「为谁、做什么、解决什么问题」一句话,然后再扩成完整 PRD。

02

用户视角优先

先讲「谁在用、为什么用」,再讲「做什么、怎么做」。永远从用户出发。

03

每个需求都可验收

写完后回头看,每条需求都能回答「怎样算做好了」。不能回答的,继续改。

→ 完 · END OF FIELD NOTE 01