03 - 其他产品文档

前言

PRD 是产品经理最核心的文档，但不是唯一的文档。在真实的工作中，你还需要写（或至少要读懂）多种产品文档。它们各有侧重、各有受众，共同构成产品从"想法"到"上线"的完整文档体系。

本篇将介绍以下几种常见的产品文档：

BRD — 商业需求文档
MRD — 市场需求文档
竞品分析报告
产品路线图（Roadmap）
BRD / MRD / PRD 的关系与写作顺序

一、BRD（Business Requirements Document）— 商业需求文档

1.1 什么是 BRD？

BRD 是面向决策层的文档，核心目的是回答一个问题：

"这件事值不值得做？"

BRD 不关心具体的功能设计，不关心技术实现，它关心的是商业逻辑：市场有多大？用户痛点是什么？我们能赚多少钱？投入多少资源？

1.2 什么时候写 BRD？

  想法萌芽 --> 写 BRD --> 老板拍板决策 --> 继续推进（写MRD/PRD）
                              |
                              +--> 否决 --> 暂时搁置

BRD 是在项目立项之前写的，用于向管理层争取资源和支持。

1.3 BRD 给谁看？

受众	关注点
CEO / 总经理	战略方向、市场机会
CFO / 财务	投入产出比、财务预测
VP / 事业部负责人	资源分配、优先级
投资人	商业模式、增长潜力

1.4 BRD 的核心内容

章节	说明	关键问题
项目背景	为什么要做这个项目	市场发生了什么变化？
商业机会	市场有多大、增长趋势	TAM/SAM/SOM 分别是多少？
用户痛点	目标用户的核心问题	没有我们的产品，用户怎么解决？
解决方案概述	我们打算怎么做（高层级）	用一句话描述我们的方案
商业模式	怎么赚钱	收入来源、定价策略
竞争分析	竞品是谁、我们的优势	凭什么是我们来做？
财务预测	投入多少、预计多少回报	ROI 是多少？多久回本？
风险评估	可能的风险和应对方案	最坏的情况是什么？
资源需求	需要多少人、多少钱、多长时间	团队配置和预算
决策请求	需要管理层做什么决定	批准立项 / 批准预算

1.5 BRD 中常用的市场规模概念

+--------------------------------------------------+
|                                                  |
|  +--------------------------------------------+  |
|  |                TAM                         |  |
|  |  Total Addressable Market                  |  |
|  |  全部潜在市场规模                            |  |
|  |                                            |  |
|  |  +--------------------------------------+  |  |
|  |  |              SAM                     |  |  |
|  |  |  Serviceable Addressable Market      |  |  |
|  |  |  可服务的市场规模                      |  |  |
|  |  |                                      |  |  |
|  |  |  +--------------------------------+  |  |  |
|  |  |  |            SOM                 |  |  |  |
|  |  |  |  Serviceable Obtainable Market  |  |  |  |
|  |  |  |  可获得的市场规模                 |  |  |  |
|  |  |  +--------------------------------+  |  |  |
|  |  +--------------------------------------+  |  |
|  +--------------------------------------------+  |
|                                                  |
+--------------------------------------------------+

示例（在线教育）：
TAM = 中国在线教育市场 5000亿
SAM = K12 在线辅导市场 800亿
SOM = 我们第一年可触达的市场 5亿

1.6 BRD 写作要点

语言要通俗：老板不一定懂技术，要用商业语言
数据要有来源：市场数据标注出处（行业报告、调研数据）
结论要明确：不要模棱两可，明确告诉老板"建议做/不建议做"
篇幅要精炼：一般 5-10 页，老板没时间看长篇大论

二、MRD（Market Requirements Document）— 市场需求文档

2.1 什么是 MRD？

MRD 是连接商业决策和产品设计的桥梁文档。BRD 回答"值不值得做"， MRD 回答**"做给谁、怎么定位、大概做什么"**。

2.2 MRD 的定位

  BRD                    MRD                     PRD
  "值不值得做"    --->   "做给谁、做什么"   --->  "具体怎么做"
  商业视角               市场视角                 产品视角
  给老板看               给产品团队看              给研发团队看
  5-10 页                10-20 页                 20-50+ 页

2.3 MRD vs PRD 的区别

