BRD：Business Requirements Document，商业需求文档。

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

好的BRD应有的特点：商业价值、资源评估、风险和对策三大块是一个BRD最重要的三部分。好的BRD应当有煽动性、导向性。在写BRD时应当充分考虑阅读人（通常是老板）的出身背景、知识结构及思考问题的一般方法，考虑到他在看了BRD后会有什么反应，他是怎样考虑的，而不是仅仅是将要表达的结果做一个简单的信息传递，应当做到未雨绸缪。通常要做到这种程度，需要很深刻的了解公司的高端愿望，在企业里做到信息对称，高端愿望解码正确。当然，如果写BRD的人在公司对老板的影响力非常大，也会对BRD增色不少。

BRD文档通常包括：项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策。

项目背景：我们在哪里？为什么要做这个项目？解决什么问题？可以列出一些数据说明项目的必要性。
商业价值：我们去哪里？最关键的重点！做了这个项目以后有什么价值？一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打包好的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会高点技巧性的东西，比如要砍掉的需求，俗称李代桃僵。
非功能需求描述：提一下重要的非功能需求。
资源评估：达成项目的目标需要多大的花费。
风险和对策：项目中可能存在的风险及应对策略。

BRD技巧：通过一系列的市场分析或调查，掌握到了一个潜在的、未被满足的大量用户需求，而这些需求背后将映射着一个广阔的市场空间。说明这个项目很有价值（社会价值——造福全人类？；商业价值——未来的赢收主体？；用户价值——引领用户潮流？比如说Iphone；市场价值——也许明年我们的市场份额就会扩大一倍；投资价值——我们将全面进入一个新兴的领域）。写BRD，不应该站在自已的角度来写这份报告，充分了解决策层，也就充分把握到了报告编写的要点。站在评审方的角度来写报告，你的报告成功的可能性就已经占了很大一部分了。

BRD实例：

让我们假设你的公司正在开发一个用户关系管理系统（CRM）。这个系统是协助其他公司的销售经理如何跟进产品销售过程，并分析得出关于销售的靠谱的预期的。那在这种情况下我们的BRD应该怎写呢：

A. 谁会面对这些问题？——世界五百强的销售经理。

B. 他们面对的时什么问题？——1.无法实时的查看交易进行状态；2.无法分析出一个可信赖的销售预期。

C. 建议的解决方案是什么？——创建一个基于页面的系统，能够查看实时交易进行状态，并分析出一个可信赖的销售预期。

BRD与PRD的差异

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

说白了，BRD需要产品经理（产品设计师）像对待PRD一样，充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。基于这样的状况，显然不是给大家一份完整的BRD标准格式规范，就能够搞定一切的！哈，也许有人会说这有点危言耸听，不过我一向赞成，面对一切“产品”，都应该用设计的眼光看待它。你应该把决策层当作你的产品——BRD的受众群体，一切从这里开始。

MRD：Market Requirements Document，市场需求文档。该文档在产品项目过程中属于“过程性”文档。

该文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。

MRD要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。

MRD就是对产品所在市场数据的整合，说白了，就是对市场分析后的结论体现，在这个文档中，需要体现的主要内容包括：

1、市场的问题和机会

在这个主题中，主要是要求产品管理者说明自己负责的产品现在所处的市场都有什么问题和机会、面对这个现实的市场，产品有什么问题和机会，以及产品所需技术面临的问题和机会。其实就是要求从市场层面、产品层面、技术层面来阐述问题和机会。

2、市场特征

在这个主题中，主要是要求产品管理者说明目标市场的现状和趋势。应该包括的信息有：目标市场特征、目标市场趋势、目标市场细分、目标市场时间约束。

3、用户特征

这里的用户是个广义的概念，它其实包括两个方面的信息：1、客户（customer）；2；购买者（buyer）。在这个主题中，主要是要说明这产品的目标用户的特征、细分、动机、影响因素以及用户期望（目标）。

4、使用者特征

之所以把这个主题独立出来，就是因为，无论什么产品，最终是要由具体的人来介入的，这类人才是产品的最终享受者，具体到产品上，其实我们日常分析的产品需求和功能都是基于他们考虑的。在这个主题中，要说明这类用户的特征、现实需要和相关联系。

5、市场的需求

就是把市场需求按类别描述出来即可，具体的标准，大家应该很清楚的，就是“描述性的语言来说明用户的期望”，主要包括的内容有：功能分类、开发环境说明、兼容性说明、性能说明、国际性说明、文档说明、外观说明、发布说明、支持和培训说明、其它说明、方案概述、技术概述。建议大家加一个表格，就是“需求概要表”，这个表格的作用就是用列举的形式来把所有市场需求记录下来，毕竟上面的内容都是描述性的，这个表格有助于快速浏览。这个表格应该包括的内容有但不仅限于：实现目标、约束条件、需求联系、原型、类型、优先级。

MRD主要用处是定义市场需求，可能是针对一个新产品也可能是旧有产品的一个增强型的功能，BRD是对于商业问题和解决问题的方法的简要定义，而MRD则更加的细节，他可能包括以下几点：

