3D文档：
一般来说，BRD作为战略方向的制定，是最早产出的文档，而MRD则是在战略方向的基础上对市场进行的分析，同时对后续工作的方向进行一些说明和指导，也可以说是通过对市场环境、竞品的分析，明确用户定位和产品定位的过程，PRD则是在战略方向、工作方向已经很明确的情况下，所产出的关于产品具体怎么设计的文档。
由此可见，这三份文档是一个从抽象到具体的过程，从想法到实际落地的过程。
BRD商业需求文档：
BRD(Business Requirement Document)是商业需求文档简称，指的是基于商业目标或价值描述产品需求的文档。
BRD是产品生命周期中最早产出的文档，通常是供决策层讨论的演示文档，一般比较短小精悍，没有产品细节。对不同的企业，BRD的决策层不同。
产品经理在日常产品管理过程中，通过一系列的市场分析或调查，掌握了一个潜在的、未被满足的大量用户需求，而这些需求背后映射了一个广阔的市场空间。
BRD文档的作用：
BRD说白了就是给老板和投资人看的，是为了拉融资或让老板同意某个项目的。
要确定商业需求文档的内容，就要先理解商业文档的用途。商业需求文档应该回答以下问题:
是什么：即做的什么产品，解决了用户的哪些诉求。为什么：提出商业背景、竞品分析、市场机会。如何做：对产品进行规划。需要什么资源：列举项目中需要支持的资源。能得到什么：列举商业收益，如用户、资金、流量等。投入产出比：列举目前的风险、能力与资源。综上所述，商业需求文档核心的用途就是在产品投入研发之前，作为企业高层决策评估的重要依据。因此商业需求文档的内容和格式要求直观、精炼、要点突出，必须让高层明白产品将展现出怎样的商业价值，用有力的论据来说服企业高层认可这个项目，并为之投入研发资源及市场费用。
BRD文档的汇报对象：
资本型决策者：
以CFO(首席财务官)、财务总监等为主。因为对财务来说，最好的方式就是只有利润没有成本。在BRD中，要专门针对这一方面做一份详细的报告。通常而言，做一个互联网项目，主要的投入在于人力成本运营或营销成本、时间成本、软硬件成本和环境成本。如果只给出成本计划，财务型决策者肯定不会马上同意，一定要明确给出收益预测。而有时候项目关注的不是短期效益，更多的项目在初期通常不大可能获得较高效益，这就需要在报告中体现出长远的效益预测。
市场型决策者：
以市场总监、运营总监等为主。市场型决策者最关注以下几个方面:
- 有没有成熟的推广渠道。有成熟的推广渠道，营销工作就容易开展。如果没有，项目难度就会大增，甚至有可能根本无法落实。
- 有没有竞争对手，外部环境如何。外部环境通常指行业环境、市场环境和政策环境。越成熟的市场环境，对新兴项目越不利;而越紧缩的政策环境，也对项目越不利。
- 有没有营销资源，市场占有情况如何。市场占有情况就是要看产品有多大的市场份额。
- 市场空间有多大。市场空间和市场占有情况相似。
研发型决策者：
也叫技术支持型决策者，以首席技术官为主。大多数产品经理并不具备很强的技术研发功底。在BRD中，研发部分可尽量简化表达，目的只有一个，让研发型决策者充分理解该项目的主要功能模块是什么类型即可。
战略型决策者：
主要是董事长、CEO(首席执行官)、COO(首席运营官)或直属副总裁。公司的VP或COO通常不特别注重短期效益，也不仅关注单一的经济效益，还关注是否是潜在市场或新兴市场，是否有长期投资的价值，未来的趋势是否很好，风险是什么，等等。
BRD文档的内容：
商业需求文档中通常包含基本信息（如文档状态、当前版本、作者等）和内容信息。为了方便查看，通常会生成一个目录，且以PPT的方式呈现。
1. 项目背景
在项目背景部分应说明以下问题:
- 行业现状。说明项目提案的原因，概述本行业的现状及问题。
- 用户需求。列出用户需求以及如何满足这些用户需求，说明这些用户的特征是什么，以及满足了用户需求会有什么样的客户价值。
- 行业市场规模。阐述国内外本行业的市场状况，如市场规模、发展趋势、环境变化等。
- 行业盈利模式。简要叙述本行业的产品依靠什么手段盈利。
- 竞争格局。简要说明市场上是否有同类或相似的竞争对手。若有，那么这些竞争对手的优势和市场占有状况如何。
2. 核心需求
本部分要阐述产品的核心需求。产品的核心需求是指用户真正要获得的利益，即产品的使用价值、商业模式、发展方向等
3. 收益、成本和风险
在本部分 要说明以下问题：
- 项目收益预估。阐述项目可以带来的收益。
- 项目成本估算。简要说明项目实施所需要的人力和财力，汇总为项目成本估算表。
- 项目风险与对策。阐述项目的内部风险和外部风险以及应对的策略。
MRD市场需求文档：
MRD全称Market Requirement Document，中文名
市场需求文档，顾名思义，MRD要承载一些市场目的的文档，MRD是对市场分析及后续工作方向进行指导的文档。
- 通俗的说，就是让对应的决策人员在查看了MRD以后，能够清晰明确目前行业的市场环境，并且能够明确出我们自己的用户定位和产品定位
MRD文档的汇报对象：
CEO(老板)
这个时候其实老板已经不一定要全程参与了，但有一些相对比较小的公司或者老板管的比较细的公司，依然还是会关注到MRD的相关内容。
市场总监
此时一般来说便是负责市场的相关领导，其实是对市场有着和产品经理不同角度的了解，所以将MRD让市场的负责人查看并提出相关意见也是会比较常见的情形。
产品总监&产品经理
很多情况下，MRD会由产品总监来撰写，但也不排除有时候产品总监会把这种活交给手底下的产品经理去做，产品总监只是负责后续的审阅工作，所以撰写完成后，给产品同事查看提出意见然后给总监去审阅是比较合适的流程。
MRD的撰写目的以及内容：
- 基本信息：公司名称、产品名称、文档创建时间、创建人、版本记录
- 目标市场的现状如何?
- 目标市场的趋势如何?
- 目标市场的竞品情况?
- 我们在目标市场中的优势、劣势、机会、威胁?
- 目标用户是哪些?
所以，MRD主要就是为了解答以上的问题而存在的，在文档当中至少应该具备以下两大要素：
市场环境分析、用户分析
PRD产品需求文档：
PRD全称Product Requirement Document，中文名
产品需求文档，是对产品需求以实际可落地方式进行细化描述的文档。这里面有个关键词实际可落地，也就意味着通过查看PRD能够大致知道需求会最终以什么样的实际形态或方式被呈现出来，而不是说看完了PRD以后，依然不知道需求会被做成什么样或者说感觉需求还只是停留在一种概念性的层面。到了写PRD就标志着项目从概念化进入图纸化。
PRD文档的作用：
协助项目组成员完后项目开发，就是通过文字和图形等内容来表达产品经理对产品的需求，并传达给开发和设计人员，并在上线后将这些需求呈现在用户面前。一份PRD文档，核心部分是页面原型以及对原型的交互说明。光有原型还不够，因为原型只能传递可视化的需求，而更多的需求和逻辑则是非可视化的，因此需要附加交互说明。
PRD的查看对象：
- 产品同事
- 运营
- 设计师
- 开发工程师
- 测试
- 其他需求方(相关业务部门等)
交互说明怎么写：
交互说明是页面规则的描述，从两个维度展开：数据和操作。
对一个页面而言，给用户的体验就是两件事：
能看到什么?能做什么?前者称为数据，后者称为操作。因此，交互说明就是要描述出一个页面有哪些数据，即数据规则，能做什么操作，即操作规则。
数据规则：
数据，什么是数据?在数据规则里，汉字、数字、字母、字符、图片、视频、音频、这些都是数据。在交互说明里，对数据规则的描述要包含以下几点：
- 数据怎么来的?是后台上传，用户行为还是前台写死的数据?
- 数据的显示有什么限制?比如字符长度、显示尺寸、行数等限制。
- 数据在不同状态下的显示有什么区别?比如登陆和非登陆的状态、会员和非会员的状态、可用和不可用的状态、互斥状态、不同网络条件等
- 数据是否存在为空的情况?如果是，为空怎么显示?比如头像，如果用户没有上传头像，该怎么显示?
操作规则：
操作，什么是操作?在操作规则里，要说明用户在页面能做什么，操作反馈如何。操作+反馈才是完整的交互规则。在交互说明里，对操作规则的描述要包含以下几点：
- 用户能做什么操作?比如输入、点击、滑动等。
- 操作后有什么反馈?比如跳转新页面、弹框、toast、面板切换、动画效果等。
- 不同状态下的操作有什么限制?比如登陆和非登陆的状态、会员和非会员的状态、可用和不可用的状态、互斥状态、不同网络条件等。
- 不同状态下的操作反馈有区别吗?具体有什么区别?
PRD的文档结构：
