在产品经理工作中，需求文档（PRD）应该是接触最多的文件之一，也是产品日常需要撰写修订最多的文件。这篇文章，作者分享了策略产品经理写的PRD文档结构，与C端的PRD有所不同，希望能对大家的工作有所帮助。

策略产品是大中厂团队中的灵魂，从内容推荐分发来说，取悦内容消费用户；从本地业务来说，平衡骑手、商家、用户的需求；从生活服务业务来说，精准连接用户与POI，并在这个过程中持续优化路径体验。

好的策略产品需要从定量、定性的方法上输出考虑周全，执行清晰、评估客观的文档是非常关键的。

接下来，列举一份好的策略PRD应该有的基本结构：

一、相关方信息同步

因为策略相关的动作通常有合规背景、业务背景，策略的变更会引发上下游业务、运营、算法等各个团队的调整，通常来说，这部分的信息留在整体文档梳理完成之后再撰写。方便相关方快速找到自己对于策略的关系与定位。

下面给个基本的格式用以参照：部门、负责人、RACI、给的建议（是否知悉或者同意&确认）。

RACI模型的名称来自四个主要角色：负责人（Responsible）、问责人（Accountable）、被咨询人（Consulted）和被通知人（Informed）。这个模型可以用于任何项目或流程，无论大小。

二、概括背景

背景部分其实已经是主体的重要表现，通常情况下，需要在文档开篇就开宗明义表现出来，主要让读者了解新策略的背景原因，要做的事情有哪些，解决目标问题是什么

1. Background需求背景

一般看项目大小，最好可以把项目与团队目标在背景部分做好全面的介绍。

比如平台团队目标是内容生态，而项目目标是通过引入MCN来做内容丰富度、多样性的引导。那么需求背景就要说明我们这么做是因为什么？可能是竞品，也可能是行业通用法则，也可能是平台内消费用户的诉求。

2. WHAT要做什么事情

基于需求背景本身，可以用一句话讲清楚要做的是什么事。好的一句话需求至少应该包括：目标用户（主体），要做什么事情或者功能（动作），预期的效果（目标），有无特殊情况（需要遵守的规则）。

从内容生态引入MCN的供应来说，这个需求可能是“为了丰富我们的内容生态（主体），我们需要为引入在平台入驻认证（约束条件）的MCN的机构（动作）来搭建平台，以此提供多元化的内容（目标），以满足不同用户的需求并提升用户体验”

3. WHY解决什么问题

讨论必要性的部分最好围绕几个视角撰写，抛出几个视角：线上的问题为什么一定要解决——哪个视角有什么需求；如果不解决对后续的影响——策略可扩展性有多大。一般来说，策略需求主要满足的几个视角，有的话可以往上靠：误伤、漏放、合规、透明度、特殊群体保护、去肥增瘦。

三、指标看什么（用什么方式验证）

这些指标就不做过多的赘述，不过在列举指标的时候，需要讨论说明清楚指标的定义、口径是什么、预期上线策略指标是上升还是下降：

四、策略设计主体

前面主要说了是什么，主体部分重点讨论如何实现，其中会涉及前端的改造成本、后端的逻辑方案、是否有跟版的需求

1. 前端改造

怎么把前端改造介绍清楚？一般分三个维度介绍，第一，现状是如何；第二预期的样子；第三页面交互：前置条件（该页面的激发动作）；用户点击前后的交互、展现效果；页面元素获取的数据链路；元素激活的筛选条件（提示信息）；异常状态的提示信息；

2. 后端改造

这里的后端设计并不是指支持前端的链路流程，而是指整条策略从规则、识别、召回、送审到最后一步感知的条件判断与流程规划，正常应该包括的元素：流程图、条件判断、异常判断、处置链路等

3. (是否)跟版

一般来说，策略产品的需求不会涉及到跟版，除非有大条件约束才会产生跟版的需求，比如端上新用户的弹窗类需求，因此这部分在实际撰写过程中需要跟端上同学确认前端页面是否都由前端同学完成即可，避免遗漏。

五、方案上线前灰度

策略若能真正完成灰度上线，很大一部分程度需要先验的数据分析，但是对需要通过用户反馈来对策略进行调优，最好在开启验证前做好AB测试。

在AB设计关注以下几件事情：

1. 扩量的数据指标

后续的数据指标决定全量放量时间跟收益评估，最好在实验开始之前就思考清楚，以减少后续的重复劳动，或者回滚操作。

六、方案是否涉及回查平台改造

在策略环境下，回查平台涵盖的信息多样，如果是新的策略上线，为了全面追踪case的分发详情，最好可以在回查平台也同步配置命中该策略的效果，可能涉及跨团队部门的协作配合。

以上就是一篇完整的策略文档，期待使用后的反馈。