近期在產品團隊時也開始接觸產品路線圖（Product Roadmap）的制定，包含功能分類、優先級排序、時程規劃等，因此這篇想記錄我在學習產品路線圖的心得。
誰適合看這篇文章？
✔ 對產品經理、產品企劃、產品專員工作內容有興趣的朋友
✔ 對產品路線圖、產品藍圖、產品需求清單有興趣的朋友一、為什麼需要產品路線圖
在向上管理、跨部門溝通時，通常會被問到：
- 業務：能不能幫我開發 A 功能，在下個月可以完成嗎？
- 行銷：上次說的 B 功能，現在開發到哪了？這個月會上線嗎？
- 別部門主管：怎麼感覺最近都沒有新功能發布，產品團隊都在忙什麼？
- 老闆：今年上半年的重點開發功能是什麼？
不同部門都想知道產品開發狀況，同時也想請產品團隊優先滿足他們的願望，因此產品路線圖就是一個「溝通工具」。
好處有幾個：
- 向上管理回報：當老闆、投資人詢問產品發展時，可以拿出來說明現在的開發項目。
- 跨部門協商：跟其他部門溝通產品進度時，可以有效告知現在在做什麼功能，以及對方的功能會排在什麼時候。
- 凝聚產品團隊：當產品團隊內部的產品經理、產品企劃要提出新規畫時，可以更明確知道整體產品狀況，協調彼此開發順序。
- 對外新聞發表：當行銷、公關需要定時發布記者會或新聞稿時，可以明確知道產品走向以及掌握每一季的宣傳亮點。
二、怎麼規劃產品路線圖
（一）產品需求來源
在開始規劃產品路線圖前，要先確定有哪些產品需求管道，通常包含：
- 使用者反饋：從 App Store、Google Play、或網站內的匿名評價等，可以初步收集到多數使用者的痛點或需求。
- 使用者訪談：有些產品團隊有配置 User Experience Researcher 使用者經驗研究員，也可以定時從訪談者身上獲得最新的 User Story。
- 老闆和主管的產品願景：作為公司創辦人或CXO，根據競品分析、或產業趨勢、法規動向、國際市場，有時也會提出對產品的功能方向。
- 跨部門實際需求：公司內部的行銷、業務、客戶成功專員，在銷售或服務客戶時，也會提出使用痛點。
- 產品團隊期待：產品團隊的產品經理、產品企劃，也會提出自己對於產品的想像。
根據上述需求來源，要如何整理成一張產品路線圖就是一個大功課了！
（二）產品路線圖框架
一份基本的產品路線圖通常會包含：
- 大計畫：根據專案管理工具 JIRA 的用法，最高層級會用 Initiative（計畫），像是「提高客單價」、「優化購物體驗」等。
- 中項目：在大計畫下面的層級會用 Epic（史詩故事），像是「購物車系統」、「相似商品推薦系統」。
- 小功能：在中項目下面的層級會用 Ticket（票），像是「推薦邏輯機制建立」、「加購商品的運費計算機制」。
- 具體內容：此欄位可以闡述 Ticket 的 User Story，說明這項功能預期在什麼情境被使用，預計達到什麼功效。
- 優先順序：可以分成 P0（緊急且重要）、P1（緊急）、P2（重要）、P3（不緊急）。
- 預期時程：根據優先順序和工程人手，先初步規劃時間。
三、規劃完產品路線圖，然後呢？
上述的表格整理完，就是請工程師按表開發嗎？不一定，產品團隊很常需要根據每週、每個月的市場現況去調整開發順序，甚至也可能會將某個排程整個打掉。
通常會更改產品路線圖的時機：
- 隕石需求：有時老闆或高層會根據競品動向、產業趨勢、法規動向、或國際市場，臨時提出新的功能許願，並要求插隊執行，這類通常就是隕石需求（ aka 措手不及的需求或改動）。
- 開發延遲：有時遇到工程師錯估開發時程，導致時間到來不及開發完。
- 錯估範疇：有時是 PM 錯估功能範疇，每一段時間就調整 PRD 需求文件，導致需求越長越大，工程師越做越多。
- 功能打架：有時是產品團隊都未發現的邏輯盲點，例如做了 A 功能會讓特定情境的使用者無法使用 B 功能，導致要先暫緩開發。
因此在產品團隊最重要的是「保持彈性」，很多時候更改功能、需求插隊，並不是大家樂見的，但我們也必須了解團隊所有人都不是全知全能視角，身為產品經理、專案經理、或產品企劃，僅能不斷保持彈性、不要設定標準答案、快速掌握產業脈動、聆聽最新的市場需求，才能讓產品路線圖維持在最大公約數（= 多數人滿意的狀態）。
四、總結
這篇主要是紀錄最基礎的產品路線圖（Product Roadmap）可以如何撰寫，不同產品人規劃一定都會不同，有些可能會再補得更詳細，像是：
- BRD：Business Requirement Document 商業規劃文件
- MRD：Market Requirement Document 市場規劃文件
- Disclaimer：免責聲明文字
- Product Strategy：產品策略地圖、產品願景金字塔、產品定位等
或是其他項目，大家都可以針對公司內部需求去做擴充。
以上是單純我的學習心得，如對這系列有興趣，也可以持續觀看：
