# Product Management

> 產品管理：PRD撰寫、用戶故事、OKR設定、路線圖規劃

- Skill: `miles990/product-management` (Agent Skill)
- Install (CLI): `npx skillmds@latest add miles990/product-management`
- Raw SKILL.md: https://api.skillmd.com/api/skills/miles990/product-management/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: miles990 (https://skillmd.com/u/miles990)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/miles990/product-management

---


# 產品管理 Product Management

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

## 適用場景

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

## PRD 結構框架

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

## User Story 格式

```markdown
### 標準格式
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

| 維度 | 說明 | 評分 |
|------|------|------|
| **R**each | 影響多少用戶 | 用戶數/季 |
| **I**mpact | 影響程度 | 0.25/0.5/1/2/3 |
| **C**onfidence | 信心程度 | 50%/80%/100% |
| **E**ffort | 開發成本 | 人月 |

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

### MoSCoW 分類

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

## 路線圖模板

```markdown
## Q1 2025

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

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

---

## Q2 2025

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

## 常見錯誤

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

## 溝通模板

### 功能規格簡報

```markdown
# [功能名稱]

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

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

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

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

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

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

## 相關資源

- [Inspired - Marty Cagan](https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers/dp/1119387507)
- [Shape Up - Basecamp](https://basecamp.com/shapeup)
- [The Mom Test - Rob Fitzpatrick](http://momtestbook.com/)

## 產品發現 (Product Discovery)

### 用戶訪談技巧

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

### 訪談問題範例

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

## 數據驅動決策

### 產品指標體系

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

### A/B 測試框架

```markdown
## 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