在中有介绍，产品经理的两项主要职责包括：对产品机会进行评估，以及对开发的产品进行评估。而定义即将开发上线的产品，则需要借助产品需求文档，来进行产品的特征和功能描述。PRD文档的写作会因公司、团队以及个人习惯而异，没有标准的规范和统一模板，但有三大原则是不可忽略的：文字简练、中低保真、测试验证。本文仅陈述个人对产品需求文档的理解，若有不正确的地方，还望多多指教。

（一）PRD的定义、主要构成及用处

简而言之，产品需求文档（Product Requirement Document），是将商业需求文档(BRD)和市场需求文档（MRD）进行结合，然后用更加专业的语言进行描述。它向上是对BRD内容的继承和发展，向下是把MRD文档中的各种理论要求技术化，向研发和设计部门说明产品的功能和性能要求。BRD>MRD>PRD是一个逐步论证并产出结果的过程，也是产品经理思维升华的过程。

PRD主要构成：

1.引言及概要

这部分主要解释：需求背景、需求概要、需求目的、全局规则说明、名词解说以及文档变更记录等，目的是让阅读者尽快了解并熟悉需求背景和概要。作为公司内部文档来看的话，可以从简来写作。

2.业务说明及原型图

整个文档最核心的部分，其中包括产品功能主框架，比如：业务结构图／流程图、／功能模块元素构成、权限说明表等。同时，各页面之间基本的交互形式、文本注释及线框图，也是不可或缺的。

3.非功能需求

一些偏向“辅助”类的需求，包括：地理位置获取、CDN缓存策略、Push推送机制、本地文件存放策略...

如果是产品的第一个版本，那么在整个产品的业务流程和功能结构上就需要花更多时间来说明，既可以降低与整个团队的沟通成本，也能作为后期开发的证据和备份，而这恰好是PRD文档最大的用处。此外，它也发挥着将需求管理归档，促进从“概念化”阶段到“图纸化”阶段的过渡作用。

（二）PRD写作的三大原则

1.文字简练

诚然详尽的说明能给开发人员最全面的指导和参考，但“事无巨细”的备注及文字说明，有时反而会成为“过犹不及”的反例，增加沟通成本及延误开发进程。在产品进行评审和讨论具体开发细节时，有些问题会被重复提到，而在此过程中，如果能把关键性的逻辑用图表或文本展现出来就很关键了。对于有些“众所周知”的规则和功能需求的话，可以在产品文档中进行适当精简，否则开发人员也是没有耐心看完的。

事实上，即使你的PRD已经十分精练，团队成员也很有可能不会完完整整地看完，有时候甚至会忘记其中一些内容，然后认定是你当时没有添加。当然，如果你跟团队成员之间已经很有默契，彼此知道对方的开发习惯和设计套路，那么即使有些需求没有说明，产品的规划和迭代也同样能进入高效运转的状态。

2.中低保真

追求视觉细节和交互特效，在对外展示或用户测试时，效果固然好。但通常的原型是为了内部沟通交流，只需要用将核心功能及架构进行展示，便可以把产品设计的思路梳理清晰。相反，高保真的原型在遇到后期的需求变更时，会带来非常高的修改成本，而且会严重影响产品设计和开发的进度。正如用户体验五要素理论，产品的设计流程应该是：战略层>范围层>结构层>框架层>表现层。

3.测试验证

这是将产品经理的想法进行呈现的阶段，也是创造力和创新力出彩的地方。对于很多产品来讲，有下面三个测试十分重要，而且对于PRD最终是否“接地气”有着不言自明的决定作用。

1）可用性测试 － 不仅能适应不同的用户，而且可以找出遗漏的产品要求，从而进一步确认产品最初的要求是否是必须的。当然，从目标用户获取测试反馈，也是非常科学和艺术的。

2）可行性测试 － 通过让设计师和工程师介入技术的可行性调查和探索，可以尽早解决一些不太“现实”的问题，避免后期再调整的时间和精力代价。

3）概念测试 －对用户是否有价值以及产生购买欲望的测试，可以结合一些优质（比如Mockplus），将产品的预览版本呈现出来，之后在实际目标顾客身上测试，从而得到有质量的反馈。

总而言之，精简说明文字、保持、进行原型测试和验证，把时间和精力花在如何提高产品核心竞争力上，减少无效及重复的工作，是产出优质、有价值产品及产品需求文档的牵引力。