【产品经理】BRD、MRD、PRD究竟是什么？
BRD、MRD、PRD：别再傻傻分不清了，它们分别回答三个问题
每次新人入职，总有人问"BRD、MRD、PRD到底有什么区别？"网上资料一大堆，看完还是懵。我自己的理解方式特别简单——三份文档，分别回答三个问题：做不做？怎么做？做成啥样？搞清楚这三个问题，剩下的都是细节。这篇文章不搞理论堆砌，就把我自己怎么理解、怎么用这三份文档的逻辑讲清楚。
一、一句话搞懂三者关系
| 文档 | 回答的问题 | 类比 |
|---|---|---|
| BRD | 做不做？ | 开餐厅前写的商业计划书——能赚钱吗？投多少？ |
| MRD | 怎么做？ | 开餐厅前调研——卖给谁？竞争对手是谁？菜单怎么定？ |
| PRD | 做成啥样？ | 厨房操作手册——菜品原料、步骤、用量、摆盘标准 |
或者用原文档里那个更生动的比喻：MRD是规划一桌荤素搭配的菜，PRD是明确每道菜的原料、步骤、用量和营养标准。
三者的递进关系：
BRD（战略层：做不做）→ MRD（战术层：怎么做）→ PRD（执行层：做成啥样）BRD决定产品的商业价值，MRD承上启下验证可行性，PRD决定项目落地质量。中间那层MRD如果写烂了，战略意图就落不下去——产品做着做着就跑偏了。
二、核心区别一张表
很多人分不清这三份文档，本质上是因为没搞清楚它们的"受众"不同——给谁看，决定了写什么。
| 维度 | BRD | MRD | PRD |
|---|---|---|---|
| 给谁看 | 老板、CEO、管理层 | 商务、运营、市场 | 开发、测试、设计 |
| 核心目的 | 拿资源、批项目 | 统一方向、指导对外 | 落地开发、验收标准 |
| 关注什么 | 能赚多少钱、要投多少 | 用户是谁、市场多大、怎么赢 | 功能长什么样、怎么实现 |
| 核心内容 | 商业模式、盈利模式、财务计划 | 市场分析、用户画像、竞品分析 | 功能清单、流程图、用例表 |
| 写作风格 | 商业计划书，讲投资回报 | 市场调研报告，讲数据和策略 | 技术文档，精确无歧义 |
| 出现时间 | 立项前 | 项目启动时 | 研发启动前 |
一个关键洞察：管理层不关心按钮放左边还是右边，开发不关心商业模式多漂亮——每份文档的服务对象不同，写偏了就是废纸。
三、BRD：说服老板给你投钱
BRD的本质
BRD就是一份"商业计划书"——核心目的只有一个：说服管理层批资源、上项目。
老板看BRD，只关心三件事：
| 老板关心什么 | 对应内容 |
|---|---|
| 做什么产品？ | 产品介绍——一句话说清楚 |
| 要投多少？ | 团队规划、资源投入、时间周期 |
| 能赚多少？ | 商业模式、盈利模式、财务计划 |
BRD必须包含的板块
- 产品介绍：一句话定义产品定位
- 商业模式：怎么赚钱——广告？会员？电商？SaaS订阅？
- 市场分析：宏观行业趋势+微观市场现状
- 竞品分析：谁在做、我们凭什么赢
- 团队规划：需要什么人、花多少钱
- 产品路线图：分几个版本、大致时间节点（不需要太细，老板看个节奏就行）
- 财务计划：收入来源、收支平衡点、收益增长率
- 战略壁垒（加分项）：别人抄不了的护城河是什么
我的体会
BRD最难写的不是内容，是"分寸"。写太细，老板觉得你没想清楚大方向；写太粗，老板觉得你在画饼。核心技巧：用数据说话，用逻辑推演，用竞品对标。别说"这个市场很大"，要说"这个市场规模是XX亿，年增长率XX%，头部竞品市占率XX%，我们的切入点是XX"。
四、MRD：验证BRD不是在吹牛
MRD的本质
BRD说"这个市场很大、用户很多、能赚钱"——MRD的责任就是验证这些说法到底靠不靠谱。
BRD说目标用户是中小企业 → MRD要把用户画像画出来，说明是什么行业、多大规模、什么痛点
BRD说市场空间巨大 → MRD要拿出市场规模数据和增长趋势
BRD说竞品有弱点 → MRD要把竞品逐个拆解，指出具体差距在哪
MRD必须包含的板块
- 目标市场分析：市场规模、特征、增长趋势
- 目标用户分析：用户画像、使用场景、核心痛点
- 竞品分析：竞品战略、商业模式、功能体系、市场份额
- 产品需求概况：产品定位、核心目标、整体架构、迭代路线图
MRD的承上启下作用
| 向上 | 向下 |
|---|---|
| 验证BRD的商业假设 | 指导PRD的功能设计 |
| 把市场洞察对齐商业目标 | 用用户调研指导交互规划 |
| 确保产品既满足市场又创造商业价值 | 打造具备市场竞争力的产品 |
我的体会
MRD是最容易被忽略的文档。小团队直接跳过MRD写PRD，结果就是：开发做出来的功能，市场和销售根本用不上；或者产品上线后才发现用户根本不是你以为的那群人。
MRD的价值是"纠偏"——在投入研发资源之前，先把方向校准。方向错了，后面做得再精细也是白费。
五、PRD：让开发能照着做，让测试能照着验
PRD的本质
PRD是从"概念"到"图纸"的核心载体——它要精确到开发能照着写代码、测试能照着验功能。
PRD和MRD的关键差异
| MRD | PRD | |
|---|---|---|
| 侧重点 | 市场、用户、需求定义 | 流程、结构、功能、性能 |
| 配合展示 | 原型图（让概念形象化） | 完整用例表+流程图（让实现精确化） |
| 类比 | 菜单和菜品规划 | 原料、步骤、用量、营养标准 |
PRD必须包含的板块
- 文档基础信息：产品名称、版本历史、目录
- 文档介绍：编写目的、目标读者、术语解释
- 产品概述：项目背景、目标、竞品概况
- 产品需求清单：完整feature list
- 产品结构图：脑图形式的产品架构
- 全局功能说明：公共规则、UI规范、通用交互
- 详细功能说明：按模块拆分，搭配流程图+用例表
- 非功能性需求：性能、适配、运行环境、数据统计
- 关联文档：数据埋点文档等配套
- 上线需求：设计交付节点、测试节点、上线时间
用例表的标准格式
| 字段 | 说明 |
|---|---|
| 简要说明 | 这个功能做什么 |
| 行为者 | 谁来操作 |
| 前置条件 | 操作前必须满足什么 |
| 后置条件 | 操作后系统变成什么样 |
| 功能说明 | 具体的交互和逻辑 |
| 备注 | 异常场景、兜底规则 |
关键原则：PRD里禁止出现"大概""差不多""基本"这类词。每个描述必须精确无歧义——因为开发是照着你写的字来写代码的，你说"差不多"，他写出来的可能差很多。
同时，必须写异常场景和兜底规则（default）。正常流程谁都会写，但用户点错按钮、网络断开、数据为空这些情况如果没写，上线后就是BUG。
六、三份文档怎么联动？不是写完就完事
联动逻辑
BRD（确定做什么）→ MRD（验证怎么做）→ PRD（定义做成啥样） ↑ ↓ └──── 市场反馈反向校验商业目标 ────────┘三份文档不是"写完就锁进抽屉"，而是动态联动的：
| 联动动作 | 做什么 | 为什么 |
|---|---|---|
| 需求映射 | 用功能矩阵核对BRD目标→MRD需求→PRD功能的对应关系 | 避免需求脱节——BRD里说要赚钱的功能，PRD里没做 |
| 跨部门同步 | 定期组织各团队对齐文档内容 | 减少沟通偏差——开发的理解和老板的预期可能不一样 |
| 动态更新 | 市场/用户/需求变化时，三份文档同步迭代 | 保证文档和实际项目一致——过时的文档比没有文档更危险 |
我踩过的坑
最大的坑：PRD写完了，BRD里的商业目标已经变了，但没人同步更新PRD。结果开发做出来的东西，和公司现在的战略方向完全不匹配。
我的做法：每次需求评审会，先花5分钟过一遍BRD的核心目标，再讨论PRD的功能细节。这个习惯看起来浪费时间，实际上避免了大量返工。
七、别教条：按团队规模灵活用
| 团队规模 | 建议做法 | 理由 |
|---|---|---|
| 小团队（5人以下） | MRD合并到BRD | 人少分工简单，商业到市场论证周期短，单独写MRD是浪费时间 |
| 中型团队 | BRD + MRD + PRD完整输出 | 分工明确，三份文档各司其职 |
| 大厂 | FRD（MRD+PRD合一） | 腾讯/阿里的做法，MRD侧重需求定义+原型，PRD侧重流程功能+技术化 |
我的观点：文档的形式不重要，重要的是三个问题都被回答了——做不做？怎么做？做成啥样？小团队把MRD合并到BRD没问题，但如果BRD里既没有市场分析也没有用户画像，那就是在裸奔。
写在最后
BRD、MRD、PRD，说到底就是产品从"想法"到"上线"的三道关卡：
- BRD是"过会关"——说服老板这不是拍脑袋，有商业逻辑
- MRD是"校准关"——验证方向没跑偏，用户和市场真的需要
- PRD是"交付关"——让开发知道做什么，让测试知道验什么
三份文档的共同敌人是"模糊"。BRD模糊→项目方向不清；MRD模糊→做了没人用；PRD模糊→开发做出来不是你要的。
产品经理的核心能力之一，就是把模糊的想法变成清晰的文档。而清晰的前提是——你知道自己在回答什么问题，写给谁看。
记住这个对应关系就够了：
- 写给老板看 → BRD
- 写给市场看 → MRD
- 写给开发看 → PRD
搞混了受众，再漂亮的文档也是废话。