PRD 先是說服文件, 然後才是規格書
PRD 是 Product Requirements Document 的縮寫，即產品需求文件: 寫清要做什麼、為什麼做，讓工程師、設計師和相關方看到同一張圖。新手最常見的誤解就在這裡，把 PRD 當成功能規格書，上來就填頁面和按鈕清單。
拿到一份只有功能清單的文件，工程師只會做兩件事之一: 照單實作、遇到怪地方就來回追問，或者用自己的理解填空。哪種都會讓會議變多。好的 PRD 恰恰相反，它說服讀者: 這個問題是真的，這個方向是對的，範圍到這裡為止。被說服的工程師不會追問你的意思，而是提出更好的實作。
文件的一半是問題定義
具體寫清: 誰、在什麼場景下、多久遇到一次這個問題。有數據就附數字，沒有就附使用者訪談、客服工單這類證據。問題定義含糊的功能，在優先級會議上一旦開始被擠，就再沒有守住的辦法。
寫問題的時候覺得證據單薄，那不是文件的問題，是規劃的問題，而 PRD 恰好在上線前把它暴露了出來。不管是補證據還是換方向，成本最低的時機都在寫程式碼之前。
寫下不做什麼, 會就少開了
寫明刻意排除在範圍外的 non-goals 一節，在谷歌工程師的設計文件裡幾乎是標準做法。把那些讀者合理期待、但這一輪決定不做的事釘在文件裡，比如: 這次搜尋改進不涉及錯別字校正。
沒有這一節，同樣的爭論會貫穿整個開發過程，每次有人問這個是不是也該支援，都得從頭解釋一遍。決定和理由都寫在文件裡，一個連結就能了結。這是阻止範圍一點點膨脹的最便宜的裝置。
需求要寫成可驗證的句子
需求句子的標準只有一條: 第三方能不能判定它做沒做完。改善、讓它更方便這類動詞無法判定，所以那不是需求，是願望。
成功指標要在上線前定
上線後再挑指標，挑到的一定是恰好在漲的那個。所以成功指標要在動工前寫好，連目標數值和測量方式一起: 比如上線四週後購物車放棄率從 60% 降到 45% 以下算成功。
指標提前定好，上線就不是終點而是實驗的起點。沒達標的結果也會留下數據，告訴你哪個假設錯了，下一份 PRD 的問題定義會因此更紮實。
一頁紙的骨架
格式因團隊而異，但要回答的問題是一樣的。有了下面五節，一頁紙也能頂一份 PRD。
| 小節 | 要回答的問題 |
|---|---|
| 背景與問題 | 誰在什麼場景下因為什麼而受阻 |
| 目標與指標 | 用哪個數字確認成功 |
| 不做什麼 | 哪些事合理期待但這次不在範圍內 |
| 需求 | 用可判定完成與否的句子寫清做什麼 |
| 待定問題 | 還沒定的是什麼, 由誰在什麼時候定 |
一直改到上線的文件
PRD 不是寫完簽字就完事的文件，而是一路更新到上線的工作文件。開發中需求變了，先改文件，並記下改動日期和原因。文件和實際在做的東西一旦脫節，PRD 就成了沒人打開的檔案。
寫完後先拿給最忙的那位工程師看，問問讀到哪裡卡住了。有疑問的地方就是文件的洞。把洞補上再全員共享，啟動會就不再是宣講會，而是討論會。
常見問題
PRD 和產品企劃案有什麼區別?
很多時候只是叫法不同，是同一樣東西。真正要區分的是頁面設計稿: PRD 講做什麼、為什麼做，頁面設計稿講長什麼樣。只靠沒有為什麼的設計稿開工，實作過程中的每個判斷都會變成回頭來問你的問題。
PRD 要寫多長?
有問題、指標、範圍、需求、待定問題這五樣，一頁也是 PRD; 缺了這五個答案，十頁也不夠格。頁面細節、資料定義這類會寫長的內容放進附錄或連結文件，正文短，才會被讀。
敏捷團隊也需要 PRD 嗎?
不是讓你每個衝刺 (1-2 週的開發週期) 都寫厚文件。待辦清單 (backlog) 裡的單個條目，用使用者故事這種從使用者視角寫的一行需求就夠了; 但橫跨多個週期的功能塊，需要一份承載為什麼和範圍的文件。沒有它，誰也說不清那些故事碎片最終拼向哪裡。