维度	MRD	PRD
核心问题	做什么产品？给谁用？	这个功能具体怎么设计？
抽象层级	高层级，不涉及具体交互	低层级，精确到按钮和文案
受众	产品团队、市场团队、管理层	研发、设计、测试
关注点	用户画像、市场定位、功能范围	功能细节、业务规则、异常处理
产出时间	立项后、PRD 之前	MRD 之后、开发之前
更新频率	较少更新	频繁更新
典型篇幅	10-20 页	20-50+ 页

2.4 MRD 的核心内容

章节	说明
市场分析	市场现状、趋势、规模、增速
目标用户	用户画像、用户分群、核心需求
用户场景	典型的使用场景描述（不是用户故事，更宏观）
产品定位	我们的产品在市场中的位置（对标谁、差异化在哪）
功能规划	功能列表（Feature List），不含具体设计，只列方向
竞品对比	主要竞品的优劣势分析
上市策略	GTM（Go-To-Market）策略，推广计划
成功标准	产品成功的衡量指标（比 BRD 中更细化）

2.5 用户画像模板

在 MRD 中，用户画像是核心内容之一：

+----------------------------------------------------------+
|                    用户画像 - 小王                          |
+----------------------------------------------------------+
|                                                          |
|  基本信息：                                               |
|  - 年龄：28 岁                                            |
|  - 性别：男                                               |
|  - 职业：互联网公司程序员                                   |
|  - 收入：月薪 20K                                         |
|  - 城市：北京                                              |
|                                                          |
|  行为特征：                                                |
|  - 每周网购 2-3 次                                         |
|  - 偏好手机端购物（占 80%）                                 |
|  - 习惯比价，会看多个平台                                   |
|  - 容易被限时折扣吸引                                       |
|                                                          |
|  痛点：                                                   |
|  - 想一次买多件，但没有购物车                                |
|  - 每次买东西都要重新填地址                                  |
|  - 看到喜欢的想先收藏，以后再买                              |
|                                                          |
|  期望：                                                   |
|  - 能把想买的东西先存起来                                    |
|  - 能一次性结算多件商品                                     |
|  - 能收到降价提醒                                          |
|                                                          |
+----------------------------------------------------------+

三、竞品分析报告

3.1 什么是竞品分析？

竞品分析是系统性地研究竞争对手的产品，以发现机会、找到差异化、辅助决策。

竞品分析不是简单地"我去看看别人怎么做的然后抄一下"，而是要有系统的方法论。

3.2 竞品分析的结构模板

+--------------------------------------------------+
|              竞品分析报告结构                        |
+--------------------------------------------------+
|                                                  |
|  1. 分析概要                                      |
|     - 分析目的、范围、方法                          |
|                                                  |
|  2. 竞品选择                                      |
|     - 直接竞品、间接竞品、替代方案                    |
|                                                  |
|  3. 竞品概览                                      |
|     - 各竞品的基本信息（公司、产品、定位）             |
|                                                  |
|  4. 功能对比                                      |
|     - 核心功能对比矩阵                              |
|                                                  |
|  5. 用户体验对比                                   |
|     - 交互设计、视觉设计、使用流程                    |
|                                                  |
|  6. 商业模式对比                                   |
|     - 盈利模式、定价策略                             |
|                                                  |
|  7. 优劣势总结                                    |
|     - SWOT 分析                                   |
|                                                  |
|  8. 结论与建议                                    |
|     - 我们应该怎么做                                |
|                                                  |
+--------------------------------------------------+

3.3 功能对比矩阵（示例）

以"购物车功能"做竞品分析为例：

功能点	我们的产品	竞品A（淘宝）	竞品B（京东）	竞品C（拼多多）
加入购物车	计划中	支持	支持	支持
修改数量	计划中	支持	支持	支持
批量删除	计划中	支持	支持	不支持
勾选结算	计划中	支持	支持	支持
库存提醒	P1	支持	支持	部分支持
价格变动提醒	P1	支持	支持	不支持
优惠券推荐	P2	支持	支持	支持
凑单工具	未规划	支持	不支持	支持
购物车分享	未规划	支持	不支持	不支持
心愿单/收藏	未规划	独立功能	独立功能	不支持

图例：支持 = 已上线 / 不支持 = 暂无此功能 / 部分支持 = 功能不完整

3.4 SWOT 分析模板

