高质量的产品需求文档是团队高效沟通协同的桥梁，也是提高整体效率的重要通道。

PRD是产品经理的重要产出，产品经理至少有一半左右时间在写需求文档或者在写的路上，对于复杂的需求，如果产品经理思维、逻辑，很容易出现如下问题：

• 需求流程复杂、场景多而且乱

• 研发看起来很费劲，看完后没太看懂，还要不断问问题。

• 很容易出现遗漏，特别是评审后才发现的，甚至是开发完测试验收发现

规范的产品需求文档至少包含两个重点: 清晰的需求内容描述和规范标准的产品模板。

要把产品需求文档当做你的产品，把UI、UX、研发、测试当做你的用户，要站在用户的角度来审视你的文档是否清楚明白，逻辑是否清晰，阅读体验是否较好。

什么是产品需求文档

产品需求文档是为了实现用户需求和产品目标而撰写的详实的说明，也是给到团队成员和外部相关人员的产品需求指南。

产品经理做好需求分析后，需要把需求分析的思路和内容输出成文档，主要包括如下几个重要部分，

比如，背景、用户故事、竞品分析、原型图、交互说明。

在之前的文章有说到敏捷和瀑布方法，方法不同产品需求文档也会有较大的差异。

瀑布方法产品需求文档: 产品需求文档通常只有一个确定好的版本，在编写完成并和用户确定后就很少变动了。

敏捷方法产品需求文档: 产品需求文档针对每个功能都会有很多需求版本，即便是当时用户确定后，还会不断根据实际情况进行需求迭代，甚至推翻从来。

下面主要针对产品迭代方法来分解产品需求文档。

如何撰写规范的产品需求文档

产品文档内容整体包括两大部分:

第一部分是产品整体说明，主要包括产品背景、产品目标、产品价值、用户画像、产品路线图。

此部分通常按季度年度更新调整一次，是产品的大方向，是产品介绍。

一、前言

1.1 产品背景

为什么要做这个产品，主要背景原因是什么，是公司战略规划，还是创新，是客户需求，还是你发现了什么机会点，总的来说就是你要做这个产品的初衷。

1.2 产品目标

做产品必须有一个目标，我们做产品做项目都是为了目标而奋斗，没有目标就没有方向，没有方向是肯定找不到出路的。

1.3 产品价值

一定是会产生价值的事情我们才会去做，一个产品不管是付费的、免费的，还是公司内部的，一定是要给用户来带价值的，有价值才有机会在市场上去竞争，才有机会存活下来。

二、目标用户

要做产品首先的确定你的目标用户群，不是说所有人都是你的用户，针对不同的用户群的策略和玩法是完全不一样的，要先定好用户画像，才能去确定产品做成什么样子。

三、产品规划

目标确定好后，可以根据目标做一个短期、中期、长期的规划，这个就是产品路线图，这个也是产品的战略方向和计划。

第二部分是每个模块功能的明细需求，针对具体功能需求的详细梳理，包括修订记录、需求背景、需求场景/用户故事、用户价值、需求描述（流程图、功能描述、原型设计、交互说明）、埋点需求、接口需求、非功能性需求（性能、安全、兼容性说明）

此部分需求文档可能每周都会新增或更新调整，是产品经理日常工作中用的最多的地方，也是产品经理重要的工作产出。

四、产品Xx模块需求

4.1 Xx功能需求文档

一、修订记录

每一次修订都需要进行记录：

1、更新内容需要插入超链接锚点可直接跳转至本页面的更新部分

2、修改中删除部分尽量不要直接删除仍保留，使用删除线划掉，便于后续查看，说明修改人，修改时间，修改原因

二、需求背景

2.1 要解决的问题

尽量简单的描述需求要解决的问题 以及 需求来源，让文档读者能够快速抓住重点

2.2 用户故事

把用户使用需求的各种场景、每一个步骤和前后关系进行描述说明，什么人什么时候在哪里做什么事情怎么做。不要搞得太复杂，链路要清晰。

2.3 用户调研

简要说明调研方法、样本情况及关键结论。

2.4 数据分析

只在本文档里列出关键结论，如果有更详细的数据分析过程可以另写一篇文档

2.5 竞品分析结论

列出竞品相关能力的主要信息和关键结论，可以重点推演它们背后设计的动机与目标，再与我们要解决的问题对比

三、需求目标

目标需要是可衡量的，能帮助我们事后判断是否实现了目标。衡量的方式可以是定量的或是定性的。

需求目标: 例如通过增加用户签到以及赠送积分的能力，能提高用户的活跃度。

衡量标准: 例如功能上线 1 个月后，用户活跃数达到 X%

四、需求范围

可条理性地罗列需求范围、功能点说明

五、功能详细说明

5.1 流程图

用户使用某个功能步骤，比如登录注册流程，每个步骤是否要满足什么条件，确定好每个流转路径。

5.2 原型、交互及说明

复制网页链接，直接粘贴到文档中，所有原型和交互说明都在链接中，这里要注意链接必须是一直可用的。

或 直接以图文方式表达出来，一张原型图对应一份说明。

或 最好是网页链接贴上去，然后再以图文方式表达出来，网页链接可以看到和体验交互方式，图文可以把更多的逻辑说清楚。

5.3 系统对接需求

需求需要和哪些系统对接，要把对接的业务说清楚，你需要什么数据，返回什么数据，具体对接以及接口文档可以让技术双方对接即可。

接口名称：用户最新积分获取

获取数据目的：发送邮件

时间：每周一早上9点

需要什么数据：用户最新的积分数量

5.4 数据需求

提前思考功能上线后，想要看到的数据有哪些，想通过每个数据得到什么样的用户洞察

六、非功能需求

可以列举产品性能需求、兼容性需求、其他说明等

附录

输入正文提及的具体文档，或需求相关的其他说明文档附在此处以供查阅

• 数据分析报告

• 用户调研报告

• 竞品分析报告

• ......

写PRD用什么工具

文档工具: Confluence、飞书、语雀、Word

原型工具: Axure、墨刀、PPT

流程图: Axure、Xmind、ProcessOn、PPT

以前需求文档都是用Word文档来写，协同起来特别费劲，存档的版本也特别多，同事之间传来传去修改，特别是文档格式很容易乱。

现在基本都是用在线文档来实现协同，一起编辑文档实现高效协同，必要时也可以导出Word文档，如果对文档有较高要求，可以调整一下格式目录就可以用来发给客户或者用户了。

现在第三方工具越来越好用了，而且效率也越来越重要，要多去学习和使用新的工具来想办法提高自己的效率才行。

最后需要注意，产品经理写需求文档最容易放的错误是：“我们以为研发知道”，特别是你以为某些细节就是产品的标准，都是大家认可的常识，所以没有太细的列出来。

所以，产品经理不能期望你的团队所有成员都能和你在同一个理解层次和频道上面，我们写的需求文档一定是要把所有细节全部列清楚，这样需求开发完成后出现缺失、遗漏、没有理解一致的风险是最低的。