a. 解决这个商业问题的功能需求；
b. 市场和竞争对手分析；
c. 功能与非功能需求；（所谓非功能需求包括性能要求等）
d. 功能需求的优先级；
e. 需求用例。

MRD实例：

紧接着上面那个CRM的例子继续，MRD会定义需求，对需求进行优先级排序，同时描述需求用例。需求主要包括功能需求和非功能需求两种：

A. 功能需求：

必须能够在IE（6.0版本以上）和FireFox（1.5版本以上）上工作；
必须使用SSL协议保证通信能够被加密；
用户能通过交互界面输入以下字段的内容：用户名称、公司名称、联系方式、机会说明、销售额度等等。
…

B.非功能需求：

能够承担十万同时在线用户；
系统稳定性达到99.9%；
拥有英、德、日三种语言的用户使用说明。
…

PRD：Product Requirements Document，产品需求文档。

PRD是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。

PRD文档，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身是在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing & Product Requirements Document”。

产品需求文档侧重于产品需求的具体阐述，是BRD的延伸。如果说BRD可以决定要不要做以及做什么的话，那么PRD就解决怎么做的问题。商业需求文档侧重性价比的描述，产品需求文档侧重产品功能规划及实施，即想方设法实现BRD中提到的价值并使之最大化。该文档的内容主要包括产品定位、目标人群界定、用于满足用户哪些核心需求或解决哪些问题、同行竞品分析、差异化竞争优势、推广运营策略、盈利模式分析以及详细的产品功能规划（如业务逻辑、权限分配、功能模块设置、参数规格等）、产品实施路线图、非功能性需求（如界面UI风格、安全性、易用性、兼容性、性能等需求）。通过该文档，读者对整个产品有个全面清晰的了解。

产品需求文档和产品战略文档（Product Strategy）、产品发展路线文档（Roadmap）的区别：产品战略描绘出2-5年产品的发展方向和蓝图而产品发展路线文档描绘出不同的阶段到达这个目标；产品需求文档则是在这个蓝图中某一个阶段的详细需求产品。

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

PRD文档一般可以包括以下内容：

该产品的远景目标（vision）
目标市场和客户（target market and customers）的描述
竞争对手分析（competitive summary）
对产品主要feature的比较详细的描述
这些feature的优先级
初步拟定的实现进度安排
用例（use cases），这可以是较粗略的大致描述，未必一定要UML Use Case图。
产品的软硬件需求
产品的性能要求
销售方式上的思路、需求（直销还是渠道？直销怎么做？渠道怎么做？）
技术支持方式上的思路、需求（提供什么样的技术服务？）

在一个完整的PRD中，最好对产品的10个产品需求项指标进行说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。

MRD往往从市场需求角度描述产品的需求，而PRD更加关注产品本身的需求，会详细描述各种特性与功能的细节，PRD中还常常包括用户界面和用户流程。如果一家公司的MRD不包括各种特性与功能的细节需求和用户需求用例的话，这些内容就会由PRD来描述。

PRD实例：

继续上面的CRM项目，在这个项目中PRD文档应该包括的内容是：

登录界面应包括用户名、密码字段，还应该有“忘记密码？”提示文字链；
“联系我们”界面应该让用户可以输入姓名、电话、Email…
“销售预测”界面在生成年度预测报告前，应该有5个步骤，每个步骤用户都会输入一些限定条件，每个步骤的详细说明如下：
…

PRD文档除了上面描述的这些功能逻辑外，还应该包括一些详细的需求用例。

FSD：Functional Specifications Document，功能详细说明文档。

FSD这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。功能详细说明文档从具体执行的角度定义产品的功能需求，FSD会对每一个界面和功能做出非常细节的定义说明，并能够直接交付技术人员进行开发。我们再来对比一下MRD、PRD还有FSD的不同，MRD是关注于市场需求的需求定义，PRD是关注于产品本身的需求定义，而FSD是关注于定义功能的细节设计，这个设计会以技术人员熟悉的格式撰写，并直接交付技术人员进行开发，FSD还包括确定的UI设计，界面各个部分细节都已经被确定。这篇文档通常由产品分析师、技术负责人或者项目经理来撰写，总之这个文档的作者一般都隶属于技术团队。这篇文档一般是无数页的word或者其他的文本文件格式文档。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。

注：Pivot 是“转轴”，“轴心”的意思，也就是一个机械构造赖以旋转的基础，是一个平常很少用的单字。但是 Pivot 变成了形容词 “pivotal” 之后，就带有“关键转折”，“逆转声势”的意思，变成一个非常常用的单字。

而创业上的 Pivot，就是比较接近“关键转折”这个意思，一个团队经历一个 Pivot 后，做出了更符合市场需求的产品。什么意思呢？我们先用几个例子来看看吧：

Pyra Labs 与 Blogger