+---------------------------+---------------------------+
|        优势 (S)            |        劣势 (W)           |
|  Strengths                |  Weaknesses               |
+---------------------------+---------------------------+
|                           |                           |
|  - [我们产品的优势1]       |  - [我们产品的劣势1]       |
|  - [我们产品的优势2]       |  - [我们产品的劣势2]       |
|  - [我们产品的优势3]       |  - [我们产品的劣势3]       |
|                           |                           |
+---------------------------+---------------------------+
|        机会 (O)            |        威胁 (T)           |
|  Opportunities            |  Threats                  |
+---------------------------+---------------------------+
|                           |                           |
|  - [外部机会1]             |  - [外部威胁1]             |
|  - [外部机会2]             |  - [外部威胁2]             |
|  - [外部机会3]             |  - [外部威胁3]             |
|                           |                           |
+---------------------------+---------------------------+

填写示例（XX 商城购物车）：

维度	内容
S 优势	技术团队响应快；用户基数增长迅速；产品体量小，迭代灵活
W 劣势	功能落后于竞品；缺乏购物车相关运营经验；设计资源有限
O 机会	竞品购物车体验趋同，有差异化空间；社交电商兴起，可结合社交分享
T 威胁	竞品功能成熟、用户习惯已养成；巨头可能快速复制创新功能

3.5 竞品分析的常见方法

方法	说明	适用场景
产品体验	注册使用竞品，记录操作流程和体验	了解竞品的交互和功能
用户评价分析	看应用商店评论、社交媒体讨论	了解竞品的优缺点
数据监测	使用第三方工具（七麦、蝉大师等）	了解竞品的下载量、排名
行业报告	阅读券商研报、行业白皮书	了解市场格局和趋势
专家访谈	与行业资深人士交流	获取深度洞察

四、产品路线图（Roadmap）

4.1 什么是 Roadmap？

产品路线图是一份时间维度的产品规划，展示产品在未来一段时间内要做哪些事情、先后顺序是什么、预期目标是什么。

4.2 Roadmap 给谁看？

受众	Roadmap 的作用
管理层	了解产品战略方向，做资源分配决策
研发团队	了解接下来要做什么，提前做技术预研
市场/运营	配合产品节奏，规划推广和运营活动
客户/合作伙伴	了解产品发展方向，建立信心
PM 自己	梳理思路，确保产品方向清晰

4.3 Roadmap 的粒度

根据受众不同，Roadmap 有不同的粒度：

粒度	时间跨度	适用受众	详细程度
年度 Roadmap	1年	管理层、投资人	只标注大方向和里程碑
季度 Roadmap	1个季度	产品团队、研发团队	标注功能模块和预期目标
月度 Roadmap	1-2个月	研发团队	标注具体功能点和交付时间
Sprint Plan	1-2周	开发小组	精确到具体任务和责任人

4.4 Roadmap 示例 — 季度级别

XX 商城 2026 Q2 产品路线图
=====================================================================

     4月               5月               6月
  ---------         ---------         ---------

  [购物车基础功能]
  |===================|
  4/21 需求评审    5/26 全量上线

                   [购物车增强]
                   |================|
                   5/12 启动    6/15 上线
                   (优惠券、凑单)

  [搜索优化]
  |============|
  4/15 启动  5/10 上线

                                  [个性化推荐 V1]
                                  |==============...
                                  6/1 启动
                                  (Q3 继续)

  [支付体验优化]
  |======|
  4/5  4/25
  (微信支付优化)

                   [会员体系 V1]
                   |======================|
                   5/5 启动          6/30 上线

=====================================================================
  图例：|====| 表示项目周期       ...  表示跨季度继续
=====================================================================

4.5 Roadmap 示例 — 月度级别

XX 商城 2026年5月 月度 Roadmap
=====================================================================

  第1周(5/4-5/8)   第2周(5/11-5/15)  第3周(5/18-5/22)  第4周(5/25-5/29)
  ---------------  ----------------  ----------------  ----------------

  购物车功能
  |-- 开发中 ---|-- 测试 --|-- 灰度 --|-- 全量上线 --|
                           5/15内测   5/19灰度   5/26全量

  搜索优化
  |-- 测试 --|-- 上线 --|
             5/10全量

  会员体系V1
  |-- 需求评审 --|-- 设计 --|-- 开发启动 ------...
  5/5 评审                  5/18 开发

  购物车增强(优惠券)
               |-- 需求 --|-- 评审 --|-- 设计 ------...
               5/12 启动   5/15评审

=====================================================================

4.6 制作 Roadmap 的工具

