PRD (产品需求文档), 英文全称是：Product Requirement Document。PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD或BRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
产品经理工作中最重要的产出是独立撰写一份PRD，这是产品经理的基本功之一。
怎么理解PRD
产品需求文档，即Product Requirement Document
是产品经理能力基础中的基础
是从产品规划到产品设计阶段的里程碑式综合产出物
“PRD写的好，不一定是好的产品经理，PRD写的不好，一定不是好的产品经理。”
今天我们就来谈谈这个基本功的话题——怎么样写出一份高质量的PRD。
如果你看完一份PRD也有以下感受：
- 文档通篇是各类名词、页面功能点跳转、点击之类的逻辑；
- 看完了文档有一肚子的疑问：为什么要有这个功能，为什么要这么做产品设计；
- 第一遍头晕眼花，必须得看第二遍、第三遍才能明白功能之间的关系。
这确实是一份不友好的PRD。
这种PRD产生，主要由于以下两个问题：
1、产品经理以为没写出来的那些内容，研发都已经潜在知晓了、明白了，或者作者打算“PRD评审的时候我会说这些内容的”。
2、产品经理撰写到PRD里面的，只是自己产品设计的结果，就是用例、功能、交互。
第一个问题——
“想不如说、说不如写。想不明白肯定也写不清楚。”
大家可以挑战一下自己，把那些打算放在评审会说的话，都先写在PRD里面。
第二个问题——
产品经理把PRD评审当做一次功能宣讲，只关注“让研发需要开发”的功能点（只说结论），忽略了其他也应该同步给项目团队的其他核心内容以便达成共识，导致开发过程的衍生问题，每次多要事无巨细的去讨论、争论。
这两个问题如何解呢？先从PRD的作用说起吧。
PRD的作用
作用一：PRD是项目工程人员围绕其进行技术落地的设计图纸。
- 研发根据PRD进行编程开发；
- 测试根据PRD写测试用例；
- 交互设计师根据PRD设计交互稿；
- 运营人员可以根据PRD提前了解将上线产品的功能，进行推广计划；
从这个意义上说，我们应该给出设计细节，还应该给出设计初衷和设计原则。在开发过程中，技术人员面临着各种细节，如果他们明白产品功能设计的由来，对于一些临时出现的问题直接从PRD可以找到答案，这能够帮助他们高效开发（判断一些细节，避免凭自己的理解猜测产品原意来做决定）。
作用二：PRD是产品经理进行产品设计工作的总结。
PRD除了写出产品设计结果（页面是什么样子的，按钮触发什么流程、流程图是什么样的），还需要写产品设计思路（为什么是这样的设计方案，功能之间是什么关系，对于用户起什么作用等）。为未来接替你的产品经理可以根据PRD了解目前产品功能细节，为项目留下一份可阅读意义的文档。
梳理PRD怎么写，无法脱离于项目流程单独思考，需要带入流程
再来看这张图
项目的流程大同小异，在做好需求评审前的各个环节之后，你自然会积累从抽象逐渐到具体的一系列文档内容。此时将它们进行整理，做汇总提炼，补充颗粒度更细的内容即可
一顺百顺一损俱损
从项目的维度拆解PRD的组成后，可以发现，前面的每一个环节做的越完善，在撰写PRD的时候越能降本增效
在撰写PRD出现问题时，也可以追本溯源根据内容部分找到对应的环节，定位问题从而找到解决方案
所以PRD到底怎么写，如果你把问题定位在“怎么写PRD”这个颗粒度，你能找到的大部分内容大致是一下3种
- 模板+简要的讲解
- 从各种角度切入，或重新解读或填充某部分的细节
- 长篇幅的系列文章
多看第三种，更有可能通过结论找到思考路径
但是这些都是被动的做法，你只能去碰，找到能给你启发适合你应用的内容的概率
主动的做法是，拆解→定位→聚焦
我对身边的同学做了一次小范围的调研，他们告诉我：
什么是优秀的PRD（第1版）
这是各个岗位对一份PRD文档的感性认识。从中我们可以得到几个通用的感受：
1、研发：要求细节丰富，不要有遗漏，尽量全面；
2、测试：有必要的Case，所有需要开发的要点，都应该体现在PRD中，减少需求变更；
3、产品：希望文是好文，有骨干（整体框架）、有血肉（概念定义和细节）；
4、交互：希望能看到清晰的信息结构，及未来扩展性。
大家可以先思考如下问题：
- 这只是数据可视化需求/字段新增需求，需要有系统流程图吗？
- 我这个需求只是一个小迭代，也应该写整体产品解决方案或思路吗？
- 什么是用户视角的场景化案例/用例，每一个功能的用例都应该详细写出来吗？
带着这几个问题，我们再来看：
什么是优秀的PRD（第2版）
如果我们不再把需求文档看成是产品经理“工作交付”文档，而是从产品的角度来看PRD本身，PRD的用户是谁？是产品开发流程的上下游，是项目的各个相关方。
“PRD是产品经理给项目成员讲述的故事。好的PRD是能让人听一次就记住的好故事。”
写文档的过程本质上是做一个“建设”的过程，将对在大脑中对产品设计的各种零散构思进行加工后织成一张网，然后将脑海中网状的结构输出到线性展开的文章中。
就像是将Xmind导出的思维导图，转化成一篇文档，不仅需要调整各个部分的顺序、还需要加入很多说明细节，这些调整和填充——就是PRD的故事性发挥之地：如何向大家全面讲清楚一个需求（从背景到细节）。
我们先来看看作为产品经理的你，是怎么向研发描述需求的日常。
你的开场白是什么？“小哥哥，我们有一个新的想法，想找你帮忙看看，大概占用10分钟时间，可以么”
开始沟通后，立即介绍背景：“你知道我们之前上线过的甲功能吧”（先确认需求前置信息是否已经同步了）
“这个功能上线后呢，效果还不错，业务想要进一步增加覆盖的产品线，然后运营会做全国推广”（快速说完背景）
“新增产品线，需要在前端界面里面展示，通过点击一个产品列表展开产品线的内容，新增的产品线在前端显示的数据字段，和现在线上产品基本是一样的”（说产品目标）
“线上目前功能不支持多产品线，现在我们的流程是从前台调用你们中台，中台还需要获取AB这些外围系统的数据，如果要支持多个产品线，从前台到中台都要改”（抛出整体解决方案：涉及哪些系统的修改）
“不过，因为新增的产品线，显示内容基本一致，所以上下游各系统的改动点是前端调中台的接口、中台调用AB外围系统的接口，都要带上产品线id，但要注意一下，如果是新增产品【甲】，前台页面就不展示金额了，这个逻辑可以前台做，也可以中台做，需要技术评估放在哪做比较合适”（说需求细节）
“对于异常情况，目前我想到的异常有：如果A、B外围系统数据没更新，会导致新增产品在A或者B外围系统查不到数据，这种情况中台不返回值给前端，前端页面这次就不显示新增产品的内容”（讲异常逻辑）
“我们这个需求还有点急，希望下个月就能全国推广了，你看看你负责的中台改动量大不大呢，咱们这部分月底能上吗”（谈排期）
一个这样的需求描述，研发听下来很容易就明白要做些什么。
这么讲述需求具体好在哪里？
大家知道知乎写作课的故事八步法吗？
故事八步法是讲怎么写小说的，解决的是脑子里已经有了画面但是写不出文字，或者写了开头不知道如何继续的问题。其实这个情况和我们写文档还挺像的，所以这次我们也用一下这个工具：
我们按照这个工具拆解一下刚才和研发小哥哥讲述的产品需求：
我们发现和研发小哥哥的需求沟通，不仅覆盖到了故事核心的几个要素，还是按照故事发展的线性顺序来组织需求描述的，所以听的人觉得很通顺、很好理解。
为什么大家很少会看觉得大部分文档都没这么好懂、易读？
因为向研发面对面讲述需求的时候，一切的语言组织都是围绕着“让研发听懂要干啥、为啥干，然后给我排期”为目标的。
但大多数产品经理在写PRD的时候，首先会拿出PRD模板（有的公司有规定的模板），逐个将细节内容填入模板的各个板块，反而欠缺了那条故事性展开的脉络。
大家拿到一个模板，首先要认识到，模板内容并不是要求全部都填好的，模板是公司按照最大公约数情况给大家的一个范例，所以我们也可以利用一个模板来讲好“故事”。
我们来看一个案例：
这样一看，PRD里面有一些核心模块，是能够起到很重要的作用的，大家在写PRD的时候应该认真对待。
那些研发、测试都提到的“注意细节”、“有用例case”，就是故事主干之外的细节了。
一位英雄回家的故事，可以写成《奥德赛》（荷马史诗的下部），也可以只是一个大结局结尾的几句话。差别在于，故事想讲的内容（产品解决方案）到底是从英雄开始回家说起，还是以英雄开始回家结束。
现在我们再回过头来看之前的那几个思考题，我的答案是：
-
这只是数据可视化需求/字段新增需求，需要有系统流程图吗？
涉及到系统流程改动了吗？如果是原有系统流程，可以不用放系统流程图。
-
我这个需求只是一个小迭代，也应该写整体产品解决方案或思路吗？
产品的功能点，有时候就是产品解决方案本身。所以小迭代也应该写。
-
什么是用户视角的场景化案例，每一个功能的用例都应该详细写出来吗？
涉及到牵涉系统改动的核心功能和异常处理逻辑的，应该写场景化案例/用例，但是不复杂的辅助功能就不需要写。判断的标准是，如果一个用例需要系统的多个流程步骤才能走完，就应该写，因为这种已经有一定的复杂程度了，需要用一个实际用例把需求内容都串起来，以便让各方都100%理解无歧义。
就例如白雪公主的童话故事，最激动人心的是白雪公主吃下毒苹果然后又被救活的情节，但是作者只写白雪公主吃下毒苹果后嫁给了王子大结局，这些核心的步骤都省略了，让这个故事有烂尾之嫌。
