MRD在BRD和PRD之间起到一个承上启下的作用

为什么强调“简练”PRD？

标题中强调简练，是因为作者在初入职场时也看过非常多的PRD教程，大部分事无巨细，最长的可以分出十几个一级标题，这样“冗长”的PRD让初入职场的产品经理往往失去了方向。

其实作为文档三兄弟（BRD、MRD、PRD）中的一环，前两个文档如果写得清晰，那么PRD就可以写的相对“简练”。

所以让我们重新梳理一下BRD、MRD和PRD在一个产品调研、设计、开发、上市中分别起到怎样的作用，以及它的受众是谁，需要如何影响受众 (熟悉的概念的朋友可以跳过这一部分）。

理清三者的关系后有助于产品新手明白哪些内容是应该在BRD和MRD中完成的，哪些内容才是PRD的核心，进而明白为何PRD可以很“简练”。

1. BRD：Business Requirement Document

BRD可以说是一个产品从0-1过程中第一个诞生的正式文档，用于论证产品在商业上的可行性。BRD文档是产品经理向上司、以及财务和预算等职能部门沟通产品立项的工具，主要就是为了说明经典的“产品精益画布”当中的内容——即下图1到9几个模块。

产品精益画布是论证商业可行性的常用工具，说明产品卖给谁、成本和收入情况、为什么能赢利、通过什么渠道盈利等关键问题。对BRD中产品精益画布感兴趣的朋友可以细读《精益创业实战》（第二版）第三章，本文不做细述。

若产品上司、财务预算等职能部门认可了产品经理的BRD分析，那么就意味着产品可以立项了，公司会对这个产品开始投入资源，并开始产品备案等流程。

2. MRD：Market Requirement Document

相比于BRD沟通投入产出、盈利性等目的，MRD在BRD和PRD之间起到一个承上启下的作用，在BRD之后进一步说明立项产品所处的行业市场现况，目标用户，竞品调研和自身打法。

MRD的受众主要是产品经理的上司、公司的产品运营和市场品牌部门，向他们说明产品在市场中的定位和打法，同时为自己的产品在同公司的众多产品线中争取更多的运营和市场资源倾斜。

3. PRD：Product Requirement Document

当一个产品已经通过了BRD、MRD评审后，说明该产品在资源投入和定位、打法上已经获得了公司层面的认可，已经具备了启动产品设计、开发、投向市场的资格。

在这种前提下，一份PRD文档的受众就可以抛开运营和市场等职能部门，无需再赘述过多的商业可行性、盈利性等信息，仅面向产品后端RD、前端FE、交互设计师（UI或UX）、测试QA输出信息即可。

二、如何写一份“简练”的PRD？

1. PRD文档的受众关心什么

基于上文，PRD是面向后端RD、前端FE、交互设计师和QA的文档，我们首先要拆解分析这些角色的核心关注点，然后把他们的关注点融合到PRD的不同章节中。

• 后端RD：后端研发主要关注所设计的产品需要存储哪些数据，需要如何建表存储这些数据，这些数据是否需要支持增、删、改、查等功能，以及为了操作这些数据需要为产品提供哪些接口；
• 前端FE：前端FE主要关注后端接口如何与前端界面相结合，调取后端哪个接口，并用怎样的方式为后端收集入参，在收集入参时前端是否要做额外的限制，以及后端返回的出参如何转化为前端的提示等；
• 交互设计师：主要关注产品在用户交互上的体验及产品的界面调性、视觉样式是否符合公司的规范。大部分交互设计师和产品经理沟通时都是对着原型图深化UI稿，所以他们往往是最关注PRD中原型的人；
• 测试QA：主要关注产品的user story，因为QA需要模拟不同的使用场景设计测试case，大部分情况下QA会用Xmind等脑图设计工具来设计、覆盖可能出现的case，并进行遍历测试。

当然，除了上述不同的关注点，PRD的受众也需要知道一些共同的信息，例如：产品中有哪些通用概念，本次迭代与之前版本的功能迭代的关系，以及本次产品开发的紧急性和重要性。

2. 如何将受众的关注点融入PRD框架

虽然说不同的产品经理在PRD框架上有自己的见解，本文根据作者自身经验及对大厂同事们PRD的参考，建议产品新人遵循以下框架，就能满足大部分RD、FE、UI/UX、QA们的需要。

1）迭代管理

迭代管理记录了产品开发从0-1的过程，产品经理需要写清每一次迭代新增、修改或下架了哪些功能，以及迭代的原因。

同时，迭代版本号反映出每次迭代版本更新的大小，以下图为例，通常两级版本号就能够表达出需求属于“大步迭代”还是“小步快跑”。

2）需求背景

需求背景是RD、FE、UI/UX和QA共同关注的点，在大厂中，一般后端RD和QA是分组的，而FE和UI/UX是部门共享的人力，意味着你的需求在FE、UI/UX面前是要和部门内其他组的需求抢排期。

所以建议“简练”版的需求背景要包括以下两点：

1. 需求产生的原因：可以是发现了原来版本的局限性，即优化/修改老需求；也可以是基于新发现的用户需求对产品进行迭代，即增加新需求；
2. 需求的合理性和必要性：在需求评审中，RD通常会对需求合理性、必要性挑战产品经理——即为什么一定要开发上线这些功能，FE和UI/UX同样也会评估该需求是否为高优紧急。所以产品经理可以正向回答——即开发了需求所提的功能预计能为项目组、为部门带来怎样的好处，或逆向回答——不开发该功能会导致什么样的问题和风险。

3）功能清单

功能清单建议以列表的方式阐明本次新增和修改的功能。在功能清单中需要说明项目信息、新增/修改的功能点、功能点详情，以及优先级。

功能清单的目的主要是让后端RD快速了解本次开发的内容大纲，并评估出工作量，当产品经理定好每个功能点的优先级后，后端RD就可以根据工作量和优先级给出详细的排期，并协调QA提测的时间。

功能清单建议不要写的太过于繁杂，否则满满的文字RD、FE们很容易感到厌烦，反而导致整个文档模块被忽略。下表是典型的功能清单例子，大家可以参考：

4）产品流程图

产品流程图是PRD中的必备内容，通常有很多画法，每个产品经理在流程图中表达的信息都不尽相同。

非技术背景出身的产品经理往往站在使用者的角度来梳理流程，而一些技术背景出身（或研发转产品）的产品经理往往在流程图会额外表达数据的流转关系。

但不论采用何种画法，他们的目的都是为了让PRD的受众理解产品使用的主线和分支。既然本文的核心在于“简练”，那么如何画出即简单但又满足需求评审要求的流程图呢？

下面分ToC和ToB两个场景来讨论：在ToC产品中，产品的使用对象往往为单一的个体，产品不涉及多个用户时，它的故事线和流程图往往比较简单，只需按照时间维度，按产品使用流程的主线来整理即可，同时在主线上注明不同分支。

下图就是一个很简单的例子: