PRD¶
定义1¶
PRD是产品汪思考后的产品方案呈现载体，主要用于沟通研发、测试、设计、运营等，也会用于存档便于查看和回溯。
PRD 主要是给开发人员、UI 设计人员、测试人员等看的，目的是让开发人员知道如何按照产品经理的思路为需求撰写代码，让UI 设计人员知道他们需要输出哪些UI 设计稿，让测试人员知道测试用例中需要包含哪些测试点。PRD 的撰写侧重点是需求描述、需求逻辑、需求原型。PRD 是所有产品经理都会接触到的，也是产品经理平时写得最多的文档，所以大家一定要好好研究。
战略层——用户需求&产品目标¶
将需求背景、用户需求写在开头，后续撰写都要围绕这个核心，相当于定了方向，也可以指引阅读者更好更快的了解需求。 不管是定量目标还是定性目标，都要落实到PRD上，这是整个项目团队工作的预期成果。
范围层——功能规格&内容需求¶
战略层中明确了用户需求和产品目标后，范围层就要确定做哪些功能、提供什么内容来实现产品目标，可以将各个功能点以及它们的优先级用脑图或excel画出来（工具随意），相当于把整个需求分拆成各个模块，便于理解和评估工作。
结构层——交互设计&信息架构¶
范围层把需求分拆之后，结构层再把各个部分用流程图或思维脑图连接起来，让阅读者能抽象出产品的使用流程或信息架构。
偏交易、工具的产品需求可以使用流程图，偏内容的产品需求可以使用思维脑图，此处放一个点餐交易的局部流程图，仅做示例参考。
框架层——界面设计&导航设计¶
结构层将需求分拆模块，框架层梳理整体流程，相信这时候PRD读者已经对需求有了清晰的思路，框架层主要对每个模块或页面的逻辑、布局做详细阐述。
表现层——视觉设计¶
表现层主要包括但不限于视觉、听觉、触觉等内容，需要做一些高保真的设计，建议与UED、用户体验部门联合产出，这里不做过多展开。
过程2¶
先找研发对一下需求，连接上下游的关系。然后再写，把层次关系梳理出现，再用图表或流程图表现。拆分组块业务逻辑，梳理业务上下游。
目录：
产品背景
名词解释
产品综述
用户故事
需求详述
评审记录
其他问题描述
产品背景¶
背景概述¶
含义解释：背景概述是用简单的语言大概概括一下大的背景，让人知道我们本次要讲的内容大概是什么。
描述正文：官网为用户提供产品试用，目前，完整的试用流程如下：
用户在官网进行注册，填写申请试用表单。商务（运营）在管理后台，对用户的申请进行授权操作（允许/拒绝）。
注释：这样的背景描述，是将云官网，本次的产品需求，用业务流程串联起来，从前端到后端。从业务流程出发，将业务串联起来，这是一种非常好的方式。用一个事件，将涉及的所有产品功能都串联起来，让本次讨论有主线。
一般来说，这段话的作用在于让人阅读后明白我们为什么要花时间做这件事，以及明白了这件事的意义所在。重点在WHY，关于WHY的重要性，大家可以看一个演讲叫做How great leaders inspire action。
既然是完善和优化，那么产品经理就需要向运营、向研发证明，为什么这样的修改，相较于原来的流程，更好。
AI产品¶
二者的差异主要集中在需求内容的部分。而需求内容这方面的差异又因PM角色的不同而有所不同。
测试完整性3¶
现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？
当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。
管理产品3¶
解决所有PRD中存在问题，如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。
如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。
记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。
confluence：这个不多说了，非常好用的一款产品PRD在线编辑软件。4
COD评分表方法¶
信息架构¶
组织系统、标签系统、导航系统、搜索系统