「PRD 永遠寫不完，因為需求改到我都快辭職了」
這不是玩笑，是每個做產品 PM 的日常痛點。 開發進度不斷前進，需求持續變動，我們該怎麼寫一份能讓團隊一起跑下去的PRD？
一、PRD 的核心，不是文件，是「對齊共識」
PRD（Product Requirements Document）不該是一份上傳完就沒人要看的文件，而應該是：
👉 促進跨部門對齊的「共識文件」
👉 能快速更新，能隨時追蹤的版本控管文件
👉 讓開發團隊清楚「該做什麼」、「為什麼做」、「做到什麼程度」
🧩 WBS（工作分解結構 Work Breakdown Structure）
你可以把功能需求切分成 WBS，從模組 → 功能點 → 子任務，讓需求在一開始就有執行層級的展開。 例如：
- 活動模組
- 建立活動
- 設定折扣規則
- 設定曝光位置（banner, 頁面置頂）
這樣有什麼好處？
📌 工程能直接拆工時、設計知道場景、QA 能列測項，所有人都能「知道怎麼做」。
二、PRD 中該寫什麼？給你一個簡單架構
🎯 目標與背景：為什麼要做這功能（用數據佐證會更強）
📊 User Scenario（使用者情境）：使用者什麼情境會用到這功能
🔍 功能需求（Feature Requirement）：列點拆解（能對應到 user story）
✅ Acceptance Criteria（驗收標準）：明確定義什麼叫「完成」，例如：
使用者可以於 3 秒內完成報名，並收到成功訊息通知。
🧪 非功能性需求（NFR）：如效能、相容性、瀏覽器支援等
🔗 API 與前後端介接說明：有哪些欄位、參數、事件需同步？可用表格呈現
📎 設計連結與 wireframe：UI/UX 要參考什麼版本？prototype 點哪裡？
三、怎麼應對需求變動？PM 的 3 層防線
1️⃣ 先用「User Story Map」確認流程邏輯
把所有情境視覺化，看功能覆蓋了哪些行為，缺了什麼場景？ 用例句模板：「作為一名＿＿，我想要＿＿，以便＿＿。」
2️⃣ 分階段執行，搭配 MVP 思維 + 版本規劃
功能分成 MVP → V2 → V3，讓團隊可以先上線後迭代 範例：V1 只提供簡單的優惠券派發，V2 再導入綁定活動頁與個人化露出。
3️⃣ 每週滾動同步一次，強化「變更控制流程」
別再把更新記在腦中，用 Notion/Confluence 建立「PRD 變更紀錄表」：
日期｜變更項目｜修改人｜原因說明｜對應版本
四、從 PM 的角度，怎麼做出一份「有用」的 PRD？
- 🧭 別被格式綁住，內容能對齊才最重要
- 🗣 每一段落都為了溝通，不是表演文筆
- 💬 重點放在「最容易誤解」的地方，多舉例
- 🔁 文件更新要明確時間與版本號
🧠 延伸 Tips：PRD 的三不原則
❌ 不要寫太多願景沒人看
❌ 不要只寫功能點，沒有情境會被曲解
❌ 不要拿過去範本直接貼，會落入格式陷阱
📣 最後總結：PRD 是產品溝通的橋梁，不是產品本身！
不管產品怎麼變、需求怎麼改，PM 唯一能做的，是用每一次的溝通，把混亂變有序。
如果你也正在被改到崩潰，記住一句話：寫PRD不是輸出文案，而是設計溝通路徑。
