原文書名：Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty
中文書名：產品路線圖：從革新到蛻變
推薦指數：★★★★☆
何謂產品路線圖？
一說到產品路線圖（product roadmap），很多人都會聯想到功能列表（feature list）、專案計畫（project plan）與發布計畫（release plan）。這樣的使用方式，往往造成兩個明顯的問題。
第一個是計劃趕不上變化。這個場景你應該很熟悉，產品經理每兩週就在產品路線圖上塗塗改改，調整功能的先後順序以及更改預計完成時間。
第二個是對於產品願景或是產品策略的著墨過少。這個場景你應該也不陌生，聽完產品經理分享完路線圖後，只知道要做什麼功能以及什麼時候上線，但是不知道這些功能如何解決客戶的需求與問題。
有用的產品路線圖應該是用來說明你想實現的產品願景。適當的執行產品路線圖，能引導整個組織實現公司的策略。路線圖的定義如下：
為了擬聚各個利害關係人之間的支持力與協調各方所投入的努力，產品路線圖的焦點會放在你提供給客戶與組織的價值。
根據定義，路線圖是一個與利害關係人溝通的工具，內容著重在客戶與組織的價值。這個定義與大多數人的印象可能不大ㄧ樣，也就是為什麼作者認為路線圖需要革新的理由。
路線圖應該要：
- 在策略背景下規劃組織的計畫
- 把焦點放在提供價值給客戶和組織
- 納入學習，這是成功產品開發過程的一環
- 以優先項目為中心，擬聚組織向心力
- 讓客戶對產品的走向感到興奮
路線圖不應該：
- 做出產品團隊無法交付的承諾
- 浪費時間在前期設計與評估流程上
- 與專案計畫或發布計畫混為一談
路線圖不是專案計畫，我們需要明確的區分目的性與使用場景。
從上圖中，我們可以看見路線圖有五個主要組成要素，將在下一章節做詳細說明；依造時間的先後順序，簡單分成現階段、下一階段、未來展望；路線圖下方搭配著專案計畫或發布計畫使用。
路線圖關注成果，專案計畫或發布計畫關注產出。他們有各自擅長的場景，不要將兩者混在一起。
路線圖的組成要素
路線圖有五個主要組成要素，這些要素是路線圖的必要條件，有用的路線圖應該都要納入這些元素。
1. 產品願景（Product Vision）：產品願景就像是北極星一樣，指引產品前進的方向。
2. 業務目標（Business Objectives）：業務目標有助於衡量進度，讓利害關係人對產品未來的走向感到興奮。
3. 時限（Timeframe）：寬鬆且有彈性的時間表避免承諾跳票。
4. 主題（Themes）：主題要聚焦於成果而非產出。特別是以客戶需求或問題作為主題時。
5. 免責聲明（Disclaimer）：保護你免於因為承諾跳票而受到指責，也可以保護客戶，提醒客戶任何的變更都可能發生。
路線圖有五個次要組成要素，與不同的利害關係人溝通時，可以選擇性加入他們所需要知道的關鍵資訊，提供輔助路線圖的背景，而非加入過多無用的資訊。
1. 特色功能／解決方案（Features and solutions）：舉體交付項目要符合路線圖主題的需求並且解決問題。
2. 發展階段（Stage of development）：透過標籤標示出目前產品所處的階段，例如：探索、設計、原型、試生產、beta 測試。
3. 自信（Confidence）：對於各主題的自信程度，也就是達成承諾的可能性。
4. 目標客戶（Target customers）：如果產品服務的客戶不只一種，可以在路線圖中列出這些客戶。
5. 產品範疇（Product areas）：不同的產品範疇可能會有不同的業務目標。
產品願景很重要嗎？
曾幾何時，我們的路線圖窮得只剩下功能列表和完成時間。產品經理向產品團隊說明路線圖時，通常只剩下做什麼（what）的部分，好似產品團隊就是一個功能工廠（feature factory），只要專注在接單與交付。
通常這種狀況，產品經理與團隊的關係是比較緊張的，因為沒有讓團隊感受到為何而戰，團隊看不清楚產品的方向，也不知道要去哪裡。因此，好的產品經理應該要能明確提出能激勵人心的產品願景。
產品願景要做的第一件事是釐清你把產品推向市場的原因，以及產品成功對世界和組織的意義。願景是投入整體努力的主因，也是構成路線圖的基石，路線圖幫助我們計畫如何抵達目的地。
建立產品願景時，可以參考「價值主張範本」（Value Proposition template），這個方法出自 Geoffrey Moore 的著作《跨越鴻溝》（Crossing the Chasm）。
接著嘗試以下列的規則濃縮上述的資訊，歸納成適合的願景宣言：
A world where the [target customer] no longer suffers from the [identified problem] because of [product] they [benefit].
[目標客戶] 不再受 [確認的問題] 所影響，因為 [產品] 而 [獲得的好處]。
利用 Wombat 水管為例子：
A world where American landscape enthusiasts [target customer] can have a more predictable and automatic [identified problem] watering system that can perfect their lawns [benefit] with an effective water delivery system [product].
美式庭園景觀愛好者 [目標客戶] 有了可預測和自動化的 [確認的問題] 灑水系統後，因為這個有效率的供水系統 [產品] 而打造出完美的草坪 [獲得的好處]。
有些團隊會再縮減成更短的句子：
To [benefit realized] by [product differentiator].
藉由 [產品差異化因子] 來 [實現效益]。
利用 Wombat 水管為例子：
To perfect American lawns by perfecting water delivery.
完善供水，打造完美的美式草坪。
從主題發覺客戶需求
產品經理如同餐廳的行政主廚，行政主廚會制定菜單、控制烹調過程、選擇供應商、外場調配等等。在這個比喻裡，路線圖就相當於主廚的菜單，定義未來要交付的成果。不過，到目前為止，我們的菜單還是空空的，我們還需要定義菜單上的餐點、上菜的流程以及餐點要如何呈現。
這本書提到一個嶄新的做法，可以利用主題（themes）與子主題（subthemes）來表達客戶需求。簡單的說，主題具有組織結構，用於定義當前客戶重要的需求或問題。需求通常是客戶尚未擁有的東西，而問題是現有產品或現在使用的替代產品運作不正常。
主題是大方向層級的客戶需求，子主題則是更具體的特定需求。主題可以獨立存在，也能代表一組子主題。讓我們試著用一個軟體為例：
主題：解決和可用性相關的議題
子主題：分頁
子主題：導覽選單
子主題：儲存狀態
有許多的方法可以幫助我們發掘主題與子主題，例如使用者旅程地圖（user journey map），能幫助我們了解使用者解決問題時所採取的步驟。下圖是一位度假旅行者的使用者旅程，確定了幾個大階段以後，定義每個階段下使用者會採取的步驟。
我們也可以嘗試使用「機會／解決方案樹」（Opportunity-Solution Trees），這個方法很簡潔的把目標、主題、解決方案區隔開，幫助我們釐清思緒。又很棒的把這些東西聯結在一起，幫助我們建立相關性。
無論採用什麼發掘的方法，在定義主題與子主題是要專注在使用者的需求與問題上，而不是一長串的功能列表。
這麼多的需求，要怎麼排訂優先順序
為什麼排定優先順序很重要，我們可以從幾個不同的面向來討論。第一個是機會成本，我們的資源有限，當你選擇做一件事情後，等於放棄其他的機會。第二個避免「新奇想法」症候群，老闆們每天都有新奇的想法產生，很神奇的認為可以同時做一百件事情，不然就是優先順序天天在變，導致大家無所適從。
第三個是測試矩陣呈指數型成長，團隊開發的功能越多，開發下一個功能時需要的時間就越長。每增加一個功能的測試負擔不單是單一個功能測試而已，實際上，和這個功能相關的所有功能都需要做測試。通常，我們會稱它為「回歸測試」，很不幸的，測試矩陣裡的大小隨功能的數量呈指數型成長。
當然，測試團隊不可能每次都手動測試所有可能的組合，因此，自動化和抽樣有助於降低測試的工作量。
既然，排訂優先順序這麼重要，那我們是不是有比較科學的方法來排優先順序呢。這本書提供了五種方法，包含要徑分析法（Critical Path）、Kano 模型、評估客戶需求性／技術可行性／商業可行性、ROI 計分卡（ROI Scorecard）、MoSCoW。我挑選其中兩個比較簡單與實用的方法做說明。
Kano 模型
Kano 模型將客戶的期望分為三大類型：
- 期望型需求（Expected Needs）
- 基本型需求（Normal Needs）
- 興奮型需求（Exciting Needs）
期望型需求是客戶對於產品或服務的期望需求，當需求不滿足時，客戶會很不滿意；當需求滿足時，客戶也不會因而表現出非常滿意。以汽車雨刷為例子，如果製造商提供手動式雨刷，只能說滿足基本的需求，但是沒有提供的話，客戶肯定會很生氣。
基本型需求是指客戶的滿意狀況和需求滿足的程度呈現線性關係。通常品質越好，客戶的滿意度就會上升；品質下滑，客戶就會給予負面評價。以汽車雨刷為例子，如果提供間歇式雨刷，客戶會很滿意。
興奮型需求是指客戶不會過度期待的需求。但是一旦獲得滿足，客戶表現出的滿意度會非常的高。通常多提供這類型的需求，可以與其他產品產生差異化。同樣以汽車雨刷為例，如果提供雨滴感應式全自動雨刷，相信客戶會有驚喜的感覺。
評估客戶需求性／技術可行性／商業可行性
排定需求的優先順序，我們可以從這三個面向來計分。客戶需求性指的是對於客戶的價值；技術可行性是指解決這個問題，對組織來說有多簡單，當需要投入越多資金、心力與時間的解決方案，技術可行性就越低；商業可行性是指解決方案對於組織的價值，通常會以營收獲利潤來衡量，能讓公司越成功的方案，商業可行性就越高。
當我們知道定義以後，可以利用 1–3 分表示可能性，分數越高表示可能性越高。根據三個面向加總後，得出每個需求的綜合分數。通常能夠兼顧三個面向的需求，能夠得到高優先序的位置。
以汽車的特色功能為例，根據客戶需求性、技術可行性、商業可行性計算優先指數。
後記：產品路線圖 vs. 專案計畫和發布計畫，傻傻分不清楚
當我在學習專案管理的時候，我以為產品路線圖應該要是一張精美個甘特圖，上面有功能列表、開發長度、完成時間、負責人員資訊。當利害關係人第一次看到這張圖時，會被這張精美的圖表吸引，以為產品功能就可以如期如質的完成。不過你我都知道，計劃趕不上變化，很少有產品團隊可以完全地按圖施工。
當我在學習敏捷開發的時候，我以為再也不需要產品路線圖。我們只需要 Product Backlog，裡面存在放著用戶的需求與問題。當 Sprint 開始時，我們就從 Product Backlog 上方選取高優先權的項目進行開發。這樣的開發流程，容易讓我們專注在滿足當下的需求，卻忽略未來客戶的重要的需求，看近不看遠。
如果我們可以正確的使用產品路線圖，是有機會解決上面提到的兩個常見的問題。產品路線圖不是專案計畫，它是一個與利害關係人溝通的工具，幫助團隊成員達成一制性。專案計畫與發布計畫提供的是執行的細節。所以兩個工具的目的性其實有很大的差異性，盡可能不要混在一起。
我很喜歡這本書對於路線圖關於時限（timeframe）想法，因為是高層次的溝通工具，因此可以用比較粗的時間單位，譬如以季度為單位做規劃，這樣的好處是避免利害關係人認為是一個承諾，彈性的時間單位，可以幫助我們面對變化的時候，可以更從容的調整與面對。
產品經理發展出路線圖後，應該盡可能納入更多人的想法與意見，讓這份路線圖變成我們團隊的路線圖。當團隊每一個人對齊目標以後，能夠以更快更好的方式推出讓客戶滿意的產品與服務。
這本書透過深入淺出的方式介紹「產品路線圖」，帶給我很大的幫助，讓我釐清過去的一些錯誤的認知。閱讀完這本書以後，真得有一種相見恨晚的感覺。推薦這本書給所有的產品經理。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
