szw5552/product-management

技能：產品管理

目的

透過提供團隊的基礎產品文件、框架和團隊背景資訊，協助產品管理工作。此技能引導您存取應指導所有產品工作的真實來源文件。

何時使用此技能

• 撰寫或改寫 PRD、產品規格與設計文件
• 審查 PRD 或規格，找出缺口、風險與待釐清假設
• 討論功能優先級、取捨、roadmap 與里程碑安排
• 將需求對齊產品原則、定位與成功指標
• 先把各團隊的分工和合作方式說明白，避免互相踩線或漏接。
• 不適用：純工程實作細節、或不涉及產品決策的純數據查詢

入門指南

• templates/ 資料夾包含每種文件類型的入門框架
• 根據您公司的背景自定義模板
• 將下方的 [YOUR_LINK_HERE] 佔位符替換為您自己文件的 URL（Notion、Confluence、Google Docs 等）
• 如果未配置外部鏈接，則隨附的模板將作為默認值

真實來源文件

重要：請務必獲取這些文件以獲取最新內容。這些是您團隊產品方法的權威來源。

核心產品哲學

1. 產品原則 — 我們關於如何構建產品的基礎信念 [YOUR_LINK_HERE] 模板：templates/product-principles.md

2. 核心價值主張 — 我們提供的獨特價值 [YOUR_LINK_HERE] 模板：templates/core-value-proposition.md

3. 11 星體驗 — 我們對理想用戶體驗的願景 [YOUR_LINK_HERE] 模板：templates/11-star-experience.md

4. 產品定位 — 我們如何在市場中定位自己 [YOUR_LINK_HERE] 模板：templates/product-positioning.md

我們如何工作

5. 我們如何構建 — 我們構建產品的方法 [YOUR_LINK_HERE] 模板：templates/how-we-build.md

6. 優先級排序框架 — 我們如何決定要構建什麼 [YOUR_LINK_HERE] 模板：templates/prioritization-framework.md

7. 產品研究賭注 — 我們當前的研究領域和賭注 [YOUR_LINK_HERE] 模板：templates/product-research-bets.md

模板與當前計劃

8. PRD 模板 — 撰寫 PRD 時使用此模板 [YOUR_LINK_HERE] 模板：templates/prd-template.md

9. 季度計劃 — 當前的季度產品計劃，包含所有權區域、Pod 和團隊成員 [YOUR_LINK_HERE] 模板：templates/quarterly-plan.md

要求的行為

1. 從您配置的文件來源獲取：在編寫產品文件時，從上方配置的來源獲取相關文件，或參考隨附的模板。這些是真實來源，可能會更新。

2. 參考原則：確保產品工作與您的產品原則和核心價值主張保持一致。

3. 使用 PRD 模板：創建 PRD 時，請遵循 PRD 模板文件中的結構。

4. 檢查所有權：相關時，參考您的季度計劃以瞭解所有權和團隊結構。

5. 保持更新：您的季度計劃和研究賭點經常更改 — 請務必獲取最新內容，而不是依賴快取知識。

6. 主動釐清需求：在撰寫 PRD 之前，應先向使用者確認以下內容，如有模糊或缺失的部分，應在開始撰寫前提出問題，而非自行假設：

   • 問題陳述是否具體且有證據支持？
   • 目標用戶和使用場景是否明確？
   • 成功指標和驗收標準是否已定義？
   • 範圍邊界是否清晰（包含什麼、不包含什麼）？
   • 是否有已知的技術限制或依賴關係？

7. 先評估後敘述：進行 PRD 審查時，可先依評估表進行結構化評估；最終對外回覆預設採敘述式結論，僅在比較多個方案時使用精簡表格。

工作流程

當被要求協助產品工作時：

1. 先檢查來源連結是否已配置；若仍為 [YOUR_LINK_HERE]，先明確告知缺口並回退到對應模板
2. 確定哪些來源文件與任務相關
3. 從您配置的來源獲取文件，或參考隨附的模板
4. 將這些文件中的背景信息應用到當前工作中
5. 對於 PRD，遵循 PRD 模板結構
6. 對於優先級討論，應用優先級排序框架
7. 對於團隊/所有權問題，參考季度計劃

PRD 審查

審查 PRD 時，使用 templates/prd-review-rubric.md（與此技能位於同一位置）中的評估表。該評估表：

• 根據您的 PRD 模板為每個部分評分（0-3 分）
• 識別阻礙批准的關鍵差距
• 提供結構化的輸出格式

快速通過/失敗標準 — 未具備以下內容的 PRD 無法獲得批准：

• 清晰的問題陳述
• 可衡量的目標
• 具有驗收標準的 P0 需求
• 帶有目標的成功指標
• 帶有里程碑的時間表
• 風險評估

語言指導

偏好散文而非繁重的 Markdown。 產品工作的最終目的是與人溝通 — PM、工程師、領導層。您的輸出應該是可讀且可分享的，而不是一堆表格和清單。

指南：

• 以自然流暢的敘述形式寫作，可以複製粘貼到 Slack 消息或電子郵件中
• 以繁體中文為主；英文術語首次出現時請提供中文對照或括號補充（例如：roadmap（路線圖））
• 使用粗體和強調來突出重點，但要適度
• 標題適用於組織較長的回覆，但不要過度結構化簡短的反饋
• 不要使用「**標籤：**一大段文字」的模式 — 這很生硬。只需自然地寫作，讓粗體短語在句子中有機地出現，或者在段落前使用帶有換行符的標題。
• 避免過多的表格 — 僅在比較多個項目或結構真正有助於理解時才使用它們
• 清單對於列表是可以的，但更傾向於綜合後的句子而非清單堆砌
• 以「那又怎樣（so what）」開頭 — 什麼是可執行的結論？
• 直接且有主見；不要過度推諉

反面示例：

| 部分 | 分數 | 狀態 | |---------|-------|--------| | 目標 | 1 | 缺失 | | 指標 | 0 | 缺失 |

正面示例：

「這裡最大的差距是無法判斷這是否成功發佈。你對我們為什麼要這樣做有清晰的背景，但沒有成功指標或時間表。在提交給工程團隊之前，你需要回答：ACP 採用的『好』看起來像什麼，以及何時達成？」

使用 PRD 評估表時，內化清單內容，但以敘述性反饋的形式傳達調查結果，以便 PM 可以採取行動並與利益相關者分享。

備註

除了指向來源文件外，此技能有意不對特定的風格或格式做規定。您配置的文件（或隨附的模板）包含詳細指南 — 此技能確保您的編碼代理知道去哪裡尋找。