工具	特点	适用场景
飞书多维表格	免费、协作好	国内团队日常使用
Notion Timeline	灵活、美观	小型团队
Jira Roadmap	与开发流程集成	使用 Jira 的团队
Productboard	专业的产品管理工具	中大型产品团队
Excel/Sheets	简单直接	任何团队
PPT/Keynote	展示效果好	向管理层汇报

4.7 Roadmap 的常见错误

错误	正确做法
把 Roadmap 当成固定的承诺	Roadmap 是计划，计划会根据情况调整
排得太满，没有 Buffer	留出 20-30% 的时间应对突发需求
只有功能，没有目标	每个 Roadmap 项要关联业务目标
所有事情都排在"下个季度"	做减法，聚焦最重要的 3-5 件事
不跟团队同步	定期（每周/每两周）review Roadmap

五、BRD / MRD / PRD 的关系与写作顺序

5.1 三者的关系

BRD、MRD、PRD 不是三份独立的文档，而是层层递进的关系：

  商业层面              市场层面              产品层面
  (Business)           (Market)             (Product)
                                          
  +--------+          +--------+          +--------+
  |  BRD   |  --->    |  MRD   |  --->    |  PRD   |
  +--------+          +--------+          +--------+
  |        |          |        |          |        |
  | 值不值 |          | 做给谁  |          | 怎么做 |
  | 得做？ |          | 做什么？|          | 细节   |
  |        |          |        |          |        |
  +--------+          +--------+          +--------+
      |                   |                   |
      v                   v                   v
   决策层              产品团队             研发团队
   投资人              市场团队             设计团队
                       运营团队             测试团队

5.2 写作顺序流程图

  +-------+     通过      +-------+    通过     +-------+
  |  BRD  | -----------> |  MRD  | --------->  |  PRD  |
  | 撰写  |              | 撰写  |             | 撰写  |
  +---+---+              +---+---+             +---+---+
      |                      |                     |
      v                      v                     v
  +---+---+              +---+---+             +---+---+
  | 管理层 |              | 产品  |             | 技术  |
  | 评审  |              | 评审  |             | 评审  |
  +---+---+              +---+---+             +---+---+
      |                      |                     |
    通过?                   通过?                  通过?
    / \                    / \                   / \
   是   否                是   否               是   否
   |    |                |    |               |    |
   v    v                v    v               v    v
  继续  修改/            继续  修改/           进入  修改/
  推进  搁置             推进  调整           开发  完善

5.3 三份文档的对比总结

维度	BRD	MRD	PRD
全称	Business Requirements Document	Market Requirements Document	Product Requirements Document
中文	商业需求文档	市场需求文档	产品需求文档
核心问题	值不值得做？	做给谁？做什么方向？	具体怎么做？
抽象层级	最高（战略层）	中等（策略层）	最低（执行层）
主要受众	CEO、CFO、投资人	产品团队、市场团队	研发、设计、QA
核心内容	商业机会、ROI、风险	用户画像、市场定位、功能范围	功能细节、交互、业务规则
篇幅	5-10 页	10-20 页	20-50+ 页
更新频率	很少更新	偶尔更新	经常更新
必要性	大项目必须，小需求可省略	新产品/新方向必须，迭代可省略	所有需求都需要
写作时间	项目最早期	立项后	开发前

5.4 实际工作中的简化

在实际工作中，并不是每个需求都要按 BRD -> MRD -> PRD 的完整流程走。根据项目大小和公司文化，可以灵活调整：

+--------------------------------------------------------------+
|                   不同场景下的文档组合                           |
+--------------------------------------------------------------+
|                                                              |
|  大型新产品/新业务线：                                          |
|  BRD --> MRD --> PRD（完整流程）                               |
|                                                              |
|  中型新功能：                                                  |
|  简版 BRD（背景+价值说明）--> PRD                              |
|                                                              |
|  小型迭代需求：                                                |
|  直接写 PRD（背景章节包含商业价值说明）                           |
|                                                              |
|  紧急 Bug 修复 / 体验优化：                                    |
|  简版 PRD 或 需求卡片（Jira/飞书工单）                          |
|                                                              |
+--------------------------------------------------------------+

给零基础转行者的建议：
如果你是初级 PM，日常接触最多的一定是 PRD。 BRD 和 MRD 更多是高级 PM 或产品总监来写。但你需要能读懂它们，因为你写的 PRD 要和公司的 BRD/MRD 保持一致。

六、其他可能遇到的文档

除了上面讲的几种主要文档，你在工作中可能还会接触以下文档：

