产品经理三大文档

商业需求文档

Business Requirement Document

BRD和MRD，PRD一块儿被认为是从市场到产品须要创建的文档规范。

是产品生命周期中最先的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，一般是供决策层们讨论的演示文档，通常比较短小精炼，没有产品细节。是基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发以前，由企业高层做为决策评估的重要依据。

BRD与PRD的差别

BRD不一样于常见的MRD和PRD，既然是用于产品实施以前的决策评估依据，必然对其文档（报告）的内容和格式要求够直观、精炼，要点突出。做为报告的撰写者，你必须让高层明白，你的报告中将展示出怎样的商业价值，如何用有力的论据来讲服企业对你这个项目的承认，并为之慷慨的投入研发资源及市场费用。若是说PRD的好坏，直接决定了项目的质量水平，那么BRD的做用，就是决定了你的项目的商业价值。优秀的BRD文档，可让决策层充分被你的报告观点所吸引，或许财务主管会由于报告呈现的低投入高产出的经济效益预测而蠢蠢欲动；或许技术主管会由于项目的牵涉面普遍而头疼不已；又或许公司的VP之流因之报告而看到了将来一年业绩的飞速发展的广阔前景……

说白了，BRD须要产品经理（产品设计师）像对待PRD同样，充分应用市场调查、用户研究、需求分析等各类设计手段来充分阐述报告的内容。基于这样的情况，显然不是给你们一份完整的BRD标准格式规范，就可以搞定一切的！哈，也许有人会说这有点危言耸听，不过我一贯同意，面对一切“产品”，都应该用设计的眼光看待它。

市场需求文档

Market Requirement Document

该文档在产品项目过程当中属于“过程性”文档。

1文档做用

该文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其做用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。

2文档意义

该文档在产品项目中是一个“承上启下”的做用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工做的方向说明和工做指导。

3文档撰写

撰写MRD，大体下几个方面（按前后顺序）着手：

一、项目背景；

二、名词解释；

三、可行性分析（前期调研信息和数据+项目预期目标）；

四、综合描述（功能概述+对其余产品的影响）；

五、功能详述（功能需求+功能点）；

六、其余问题描述。

4文档核心

该文档中，侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并经过原型的形式加以形象化

5错误认识

1）根本没有MRD的思想，许多企业把产品经理归为技术端，所以，在现实中，许多产品经理的产品文档只是侧重于功能描述，而对基础性的市场缺少足够认识和记录；

2）把MRD和PRD混为一谈，MRD是PRD的基础，PRD是MRD在产品功能上的具体化。

3）照搬国外的MRD模板，来源于何处，不知道，将去向何处，也不知道，无头无尾，一个被割裂的文档。

产品需求文档

产品需求文档(Product Requirement Document，PRD)的英文简称。

是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。

 

文档意义

该文档在产品项目中是一个“承上启下”的做用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。

文档撰写

在该文档中，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求自己是在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

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

文档核心：

该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的一样内容，要更加详细，并进行量化。

在一些国外的公司，是容许把MRD和PRD合并成一个文档的，一般叫作“Marketing & Product Requirements Document”。

该文档通常能够包括如下内容：

该产品的远景目标（vision）

目标市场和客户（target market and customers）的描述

竞争对手分析（competitive summary）

对产品主要feature的比较详细的描述

这些feature的优先级

初步拟定的实现进度安排。

用例（use cases），这能够是较粗略的大体描述，未必必定要UML Use Case图。

产品的软硬件需求

产品的性能要求

销售方式上的思路、需求（直销仍是渠道？直销怎么作？渠道怎么作？）

技术支持方式上的思路、需求（提供什么样的技术服务？）

开发工具推荐 ：

Rational Rose★★★★－－熟悉项目发生的相关业务行为。

visio 2007★★★★－－将业务，从产品层面肢解开来，作到抽丝剥茧部分与总体统一

mind manager★★★－－把项目条目化，条理化，目录结构具体规定好。

Axure★★★－－前台结构布局，合理规范的将系统脱去朦胧的华纱。

Word★★★★★--穿针织网，把需求综合起来，整理成最终的产品需求文档。

错误认识

1）PRD无原始数据（MRD为体现载体）支持，只是我的经验、部门要求或者领导指示进行撰写。

2）在PRD中，只重视“产品功能”的描述，而缺少对产品其它指标项的说明。在一个完整的PRD中，一共须要对产品的10个产品需求项指标进行说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。

3）照搬国外的PRD模板，来源于何处，不知道，将去向何处，也不知道，无头无尾，一个被割裂的文档。

更多内容关注微信公众号：

--------------------------------------------------------------------------------------------------------------------------------------------------------