在產品經理工作中，需求文檔（PRD）應該是接觸最多的文件之一，也是產品日常需要撰寫修訂最多的文件。這篇文章，作者分享了策略產品經理寫的PRD文檔結構，與C端的PRD有所不同，希望能對大家的工作有所幫助。

策略產品是大中廠團隊中的靈魂，從內容推薦分發來說，取悅內容消費用戶；從本地業務來說，平衡騎手、商家、用戶的需求；從生活服務業務來說，精準連接用戶與POI，并在這個過程中持續優化路徑體驗。

好的策略產品需要從定量、定性的方法上輸出考慮周全，執行清晰、評估客觀的文檔是非常關鍵的。

接下來，列舉一份好的策略PRD應該有的基本結構：

一、相關方信息同步

因為策略相關的動作通常有合規背景、業務背景，策略的變更會引發上下游業務、運營、算法等各個團隊的調整，通常來說，這部分的信息留在整體文檔梳理完成之后再撰寫。方便相關方快速找到自己對于策略的關系與定位。

下面給個基本的格式用以參照：部門、負責人、RACI、給的建議（是否知悉或者同意&確認）。

RACI模型的名稱來自四個主要角色：負責人（Responsible）、問責人（Accountable）、被咨詢人（Consulted）和被通知人（Informed）。這個模型可以用于任何項目或流程，無論大小。

二、概括背景

背景部分其實已經是主體的重要表現，通常情況下，需要在文檔開篇就開宗明義表現出來，主要讓讀者了解新策略的背景原因，要做的事情有哪些，解決目標問題是什么

1. Background需求背景

一般看項目大小，最好可以把項目與團隊目標在背景部分做好全面的介紹。

比如平臺團隊目標是內容生態，而項目目標是通過引入MCN來做內容豐富度、多樣性的引導。那么需求背景就要說明我們這么做是因為什么？可能是競品，也可能是行業通用法則，也可能是平臺內消費用戶的訴求。

2. WHAT要做什么事情

基于需求背景本身，可以用一句話講清楚要做的是什么事。好的一句話需求至少應該包括：目標用戶（主體），要做什么事情或者功能（動作），預期的效果（目標），有無特殊情況（需要遵守的規則）。

從內容生態引入MCN的供應來說，這個需求可能是“為了豐富我們的內容生態（主體），我們需要為引入在平臺入駐認證（約束條件）的MCN的機構（動作）來搭建平臺，以此提供多元化的內容（目標），以滿足不同用戶的需求并提升用戶體驗”

3. WHY解決什么問題

討論必要性的部分最好圍繞幾個視角撰寫，拋出幾個視角：線上的問題為什么一定要解決——哪個視角有什么需求；如果不解決對后續的影響——策略可擴展性有多大。一般來說，策略需求主要滿足的幾個視角，有的話可以往上靠：誤傷、漏放、合規、透明度、特殊群體保護、去肥增瘦。

三、指標看什么（用什么方式驗證）

這些指標就不做過多的贅述，不過在列舉指標的時候，需要討論說明清楚指標的定義、口徑是什么、預期上線策略指標是上升還是下降：

1. 對北極星影響
2. 過程指標
3. 護欄指標

四、策略設計主體

前面主要說了是什么，主體部分重點討論如何實現，其中會涉及前端的改造成本、后端的邏輯方案、是否有跟版的需求

1. 前端改造

怎么把前端改造介紹清楚？一般分三個維度介紹，第一，現狀是如何；第二預期的樣子；第三頁面交互：前置條件（該頁面的激發動作）；用戶點擊前后的交互、展現效果；頁面元素獲取的數據鏈路；元素激活的篩選條件（提示信息）；異常狀態的提示信息；

2. 后端改造

這里的后端設計并不是指支持前端的鏈路流程，而是指整條策略從規則、識別、召回、送審到最后一步感知的條件判斷與流程規劃，正常應該包括的元素：流程圖、條件判斷、異常判斷、處置鏈路等

3. (是否)跟版

一般來說，策略產品的需求不會涉及到跟版，除非有大條件約束才會產生跟版的需求，比如端上新用戶的彈窗類需求，因此這部分在實際撰寫過程中需要跟端上同學確認前端頁面是否都由前端同學完成即可，避免遺漏。

五、方案上線前灰度

策略若能真正完成灰度上線，很大一部分程度需要先驗的數據分析，但是對需要通過用戶反饋來對策略進行調優，最好在開啟驗證前做好AB測試。

在AB設計關注以下幾件事情：

1. 干預變量越少越好
2. 保持分組的抽樣隨機性
3. 實驗組觀測量可以從總用戶中5%開始慢慢推進，以觀測效果為核心測試

1. 擴量的數據指標

后續的數據指標決定全量放量時間跟收益評估，最好在實驗開始之前就思考清楚，以減少后續的重復勞動，或者回滾操作。

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

在策略環境下，回查平臺涵蓋的信息多樣，如果是新的策略上線，為了全面追蹤case的分發詳情，最好可以在回查平臺也同步配置命中該策略的效果，可能涉及跨團隊部門的協作配合。

1. 查詢入口
2. 查詢字段

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