产品经理如何写出一份“简练”的PRD.docVIP

产品经理如何写出一份“简练”的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面前是要和部门内其他组的需求抢排期。 所以建议“简练”版的需求背景要包括以下两点： 需求产生的原因：可以是发