文档类型	说明	谁来写
技术方案文档	描述技术实现方案，PM 需要 review 关键点	工程师
测试用例	基于 PRD 编写的测试场景和步骤	QA
上线 Checklist	上线前的检查清单	PM + 工程师
复盘报告	项目上线后的效果评估和经验总结	PM
FAQ 文档	功能相关的常见问题解答	PM + 客服
用户手册	面向用户的功能使用说明	PM + 技术写作
数据分析报告	功能上线后的数据表现分析	PM + 数据分析师

七、文档管理的最佳实践

7.1 文档命名规范

推荐格式：[项目名]-[文档类型]-[版本号]

示例：
  购物车-PRD-v1.0.md
  购物车-竞品分析-v1.0.md
  XX商城-BRD-v2.0.md
  2026Q2-产品路线图-v1.0.md

7.2 文档存储建议

/产品文档
  /BRD
    XX商城-BRD-v1.0.md
  /MRD
    XX商城-MRD-v1.0.md
  /PRD
    /2026-Q2
      购物车-PRD-v1.0.md
      搜索优化-PRD-v1.0.md
    /2026-Q1
      ...
  /竞品分析
    购物车竞品分析-202604.md
  /Roadmap
    2026Q2-Roadmap-v1.0.md
  /复盘
    购物车上线复盘-20260530.md
  /模板
    PRD模板.md
    竞品分析模板.md

7.3 文档协作原则

原则	说明
单一来源	同一份文档只在一个平台维护，避免多处不同步
及时更新	需求变更后 24 小时内更新文档
版本可追溯	保留修改记录，能看到每次改了什么
权限管控	正式评审通过的 PRD 设为"只读"，修改需走变更流程
定期归档	已上线的项目文档定期归档，保持文档库整洁

本篇小结

+--------------------------------------------------------------+
|                      本篇核心要点                               |
+--------------------------------------------------------------+
|                                                              |
|  1. BRD 面向决策层，回答"值不值得做"                             |
|  2. MRD 面向产品和市场团队，回答"做给谁、做什么方向"              |
|  3. PRD 面向研发团队，回答"具体怎么做"                           |
|  4. 三者是层层递进的关系：BRD -> MRD -> PRD                     |
|  5. 竞品分析要有系统方法论，不是"看看别人怎么做然后抄"             |
|  6. Roadmap 是时间维度的产品规划，粒度按受众调整                  |
|  7. 实际工作中可以根据项目大小灵活裁剪文档组合                     |
|  8. 文档管理：命名规范、集中存储、及时更新、版本追溯               |
|                                                              |
+--------------------------------------------------------------+

上一篇: 02 - 完整 PRD 模板 + 范例
返回目录: 模块概览

03 - 其他产品文档 ​

前言 ​

一、BRD（Business Requirements Document）— 商业需求文档 ​

1.1 什么是 BRD？ ​

1.2 什么时候写 BRD？ ​

1.3 BRD 给谁看？ ​

1.4 BRD 的核心内容 ​

1.5 BRD 中常用的市场规模概念 ​

1.6 BRD 写作要点 ​

二、MRD（Market Requirements Document）— 市场需求文档 ​

2.1 什么是 MRD？ ​

2.2 MRD 的定位 ​

2.3 MRD vs PRD 的区别 ​

2.4 MRD 的核心内容 ​

2.5 用户画像模板 ​

三、竞品分析报告 ​

3.1 什么是竞品分析？ ​

3.2 竞品分析的结构模板 ​

3.3 功能对比矩阵（示例） ​

3.4 SWOT 分析模板 ​

3.5 竞品分析的常见方法 ​

四、产品路线图（Roadmap） ​

4.1 什么是 Roadmap？ ​

4.2 Roadmap 给谁看？ ​

4.3 Roadmap 的粒度 ​

4.4 Roadmap 示例 — 季度级别 ​

4.5 Roadmap 示例 — 月度级别 ​

4.6 制作 Roadmap 的工具 ​

4.7 Roadmap 的常见错误 ​

五、BRD / MRD / PRD 的关系与写作顺序 ​

5.1 三者的关系 ​

5.2 写作顺序流程图 ​

5.3 三份文档的对比总结 ​

5.4 实际工作中的简化 ​

六、其他可能遇到的文档 ​

七、文档管理的最佳实践 ​

7.1 文档命名规范 ​

7.2 文档存储建议 ​

7.3 文档协作原则 ​

本篇小结 ​