譯註：本文來自romanpichler，中文版由天地會珠海分舵翻譯。主要描述了作為產品經理在編寫Product Roadmap時應該如何選擇Roadmap的類型，應該是面向功能呢，還是面向目標？
面向功能 vs 面向目標
眾所周知，Product Roadmap這玩意兒的格式不一而足，且可大可小。而當前最流行的兩個格式應該要數「面向功能」和「面向目標」的這兩種了。前者是是基於產品的功能點的，比如註冊功能、搜索功能、報告功能等，這些功能最終都會映射到一個時間軸上面。
面向目標的Roadmap關注的是目標或者效益，並且明確指定要在什麼時間完成什麼樣的目標。目標多種多樣，比如可以是客戶和用戶獲取，粘住用戶，增加用戶對產品的融合度（engagement），開始獲利，等等。功能點在這裡會變成一個二等公民，他們源於目標，且通常一個大的功能點可能會跨多個目標。
以下的兩張圖片闡述了這兩個不同的Roadmap格式，它們描述的是覆蓋一個產品的兩個版本發布m和n的Roadmap。
功能Roadmap vs 現象目標Roadmap
跟你要採取的是那一種格式沒有任何關係的是，你的Product Roadmap應該說的是一個實在的且前後要一致的描述你的產品是如何成長的故事。它應該執行的是你的產品戰略，這樣的話，前面的每一次發布都會把你往前向你的願景推進。它不應該包含一些隨機的目標或者一些鬆散的功能點。
面向目標的Product Roadmap示例
下圖顯示的就是我之前做的一個面向目標的Product Roadmap的模版，當然，你也可以通過這個連接進行查看了。
以下是一個實例：
如何選擇正確的Product Roadmap格式
在不同的情況下，你應該使用不同的Product Roadmap。為了找到最適合你的Roadmap格式，你應該要考慮的是你的產品的成熟度以及市場的穩定性。你的產品越年輕（比如還在產品開發的早期），那麼功能或者需求可能需要修改的地方就越多，那麼這種情況下你就不應該使用面向功能的Roadmap而應該使用面向目標的Roadmap，否則你的Product Roadmap就需要經常隨著功能的改變而改變了。
與之對應的是，越老的、越成熟的產品就越應該使用面向功能的Roadmap格式，道理很簡單：當你的產品日催成熟之後，改變就相對比較少了，這個時候你就會處在一個很好的位置，通過在你的Roadmap中增加更清晰穩定的功能，來讓你更準確的把控你的產品成長預期了。
除了產品成熟度會對你選擇Product Roadmap格式有影響之外，市場的穩定性也會產生影響。所以就算你的產品已經很成熟了，但是市場卻是非常的不穩定的話，比如競爭對手一直有新的功能的增加，或者說相關的關鍵技術發生了巨大的改變，那麼你就需要頻繁的更新你的產品以保衛你的市場份額了。
結果就是，很多不確定的因素和功能會不停的走進你的Product Roadmap裡面去。這就會讓你很難周詳的去提前計劃一些細節性的東西以及預測那些功能點將是必須要要在下一版本進行發布的了。所以這種情況下，你更應該是採用面向目標的Roadmap格式。
下圖描述了我們在綜合考慮產品成熟度和市場穩定性之後，應該如何的選擇Product Roadmap的格式。
總的來說，如果你的產品或者市場傾向於需要頻繁改動的話，那麼我建議你使用面向目標的Roadmap。你只有在你的產品已經很成熟且市場很穩定的情況下才應該使用面向功能的Roadmap。在現實中我曾經看到過很多企業的做法是相反的：它們在產品本身還非常不成熟，市場也很不穩定的情況下照樣使用面向功能的Roadmap，最終做的一團糟。
需要謹記的是，就算是一個很成熟的產品也有可能需要做大的改變。你也許需要像蘋果對它的iPod Nano一樣，為你已成成熟的產品做出重大的改變，以使得你的產品重新精神煥發——為了讓自2005年就已經發布的iPod Nano重獲活力，蘋果曾經為其動過相當大的手術，大大的縮減了它的大小，改變了它的形狀，並且給它換了個觸摸屏。所以這種情況下，你就應該需要從原來的面向功能的Product Roadmap轉換成面成面向目標的Product Roadmap了！
提醒:更多文章請關注公眾號:techgogogo。當然，也非常歡迎您直接私人微信(zhubaitian1)勾搭。版權:本作品採用[創作共用署名3.0中國大陸版許可證], 若非授權，轉發時切勿刪除聯繫信息，否則追究相應責任。本文首發虎嗅。
From 天地會珠海分舵
如何選擇正確的Product Roadmap類型：面向目標 vs 面向功能
