← 手冊總覽

PART 2 · 從需求形成 PRD

2.2

建立 PRD 初稿

將產品機會組裝成清楚、可檢查的 PRD 初稿。

WHY|把零件組裝成可討論的規格

  • 2.1 給的是零散的零件,還沒有排成使用者實際會走的流程。
  • 沒有先決定 MVP 範圍,很容易把所有想到的功能都塞進去,做不完也做不好。
  • 一份完整的 PRD,能讓工程師、設計師不用再回頭問「這個到底要不要做」。

PRD 的 10 個欄位,素材從哪裡來?

欄位 素材來源
問題背景、目標使用者、使用情境、要解決的問題 1.3/2.1 已整理
產品概念、成功指標 2.1 已整理
核心使用流程、MVP 範圍、不處理的事情 本章新增:User Flow、MoSCoW
風險與待確認問題 帶入 1.3 假設清單,並補充本章新發現

HOW|依「鋪流程 → 檢查 → 定範圍 → 排序 → 組裝」的 5 個方法

1. User Flow

把 2.1 的 User Story 畫成使用者實際操作的流程圖

接單前往店家顯示預估
等待時間
是否先接
下一單?
取餐送達

例:把 2.1 的 User Story 拆成 6 個步驟,中間插入關鍵決策點,方便後面檢查每一步是否必要。

2. Impact Mapping

從目標往下拆,檢查每個流程步驟是不是真的對目標有幫助

目標:降低外送員因等待取消訂單
Actor:外送員Impact:能提前規劃行程Deliverable:顯示預估等待時間
Actor:店家Impact:減少被催單Deliverable:暫無對應功能

例:「顯示預估等待時間」連得到目標;店家 Actor 沒有對應功能,則是未來可探索的機會。

3. MoSCoW

把檢查過的功能分成 Must/Should/Could/Won't

Must顯示預估等待時間
Should等待超時提醒
Could顯示店家忙碌程度
Won't即時串接店家出餐系統

例:預估等待時間是這次一定要做的 Must;即時串接店家系統則明確列為這次不做的 Won't。

4. RICE Scoring

針對 Should/Could 的功能,用分數排出優先順序

功能ReachImpactConfidenceEffortRICE Score
等待超時提醒800人/月2(高)70%1人月1120
顯示店家忙碌程度500人/月1(中)40%(推估)3人月67

例:沒有真實數據時,可合理推估 Reach 與 Confidence,但必須清楚標記為「推估」。公式為 (Reach × Impact × Confidence) / Effort。

5. One-Pager PRD

把以上所有結果,收斂成一頁完整的 PRD

  1. 問題背景外送員因無法預期等待時長而焦躁,可能取消訂單。
  2. 目標使用者兼職與全職外送員。
  3. 使用情境抵達店家發現要等 15 分鐘以上。
  4. 要解決的問題不知道還要等多久,無法決定要不要先接下一單。
  5. 產品概念訂單頁面顯示「預估出餐等待時間」。
  6. 核心使用流程接單→前往店家→顯示等待時間→決定是否先接單→取餐→送達。
  7. MVP 範圍Must:預估等待時間;Should:超時提醒(RICE 排序第一)。
  8. 不處理的事情不即時串接店家系統,不做忙碌地圖。
  9. 成功指標外送員因等待而取消訂單的比例。
  10. 風險與待確認問題店家歷史出餐資料是否足夠準確。

例:用 10 項檢查清單收納前面方法的產出;資訊不足時標記待確認,不自行補造內容。

工具箱|讓 PRD 初稿可交付

這三張卡不會取代前面的五個方法;它們將需求、範圍與已知條件整理成工程、設計和利害關係人都能接手討論的紀錄。

01

需求追溯卡

把每個 Must-have 功能連回產品目標、流程節點與成功指標;要砍功能時,能看清楚會影響什麼。

需求支援目標流程節點優先級成功指標
顯示預估
等待時間
降低外送員
等待取消率
抵達店家後
查看訂單
Must因等待而
取消的比例
02

限制與相依卡

分開記錄假設、實作限制與外部相依;若其中一項不成立,就能及早知道要調整哪個範圍。

假設店家歷史出餐資料足以推估等待時間。
限制MVP 不串接店家即時出餐系統。
相依可取得訂單與店家歷史資料。
若不成立改顯示較粗略的等待區間,並列為待驗證風險。
03 · 進階選配

