PRD 產品需求文件

說明產品目標、使用者情境、功能範圍、限制與驗收標準的文件。

先用一句話理解

英文全名：Product Requirements Document

說明產品目標、使用者情境、功能範圍、限制與驗收標準的文件。

打個比方

像蓋房子前的設計圖與需求清單。

什麼時候會遇到

多人協作、接案或需求容易變動時。

再往深一點看

PRD 的核心功能是讓每個參與這個功能的人——產品、設計、工程——對「我們要解決什麼問題、誰的問題、怎樣算做完」有共同的理解。它不只是功能清單，更重要的部分是「為什麼要做」和「不做什麼」：把 scope 明確界定在這份文件裡，可以阻止後來的需求蔓延。PRD 和 user story 的關係是：user story 是從使用者角度描述單一需求，而 PRD 是把多個 user story 放在一起，補上背景、限制、成功指標，成為整個功能的對齊文件。

舉個例子

你在 Notion 裡為「會員訂閱功能」寫 PRD：包含目標用戶（付費意願高的進階用戶）、核心流程（用 Stripe 訂閱、管理頁取消）、不包含項目（發票功能留到下個版本），以及驗收標準——設計師和工程師各自從這份文件拿到足夠資訊，不需要再來問你同樣的問題。

常見誤解

- 只寫功能名稱，沒有寫使用者是誰、這功能解決什麼問題、驗收標準是什麼——工程師只好自己猜，做出來的不是客戶想要的。
- PRD 寫完就鎖進文件夾沒人看，開發過程需求悄悄改動但沒更新文件，最後文件和實際做的對不上，驗收時才發現。
- 把 PRD 寫得太長太細，每個欄位都想把所有情境寫進去，文件變成 20 頁沒人讀完，反而失去對齊的作用。