product-management

schema	1.0
name	product-management
version	1.0.0
description	產品管理：PRD撰寫、用戶故事、OKR設定、路線圖規劃
domain	business
triggers	{"keywords":{"primary":["PRD","產品需求","user story","OKR","roadmap","產品經理","product manager"],"secondary":["路線圖","產品規格","spec","功能規劃","feature","backlog","RICE","MoSCoW"]},"context_boost":["需求","requirement","規劃","planning","優先級","priority"],"context_penalty":["code","程式碼","database","api"],"priority":"high"}
dependencies	{"software-skills":["documentation","api-design"]}
author	claude-domain-skills

產品管理 Product Management

從需求到交付的完整產品開發流程

適用場景

• 撰寫產品需求文件（PRD）
• 定義用戶故事和驗收標準
• 設定 OKR 和成功指標
• 規劃產品路線圖
• 功能優先級排序

PRD 結構框架

┌─────────────────────────────────────────────────────────────────┐
│  PRD 標準結構                                                   │
│                                                                 │
│  1. 概述 Overview                                               │
│     ├─ 問題陳述（為什麼做）                                    │
│     ├─ 目標用戶（為誰做）                                      │
│     └─ 成功指標（如何衡量）                                    │
│                                                                 │
│  2. 需求詳情 Requirements                                       │
│     ├─ 功能需求（User Stories）                                │
│     ├─ 非功能需求（效能、安全）                                │
│     └─ 設計約束                                                │
│                                                                 │
│  3. 設計 Design                                                 │
│     ├─ 用戶流程                                                │
│     ├─ 線框圖/原型連結                                         │
│     └─ 邊界情況處理                                            │
│                                                                 │
│  4. 技術考量 Technical                                          │
│     ├─ 架構影響                                                │
│     ├─ API 需求                                                │
│     └─ 依賴項目                                                │
│                                                                 │
│  5. 上線計劃 Launch                                             │
│     ├─ 里程碑                                                  │
│     ├─ 風險評估                                                │
│     └─ 驗收標準                                                │
└─────────────────────────────────────────────────────────────────┘

User Story 格式

### 標準格式
As a [用戶角色]
I want [功能/目標]
So that [價值/原因]

### 驗收標準 (Acceptance Criteria)
Given [前提條件]
When [觸發動作]
Then [預期結果]

### 範例
As a 電商買家
I want 保存商品到願望清單
So that 我可以稍後購買

驗收標準：
- Given 用戶已登入
- When 點擊「加入願望清單」
- Then 商品出現在願望清單中
- And 顯示成功提示

OKR 設定框架

元素	說明	範例
Objective	定性目標，激勵人心	成為最受信任的支付平台
Key Result 1	可量化的結果	NPS 從 45 提升到 60
Key Result 2	可量化的結果	交易成功率達 99.9%
Key Result 3	可量化的結果	客訴處理時間 < 2 小時

OKR 檢查清單

□ Objective 是否具有挑戰性但可達成？
□ Key Results 是否可量化？
□ Key Results 是否有明確的基準和目標值？
□ 是否有 3-5 個 Key Results？
□ 是否設定了檢查週期？

優先級排序框架

RICE Framework

維度	說明	評分
Reach	影響多少用戶	用戶數/季
Impact	影響程度	0.25/0.5/1/2/3
Confidence	信心程度	50%/80%/100%
Effort	開發成本	人月

RICE Score = (Reach × Impact × Confidence) / Effort

MoSCoW 分類

分類	說明
Must have	核心功能，沒有就不能上線
Should have	重要功能，但可以後續迭代
Could have	錦上添花，有時間就做
Won't have	這次不做，明確排除

路線圖模板

## Q1 2025

### 主題：基礎建設
- [ ] 用戶認證系統重構
- [ ] API Gateway 升級
- [ ] 監控系統建置

### 里程碑
- 1/15: 技術設計完成
- 2/28: 開發完成
- 3/15: 上線

---

## Q2 2025

### 主題：用戶體驗優化
- [ ] 新版首頁
- [ ] 搜尋功能強化
- [ ] 個人化推薦 V1

常見錯誤

