之前有記錄過一篇產品經理寫產品需求文件 PRD 的方式，但過了一陣子發現有些內容可以再更新，因此這篇會記錄 PRD 的前情提要，以及實際用案例來舉例 PRD 的內容要放哪些資訊。
一、關於 PRD 要先知道的事
⠀⠀
PRD 的目的不是寫文案，而是對齊決策與加速執行PRD（Product Requirement Document）是產品開發流程中最具爭議、也最容易被誤解的文件之一。新手產品經理會將 PRD 當作「寫清楚就好」的說明書，結果越寫越像流水帳；而部分資深 PM 則認為「熟了就不用寫太詳細」，只寫重點，剩下用口述的，導致後續開發混亂、需求來源難追溯。
但 PRD 的真正價值不是在於「寫得多完整」，而是它是否能協助團隊對齊需求目標、降低溝通成本，並有效推進產品落地。換句話說，PRD 是一份「可交付的思考歷程」，幫助產品團隊知道：
- 為什麼要做這件事（目標）？
- 要怎麼做，做成什麼樣（規格）？
- 成功的標準是什麼（驗收標準）？
當一份 PRD 能夠回答這三個問題，並用團隊能理解的語言呈現，就已經完成八成任務。
⠀⠀
但 PRD 並非萬能，也不需要所有需求都撰寫一份長篇文件，產品經理可以依照「需求顆粒度」決定是否需要 PRD，以下的情境通常會撰寫 PRD：
- 新型需求，需釐清邏輯：如「AI 生成商品敘述」，須釐清 AI input 來源、觸發時機、AI Output 內容等。
- 既有功能，但有迭代新邏輯：如「會員制度調整、訂單流程重構」，須界定新的邏輯機制等。
基本原則是「新頁面 / 新邏輯 / 新機制」都會需要 PRD。
⠀⠀
但也有些情境不需特別寫 PRD，可直接在看板工具開 Ticket 的方式：
- 前端介面顯示：UI 按鈕調整、文案修正、增加 Tooltips
- 後端欄位調整：增加某欄位的限制、增加阻擋條件
- 特殊開關設定：開啟某個配置或設定
- 日常維運處理：壓資料、刪資料
上述項目並不是全新功能，主要是日常維運、或是小細節優化，因此重點在於是否有清楚記錄修改工單即可。
⠀⠀
二、PRD 應包含的核心架構
⠀⠀
PRD 雖然每間公司都不太一樣，目前常見的 PRD 架構如下：
1. 專案背景
- 為什麼現在要做這個功能？（e.g. 凸顯產品特色、滿足 OO 需求）
- 目前的問題或機會是什麼？（e.g. 上架流程過於繁瑣）
⠀⠀
2. 專案目標
- 本次需求希望達成什麼？（e.g. 優化某個使用流程）
- 有沒有可衡量的指標？（e.g. 提升客單價、流程時間縮短、滿意度上升）
⠀⠀
3. 用戶流程
- 用戶的主要操作路徑、或角色行為描述？（User Journey）
⠀⠀
4. 競品分析
- 當前產品的情況，包括現有功能、既存問題等
- 競品的類似產品或功能，可作為功能規劃設計的參考
⠀⠀
5. 需求描述
- 功能描述：使用者流程、介面元素
- 邏輯規則：觸發條件、例外處理、防呆機制、資料流、狀態表
⠀⠀
6. 開發時程
- 相關時程：Planning、開發時間、驗收時間、上線時間
三、PRD 的撰寫原則與風格建議
⠀⠀
因為 PRD 的目的是讓產品團隊看得懂，因此撰寫方式有時也會依照不同公司會有不同文化，但大方向可參考：
⠀⠀
1. 先說動機：聚焦「為什麼這樣做」、「目的是什麼」
盡量不要一開始就開始講各種細節規則，要先讓人理解為什麼要做這件事、以及為什麼要用這個流程來解決使用者任務。
2. 流程示意：盡量用條列式與示意圖，降低閱讀負擔
盡可能使用清晰的項目符號、流程圖、使用情境示意圖，減少大篇文字段落。
3. 明確標準：避免模糊描述的規格
避免寫出「適度寬度的欄位」，請寫出「商品名稱最多 100 字，商品描述最多 2000 字」的限制或標準。
4. 版更記錄：針對每次變更要有備註或提示
有些產品團隊在更新需求時，會直接異動 PRD，這時都要註記更新日期與變更內容，避免工程師已經開發完畢但沒注意到需求變更。
5. 彈性心態：不迷信格式，以團隊習慣為主
PRD 並不是 100 頁的作文比賽，有些 RD 習慣直接從 Figma 看規格，或是直接看每個 User Story 的卡片摘要，因此 PRD 具體要寫到多細滿大部分是看團隊的習慣默契。
⠀⠀
五、常見失敗範例與改善建議
⠀⠀
案例一：寫太短，缺少關鍵資訊和邏輯
PRD：「請依 Figma 設計做一個 AI 文案生成按鈕」→ 未說明觸發條件、輸入給 AI 的資訊、AI 輸出的格式。
📌 改善方式：補上功能背景、操作流程、輸入條件等，讓開發理解完整情境，和 Prompt。
案例二：PRD 和 Figma 規則不一致
PRD 的商品名稱限制 50 字，但 Figma 卻標註可以到100 字。
📌 改善方式：PM 要事前自己比對 PRD 和 Figma 的所有規則，並說明若有不一致要以哪份為最終結果。
案例三：未定義錯誤流程與例外情況
PRD 中未提到「打 API 失敗的狀況」→ 測試時才發現會有 Timeout 狀況，但介面沒有向使用者說明。
📌 改善方式：PM 在每個功能流程需考慮各種例外狀況，例如 timeout、輸入錯誤、載入異常、資訊不足等。
案例四：沒有驗收標準或案例，導致 RD 和 QA 認知不同
PRD 只有提到想要「AI 生成商品描述」，但具體要生什麼文案出來、要抓什麼欄位沒有定義好，導致 QA 無法針對結果進行驗收。
📌 改善方式：PM 要提供每個功能的最終樣貌，確保 RD 自己開發完可以先產出結果，QA 也能依照 PM 的驗收標準去展開測試項目。
⠀⠀
六、結語：PRD 是產品經理的思考軌跡
⠀⠀
寫 PRD 的目的是為了幫助團隊「同步共識」與「正確執行」。
在撰寫 PRD 的過程中，產品經理也能對流程脈絡更清晰，將抽象的想法變成可驗證的需求，同時也要留意 PRD 不是寫作文，並不是寫到 50 頁就叫做很完整，還要看產品團隊需要看哪些必要資訊，但這個需要好幾次的練習才能抓到團隊默契。
⠀⠀
如對這系列文章有興趣可以再觀看：
