產品管理 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 週
相關資源
產品發現 (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
miles990