Must-have 驗收條件卡

替最重要的功能寫下可觀察的結果與例外情境,讓 Must 不只是功能名稱。它只檢查單一功能,不取代 2.3 的整份 PRD 就緒檢查。

功能顯示預估等待時間

情境外送員抵達店家後開啟訂單。

可驗收結果頁面顯示 ETA 區間與資料更新時間。

例外情境資料不足時,顯示無法估計與下一步提示。

WHAT|提示詞範例

User Flow 提示詞
以下是我們的 User Story:

【貼上 2.1 的 User Story】

請幫我把這個故事拆成一個完整的使用者流程(User Flow),包含:
1. 每個步驟使用者具體在做什麼
2. 標出流程中的關鍵決策點(使用者需要做選擇的地方)
3. 標出流程的起點和終點

請用條列步驟呈現,不要跳過任何一個使用者實際會經歷的動作。
Impact Mapping 提示詞
我們的目標是:

【填入目標,例如:降低取消率、提升某個行為比例】

以下是我們目前規劃的流程與功能:

【貼上 User Flow】

請幫我用 Impact Mapping 的方式檢查:
1. 誰(Actor)能幫助我們達成這個目標?
2. 這些人需要做出什麼改變(Impact),目標才會被達成?
3. 我們規劃的每個功能(Deliverable),分別對應到哪個 Impact?
4. 有沒有哪個功能,其實對目標沒有明顯幫助?

請誠實指出可能對目標沒有貢獻的功能,不要為了保留它硬找理由。
MoSCoW 提示詞
以下是我們目前規劃的功能清單:

【貼上功能清單】

請幫我用 MoSCoW 的方式分類:
1. Must:沒有它,這次的目標就無法達成
2. Should:重要但有替代方案,可以晚一點做
3. Could:做了會更好,但不影響核心目標
4. Won't:這次明確不做

請針對每個功能說明分類理由,不要只給分類結果。
RICE Scoring 提示詞
以下是我們 MoSCoW 分類中的 Should/Could 功能:

【貼上功能清單】

請幫我用 RICE 方式評分並排序:
1. Reach:這個功能每個月大約會影響多少使用者
2. Impact:對這些使用者的影響程度(0.25=minimal、0.5=low、1=medium、2=high、3=massive)
3. Confidence:對這個估算的信心程度(百分比)
4. Effort:大約需要投入多少人月

計算方式:RICE Score = (Reach × Impact × Confidence) / Effort

如果沒有真實數據,請用合理推估填入,並明確標記「此為推估」,不要假裝是真實數據。最後依分數排序。
One-Pager PRD 提示詞
以下是我們目前累積的所有內容:

【貼上問題背景、User Story、Product Vision Board、User Flow、MoSCoW、RICE 結果】

請幫我整理成一份一頁版 PRD,包含以下 10 個項目,每項用 1–2 句話呈現:
1. 問題背景
2. 目標使用者
3. 使用情境
4. 要解決的問題
5. 產品概念
6. 核心使用流程
7. MVP 範圍
8. 不處理的事情
9. 成功指標
10. 風險與待確認問題

請用清單格式呈現;資訊不足時請標記「待確認」,不要自行虛構內容。

延伸|開源 AI Skill 資源

使用提醒:以下為社群開源延伸資源,非本手冊團隊開發或驗證;內容、網址、授權與使用方式可能變動。使用前請確認相容性與資料處理風險,引用內容時請保留原始出處與作者標註。

neurofoo/agent-skills — rice ↗

協助以 RICE 評分候選功能,列出 Reach/Impact/Confidence/Effort 的估算依據並排序,對應本節的 RICE Scoring。需搭配 Claude Code 安裝使用。

lyndonkl/claude — one-pager-prd ↗

協助產出精簡、可決策的一頁式 PRD,涵蓋問題、解法、使用者、成功指標與範圍界定,對應本節的 One-Pager PRD。需搭配 Claude Code 安裝使用。

進階:franklinxkk/ai-delivery-spec ↗

適合需要把 PRD 初稿交接給設計、工程與測試協作時使用;可協助整理需求追溯、範圍與相依、例外情境及可觀察的驗收條件。支援 Codex、Claude Code 等相容工具。

CHECKLIST|建議產出

  • 一頁版 PRD(檢查清單式摘要格式)
  • MVP 功能清單
  • 使用者流程
  • 不做清單
  • 風險與待確認事項