產品需求文檔(Product Requirement Document,簡稱PRD)是研發(fā)將產品方案進行落地的依據,也是產品經理所有思考的載體,因此一份優(yōu)秀的需求文檔不僅能夠順利的保證項目的研發(fā)進度,而且能夠提升產品經理的個人影響力。每個企業(yè),每個團隊對需求文檔的要求不盡相同,因此本小節(jié)將討論在策略需求文檔中常見的內容和注意事項。和大多數PRD一樣,策略PRD的第一部分也應該呈現需求概述。需求概述中一般包含如下內容:需求背景和需求目標。需求背景通俗來講就是講就是這篇文檔中描述的方案要需要解決什么問題,及其必要性;需求目標就是完成這個需求所有達成的收益,通常是以指標的方式進行定義。策略需求的指標通常包括CTR、CVR,UV價值等等。具體可以參考:你應該掌握的產品數據指標需要注意的是,在定義需求目標時,不僅僅要給出可衡量指標的具體計算方式,還需要給出該需求相關的數據現狀分析結果,以保證目標確定的合理性。在實際的應用中,這兩項也可以也獨立章節(jié)存在。搜索篩選項是決定搜索流量分發(fā)效率的重要環(huán)節(jié)之一。相關用研結果表明有80%的用戶會在搜索結果頁使用篩選功能來進行商品精細化選擇。但是提取了近一周篩選功能使用數據,目前篩選項總體CTR大約為10%,用戶關注的很多因素沒有體現在篩選項中,基于此,進行本次搜索結果篩選項優(yōu)化,以提升搜索結果頁篩選項的CTR。CTR的口徑為:篩選項的點擊次數除以篩選項的曝光次數。版本控制是指當前策略需求上線的版本,這個是很多策略產品經理寫需求的時候容易忽略的一個點。通常一個產品因為用戶更新的時效,以及發(fā)布規(guī)則等限制,線上會存在多個不同版本,因此需要確定當前需求上線的版本。另外,策略需求因為其結果的不確定性,通過版本控制也可以降低因策略帶來線上風險,方便問題緊急處理。如果當前策略PRD中定義的需求屬于前端可視化類時,需要在文檔中給出交互、視覺示意圖。一方面可以快速讓大家理解本次方案的生效范圍、需求效果;另一方面其實也能提升需求評審環(huán)節(jié)的效率。大家對于圖形的接受、理解能力要遠遠大于文字。在一些完善的產品研發(fā)團隊,會有專門的交互設計師來承接交互設計的工作,策略產品經理需要明確評估當前策略對用戶完成相關流程的影響,以及可能帶來的風險。視覺示意圖一般無須產品經理直接介入,做好資源協調,細節(jié)溝通即可。策略邏輯是策略PRD中最核心的內容,它其實就是一類問題的解決方案,一般包括:策略流程圖、策略內容、優(yōu)先級定義。策略流程圖主要是指該策略從開始到結束的數據流轉過程,通過數據流程圖可以清晰的看到整個策略方案的細節(jié),以及和其他模塊的交互過程;策略內容主要是定義需求名稱、需求內容、規(guī)則邏輯、細節(jié)節(jié)說明等,策略產品經理在編寫策略內容時最主要的是注意方案的完整性,尤其涉及到數據參與計算的規(guī)則邏輯,許多邊界條件都要定義清楚;優(yōu)先級定義是指當一個策略需求文檔中包含若干策略需求內容時候,需要指明每個需求的優(yōu)先級,以便研發(fā)資源分配。這塊的呈現形式建議大家用表格的方式呈現,更加清晰合理。序號
| 需求名稱 | 方案描述
| 優(yōu)先級 | 備注
|
|
| 策略內容,描述方案細節(jié)
| P0~P3
|
|
A/B測試是策略需求中非常常見的上線手段,策略產品經理需要在PRD中定義清楚A/B測試的版本,時間范圍,測試方案以及執(zhí)行者。
示例:
本次策略上線需要進行AB試驗,核心觀測指標為CTR,持續(xù)兩周。具體分組如下:
實驗組:20%,新策略
對照組:20%,線上策略
空白組:60%,線上策略
很多產品經理認為只有涉及到前端可視化類產品優(yōu)化時才需要埋點方案,其他無須提供。這里有一個很大的誤區(qū),其實在之前的文章我不止一次提到過埋點只需要保持一個原則就行:“要看什么數據,埋什么點”,因此是否需要埋點方案不依賴于具體的產品形式,而是你的數據需求。比如為了衡量比較不同版本的算法對整個策略的效果,需要采集不同版本的算法id,每個id唯一標識一個版本,所以即便不涉及到前端改動,也需要增加埋點用來采集算法id。以上六個模塊就是一份策略需求文檔最基礎、最基本的內容要求。當然,在實際的工作中,可以根據團隊要求,需求類型靈活進行定義,增加刪除若干模塊。比如在一些線上badcase優(yōu)化中,一個簡單的excel即可進行策略需求的定義和開發(fā)。需求文檔可以說是每個產品經理的面子,一份好的需求文檔除了能夠提高需求評審效果,更關鍵的是提升個人影響力,以上希望能幫到你。