roadmap-planning
作者 deanpetersroadmap-planning 技能能幫助產品經理把目標、需求與限制，轉化為一份站得住腳的 roadmap，涵蓋優先順序、epic 定義、利害關係人對齊與排程安排。當你需要一個清楚交代「現在、接下來、之後」的敘事時，這項技能很適合用在 Product Management 的 roadmap-planning。
這項技能獲得 83/100 分，代表它很適合想要結構化 roadmap-planning 工作流程、而不是泛用提示詞的目錄使用者。這個 repository 提供了足夠清楚的內容，足以判斷它可安裝，且很可能有助於減少策略性 roadmap 建立時的猜測成本；不過它缺少支援檔與安裝時輔助資訊，因此實際導入的便利性還有提升空間。
- 觸發情境明確：frontmatter 清楚定義了適用時機，例如 Q2 規劃、6 個月 roadmap 與高階主管審查。
- 流程價值高：技能內容相當完整，明確涵蓋優先順序、epic 定義、利害關係人對齊、排程與溝通等 roadmap 規劃階段。
- 有助於安裝判斷：包含 roadmap 範本與實作範例，展示以成果為導向的規劃方式，對比薄弱的功能清單式作法。
- 沒有安裝指令、腳本或支援檔，因此使用者必須主要依賴 markdown 說明。
- repository 參照了其他技能（例如 prioritization-advisor.md），可能帶來類似相依性的脈絡，但這些內容並未一併打包在此。
Roadmap-planning 技能概覽
roadmap-planning 技能能幫產品經理把零散的需求、目標與限制，整理成一份能通過利害關係人檢視的策略藍圖（roadmap）。它最適合的不是單純列功能清單的團隊，而是需要有排序邏輯、取捨理由，以及清楚說明為什麼某些項目現在做、接下來做、或稍後再做的團隊。如果你是在做 Product Management 的 roadmap-planning，這個技能就是為了幫你完成從策略到執行的交接。
roadmap-planning 的用途
當你手上已經有像是 OKR、客戶痛點、相依關係，以及初步構想的 initiative，但還需要一份有脈絡的發版計畫時，就該用這個技能。它要解決的是把工作優先順序排出來、把 epics 定義在適當層級，並讓 roadmap 對齊成果而不是只對齊產出。這樣一來，roadmap 更容易在高層溝通時站得住腳，也更方便交付團隊執行。
什麼情況下特別適合 roadmap-planning
roadmap-planning 技能很適合年度規劃、季度規劃，以及跨團隊排序這類「選擇比數量更重要」的場景。當多個利害關係人都提出不同需求，而你需要一套有紀律的方法來決定先做什麼時，它尤其好用。如果你的核心問題是「想法太多」，這會比一般通用提示詞更合適。
roadmap-planning 的差異在哪裡
這個工作流程強調的是策略框架，不只是排版格式。它會推著你把 initiative 連到客戶問題、商業目標與相依關係，讓 roadmap 本身能說出一個故事。這樣產出的內容通常比單純的優先順序表更有說服力，因為它把工作順序背後的邏輯也一起交代清楚了。
如何使用 roadmap-planning 技能
安裝 roadmap-planning
請用 repository 裡的 skill 指令安裝 roadmap-planning 技能：
npx skills add deanpeters/Product-Manager-Skills --skill roadmap-planning
安裝後，先看 skills/roadmap-planning/SKILL.md，因為它定義了工作流程的目的、最適合的使用情境，以及預期的規劃順序。接著再看 template.md 了解輸出結構，並看 examples/sample.md 參考一個貼近實務的好壞對照。
輸入要給對內容
roadmap-planning 的使用模式，最適合你提供具體輸入，而不是一句籠統的「幫我做 roadmap」。建議提供：
- business goals 或 OKRs
- 目標客群區隔
- 候選 initiative 或 epics
- 已知的相依關係與限制
- 時間範圍，例如季度或半年
- 任何可能影響取捨的利害關係人立場
弱一點的提示會說：「幫我們規劃 roadmap。」更好的版本會說：「請為 SMB onboarding 與 retention 規劃一份 Q2 roadmap，目標是把 churn 從 15% 降到 8%，有 8 個候選 initiative、2 項工程限制，還需要展示給高層看的取捨理由。」
建議的工作流程與檔案
你可以把這個技能當成規劃助理，再用自己的產品脈絡去驗證輸出。實際上可行的流程是：
- 收集目標、客戶問題與限制。
- 草擬候選 epics，並把相關工作分組。
- 請技能依成果優先順序與排序邏輯進行優先級判定。
- 檢查 roadmap 敘事是否符合利害關係人的現實情況。
- 針對可行性、相依順序與溝通清晰度進行修訂。
如果你是在快速掃 repo，先看 SKILL.md、template.md 和 examples/sample.md。這些檔案會告訴你 roadmap 的預期樣貌、抽象層級，以及這個技能如何把策略型 roadmap 和單純的 backlog 清單區分開來。
提升輸出品質的小技巧
要明確說出哪些內容一定要保住、哪些可以調整、哪些部分仍不確定。當你把像是上市時程、團隊產能或被卡住的相依項目這類硬性限制講清楚時，roadmap-planning 指南會更好用。也要告訴它這份 roadmap 是內部用、高層簡報用，還是面向客戶，因為溝通語氣和細節層級都應該跟著調整。
roadmap-planning 技能 FAQ
roadmap-planning 只適合 Product Management 嗎？
它是為 Product Management 的 roadmap-planning 設計的，但其他相鄰角色如果需要有結構的發版計畫，也可以使用。它最強的地方，是有人負責優先級與利害關係人對齊，而不只是任務追蹤。如果你只是要做工程 sprint 計畫，這個技能通常會太策略性。
這和一般提示詞有什麼不同？
一般提示詞也能草擬 roadmap，但這個技能提供的是可重複使用的工作流程，涵蓋優先級判定、epic 定義、排序，以及溝通方式。這能降低最後只剩功能清單、卻缺少理由的風險。實務上，當你需要跨規劃週期維持一致性時，roadmap-planning 技能會更好用。
這個技能對新手友善嗎？
可以，只要你能提供基本的產品脈絡。你不需要一份已經打磨好的策略文件才能開始；這個技能本來就是要幫你把零散的輸入整理成一份站得住腳的 roadmap。新手如果搭配 template，並明確寫出目標與限制，通常會得到更好的結果。
什麼情況下不該用它？
如果你需要的是詳細的交付計畫、發版檢查清單，或純技術實作順序，就不適合用它。當你的輸入太不完整、無法支持取捨時，也不是好選擇。在這些情況下，先補足背景資訊，或改用更聚焦的 planning 提示詞會比較好。
如何改進 roadmap-planning 技能
提供更好的決策輸入
要最快改善 roadmap-planning 的結果，關鍵是提升你提供給模型的輸入品質。加入客戶證據、目標指標，以及你真正正在考慮的少數幾個 initiative。如果你只給願望清單，輸出通常也只會照單全收，而不會幫你做艱難的選擇。
及早說明取捨與限制
當提示詞先講清楚哪些事情不能發生時，roadmap-planning 技能通常表現最好。請告訴它產能限制、策略押注、技術相依，或會影響排序的利害關係人承諾。這能避免輸出變成不切實際的「全部現在就做」，也讓 roadmap 更容易向上說明。
請它輸出你實際會用的格式
如果你要的是給高層看的 roadmap，就請它輸出精簡敘述加上 now/next/later 結構。如果你需要的是規劃支援，就請它補上理由、風險與相依註記。roadmap-planning 指南最有用的時候，是輸出格式剛好對應你正在做的決策，而不是為了形式過度排版。
第一版之後要反覆調整
把第一次輸出當成規劃草稿，而不是最終答案。檢查優先順序是否真的符合你的策略、epics 的範圍是不是太大或太小，以及排序是否尊重相依關係。接著再重新執行 roadmap-planning，帶著修正指令，例如「把 enterprise SSO 提前」、「把 reporting 拆成兩個 epics」，或「這一季優先 retention 而不是 expansion」。