PRD 不是你「要寫的作業」，是你「必須做的決策」的書面記錄。 如果你拿著 PRD 開會時，開發、設計、測試三方各自理解不同，那不是溝通問題，是 PRD 問題——缺少的是「哪個流程走哪條路、為什麼」這件事被明確決定並寫下來。
先 PRD 還是先原型？woshipm 史上最熱討論
來源：產品經理應該先寫需求文檔還是先畫原型？（125,713 瀏覽，434 收藏，woshipm 閱讀量前排）
這篇文章之所以這麼熱，因為它問的其實是「PM 的工作流程到底是什麼」。
兩派主流觀點
派一：先做資訊架構模型，再畫原型，最後寫 PRD
- 邏輯：先想清楚「有哪些實體、什麼關係、哪些狀態」（結構），再畫「長什麼樣子」（界面），最後用 PRD 固化決策
- 適合：功能複雜、多狀態、多角色的產品（大多數 B 端系統）
- PRD 在這個模式下主要功能：存檔備案、降低溝通成本
派二：先出高保真原型，後補 PRD
- 邏輯：快速迭代、讓設計師和開發直接看原型對齊，文件反而是視覺設計之後的總結
- 適合：快速驗證期的 C 端新功能、設計資源充足的團隊
- 風險：高保真原型做了 80%，業務邏輯細節（異常流、邊界條件）仍然模糊
woshipm 社群的共識
團隊內部達成一致、高效溝通即可——沒有絕對的對錯。
但有一個判斷基準：如果你不確定要先做哪個，通常意味著你還沒想清楚「這個功能的核心業務邏輯是什麼」——這時候既不應該寫 PRD 也不應該畫原型，而是應該先把業務流程圖畫出來。
PRD 五段式框架
來源：【萬字長文】PRD 面面觀，手把手帶你寫出優秀的 PRD（49K 瀏覽，531 收藏）
PRD = 版本說明 + 需求背景 + 業務流程 + 需求列表 + 需求描述
1. 版本說明
記錄：版本號、更新日期、負責人、本次變更內容摘要。 目的：讓接手的人知道「目前的版本是什麼，改了什麼」。
2. 需求背景（5W1H）
- Who：誰是目標用戶
- What：用戶的什麼問題
- When：在什麼時間點/場景
- Where：在哪個入口/渠道
- Why：這個需求對業務的價值
- How：我們計畫怎麼解決
常見問題：PRD 沒有需求背景，開發不知道「為什麼要做」，就容易在實作中做錯決策。
3. 業務流程（泳道圖）
用泳道流程圖呈現「誰在哪個節點做什麼、決策後去哪裡」。核心價值不是「畫得漂亮」，而是讓分支路徑（異常流）被看見。
常見遺漏的流程：
- 用戶輸入錯誤時怎麼辦
- 第三方接口超時或失敗時
- 權限不足時的降級策略
4. 需求列表
按模組或優先級列出所有功能，每條功能標明：
- 功能名稱
- 優先級（P0/P1/P2）
- 關聯頁面
- 備注（特殊條件、依賴項）
5. 需求描述（每個功能的細節）
標準結構：流程圖 → 界面描述 → 業務規則
業務規則的寫法原則：
- MECE（相互獨立、完全窮盡）：確認沒有遺漏的情況
- 從主流程到分支，從正常到異常
- 避免歧義：不要寫「顯示相關推薦」，要寫「顯示同品類最近 30 天銷量前 5 的商品」
功能拆分：INVEST 原則
來源：同上（woshipm 萬字 PRD 文）
每個功能需求應該滿足：
| 字母 | 含義 | 如何做到 |
|---|---|---|
| Independent | 獨立，不依賴其他未完成功能 | 避免「先做 A 才能做 B」的強依賴 |
| Negotiable | 可協商，細節可與開發討論 | 不要在 PRD 裡規定技術實作方式 |
| Valuable | 有用戶/業務價值 | 每條需求都能說出「為什麼」 |
| Estimable | 可估工，開發能評估時間 | 描述要夠清楚，不留技術歧義 |
| Small | 夠小，一個迭代能完成 | 大功能拆小票，別寫「做一個完整電商系統」 |
| Testable | 可測試，測試工程師能寫測試案例 | 有明確的「輸入→預期輸出」 |
原型工具選擇
woshipm 社群現狀（截至 2025-2026）：
| 工具 | 適用場景 | 特色 |
|---|---|---|
| Figma | 高保真 UI、多人協作 | 業界標準，設計師首選 |
| Axure RP | 複雜交互邏輯、B 端原型 | 支援條件邏輯，PM 友好 |
| Balsamiq | 低保真快速草圖 | 刻意做成「草稿感」，避免糾結外觀 |
| 即時設計（中國版 Figma） | 國內團隊協作 | 本地化、速度快 |
選擇原則：保真度應該和你對需求的確信度成正比。 需求還在探索期，用低保真避免固化錯誤假設。
主張 vs 可佐證
- 可佐證：PRD 五段式框架和 INVEST 原則有大量業界實踐支撐，後者源自 Kent Beck 的 XP（Extreme Programming）文獻。
- 主張：「先流程圖再原型」是 PM 社群共識，但在快速迭代的初創公司常被省略——要看團隊成熟度決定。
- 證據缺口：PRD 對最終產品品質的影響，幾乎沒有嚴謹的定量研究。「PRD 越清楚交付越好」符合直覺，但難以排除其他變數（工程師能力、PM 親密度、測試覆蓋等）。
文件寫好之後，靠什麼決定「值不值得繼續投入」？靠數據——見 數據思維與用戶增長。