作为产品经理，写文档是核心的技能之一，而大多数产品经理可能最头痛的，也不过是写文档了。我看过非常多的PRD教程，大部分事无巨细，最长的可以分出十几个一级标题，这样“冗长”的PRD往往会让初入职场的产品经理失去了方向。
其实说起文档，产品经理最重要的就是BRD、MRD和PRD了，前两个文档如果写得清晰，那么PRD就可以写的相对简单一些了。
所以，我们今天要聊的话题就是，带你重新梳理一下BRD、MRD和PRD文档，以及如何写好一份PRD文档；帮助大家明确在一个产品调研、设计、开发、上线的过程中，各个文档分别起到怎样的作用，以及它的受众是谁，需要如何影响受众。
理清三者的关系后有助于产品经理明白哪些内容是应该在BRD和MRD中完成的，哪些内容才是PRD的核心。
BRD（商业需求文档）英文全称：Business Requirement Document
BRD可以说是一个产品从0-1过程中第一个诞生的正式文档，用于论证产品在商业上的可行性。BRD文档是产品经理向领导、以及财务和预算等职能部门沟通产品立项的工具，主要就是为了说明经典的“商业模式画布”当中的内容——即下图1到9几个模块。
商业模式画布是论证商业可行性的常用工具，说明产品给谁用、成本和收入情况、为什么能盈利、通过什么渠道盈利等关键问题。对BRD中商业模式画布感兴趣的朋友可以去读一读《精益创业实战》。
若产品领导、财务预算等职能部门认可了产品经理的BRD分析，那么就意味着产品可以立项了，公司会对这个产品开始投入资源，并开始产品备案等流程。
MRD（市场需求文档）英文全称：Market Requirement Document
相比于BRD沟通投入产出、盈利性等目的，MRD在BRD和PRD之间起到一个承上启下的作用，在BRD之后进一步说明立项产品所处的行业市场现况，目标用户，竞品调研和自身打法。
MRD的受众主要是产品经理的领导、公司的产品运营和市场品牌部门，向他们说明产品在市场中的定位和打法，同时为自己的产品在同公司的众多产品线中争取更多的运营和市场资源倾斜。
PRD（产品需求文档）英文全称：Product Requirement Document
当一个产品已经通过了BRD、MRD评审后，说明该产品在资源投入和定位、打法上已经获得了公司层面的认可，已经具备了启动产品设计、开发、投向市场的资格。
在这种前提下，一份PRD文档的受众就可以抛开运营和市场等职能部门，无需再赘述过多的商业可行性、盈利性等信息，仅面向产品后端、前端、交互设计师、测试输出信息即可。
如何写好PRD1. PRD文档的受众关心什么
虽然说不同的产品经理在PRD框架上有自己的见解，我梳理了一套我认为可行的PRD框架，主要包含以下内容：
1）迭代管理
迭代管理记录了产品开发从0-1的过程，产品经理需要写清每一次迭代新增、修改或下架了哪些功能，以及迭代的原因。
同时，迭代版本号反映出每次迭代版本更新的大小，以下图为例，通常两级版本号就能够表达出需求属于“大步迭代”还是“小步快跑”。
2）需求背景
所以建议PRD要包括以下两点：
（1）需求产生的原因：可以是发现了原来版本的局限性，即优化/修改老需求；也可以是基于新发现的用户需求对产品进行迭代，即增加新需求；
（2）需求的合理性和必要性：在需求评审中，后端开发通常会对需求合理性、必要性挑战产品经理——即为什么一定要开发上线这些功能，前端和设计师同样也会评估该需求是否为高优紧急。所以产品经理可以正向回答——即开发需求功能预计能为项目组、为部门带来怎样的收益，或逆向回答——不开发该功能会导致什么样的问题和风险。
3）功能清单
功能清单建议以列表的方式阐明本次新增和修改的功能。在功能清单中需要说明项目信息、新增/修改的功能点、功能点详情，以及优先级。
功能清单的目的主要是让后端快速了解本次开发的内容大纲，并评估出工作量，当产品经理定好每个功能点的优先级后，后端就可以根据工作量和优先级给出详细的排期，并协调测试提测的时间。
功能清单建议不要写的太过于繁杂，否则满满的文字；开发很容易感到厌烦，反而导致整个文档模块被忽略。下表是典型的功能清单例子，大家可以参考：
4）产品流程图
产品流程图是PRD中的必备内容，通常有很多画法，每个产品经理在流程图中表达的信息都不尽相同。
非技术背景出身的产品经理往往站在使用者的角度来梳理流程，而一些技术背景出身（或研发转产品）的产品经理往往在流程图会额外表达数据的流转关系。
但不论采用何种画法，他们的目的都是为了让PRD的受众理解产品使用的主线和分支。
下面我们分ToC和ToB两个场景来讨论：在ToC产品中，产品的使用对象往往为单一的个体，产品不涉及多个用户时，它的故事线和流程图往往比较简单，只需按照时间维度，按产品使用流程的主线来整理即可，同时在主线上注明不同分支。
下图就是一个很简单的例子:
但在TO B的产品中，产品的使用步骤通常涉及到多个身份的人员，不同人员之间的操作还有时序依赖关系。
在这种情况下，大家可以按时间维度 参与人员两个维度，画一份“泳道”流程图。
上面两张图提供了两个简单的例子，可以作为模板衍生、表达大部分的产品流程。
5）产品原型
最后，在一份PRD文档中不可或缺的就是产品原型了。产品经理在PRD需求评审时花往往花费大部分时间沟通产品原型。通常产品原型可分为高保真原型和低保真原型，具体采用何种形式其实取决于产品经理与UI/UX设计师之间的分工边界。
在分工极度明确的大厂，一般鼓励产品经理提供低保真原型即可。因为大厂的UI/UX部门对产品的风格调性、交互逻辑有着极为清晰的规定，产品经理在原型图上投入太多精力反而会事倍功半。
但是一些中小型公司人员分工不那么全面，产品经理与UI/UX的边界较为模糊，往往由产品经理本人输出高保真的原型图。
所以产品经理在输出PRD时原型到底画到怎样的精细度是因公司、因项目组而异的。这里我建议能输出低保真原型时尽量以低保真交付，但如果产品已经处于后期迭代时，用现有的真实界面进行P图改造也不失为一种简单的方法。
下图是在产品迭代过程中，利用原有界面和新增备注快速迭代出的原型图示例：
最后
其实初入职场的产品经理无需对PRD的撰写过分焦虑，尤其是在正确理解PRD在一个产品生命周期中所发挥的核心作用后，我们会发现其实它并不复杂。
以上就是对BRD、MRD、PRD文档的理解，以及PRD的各如何撰写的介绍。如果你也有想法，欢迎在留言区留言~
如果你觉得这篇文章对你有帮助，请分享给更多的产品人，愿与各位产品经理共同成长，感谢大家！
关于我
产品干货分享
【产品思维10讲】产品思维(一)：认知思维
【产品思维10讲】产品思维(二)：用户思维
【产品思维10讲】产品思维(三)：价值思维【方法论】产品经理面试成功的核心要素【方法论】详解产品分析的4大要素【方法论】从0-1产品设计心得【产品设计】需求文档撰写与合格交付原则【产品设计】B端产品的卡片式列表设计【产品设计】详解APP的消息通知设计【产品设计】详解用户画像知识体系
