产品需求文档(Product Requirement Document，简称PRD)是研发将产品方案进行落地的依据，也是产品经理所有思考的载体，因此一份优秀的需求文档不仅能够顺利的保证项目的研发进度，而且能够提升产品经理的个人影响力。每个企业，每个团队对需求文档的要求不尽相同，因此本小节将讨论在策略需求文档中常见的内容和注意事项。和大多数PRD一样，策略PRD的第一部分也应该呈现需求概述。需求概述中一般包含如下内容：需求背景和需求目标。需求背景通俗来讲就是讲就是这篇文档中描述的方案要需要解决什么问题，及其必要性；需求目标就是完成这个需求所有达成的收益，通常是以指标的方式进行定义。策略需求的指标通常包括CTR、CVR，UV价值等等。具体可以参考：你应该掌握的产品数据指标需要注意的是，在定义需求目标时，不仅仅要给出可衡量指标的具体计算方式，还需要给出该需求相关的数据现状分析结果，以保证目标确定的合理性。在实际的应用中，这两项也可以也独立章节存在。搜索筛选项是决定搜索流量分发效率的重要环节之一。相关用研结果表明有80%的用户会在搜索结果页使用筛选功能来进行商品精细化选择。但是提取了近一周筛选功能使用数据，目前筛选项总体CTR大约为10%，用户关注的很多因素没有体现在筛选项中，基于此，进行本次搜索结果筛选项优化，以提升搜索结果页筛选项的CTR。CTR的口径为：筛选项的点击次数除以筛选项的曝光次数。版本控制是指当前策略需求上线的版本，这个是很多策略产品经理写需求的时候容易忽略的一个点。通常一个产品因为用户更新的时效，以及发布规则等限制，线上会存在多个不同版本，因此需要确定当前需求上线的版本。另外，策略需求因为其结果的不确定性，通过版本控制也可以降低因策略带来线上风险，方便问题紧急处理。如果当前策略PRD中定义的需求属于前端可视化类时，需要在文档中给出交互、视觉示意图。一方面可以快速让大家理解本次方案的生效范围、需求效果；另一方面其实也能提升需求评审环节的效率。大家对于图形的接受、理解能力要远远大于文字。在一些完善的产品研发团队，会有专门的交互设计师来承接交互设计的工作，策略产品经理需要明确评估当前策略对用户完成相关流程的影响，以及可能带来的风险。视觉示意图一般无须产品经理直接介入，做好资源协调，细节沟通即可。策略逻辑是策略PRD中最核心的内容，它其实就是一类问题的解决方案，一般包括：策略流程图、策略内容、优先级定义。策略流程图主要是指该策略从开始到结束的数据流转过程，通过数据流程图可以清晰的看到整个策略方案的细节，以及和其他模块的交互过程；策略内容主要是定义需求名称、需求内容、规则逻辑、细节节说明等，策略产品经理在编写策略内容时最主要的是注意方案的完整性，尤其涉及到数据参与计算的规则逻辑，许多边界条件都要定义清楚；优先级定义是指当一个策略需求文档中包含若干策略需求内容时候，需要指明每个需求的优先级，以便研发资源分配。这块的呈现形式建议大家用表格的方式呈现，更加清晰合理。序号
| 需求名称 | 方案描述
| 优先级 | 备注
|
|
| 策略内容，描述方案细节
| P0~P3
|
|
A/B测试是策略需求中非常常见的上线手段，策略产品经理需要在PRD中定义清楚A/B测试的版本，时间范围，测试方案以及执行者。
示例：
本次策略上线需要进行AB试验，核心观测指标为CTR，持续两周。具体分组如下：
实验组：20%，新策略
对照组：20%，线上策略
空白组：60%，线上策略
很多产品经理认为只有涉及到前端可视化类产品优化时才需要埋点方案，其他无须提供。这里有一个很大的误区，其实在之前的文章我不止一次提到过埋点只需要保持一个原则就行：“要看什么数据，埋什么点”，因此是否需要埋点方案不依赖于具体的产品形式，而是你的数据需求。比如为了衡量比较不同版本的算法对整个策略的效果，需要采集不同版本的算法id，每个id唯一标识一个版本，所以即便不涉及到前端改动，也需要增加埋点用来采集算法id。以上六个模块就是一份策略需求文档最基础、最基本的内容要求。当然，在实际的工作中，可以根据团队要求，需求类型灵活进行定义，增加删除若干模块。比如在一些线上badcase优化中，一个简单的excel即可进行策略需求的定义和开发。需求文档可以说是每个产品经理的面子，一份好的需求文档除了能够提高需求评审效果，更关键的是提升个人影响力，以上希望能帮到你。
