القائمة
產品管理：PRD撰寫、用戶故事、OKR設定、路線圖規劃
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
非技術領域專業知識集合，包含商業、金融、創意、專業服務、生活、方法論等 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.*不能改