概述
产品文档不仅仅可以使得产品有据可依，同时也可以使得项目管理更清晰，有条理。
有了一系列的产品文档还可以为之后的交接和维护带来非常多的便利。
产品文档，我们知晓比较多的需求文档（BRD、MRD 和 PRD）。除此之外技术文档也有着非常重要的作用。
需求文档 BRD、MRD 和 PRD
需求文档BRD、MRD 和 PRD分别代表证不同的含义。
它们的关系可以理解为BRD是产品的head，MRD是产品的body，PRD是产品的Heart。有了Head、Body、Heart这就是一个完整的产品了。
BRD 商业需求文档
BRD Business Requirement Document
BRD一般都是针对老版或CEO或者项目总负责人，通常包括：
1. 要做什么样的产品
- 项目定义
- 描述项目（能让Boss感觉到产品的竞争优势）
2. 需要的资源
需要什么资源就必须知道产品的市场位置，通过多少人、多长时间、多少Money、多少关系等等能够实现这样的市场位置。
并且还需要有利且有力的商业说明，需要有一定的高度。
3. 最终产品
结果是王道，通常Boss很少关系过程如何如何，最关注的的当然是产品的结果展示及盈利，这个产品能带来什么样的收入情况
所以BRD可以概括为商业模式、盈利模式、资源投入、市场优势等
还有重要的一点就是“战略壁垒”，这一点主要是针对被Copy和产品包括。这或许决定着整个产品的成败（有特殊的资源除外）
MRD 市场需求文档
MRD Market Requirement Document
MRD一般都是针对商务、运营、市场人员，通常包括：
1. 要找什么样的客户，进行资源合作
一般公司资源合作的都是商务和市场人员，或者加上运营人员，那么他们是资源拓展者，对于产品保驾护航。
正如船要出海，就必须有在海里或者有水的地方，海的大小决定了船的大小，所以他们就是船的载体。
商务、市场及运营人员在产品之前必须对于产品进行资源拓展，且快速评估产品的实现情况。
MRD就是给他们一个清楚的方向，该找什么样的客户？
2. 找到客户后，我们该怎么和他们说
上面说了MRD指引着商务、市场和运营往前走，那么找到客户该怎么和他们说呢？
除了文档描述一个清晰的蓝图，或者说从红海中挖出新的路子，这里边就是MRD中的业务模式了，通过业务模式，可以看到清晰的产品，且客户可以看到他们在中间的位置，甚至说他们怎么赢利。
一般给客户看到的都是PPT+Demo的方式，这样对于客户更直观更易于理解，所以MRD的文档就是给团队和客户一个说明
3. 产品针对什么样的用户群体
商务是资源拓展的关键，市场是产品保障的关键，运营则是产品的推手。那么市场和运营就需要了解产品是针对什么用户群体的，毕竟最终的是使用人群是用户。
MRD基本需要明确产品的用户人群，这样市场才能更好的进行分析。
通过分析这个人群，给运营提供很好的参考资料，这样运营在推广这部分人群的时候也能够制定出很好的方案，资源优化及减少资源消耗，这就是MRD对于商务、市场、运营的关键作用
MRD可以概括为产品模式、业务模式、运营模式、市场模式等，明确客户及市场方向！
PRD 产品需求文档
PRD Product Requirement Document
PRD一般是针对项目组、开发组、测试组、策划组、体验组人员，通常包括：
1. 产品是什么
对于与产品相关的人员，就必须有一个清楚的产品概念，这个产品到底是干嘛的？
要了解到底是什么产品，那就需要详细而简单的进行说明，但是这个只能是描述，还需要有与策划、开发、测试等另一种沟通语言。
那就是UI、UE、原型图、流程图等，这样方便策划及开发人员的工作进展!
2. 怎么实现
该怎么实现，那就是规划了。包括时间、人力、资源等
什么时间完成什么事了！在前进的路上设立一些里程碑！这就对于产品经理来说就是一个挑战了。
因为产品经理与商务、市场、运营沟通的方式和开发人员方式不一样。商务、市场、运营更多的是发散型思维，而开发则更多是紧密型思维。
对于开发人员的沟通则不能用“基本”“差不多”“还好”等这样的词来进行沟通，否则开发人员会开始发散。
如果不一致，对于程序来说推导再来，就不是那么容易的了！甚至出现了大量的BUG，有时候过多的BUG会让一个产品死掉！
所以就需要有详细的功能说明，细化到什么程度了，用YN原则来说明，VISIO是甚好的工具。
不能出现模凌两可的语句，甚至需要通过语句进行if else描述，对了还有default。
这个很关键，当程序运行正确了那固然好，如果程序出现BUG，则你不能让程序没有出口吧，那就是default了，给程序的BUG找一个合理的理由！
3. 什么样的产品才能投入到市场
产品开发人员更多的是站在产品角度思考问题，以实现产品而完成产品。
产品最终开发完后，是不是能够满足运营需求呢？这时候产品经理就需要进行产品审核：
第一步：简单的依据于之前的详细功能说明来进行需求审核
第二步：就是黑盒、白盒、甚至灰盒测试
第三步：需求优化，怎么优化呢，依据于市场人员及运营人员提供的用户数据来进行，再让产品设计人员进行UI优化，立足站在用户的角度
第三步完成了，就是最终的步骤了，体验师就起了关键性的作用，AB原则就出来了。
将产品上线，体验师们就开始采集用户信息进行分析了，这个阶段对于产品的整个战略规划很关键，因为用户对于产品的第一感觉非常重要。
如果是互联网产品则你可以换个网站，反正用户没法删除你的网站，但是对于移动互联网的产品APP来说，就是一个挑战了，看着不顺眼就直接给删除了。
PRD可以概括为产品界面、产品流程、功能需求、测试需求、体验需求等，保证产品有效率有节奏的进行！
技术文档
基本的技术文档应该要包含下面的几项
- 竞品分析文档
- 技术需求文档
- 设计文档（包含Flow设计，API，数据格式等）
- 发布文档（包含Release记录，Know Issue等）
- 测试文档：主要是单元测试和人工测试
- 工作状态文档：主要是任务状态，任务分配等信息
- 产品总结文档：产品完成后的产品总结（包含框架，难点分析，遇到的挫折等）