產品管理：PRD撰寫、用戶故事、OKR設定、路線圖規劃
npx skills add https://github.com/miles990/claude-domain-skills --skill product-managementKopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um den Skill zu installieren
非技術領域專業知識集合，包含商業、金融、創意、專業服務、生活、方法論等 18 個領域
數位行銷策略、內容行銷與成效分析
專案管理：敏捷開發、Scrum、甘特圖、風險管理、團隊協作
銷售技巧：B2B/B2C 銷售、客戶開發、電商營運、成交策略
商業策略：藍海策略、差異化、競爭優勢、價值創新、商業模式設計
創意發想：頭腦風暴、靈感激發、創意思維框架、發散與收斂思考
| 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 |
從需求到交付的完整產品開發流程
┌─────────────────────────────────────────────────────────────────┐
│ PRD 標準結構 │
│ │
│ 1. 概述 Overview │
│ ├─ 問題陳述（為什麼做） │
│ ├─ 目標用戶（為誰做） │
│ └─ 成功指標（如何衡量） │
│ │
│ 2. 需求詳情 Requirements │
│ ├─ 功能需求（User Stories） │
│ ├─ 非功能需求（效能、安全） │
│ └─ 設計約束 │
│ │
│ 3. 設計 Design │
│ ├─ 用戶流程 │
│ ├─ 線框圖/原型連結 │
│ └─ 邊界情況處理 │
│ │
│ 4. 技術考量 Technical │
│ ├─ 架構影響 │
│ ├─ API 需求 │
│ └─ 依賴項目 │
│ │
│ 5. 上線計劃 Launch │
│ ├─ 里程碑 │
│ ├─ 風險評估 │
│ └─ 驗收標準 │
└─────────────────────────────────────────────────────────────────┘
### 標準格式
As a [用戶角色]
I want [功能/目標]
So that [價值/原因]
### 驗收標準 (Acceptance Criteria)
Given [前提條件]
When [觸發動作]
Then [預期結果]
### 範例
As a 電商買家
I want 保存商品到願望清單
So that 我可以稍後購買
驗收標準：
- Given 用戶已登入
- When 點擊「加入願望清單」
- Then 商品出現在願望清單中
- And 顯示成功提示
| 元素 | 說明 | 範例 |
|---|---|---|
| Objective | 定性目標，激勵人心 | 成為最受信任的支付平台 |
| Key Result 1 | 可量化的結果 | NPS 從 45 提升到 60 |
| Key Result 2 | 可量化的結果 | 交易成功率達 99.9% |
| Key Result 3 | 可量化的結果 | 客訴處理時間 < 2 小時 |
□ Objective 是否具有挑戰性但可達成？
□ Key Results 是否可量化？
□ Key Results 是否有明確的基準和目標值？
□ 是否有 3-5 個 Key Results？
□ 是否設定了檢查週期？
| 維度 | 說明 | 評分 |
|---|---|---|
| Reach | 影響多少用戶 | 用戶數/季 |
| Impact | 影響程度 | 0.25/0.5/1/2/3 |
| Confidence | 信心程度 | 50%/80%/100% |
| Effort | 開發成本 | 人月 |
RICE Score = (Reach × Impact × Confidence) / Effort
| 分類 | 說明 |
|---|---|
| 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 週
┌─────────────────────────────────────────────────────────────────┐
│ The Mom Test 原則 │
│ │
│ ❌ 不要問：「你覺得這個功能好不好？」 │
│ ✅ 要問：「你上次遇到這個問題是什麼時候？怎麼解決的？」 │
│ │
│ ❌ 不要問：「你會用這個產品嗎？」 │
│ ✅ 要問：「你現在怎麼處理這件事？花多少時間/金錢？」 │
│ │
│ 核心原則： │
│ 1. 談過去的行為，不談未來的意願 │
│ 2. 談具體事例，不談一般情況 │
│ 3. 讓用戶說，你只問問題 │
└─────────────────────────────────────────────────────────────────┘
| 階段 | 問題 |
|---|---|
| 開場 | 能聊聊你的工作/日常嗎？ |
| 挖掘痛點 | 最近遇到最讓你頭痛的問題是什麼？ |
| 了解行為 | 你現在是怎麼處理的？ |
| 量化影響 | 這個問題讓你花多少時間/錢？ |
| 替代方案 | 你有嘗試過其他解決方法嗎？ |
| 驗證需求 | 如果有工具能解決這個問題，你願意付多少錢？ |
┌─────────────────────────────────────────────────────────────────┐
│ North Star Metric + Supporting Metrics │
│ │
│ ┌──────────────┐ │
│ │ North Star │ ← 核心價值指標 │
│ │ Metric │ 例：Weekly Active Users │
│ └──────┬───────┘ │
│ ┌───────────────┼───────────────┐ │
│ ↓ ↓ ↓ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 獲取 │ │ 活躍 │ │ 變現 │ │
│ │ 新用戶數│ │ 留存率 │ │ ARPU │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ 原則：North Star 要能代表用戶獲得的核心價值 │
└─────────────────────────────────────────────────────────────────┘
## 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 → 不上線
| 技巧 | 說明 |
|---|---|
| 一頁摘要 | 開頭用一頁說明核心，讓人快速理解 |
| 用戶視角 | 從用戶體驗角度描述，不是技術實現 |
| 視覺優先 | 用流程圖、線框圖取代大段文字 |
| 版本控制 | 記錄修改歷史，標註版本號 |
| 連結而非複製 | 引用設計稿/技術文檔連結 |
| 文檔類型 | 更新頻率 | 負責人 |
|---|---|---|
| 產品願景 | 季度 | PM Lead |
| 路線圖 | 月度 | PM |
| PRD | 按需 | PM |
| 發布說明 | 每次發布 | PM |
| 任務 | 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，變更走正式流程 |
這些是產品管理中最常見且代價最高的錯誤
velocity|story.?points|功能數|features.?delivered老闆說|業務要求|大客戶需要|客戶反饋|緊急插單提升.*DAU|增加.*轉化|優化.*指標PRD.*頁|需求文件.*詳細|spec.*完整Q[1-4].*必須完成|已經承諾|deadline.*不能改