錯誤	正確做法
PRD 寫太詳細像設計文件	聚焦 What & Why，留 How 給工程團隊
User Story 沒有驗收標準	每個 Story 必須有明確的 AC
OKR 設太多	聚焦 3-5 個最重要的
路線圖鎖死日期	用「主題」而非「功能清單」

溝通模板

功能規格簡報

# [功能名稱]

## 一句話描述
[用一句話說明這個功能是什麼]

## 為什麼做
- 用戶痛點：[描述]
- 商業價值：[描述]

## 做什麼
- [功能點 1]
- [功能點 2]

## 不做什麼
- [明確排除的範圍]

## 成功指標
- [指標 1]: 從 X 到 Y
- [指標 2]: 從 X 到 Y

## 時程
- 設計：X 週
- 開發：X 週
- 測試：X 週

相關資源

• Inspired - Marty Cagan
• Shape Up - Basecamp
• The Mom Test - Rob Fitzpatrick

產品發現 (Product Discovery)

用戶訪談技巧

┌─────────────────────────────────────────────────────────────────┐
│  The Mom Test 原則                                               │
│                                                                 │
│  ❌ 不要問：「你覺得這個功能好不好？」                          │
│  ✅ 要問：「你上次遇到這個問題是什麼時候？怎麼解決的？」        │
│                                                                 │
│  ❌ 不要問：「你會用這個產品嗎？」                              │
│  ✅ 要問：「你現在怎麼處理這件事？花多少時間/金錢？」          │
│                                                                 │
│  核心原則：                                                      │
│  1. 談過去的行為，不談未來的意願                                │
│  2. 談具體事例，不談一般情況                                    │
│  3. 讓用戶說，你只問問題                                        │
└─────────────────────────────────────────────────────────────────┘

訪談問題範例

階段	問題
開場	能聊聊你的工作/日常嗎？
挖掘痛點	最近遇到最讓你頭痛的問題是什麼？
了解行為	你現在是怎麼處理的？
量化影響	這個問題讓你花多少時間/錢？
替代方案	你有嘗試過其他解決方法嗎？
驗證需求	如果有工具能解決這個問題，你願意付多少錢？

數據驅動決策

產品指標體系

┌─────────────────────────────────────────────────────────────────┐
│  North Star Metric + Supporting Metrics                          │
│                                                                 │
│                    ┌──────────────┐                             │
│                    │  North Star  │  ← 核心價值指標             │
│                    │   Metric     │     例：Weekly Active Users │
│                    └──────┬───────┘                             │
│           ┌───────────────┼───────────────┐                     │
│           ↓               ↓               ↓                     │
│     ┌─────────┐     ┌─────────┐     ┌─────────┐                │
│     │ 獲取    │     │ 活躍    │     │ 變現    │                │
│     │ 新用戶數│     │ 留存率  │     │ ARPU    │                │
│     └─────────┘     └─────────┘     └─────────┘                │
│                                                                 │
│  原則：North Star 要能代表用戶獲得的核心價值                    │
└─────────────────────────────────────────────────────────────────┘

A/B 測試框架

## A/B 測試規劃

### 1. 假設
「我們相信 [改變] 會導致 [結果]，因為 [原因]」

### 2. 指標
- 主要指標：[要優化的核心指標]
- 護欄指標：[確保不會傷害的指標]

### 3. 樣本計算
- 最小可檢測效果 (MDE)：X%
- 統計顯著性：95%
- 所需樣本量：N users
- 預計實驗時長：X 天

### 4. 實驗設計
- 對照組：當前版本
- 實驗組：新版本
- 分流比例：50/50

### 5. 決策標準
- p-value < 0.05 且效果 > MDE → 上線
- p-value < 0.05 但效果 < MDE → 考慮
- p-value > 0.05 → 不上線

產品文檔最佳實踐

PRD 撰寫技巧

技巧	說明
一頁摘要	開頭用一頁說明核心，讓人快速理解
用戶視角	從用戶體驗角度描述，不是技術實現
視覺優先	用流程圖、線框圖取代大段文字
版本控制	記錄修改歷史，標註版本號
連結而非複製	引用設計稿/技術文檔連結

文檔更新頻率

