某次，你被指派進一個產品團隊，半個月前你做完市場分析與用戶研究，現在，好不容易寫完了一份厚厚的 PRD，覺得終於可以鬆口氣。沒想到二週後：

• 用戶研究回饋：「這功能其實不重要。」
• 數據團隊提出：「轉化率不好，流程要調整。」
• 競品突然上線新功能，老闆立刻喊：「我們也要跟上！」

於是，剛整理好的 PRD 還來不及存好檔，就已經過期。

這，就是產品型案子裡的日常。

專案型 PRD 像地震，能量釋放時就是一場爆改；
產品型 PRD 則像川流不息的河，永遠在流卻永遠沒有盡頭。

為什麼產品型 PRD 永遠寫不完

專案型案子追求的是交付，產品型則是經營。既然是經營，那就意味著「不會有終點」，PRD 也不會有「最終版」。

驅動這種持續變動的來源主要有四種：

1. 使用者回饋：客服記錄、問卷調查、訪談結果，每一筆都可能帶來新需求。
2. 數據驗證：A/B 測試或行銷漏斗，顯示設計不佳或流程卡住，就要立刻改。
3. 競品動態：競爭對手推出新功能，不跟進就可能被市場淘汰。
4. 策略調整：公司優先級或商業模式改變，PRD 必須跟著轉向。

和專案型不同的是，專案型的改動像爆炸，一次就能顛覆整份文件；產品型的改動則是無窮無盡的小修小補。它不會讓你一夜之間重寫 400 頁，但會讓你永遠寫不完。

產品型 PRD 的典型困境

這樣的持續迭代，帶來不少麻煩。

首先，文件快速過時。需求一更新，文件就落後。久而久之，大家乾脆不再看 PRD，而是憑口耳相傳來工作。

再來，資訊孤島。客服手上有用戶痛點報告，數據團隊有實驗數據，業務部有市場簡報。但這些東西 都沒有關聯到 PRD，最後各走各的想法。結果就是產品策略一條，開發方向一條，設計靈感又是一條，越走越散。

第三，決策碎片化。每個 sprint 都會有小調整，但缺乏系統性追溯。半年後回顧時，沒有人記得「為什麼要做這個功能」，只剩下 Jira ticket 的殘影。

第四，維護意願低。產品型 PRD 並不是交付物，不像專案型那樣「交出去就結案」。因此在優先級排序裡，它常常排在最後。PM 自己都覺得，「反正大家都有共識，幹嘛還要更新文件？」

最後，還有一個隱性的問題：角色視角差異。

• PM 想要的是完整的背景脈絡
• 工程師只想要明確的 acceptance criteria
• 設計師需要了解業務處理流程，但不想看技術細節
• 老闆只想知道方向是否符合策略

結果就是：同一份 PRD，沒有一個人覺得有寫到位。

專案型 vs 產品型 PRD：差異一覽

產品型的 PRD 應該視為「產品的迭代百科」

如果專案型 PRD 要像 Google Maps，幫團隊在變動中導航；那產品型 PRD 就該更像 Wikipedia，一份隨時更新的「產品百科」。

這代表了幾件事需滿足：

1. 框架清晰，細節隨時更新

   文件的重點不是寫得多，而是清楚定義「問題、目標、驗收標準」。細節則要能夠快速演進，隨時補上或修改。

2. 避免變成孤立檔案

   客服紀錄、問卷結果、數據分析，都應該能連結或整合到 PRD，避免變成孤立檔案。

3. 與 Roadmap 或 OKR 對齊

   PRD 不能只是一份需求清單，而要和公司策略保持一致，確保每一項需求都能對應到長期方向。

4. 版本追溯機制

   不要再有「Final」檔案。PRD 應該是小幅度的迭代，像 Wikipedia 的修訂紀錄一樣。

   唯一會有 Final 的時刻，就是產品 EOL 或被併購的那天（謝天謝地，謝買家）。

5. 敏捷共存思維

   很多人會說：「有 Jira ticket 就夠了，還要 PRD 幹嘛？」

   事實上，PRD 和 Jira 並不衝突。

   • Jira 是「執行單位」，記錄要做的事。
   • PRD 是「背景知識庫」，記錄為什麼要做。

   兩者互補，才能讓團隊在敏捷開發中不失去方向。

實戰小技巧

1. Notion 等非線性流式的文件工具

傳統 Word 或 Google Doc 比較偏線性流，從上到下，文件一長就變成沒人想看的黑洞。

用 Notion 這類工具，PRD 可以拆解成模組化的頁面，透過超連結形成「網狀結構」。

例如競品追蹤、法規更新（尤其在金融業）可以當補充頁面，不干擾核心需求，卻隨時可查。

2. Release Note 控版本

別再依賴 Final_v2、Final_last 這種檔名了，為團隊定義好版本遞進規則。另外，一定要在每次版本釋出時，順手在 release note 裡記錄需求的增減或修改。

這樣一來，PRD 的演進能與產品歷程同步，版本追溯更自然。

3. Notebook LM：整合觀點 + QA chat

產品型 PRD 的最大挑戰之一，就是跨部門資訊分散。

Notebook LM 的好處是能把客服報告、數據分析、業務簡報整合起來，輸出觀點與歸納想法，幫助 PM 將不同角度關聯到 PRD，避免「各走各的想法」。

更進一步，它還能建立 Q&A chat。PM 把 PRD 與關聯文件丟進去後，生成一個聊天介面，分享給團隊。如此一來，工程師或設計師如果有疑問，不需要再來回追問 PM，而是能在 chat 裡直接詢問，得到和 PRD 相關的答案。

也就是說，PRD 從靜態文件，變成了一個「能對話的 Chat 知識庫」。

4. 定期文件健檢

最少每月也要回顧一次 PRD，檢查它是否仍然反映最新的產品策略。這不只是修改文件而已，更像是在透過做這件事的同時，好好審視：我們是不是還走在正確的路上？

總結

專案型 PRD 要像 Google Maps，隨時更新路況，幫你導航。

產品型 PRD 則要像 Wikipedia — 永遠「在路上」，沒有 Final 版。

好吧，還是有例外，唯一會到 Final 版的時候，就是在產品 EOL (End of Life，產品生命週期結束)，或被收購，大家財富自由的那天 (灑花~