編輯導語：產品規劃藍圖通常可以稱之為「Roadmap」，它既能表達出產品未來成功的樣子，又能看出在產品生命周期過程中通過哪些步驟一步步讓產品走向成功的。那麼，Roadmap究竟長什麼樣子呢？我們跟著本文作者的腳步，一起去看一看。
一、什麼是Roadmap？ 1. Roadmap的定義
Roadmap用來指引人們到達某個地點，或說明從甲地到達乙地的方式。從一般意義上來說，路線圖更多的被指代於地理上的圖片說明，例如尋寶圖、部分位置圖、交通示意圖等等。
在廣義上，Roadmap也可以是指引人們達到任何目標的說明性文檔，甚至沒有任何圖片說明也可以被泛指為「Roadmap」。延伸到產品設計上，它是一種能快速表達出這款產品實現成功的過程和最終的結果。
2. Roadmap的特點
1）有起點有終點
與傳統地圖不一樣的地方是，Roadmap是有起點有終點。通常起點是1個，但是終點可能是1個或多個，因為產品發展的路徑可能會從最開始的1個idea衍生成1個或多個產品解決方案。
2）有明確的路徑
這點和地圖軟體的導航很類似，從起點到終點的線路，一定是有明確的路徑。基於用戶不同訴求，路徑是有所差異的，比如從A點到B點，按地鐵優先、步行少、換乘少、時間短等不同的訴求，導航軟體推薦的路徑是不同的。
但是不管是哪種路徑，用戶都能在地圖上得到明確的路徑，一步步指引自己從A點到達B點。
3）簡單易懂、易於閱讀
Roadmap一般是淺顯易懂的，按用戶體驗場景的流程，通過簡潔、形象化的文字描述，來表達出來的圖形。步驟清晰，且承載的信息相對較少，從而簡單易懂、易於閱讀。
二、為什麼要做Roadmap？ 1. 完整性
Roadmap可以從用戶體驗場景的橫向和縱向兩個維度，讓團隊直觀的看到這款產品的完整面貌。
橫向看：從用戶開始接觸體驗這款產品，到體驗完成離開這款產品，整個用戶體驗路徑上的場景都能被Roadmap覆蓋；縱向看：在某一個用戶體驗場景上，比如從前期提供10%的該場景解決方案，到最終提供100%的該場景解決方案，都能在Roadmap上呈現出來。
2. 成功的樣子
Roadmap的價值是讓團隊清晰的知道這款產品成功是什麼樣子？以及實現成功的樣子需要設定哪些目標？這些目標要達到怎樣的標準？
這些標準需要在什麼時候提供怎樣的解決方案，這樣在產品初期規劃的時候，需要產品經理既要考慮用戶場景、又要基於企業現有能力，最終描繪出一幅「可落地可執行成功產品的藍圖」。
3. 能力儲備
一幅可落地可執行的Roadmap，可以讓團隊提前進行相應的能力儲備，以便完美實現Roadmap成功的樣子。
比如需要提前儲備用戶深度調研、需求挖掘、產品設計等能力，來解決用戶在不同場景的痛點；比如需要提前儲備運營支撐能力，產品經理提供了產品解決方案，運營則需要匹配上合適的運營推廣方案，從而更好的解決用戶痛點。
再比如要實現對應的產品解決方案和運營推廣方案，技術團隊需要建設哪些技術能力？要不要建設中臺？以及建設哪些中臺？
三、Roadmap長什麼樣子？
Roadmap不在乎用什麼工具來描繪，可以用PPT、Xmind等工具，但是它脫離不了以下這些核心的要素，通過這些核心要素按一定邏輯組合起來，呈現出的就是Roadmap的樣子。
1. 目標
給你這張藍圖定一個一句話的目標，這句目標能完美的概括出這張藍圖的重點。比如C端O2O產品目標叫「圍繞多、快、好、省來打造極致的用戶在線交易及服務體驗」；再比如B端CRM產品目標叫「建設客戶全生命周期移動化、數位化管理平臺」。
讓別人首先看到這句目標，就能快速的了解到這張藍圖的核心宗旨和願景。
2. 橫軸-完整用戶體驗路徑
大多數Roadmap的橫軸都是用時間軸來呈現，但是我更偏向於用用戶體驗路徑來當橫軸。兩者優劣點如下，大家可根據自己實際情況進行選擇。
1）橫軸-時間
優點：突出時間維度，能通盤清晰的看出每個時間段該做什麼事；缺點：沒有用戶視角，缺乏橫向邏輯性，比較難理解。
2）橫軸-用戶體驗路徑
優點：站在用戶視角，有橫向邏輯性能串聯整張Roadmap；缺點：不能通盤看到各個時間段該做什麼事。
將這款產品以用戶體驗路徑拆解成幾個階段，再基於每個階段識別出用戶的核心動作，這樣就形成橫軸的用戶體驗路徑。比如打車業務，可以分成上車前、車上、下車後3個階段，每個階段動作如下：
上車前：提交行程、等待接單、等待司機到達；車上：乘車；下車後：支付、評價、開票、投訴。
將用戶體驗的關鍵階段和動作識別出來，並基於此進行繪製每個階段和動作場景下的Roadmap，這樣就是一幅完美的Roadmap。
3. 縱軸-單個用戶場景的藍圖
1）用戶行為
用戶行為主要是為了細化用戶體驗的關鍵階段和動作，將動作拆解到具體的用戶行為上。比如上車前的提交行程是一個動作，具體的用戶行為是下載&打開App、註冊&登錄、填寫行程（上車點、終點、用車時間等），然後才是提交行程。
將這個動作下的用戶行為進行拆解，一方面可以更加清晰的了解完整的用戶行為，另一方面Roadmap也能細化到每個用戶行為上。通常可以根據「影響轉化率」這個維度來拆解動作下的用戶行為，比如影響提交行程的轉化率有以下用戶行為：
下載&打開滴滴出行App>註冊&登錄>選擇出行服務>輸入上車點>輸入終點>確認用車時間>選擇車型，然後完成訂單提交；再將相同節點完成的用戶行為進行合併，最終提交行程下的用戶行為就是：下載&打開App、註冊&登錄、填寫行程。
2）接觸點
接觸點主要指用戶在上述動作過程中通過什麼方式接觸到什麼樣的人，這裡的接觸點可以分成2類：
系統接觸點：指用戶在上述動作接觸到哪些系統的哪些核心功能人員接觸點：指用戶在上述動作接觸到哪些人員
比如等待司機這個動作下：
系統接觸點：等待司機頁（查看司機預計達到時間、車牌號等信息）人員接觸點：司機聯繫我，我聯繫客服
梳理關鍵階段和動作下的接觸點，是為了更好的了解到現有的功能支撐度和人員接觸點。以系統和人員接觸點為基礎，構建對應動作下的Roadmap，最終提高該動作下的用戶體驗和轉化率等目標。
3）用戶藍圖
用戶藍圖這個環節是Roadmap的核心環節，應該要包含以下要素：
基於該動作下的用戶痛點，輸出對應的藍圖內容（即產品解決方案），可以是一條也可以是多條。輸出的內容要能描述出該動作下「產品成功是長什麼樣的」。
是站在用戶視角下，該動作成功的樣子。比如提交行程，對於用戶來說，成功的樣子就是要能快速提交行程，按用戶行為可以拆解成3條藍圖內容：下載&打開要快、註冊&登錄要快、提交行程要快。
有了每條藍圖內容，就要明確好在什麼時間點能夠完成上線。因為Roadmap通常是按年輸出，所以計劃完成時間精確到月份即可。
評估計劃完成時間，需要考慮到藍圖內容難易程度、實現成本、難易程度、人力成本，以及過程中涉及到的產品調研、輸出方案、開發測試等環節總耗時情況，最終輸出對應的計劃完成時間，而不是拍腦袋寫個時間點。
將對應的藍圖內容按痛點程度進行拆解，通常越痛的重要程度越高。
這就需要提前洞察用戶痛點和識別痛點程度，基於此再進行重要程度標註。所以在描繪Roadmap之前，需先完成用戶和業務調研，提前洞察用戶所有痛點和痛點程度。
4）衡量標準
藍圖內容描繪的是「產品成功是長什麼樣的」，但是成沒成功？成功到什麼階段？這些沒法得知，所以需要一把」尺子「來衡量成功的標準。可以從定性和定量的兩個維度，結合起來制定這把「尺子」。
定性標準：指不能直接量化而需通過其他途徑實現量化的評估指標，比如將實現過程進行初步分級；定量標準：可以準確數量定義、精確衡量並能設定績效目標的考核指標，定量也是針對過程，和定性的區別是要有明確的數值。
比如轉化率從10%->30%，10%指現狀，30%指成功的標準。所以制定定量標準的時候，需要先計算當前標準，並且基於現狀&未來藍圖，預測出成功的標準，這個預測標準要有依據，經得起推敲，而不是拍腦袋定的。
5）業務支撐
要完成藍圖內容，達到成功的樣子，除了要有產品解決方案，還需要哪些業務支撐方案。即哪些業務部門需要參與哪些產品解決方案，便於更好的完成藍圖。
不管是C端產品還是B端產品，要想實現藍圖內容，過程中都離不開業務部門進行支撐，比如前期起制定業務規則、中期驗收試點，後期上線推廣，產品解決方案僅僅是藍圖的樣子，如何將藍圖內容落地依賴業務支撐。
6）系統支撐
除了需要業務支撐，還少不了系統支撐。
一個完整的C端App離開一套強大的後端系統支撐，B端的系統同樣需要相關領域的系統支撐。主要以業務場景相關的領域系統支撐為主，故障監控、數據分析等增值系統支撐為輔。
四、設計Roadmap需要注意什麼？
在設計和執行Roadmap過程中，應該關注以下3點：
1. 設定截止時間
這裡的截止時間是指Roadmap是要在哪個時間點完成，是做1年的Roadmap，還是3年的Roadmap？1年的Roadmap是產品1年後成功的樣子，3年的Roadmap是產品3年後成功的樣子。
不同的截止時間，Roadmap內容豐富和完整度是不同的。所以，第1步需要先設定截止時間。
2. 完成前置條件
怎麼理解Roadmap的前置條件？
其實可以拆解Roadmap目標「讓用戶未來能體驗這款成功樣子的產品！」這目標裡包含3個關鍵信息，一個是用戶，一個是未來，最後才是成功的樣子。達到這個目標，開始設計Roadmap前，則需要完成以下2個前置條件：
用戶調研：基於用戶調研，內部了解現有業務場景，外部深度挖掘用戶痛點和癢點，並按程度進行劃分重要性。業務規劃：培養業務敏感度，並提前了解中長期的業務規劃內容，不貼合業務的Roadmap，就是一張不能落地的圖畫，對後續產品工作毫無指導意義。
3. 動態刷新
Roadmap不是一張靜態圖畫，而是一張動態圖畫。隨著時間推移，隨著公司的戰略變化，隨著核心干係人變更等因素，都會影響到Roadmap內容。
所以過程中遇到相關因素變化時，Roadmap應該隨著變化而變化，要及時動態的刷新，並同步給團隊的每個成員，而不是一塵不變。
五、總結
綜上，一張「好」的Roadmap也需要遵循SMART原則，SMART原則：
必須是具體的（Specific）必須是可以衡量的（Measurable）必須是可以達到的（Attainable）要與其他目標具有一定的相關性(Relevant)必須具有明確的截止期限（Time-bound）
大家看完本篇文章，都可以嘗試針對自己的產品設計一張Roadmap。不用考慮自己有幾年的產品經驗？負責的產品規模多大？是不是負責核心模塊？
嘗試設計一張Roadmap不僅是檢驗自己對產品的熟悉程度，也是培養自己用戶思維和產品洞察力的過程。以上是基於自己對於設計Roadmap一些想法和思考，可能存在一定的局限性，僅供參考，歡迎大家多交流學習！
#專欄作家#
董小白，人人都是產品經理專欄作家。喜歡研究各類好玩好用的APP，關注出行、電商等領域；擅長整理和分析APP亮點功能設計。
本文原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺「網易號」用戶上傳並發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.