【PM總動員】理想與現實 — 產品路線圖（Product Roadmap）如何應用於日常工作中？
【PM總動員】是產品三眼怪的每月定期客座單元，挖掘邀請海內外業界產品開發相關領域的大大們和大家分享！本月邀請到的是目前在 Booking.com 上海分部擔任產品經理的 Celine，她在 2017 年時就前往中國求職，曾在中國的旅遊業霸主 Ctrip 攜程、接地氣的拼團服務拼多多擔任高級產品經理，擅長大型平台、2B 端以及數據算法等後台產品。在大型組織身經百戰、執行力超強的她，這次要來跟大家分享「產品路線圖」（也稱為產品藍圖）落地執行的過程。
大家好，今天要來分享一個已經被分享到爛的題目 — Product Roadmap。
那為什麼還是寫這個主題呢？因為我認為還有一個痛點沒有被解決，即每個公司的屬性不同，無法以同一個方法論概括。大公司的產品經理煩惱如何制訂偏向策略層面的規劃，以及 mission/vision 等方向領導團隊；而小公司多半受限於資源、時間的競爭和尚未培養起的產品文化，更多時候是個 feature list（不良示範請勿模仿），看著網路上很多高大上的理論、分享，但難以應用在實際工作中。
由於待過了 大公司/ 新創公司/ to B/ to C 等多種型態的公司，希望用多一點案例分享個人截止目前的經驗認為的產品路線圖是什麼，以及怎麼做。 文章分為以下區塊：
1. 所以什麼是 產品路線圖（Product Roadmap）？ a. 產品路線圖的重要性 b. 理想版的產品路線圖會涵蓋哪些內容？ c. 為什麼理想版產品路線圖總是令人卻步怯步？
2. 如果做不到理想版，還有什麼方式可以用簡化的方式達到類似的效果？ a. 簡單的產品框架：User Journey 使用者旅程/ 使用者分層/ OKR/ 金字塔結構 b. 如何快速了解使用者：可用性測試（Heuristic Evaluation）/ 使用案例（Use case）
本文案例（除了 iCHEF 案例為本人重新按照架構思考後的舉例之外），皆為實際工作中的案例，經過一定機密資訊處理後的分享，請放心食用。
1. 所以什麼是產品路線圖（Product Roadmap）？
a. 產品路線圖的重要性（也稱為產品藍圖）
產品路線圖對我來說是一種溝通的工具，跟「誰」溝通會一定程度使你的路線圖內容和其他人產生差異，即使在 Booking，每個產品經理寫出來的產品路線圖也都是完全不一樣的，但都在說明一件事情： 用戶遇到了什麼問題？而我們打算做什麼去解決問題？
有了產品路線圖，在對外部部門溝通的過程中能提升了他人對產品經理領導力的信任感，增加跨部門合作的順暢度；對內部而言，可以幫助工程師對產品從「點狀」的理解，上升到「線狀」的脈絡、「面狀」的全局觀，除了在寫代碼的時候可以給未來迭代留下更多彈性與空間，也可以激發工程師對產品的思考，產生更多正面的討論。
對產品經理而言，我認為最大的好處是有了一個練習向上思考的機會，在Crossing the Canyon: Product Manager to Product Leader 一文中，分析了為什麼大部分的人無法跨越 PM 到 PM leader，主要有兩大方向：一是對問題更廣更深的理解，二是培養團隊一起變好的能力。而重視產品路線圖，可以作為培養這兩類能力的初級練習。
b. 理想版的產品路線圖會涵蓋哪些內容？
雖然綜上所述，產品路線圖沒有一定的格式，但還是有很多主題是一定會提到的，引用我的 mentor Peter Su在2018年台北Product Tank 中以民宿安全產品發展為例，建議涵蓋以下部分：
＊產品願景（Product Vision） — 產品的存在到底給使用者提供了什麼價值？ e.g. 讓房東在平台上安心、安全的營業
＊商業目標（Business Objective）—如何與商業目標綁定（畢竟公司還是要賺錢的），並達成上述願景？ e.g. 房東拉新 / 留存（產品提供的價值可以幫助公司吸收更多房東、擴大流量）
＊主題（Theme） — 為了達到我們的產品與商業目標，經過使用者研究、數據分析後定義出我們要實現的幾個主題 e.g. 幫助房東清楚地與客人溝通入住規則，例如明確標注什麼樣的人可以預訂他們的房源。
＊時間線（Timeframe） — 在什麼樣的時間點預計達到的里程碑（注意此處並非承諾產品要在什麼時候上線什麼功能，而是可以解決什麼樣的問題、提供什麼樣的價值） e.g. 2018 Q4/ 2019 H1/ 2019 H2
＊備註（Disclaimer） — 為了給對方正確的期待，標注出潛在風險 e.g. 大公司比較常見的跨部門合作，可能會受到其他部門影響而延後進度，或是政府法規等外在因素導致的不確定性
透過以上的結構，可以清楚知道產品的價值是什麼（Value Proposition）以及要怎麼解決 xxx 問題以達到目標，整份文檔會有一個很完整、自洽的邏輯，這樣的文檔需要大量的時間打磨、討論，最終產出大家都認可的方向。
c. 為什麼理想版產品路線圖總是令人怯步？
理想版不難發現，除了產品經理需要了解公司的發展方向，還需要花時間做使用者研究、數據分析，找出用戶痛點並規劃解法。這種以季度、半年、一年較長的時間起跳，和一般的產品計畫不同，需要花更多心思解釋為什麼我們會這麼做決策，為什麼先解決A問題、再解決B問題等等。
以新創公司來說，因為缺乏使用者研究員、數據分析師，產品經理和設計師需一人分飾多角，除了顧及平日的開發需求，還須合理分配時間到長期規劃，我非常能理解這樣的忙碌程度（重要卻不緊急的事情往往容易被忽略），導致很容易跳過前面 WHY 和分析，直接進入解決方案。
但必須說這樣的規劃不是很推薦，我們可以簡化前面的組內和公司的策略匹配、使用者研究工作和數據分析，但是不能忽略這部分，因為沒有正確定位用戶問題之前就產出方案，產品上線依然後無法解決使用者的真實問題，導致團隊努力前功盡棄那就更得不償失了。
2. 如果做不到理想版，還有什麼方式可以用簡化的方式達到類似的效果？
a. 簡單的產品框架
在進入「定位使用者問題」之前，這邊想強調的是有一個清晰的產品框架，可以幫助整個產品有一個清晰的骨架，解決前面例如為什麼先做A而不是先做B的問題，這邊分享幾種我比較喜歡使用的框架：
- User Journey 使用者旅程圖 當產品橫跨了使用者旅程一半以上（範圍較廣），使用者旅程圖就會是個不錯的選擇，以旅遊業為例，假設我們今天的主題是針對疫情後的復甦，在不同旅程的階段對應不同的使用者痛點給到相應的解決方法。 舉個例子，下圖可以很清楚的比較在「推薦周邊景點」和「住宿展示最新評論」，（在不考慮其他影響例如開發成本的情前下）應該要先從前者開始做，因為覆蓋面廣、影響力比後者大。
- 使用者分層，找到你的裡想使用者 當我們專注於某一個範圍時，再用旅程圖就有點殺雞焉用牛刀了；以心願單為例對應到使用者旅程圖，主要是行前的「探索/規劃」、「比較」這兩個階段，兩個階段除了顯得整個策略有點單薄，也很難看出這個產品的細化程度。 此時我會更推薦使用者分層的方法，識別出該產品中的理想使用者，並把更多用戶變成你的理想使用者。 還是以心願單為例，我們把使用者分為了： 「全部使用者（但不可能讓全部人都使用心願單，所以僅列出示意）」 「平台上的深度使用者（瀏覽了超過三間住宿，但始終沒有用心願單）」 「僅收藏」、 「收藏＋看」、 「收藏＋看＋預定」 這幾不同的階段，顯然最後一個就是我們的理想使用者，接下來針對前面這些階段分析為什麼他們沒有往下一個階段走，進而梳理出產品架構。
- OKR（Objective, Key Result）寫法 OKR 是什麼這裡就不贅述了，搜尋其他文章已經有很多成熟的解釋，此寫法比較適合當公司已經有一個明確指標，例如使用者拉新（Acquisition）、降低客服投訴等等，適合圍繞著明確的指標往下延伸對應的目標和預期的效果，除了 O 和 KR 需要對應之外，也需注意 KR 需要有具體的數字衡量，例如： O → 提升產品穩定性與質量 KR → 每個月 Bug 比例從 10% 降到 8%/ AB實驗 bad stop 比例小於 5% …etc.
- 金字塔結構（Growth Strategy） 金字塔結構適用於產品如何驅動公司層面的策略變得更好，比較推薦新創公司，或是大公司裡面的創新業務部門使用，以下以老東家 toB 公司點餐系統 iCHEF 為例： - 基礎層（Core growth & Enable future growth）：確保一切發展的基礎，通常是系統級「不能沒有」的功能，例如提供穩定的服務。 - 加速層（Accelerate growth）：有了這些功能，可以讓你的服務在市場中拓展得更快，例如滿足從單一餐廳到中型 3–5 家小型連鎖的餐廳需要的跨店管理服務。 - 潛在機會層（Future growth）：這一層表示有些新的業務機會點可以嘗試，對目前的階段來說有些困難，但是有很好的市場機會點，例如跟外送平台連動合作，客戶在外送平台點餐，可以連動到餐廳的點餐系統，自動記入後台報表，減輕老闆跨平台操作、結算的負擔。
b. 如何簡單了解使用者？
這裡需要先強調一個觀念，即產品經理應該是最了解使用者的人，使用者研究，包含問卷、訪談、了解客訴都是平日應該要多多累積的基本功，本篇介紹的研究方法只是挑選了眾多方法中個人認為耗時較短的方法，但不代表只要會了這些方法就不需要再花時間做研究喔～
- 可用性測試 Heuristic Evaluation（HE 測試） 如果是一個直接面對用戶端的產品（to C），除了從 app store / 客服問題 等常用方式之外，很推薦使用 Heuristic Evaluation 檢視目前的產品發生什麼大的問題，這個方法簡單來說，只需要設計一個用戶主要使用的場景，請不同人幫忙走一遍同樣的場景下大家分別於到這10條準則裡面的什麼樣問題，這些問題對於測試者的嚴重程度有多少，可以簡單快速的定位使用性的問題（Usability）。 我們常見的做法會找 5 位比較了解產品同事（通常是產品經理、設計師、測試工程師等等），約了一個小時會議簡單跟大家解釋一下 HE 概念後，請大家按照設計好的路徑體驗，並記錄下過程中遇到的問題，再把這些問題分門別類後，基本上就是滿滿的改進點（product backlog）。 實測下來這一步驟總共只需要 1~2 天就可以完成，也很推薦產品經理自己花一個小時的時間把這些測試任務走過一次，對產品有更深入的了解。
- 使用案例 Use Case Use case 是基於輔助大家更了解痛點在表達什麼，幫助具象化的工具，假設以售後場景為例，我們的痛點是：用戶無論在什麼場景下，看到的售後介面都長得一模一樣，我們需要根據不同的使用場景給到不同的頁面排序。此時可能大家還不太明白這個痛點到底有多痛，使用案例就是一個很好的輔助角色， 例如：當用戶住宿離開的當天，他想要檢查他的付款方式有沒有問題，但當他打開預訂詳情，他必須滑過住宿地址、電話、各種各樣已經不重要的明細後，才能看到付款進度以及方式。 其實這段並沒有引用數據分析，但卻可以引起閱讀者的共鳴，進而認同產品方向上的解法，將該場景最相關的信息排在訂單確認頁面的最上方（如果直接切入解法，少了前面的共鳴，依然會增加很多溝通成本）。
- TIPS：善用外部資料 部分市面上已經很成熟的產品（例如我正在做的心願單），其實也可以在網站上找到很多參考資料，推薦 Nielsen Norman Group，UX 界泰斗，這個網站匯集了很多資料，善用搜索框或是訂閱發現更多靈感喔！
總結 — Take Aways
- WHY /產品架構— 很重要，可以簡化，但不能省略。
- 產品路線圖需要根據公司規模、階段、閱讀人（Stakeholders）做出不同的調整，例如當公司規模較大時，需要多花點時間定義小組的目標 / 指標 / 工作範疇。
- 不要悶頭自己想產品路線圖，多多和團隊合作，有了初稿後多多收集組內想法，修正邏輯不夠嚴謹的地方，就可以是一份很完整的產品路線圖，內容不用多，重點在於邏輯前後能對上、解釋到位。
延伸閱讀：
想知道更多關於 Celine 在中國求職的故事，歡迎前往她的 Medium 看更多內容！如果單純想給我們一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多新產品開發相關文章，請盡情長按拍手（50個拍好拍滿）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了～