文檔類型	更新頻率	負責人
產品願景	季度	PM Lead
路線圖	月度	PM
PRD	按需	PM
發布說明	每次發布	PM

跨團隊協作

RACI 矩陣

任務	PM	設計	工程	QA
需求定義	R	C	C	I
UI 設計	A	R	C	I
技術設計	C	I	R	I
開發實作	I	C	R	I
測試驗收	A	I	C	R

R=Responsible, A=Accountable, C=Consulted, I=Informed

常見跨團隊衝突

衝突	解決方法
需求理解不一致	用 User Story + AC 確保共識
時程估算分歧	工程主導估算，PM 協調優先級
設計與技術限制	提早拉工程參與設計評審
範圍蔓延	嚴守 MoSCoW，變更走正式流程

工具推薦

• 需求管理：Jira, Linear, Notion
• 設計協作：Figma, Sketch
• 用戶研究：Hotjar, FullStory, Maze
• 數據分析：Amplitude, Mixpanel, GA4
• 路線圖：ProductBoard, Aha!, Notion

---

Sharp Edges（常見陷阱）

這些是產品管理中最常見且代價最高的錯誤

SE-1: Feature Factory 陷阱

• 嚴重度: critical
• 情境: 團隊專注於「產出」（output）而非「成果」（outcome），一直做新功能卻不驗證價值
• 原因: 用完成的 Story Points 或功能數量衡量成功，而非用戶價值
• 症狀:
  • 每次迭代都有新功能上線，但核心指標沒成長
  • 產品越來越複雜，用戶卻越來越困惑
  • 團隊很忙但感覺沒有成就感
• 檢測: velocity|story.?points|功能數|features.?delivered
• 解法: 每個功能上線後 2-4 週必須驗證假設，用 outcome-based roadmap

SE-2: 利害關係人主導

• 嚴重度: high
• 情境: 優先級被老闆、業務、大客戶決定，而非用戶數據和產品策略
• 原因: 組織缺乏數據文化，決策靠「聲量最大」或「職位最高」
• 症狀:
  • 路線圖經常因「重要人物要求」而改變
  • 功能需求來源多是「客戶說要」而非用戶研究
  • PM 變成「接需求的」而非「做決策的」
• 檢測: 老闆說|業務要求|大客戶需要|客戶反饋|緊急插單
• 解法: 建立優先級框架（RICE），用數據說話，學會說不

SE-3: 指標操弄

• 嚴重度: critical
• 情境: 團隊優化「指標」而非「用戶價值」，導致指標漂亮但產品體驗變差
• 原因: Goodhart's Law - 當指標變成目標，就不再是好指標
• 症狀:
  • DAU 上升但留存率下降（用 push 通知轟炸）
  • 轉化率上升但退貨率也上升（用暗黑模式）
  • NPS 上升但都是「邀請好友填問卷」
• 檢測: 提升.*DAU|增加.*轉化|優化.*指標
• 解法: 設定「護欄指標」（guardrail metrics），確保不會傷害用戶

SE-4: PRD 瀑布

• 嚴重度: medium
• 情境: PRD 寫得太詳細，變成 100 頁的規格書，工程師照做但沒有理解
• 原因: PM 想「一次寫完」避免後續溝通，但忽略了不確定性
• 症狀:
  • PRD 超過 10 頁
  • 工程師說「我按照 PRD 做的」但結果不對
  • 需求變更時改 PRD 比改 code 還久
• 檢測: PRD.*頁|需求文件.*詳細|spec.*完整
• 解法: PRD 聚焦 What & Why，留 How 給團隊；用 One-Pager 開始，逐步細化

SE-5: 路線圖承諾

• 嚴重度: high
• 情境: 路線圖從「計劃」變成「承諾」，團隊失去調整空間
• 原因: 銷售/行銷把路線圖賣給客戶，或老闆把路線圖當 KPI
• 症狀:
  • 「因為已經答應客戶了」成為優先級理由
  • 即使發現方向錯誤也不敢調整
  • 團隊趕著做功能，沒時間做對的事
• 檢測: Q[1-4].*必須完成|已經承諾|deadline.*不能改
• 解法: 路線圖用「主題」不用「功能清單」，保留 30% buffer