下载掌阅APP，畅读海量书库
立即打开
BRD、MRD、PRD这三个文档是产品从市场调研到产品研发之间产生的重要文档，属于产品生命周期前期的规范性文档，同时也是商业调研、市场调研、需求输出这三个阶段的输出物。虽然这三个文档的侧重内容不同，但核心做的都是一件事——“想明白”。
BRD、MRD、PRD模板详见本书附录一、附录二、附录三。
BRD的受众主要是老板、财务、产品、运营等管理层人员，目的是为公司的决策者们提供“是否可以做这个产品”的决策依据，其可以被抽象为“各位老板，我有一个好主意……”。例如，产品经理或者公司规划要做600kg级的AMR，一旦立项，后续就需要投入高昂的成本。因此，公司需要有足够的“值得做”的理由来支撑这一活动。BRD要从商业模式、市场分析、产品路线图、成本等方面阐述产品的商业价值，论证600kg级的AMR是“值得做的产品”。
BRD面对的是能够决定对产品投入研发资源的决策者，所以常常会以PPT的形式展示。BRD输出的频率不高，一方面BRD主要针对全新的、市场潜力大的新产品，另一方面许多公司往往从MRD甚至PRD开启产品的生命周期，对BRD缺乏重视。当然，国内企业习惯于把BRD和MRD合并起来，集中在MRD上阐述BRD的内容；许多产品也是以老板为首的管理层指定要做的，因此可以跳过BRD这一环节（当然，这也是“老板是公司最大的产品经理”的体现）。
MRD的受众是产品工程师、运营工程师、研发工程师等项目组人员，目的是解决项目组成员“不知道要做什么样的产品”的问题，其可以被抽象为“兄弟们，我们要做这样一款AMR，它的用户群体是×，它具有××的功能，竞品在×××方面有值得学习的地方，我们打算融合××××的技术，计划从×××××时间开始做……”
MRD是对BRD商业意图的进一步细化，其由产品概念具化为目标用户市场、产品功能组成、研发资源分布、产品运营等具备可执行性的步骤或规划。MRD可能承接的是BRD，也可能是已有产品的迭代（可以不需要BRD）。
PRD的受众是项目经理，以及研发工程师、测试工程师、运营工程师等人员，目的是让项目经理可以划分任务包；研发负责人能依据PRD拆分功能；研发人员能依据PRD获取具体的实现目标；测试人员能依据PRD撰写测试用例等。PRD的目的可以被抽象为“兄弟们，我们要做的AMR，它载重600kg，使用SLAM激光雷达，长宽为xcm×ycm，可在线清错，满足OTA升级需求……”
PRD就是BRD、MRD产品概念的图纸化、参数化产出物，讲的是这个产品“是什么”，它的“血肉、骨骼、器官”是什么样子。PRD让产品从抽象的概念落地为非常详细的产品技术指标，使项目组内各个协作单元都能根据PRD找到自己对应的具体任务目标。可以说PRD的详细程度和准确度直接影响着研发项目的可控性及产品最终落地的质量。
PRD在定稿之前一般会经历两个重要的节点：需求评审、需求确认。这两个过程节点保证了PRD的准确性、使项目组成员完全理解PRD需求，缺一不可，否则项目进行过程中“是驴是马，是芝麻还是烂谷子”的事情就有得纠缠了。
PRD评审是项目组内成员关于产品信息的同步和确认过程，其目的是让所有项目组成员集中进行充分的沟通讨论，因此，产品经理要对PRD中的每一项功能、每一个技术指标、每一个参数要求进行有理有据的介绍并让所有成员理解文档中的需求，确保后续执行中不会有因需求理解偏差导致扯皮的情况出现。比如，AMR进坞充电时相关的灯光语音策略及其依据（此处为简化处理，非真实内容，实际上灯光的颜色、频率，语音的播报内容、播报周期等都需要详细的定义）如表2-1所示。
表2-1 AMR进坞充电时的灯光语音策略及其依据
PRD评审时，产品经理要清楚不同职能的项目组成员需要关注的重点，并在会上得到需求传达完整的确认反馈。另外，哪些风险点是需要提前说明的，哪些需求点是不容易理解的？都要重点解释清楚。简单的PRD需求有时可以被一次性通过，而复杂的PRD评审则往往需要多次的评审确认才能通过。
PRD需求评审是产品经理向项目组成员详细讲解PRD需求，对齐产品具体实现要求的过程，而PRD需求确认则是负责实现相关需求任务的项目组成员（主导者或具体实现者）向产品经理及其他项目组成员描述自己对PRD需求的理解，与相关职能角色相互印证，防止对需求出现理解偏差的过程。
PRD需求评审和PRD需求确认从一正一反两个角度的评审策略实现了PRD需求充分沟通的信息闭环，能有效减少项目研发过程中发生需求纠偏的可能性。但实际情况却是许多公司往往只关注PRD评审，而鲜有关注PRD需求确认环节。另外，PRD需求评审和PRD需求确认环节中，完整无误的需求对齐只是理想状态，实际几乎无法实现，因此，只能通过合理有效的手段去减少理解偏差而无法完全避免其出现。事实上，需求的沟通可能会持续贯穿整个项目周期。