一图了解产品经理的四大文档

商业需求文档重点放在定义项目的商业需求。

解决什么问题、满足什么用户需要

背景、市场空间、竞争对手、环境

产品规划、模块规划、研发计划、运营计划？

人力成本、软硬件成本、运营成本？

带来收入、带来用户、扩大市场、占有市场先机、满足未来三年战略规划等？

做这个有没有风险（开发失败？失去市场机会？失去先机？竞争不过对手？没有带来收入？没有带来用户？与公司战略背道而驰？）？做这个有没有风险（开发失败？失去市场机会？失去先机？竞争不过对手？没有带来收入？没有带来用户？与公司战略背道而驰？）？

Business Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。

BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。接着建议一个方案 —— 通常是新产品或者现有产品的改进来解决这些问题。BRD也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/营销策略。BRD通常是由拥有 产品经理，产品营销经理或者行业分析师头衔的人撰写的。在小公司，可能由高级主管或者甚至创始人撰写。BRD通常是一份连续的1-3页Word文档，或者 不超过10页的Powerpoint文档。

BRD（商业需求文档）

市场说明：目标市场、市场规模、特征、未来3~5年的发展趋势，现在市场存在的问题和机会。

用户说明：目标客群共性分析，常用用户特征，用户画像建立虚拟用户角色。从技术层面剖析市场，洞察用户心理案例分析（动机和目标是不一致的）影响用户使用的主要因素。

产品定位：我们用什么样的产品满足用户或时长，针对什么用户，做什么事。

产品价值:解决目标时长、用户的核心需求（划分有限就）。

产品架构：产品核心目标、时长定位、产品定位的直接体现。

产品路线图：以时间为节点，任务为导向。

产品功能性需求：功能介绍。

非功能性需求：有效性、性能、扩展性、安全性、健壮性、兼容性、可用性、用户体验。非功能性需求：有效性、性能、扩展性、安全性、健壮性、兼容性、可用性、用户体验。

Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。

市场需求文档（MRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。它包括一些或者所有这些细节：            a. 解决商业问题所需要的特色            b. 市场竞争分析            c. 功能和非功能需求            d. 特色/需求的优先级            e. 用例  MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长。

MRD（市场需求文档））

产品结构图、线框图、产品功能列表。

消灭错误：逻辑清晰、消灭错别字、理解到位。

不提技术性的东西，术业有专攻。

需求明确：不可出现含糊不清的内容，如也许、可能。文档内容是确切的，可被执行的。

沟通：写文档时不要忘记和团队沟通。

Product Requirements Document，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大 块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有 UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

产品需求文档（PRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要角度看需求的不同，PRD侧重于从产 品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和用户界面流程。在那些MRD不包括具体需求和用例的机构中，PRD就包含 这些具体内容。PRD通常是由拥有产品经理，行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的20-50页Word文档，或者针对复杂产 品甚至更长。  提醒：一些机构将这里描述的MRD和PRD合并成一个文档，并称最后的文档为MRD。在这种情况下，MRD包括本段描述的内容，也包括上一段描述PRD的内容，并且可能超过50页。

PRD（产品需求文档）

功能简介，来源、背景，能够解决哪些问题。

场景描述：用户场景模拟。

业务规则：业务规则必须完整、准确、易懂。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见、不可见、灰掉或点亮的条件在文档中都给出说明，方便阅读者理解业务规则。

界面原型：交互设计原型，产品设计框架、场景。

使用者说明

前置条件：例如上传照片，需要有照片。

后置条件：操作引发的后续处理。

主流程：每个功能流程走向分点说明。

Functional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。  功能规格文档（FSD）把焦点集中在实现，定义产品功能需求的全部细节。FSD可能通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接 让工程师创建产品的文档。与MRD和PRD侧重于以市场需要和产品角度看需求不同，FSD把重点放在了以表格形式定义产品细节，再让工程师实现这些细节。 FSD也可能包括完整的屏幕截图和UI设计细节。FSD通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 – 作者通常属于工程部门。通常一个连续几十页的Word或类似文档。

FSD（功能规格文档）

顺序：BRD》MRD》PRD》FSD

一图了解产品经理的四大文档