我想大多数人不知道，现在已经被视为网络最重要，也最基本工具之一的“博客”（Blog）当初是怎么来的。Blog 这个词，其实是从 Web + Log → Weblog → Blog 来的，可以说是由Pyra Labs 的创办人 Evan Williams 发明的。而 Pyra Labs 这家公司，是在1999年时创立，本来想要开发一个线上专案管理软件，结果这个软件本身不怎么受欢迎，想不到其中的“网路记事本”（Web Log）功能大家特别爱用。所以 Pyra Labs 最后决定来个 Pivot（转换跑道），专心做 Blogger，后来虽然也经历了不少苦日子，不过最终被 Google 买下，功德圆满。

Ludicorp 与 Flickr

当史都华‧巴特菲（Stewart Butterfield）和卡特琳娜‧菲克（Caterina Fake）在2004年创办 Ludicorp 时，他们一心想做的是一个网络万人连线游戏平台。想不到这个平台上的游戏不怎么红，但是聊天室中的照片分享功能却大受使用者的喜爱。于是他们做了一个 Pivot，把分享照片功能独立成一个网站，才有了 Flickr 这个受到全世界照相迷爱用的分享平台。

Odeo 与 Twitter

很多人大概也不知道，现在在全世界最红的“微博客” Twitter，当初是怎么来的。Evan Williams（没错，同一个人）当初离开谷歌创办 Odeo 这家公司的时候，本来是想要做一个播客（ Personal On-Demand Broadcasting 网路个人随选广播）平台。结果开发产品的同时，创办团队间发现有大量互相传简讯的需求，所以做了一个简讯转发/广播平台（ twttr ）来满足这样的需求。不久之后发现播客并不是市场想要的“未来广播”，但是twttr反倒是红了。于是，整个公司又来了一个 Pivot，才有了今天如日中天的Twitter的。

Pivot 的真正意思

看完了上面三个故事，我想你应该比较能够了解 Pivot，他的意思就是从你的产品和市场互动的结果，挖掘出一个新的方向，然后调整组织的策略，重新出发。创业团队需要 Pivot 的原因很简单，因为市场往往不是你想的那样。唯有把产品丢出去，你才能从中萃取出新的出路，新的商机。

如果你去看历史上的创业家，他们都是很会 Pivot 的，上面的 Evan Williams 就是很好的例子。而且这些人每次 Pivot，都会把组织带到一个新的境界。所以，如果要说 Pivot 是创业家最重要的本领，其实一点也不为过。

苹果公司的电子产品，最大的特点就是它的易用性（usability）—-简单，美观，容易上手。它们通常不是功能最强大的，但往往是最好用的。

很多产品经理都想模仿这些特点。但是，一个难题就会随之而来：

很难让一件产品保持简单，同时还具备大量的新功能。

如果你不断为产品添加新功能，在变得强大的同时，它还会变得越来越复杂，增加了用户的使用难度；如果你大力简化产品，在功能上比较单一，那么怎样与竞争对手抗衡呢？

每个产品经理都会面对这个难题。对于新产品，这个问题尤其重要。因为新产品通常很难打开市场，最容易想到的解决办法就是为它不断增加功能，直到引起市场注意为止。但是，这样做是否正确呢？

我对这个问题，一直很困惑，不知道开发新产品的时候，哪一个取向优先，多功能还是易用性？

昨天，我读到了硅谷产品经理Andrew Chen的文章，顿时醍醐灌顶，一下子就找到了答案。

他说，正确的做法，就是不要在功能上竞争。如果你的产品的核心概念行不通，那就重新定位这个产品，而不是为它添加新功能。你必须牢记在心，创造一个有竞争力的新产品，不要着眼于它的功能比别人多，而要着眼于它有一个截然不同的市场定位。

如果市场上都是复杂的企业级工具，那就开发一个针对个人用户的简化版；如果市场上都是很正式的高端葡萄酒，那就开发一种便宜的、针对年轻人的、更休闲的酒精饮料；如果市场上都是提供长篇Blog服务的网站，那就开发一个很简单的、每次只能写140个字的网站；如果市场上都是技术性的、廉价的电子设备，那就开发人性化的、高价的电子设备。

总之，你要做的不是添加功能，而是做一个市场定位不同的产品。

这主要有两个原因：

首先，你不太可能通过一个更多功能的新产品，战胜现有厂商。因为你开发出全面胜过别人的产品，需要很多时间；而且，等你开发出新功能，别人可能又做出了改进，或者拷贝了你的新功能。

其次，比起新功能，消费者更容易为一个特殊定位的产品掏钱。

所以，更好的策略是，开发一个简化的产品，突出某种不同的市场定位，争夺现有厂商的低端用户。这样的话，你不用开发一个全功能的产品，节省了时间，而且由于设计目标不同，更容易做出颠覆式创新（disruptive innovation）。

下面是开发新产品时，几点可行的做法：

　　（1）你不是做一个比竞争对手”更好”的产品，而是做一个”不同”的产品。

　　（2）你只提供部分功能，但是很好地满足了用户的需求。

　　（3）如果新产品的市场反响不好，增加新功能并不能解决问题。你应该重新定位你的产品，想想它能向消费者提供哪些不同的价值。

　　（4）在产品设计和推广的每一个环节，都突出它的不同定位。

[作者：阮一峰]