寫在前面：

此指南基于 Martin Cagan的 How To Write a Good PRD 和之前寫文檔暴露出來的主要問題。希望通過規范文檔書寫，重視起基礎能力的培養。

PM需要意識到：具備基礎能力未必能夠打造出優秀的產品，但是基礎能力的缺失只能導致產品的失敗，并將你和你的團隊拖入泥潭。

產品價值

即便是再細微的功能點也有其存在的價值。通常可以描述為「為WHO解決WHAT」，WHO包括外部客戶、公司、部門或崗位(如有可能應當盡量詳細定義)，WHAT指此類用戶所遭遇到的具體問題，避免使用「提升用戶體驗」這樣籠統的用詞。

產品目標

無法被評估的價值沒有意義。目標就是衡量產品價值的標準，同時也是激勵團隊實現產品價值的燈塔，目標描述應遵循S.M.A.R.T.原則，對已有產品的優化應當放出參考數據以做對比。需要注意的是：有些產品的價值通過累積體現，避免使用「上線后」這樣籠統的用詞，更為嚴謹的定義為「上線一周后日均」

產品發布時間

將此點納入產品文檔是因為目前普遍缺乏項目管理意識，團隊前松后緊，Deadline一拖再拖。PM應當在項目啟動時就宣布期望ReleaseDay(即便這是一個沒有經過評估的日期)，避免使用「8月下旬」這樣籠統的用詞。以幫助團隊提升緊迫感；技術評審后通常會得到更準確的開發和測試評估，PM 應盡快更新文檔并告知團隊

數據需求

PM對數據需求的重視程度不應亞于功能需求。功能需求上線后才開始規劃數據需求并不是迭代。衡量數據需求的標準在于是否能夠全面、準確和細致的計算產品目標。合格的數據需求應該包括：提供哪些數據？這些數據的定義和源是什么？以什么方式提供？從什么時間開始提供？

更新記錄

借助協同辦公軟件，我們可以快速查閱產品文檔的修訂記錄。PM需要做的是將重要信息及時更新到文檔，以便于自己和他人日后查閱，并避免無謂的爭議。重要信息包括：一、需求和方案變更，包括：需求、流程、邏輯、文案和設計稿；二、產品優化，包括：原因、方案；三、數據 Review，包括：數據明細，是否達到預期目標及原因分析，以及下一步動作。數據Review通常在產品上線1周、2周和1月進行，我們強烈建議PM從產品上線后第一個工作日開始關注數據，并每天在項目組內進行分享。

公共規則

在產品定義涉及多產品線的公共規則時，請盡量與公共規則保持一致；如因特殊原因需要單獨定義，需要在文檔中說明原因，并確保已與相關PM溝通。一個可以參考的案例：移動端關注功能已經上線，對于關注房源的展示數量上限設定為200，網站端關注功能尚未上線，產品文檔中將展示數量上限設定為99，兩端的規則差異并無存在意義。