关于产品需求文档（PRD），我在转行初期也经历过一段纠结时光。不知道怎么写比较好，也曾在格式、文档软件这些表面的东西上纠结。
经过几个月与研发磨合，终于明白，保持一个朴素的目标清晰的传达产品概念、产品需求就好。
所以，我们用 word、Excel 或者咱们企业内部的协作软件都可以。
我个人喜欢用 Excel ，一个 Excel 文件包含多个工作簿，这样方便管理/查看。因为研发工程师、市场、运营等部门他们都会用这个软件。
当然也可以用其他软件，比如 Axure 等，文件分享不方便其他部门打开文件；像 Axure 可以分享链接，但是不方便保存以及打开速度较慢或者有些浏览器根本就打不开。
如果您公司有协同软件那挺好，直接可以在上面编辑、权限管理等；如果没有协同软件，我们作为产品人需要考虑所有使用者的触点，方便团队所有人使用。
以上，只是想说工具不重要，重要的是准确的传达产品需求。
产品文档（PRD）包含哪些？
如图，我将产品需求文档（PRD）分为三大类文档。
如果您对技术不是很了解，《硬件需求》和《软件需求》这两个文档可以裁剪掉。但是其他的一定要详细描述清楚。
我们开产品评审会议时，主要讲解《产品功能列表》《业务及功能流程》和《产品功能需求》。
这三个文档详细描述了，我们的产品需要哪些功能、产品涉及的相关业务方和流程、产品具体的功能/性能要求。
啰嗦一句，关于文档命名的事情，我发现很多同事不喜欢将文档命名，找起来好麻烦，也不方便管理。一定要养成规范命名的习惯。
我自己的命名方式：产品需求文档_XX 产品_V1.0.1_20191210，包含文档属性、产品名称、版本、时间。
文档信息类
文档类别包含《文档信息》《项目规划》《change list》，分别描述项目的归属、整体计划、产品修订信息。
《文档信息》
这个表格表述的是整个项目的概况，方便一目了然的了解整个项目。特别是在公司项目很多的时候，这个概述很重要。
《项目计划》
这个表格表述的是项目预研以及研发设计的整体时间规划，公司项目少的话，可以不需要这个。一般我们做项目管理的时候有一个公司所有项目时间分配的汇总表。
《change list》
产品文档关于产品决策的每次变更均需要详细的记录在案，并发送到业务相关方。防止相关业务方开发出现信息错位，同时保证自己随时查阅相关产品状态。
当然，产品变更项目经理会出具会签的《变更申请表》，但是作为产品需要记录产品完整的研发路径。无论是作为产品回溯还是作为以后的经验参考都具备重要的意义。
产品需求类
《产品信息》
这份文档从全局表述了产品的形态、规格参数、包装等。产品信息全览，方便项目组成员快速了产品信息。
例如：硬件工程师看一眼就是知道，这个产品人机交互层面包含电源开关、什么类型以及几个功能按键、什么类型以及几个指示灯、是否有功能端口、是否有其他交互附件。根据规格参数选择什么样的传感器等元器件。
再例如：ID 工程师一看就明白外观上有哪些组件，以及产品 ID 概念。
所以，这份文档极大的方便项目组成员了解产品整体信息。
《硬件需求》
如果您对硬件不熟悉，可以不用出具这个文档，参与到硬件团队中，慢慢的就能学习到很多东西。待硬件工程师选型完成了，汇总到这个文档上就好。
这个文档的目的是规划产品各功能模块，产品经理在设计产品的时候，可以通过这个预估硬件成本。产品经理虽然出具这个文档，但最终还是要与硬件、系统部门工程师深入沟通最终确定这些关键元器件。
《软件需求》
这份文档是系统及系统应用、算法等软件按照模块的汇总。简明扼要的产品软件需求，并不像功能需求那么详细，做到逻辑性以及无遗漏即可。
《产品功能列表》
这份文档的目的是帮助我们梳理产品功能，与软件需求的区别是这份文档只包含功能，功能底层的支持软件不体现在这儿。
故此，您也可用思维导图来表达。
产品评估的时候会拿出来与研发团队评审，需要全面、无遗漏的描述产品功能需求。
产品测试时，可根据此文档总结开发时产品功能是否有遗漏。
《业务及功能流程图》
业务流程图是表达产品的业务流向。
功能流程图是表达产品功能关系/流向，信息流等。
我喜欢用 Axure 这个软件来做，我觉得很好用。其实用思维导图软件 Xmind 以及 office Visio 都可以。
《产品功能需求》
根据之前我们梳理过的《产品功能列表》《业务及功能流程图》制作《产品功能需求》。
包含功能描述，清晰无歧义的描述功能；功能的前置条件（触发机制）以及输出（例如执行某个动作或功能跳转）；并且详细描述功能的性能要求。
上图举例中，需求描述我做了很多裁剪。
我们在产品设计的时候，一定要反复的逻辑推演，将自己置于产品使用场景中反复推敲，确保功能能真正解决问题。这块很重要，很容易发生功能冲突等状况，所以逻辑思维能力、同理心都很重要。
想想我们自己在使用某个产品过程中，是不是抱怨这是什么傻 X 设计。原因就是，没做好前期设计或者没想到那个使用场景。
我有时候想不清楚的时候，我将这个《产品功能需求》打印出来，然后裁成一个个小纸片贴在墙上，然后用线连接起来，逐步分析。
类似电影上警察分析的那张地图。
在这些产品需求类别的文档中，《产品信息》《产品功能列表》《业务及功能流程图》《产品功能需求》非常重要，不能省略不写。工程师是根据这几份文档作为设计指导文件，不然没法开展工作。
互联网平台类
这类产品文档，网上很多，大家可以多搜索形成自己的方式。
我个人将这类文档做了裁剪，因为智能硬件产品 App 工具属性很重，我觉得相对比较好处理。
下面简单介绍我自己的方法。
《App 功能列表》
因为在做硬件产品的时候，已经将 App 融合进来考虑很久了，所以我直接就上了 App 的功能结构、页面结构、信息结构等，然后用原型图做补充。
《云平台》
这个需要我们根据产品属性来考虑，比如云端需要消息转发、云储存、音视频通讯、设备管理等功能需求；并且需要我们具备一点儿技术知识。不然不知道云端具体该怎么处理。
如果想学习这块儿知识，从我们的后台管理需要哪些功能入手进行反推，可能学习起来容易点。
小结
产品需求文档（PRD）格式可以千变万化，唯一不变的是将产品目标清晰的传达给项目组的的每一位成员。
作为产品经理设计产品的时候，用结构化思维将产品拆解成各个模块，然后用逻辑思维去编织关系。
例如，我们在分析产品需求的时候，通过思维导图慢慢的罗列功能，然后根据功能需求反推硬件需求以及 ID 上有什么交互组件。
一步步从上到下，从整体到局部，再深入细化，最后收敛验证。