面向目標 vs. 面向功能:選擇正確的Product Roadmap
編者注:本文來自romanpichler,中文版由天地會珠海分舵翻譯。主要描述了我們作為產品經理編寫我們的Product Roadmap的時候,我們應該如何選擇我們Roadmap的類型,應該是面向功能呢,還是面向目標…
面向功能 vs 面向目標
眾所周知,Product Roadmap這玩意兒的格式不一而足,且可大可小。而當前最流行的兩個格式應該要數“面向功能”和“面向目標”的這兩種Product Roadmap了。
前者是是基于產品的功能點的,比如注冊功能,搜索功能,報告功能等,這些功能最終都會映射到一個時間軸上面。
面向目標的Roadmap 關注的是目標或者效益,并且明確指定要在什么時間完成什么樣的目標。目標多種多樣,比如可以是客戶和用戶獲取,粘住用戶,增加用戶對產品的融合度(engagement),開始獲利,等等。功能點在這里會變成一個二等公民,他們源于目標,且通常一個大的功能點可能會跨多個目標。
以下的兩張圖片闡述了這兩個不同的Roadmap格式,它們描述的是覆蓋一個產品的兩個版本發布 m 和 n 的Roadmap。
功能Roadmap vs 現象目標Roadmap
跟你要采取的是那一種格式沒有任何關系的是,你的Product Roadmap應該說的是一個實在的且前后要一致的描述你的產品是如何成長的故事。它應該執行的是你的產品戰略,這樣的話,前面的每一次發布都會把你往前向你的愿景推進。它不應該包含一些隨機的目標或者一些松散的功能點。
面向目標的Product 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的格式。
如何選擇Product Roadmap
總的來說,如果你的產品或者市場傾向于需要頻繁改動的話,那么我建議你使用面向目標的Roadmap。你只有在你的產品已經很成熟且市場很穩定的情況下才應該使用面向功能的Roadmap。在現實中我曾經看到過很多企業的做法是相反的:它們在產品本身還非常不成熟,市場也很不穩定的情況下照樣使用面向功能的Roadmap,最終做的一團糟。
需要謹記的是,就算是一個應很成熟的產品也有可能需要做大的改變。你也許需要,像蘋果對它的iPod Nano一樣,為你已成成熟的產品做出重大的改變,以使得你的產品重新精神煥發。為了讓自2005年就已經發布的iPod Nano重獲活力,蘋果曾經為其動過相當大的手術,大大的縮減了它的大小,改變了它的形狀,并且給它換了個觸摸屏。所以這種情況下,你就應該需要從原來的面向功能的Product Roadmap轉換成面成面向目標的Product Roadmap了!
#專欄作家#
天地會珠海分舵,微信公眾號:techgogogo。人人都是產品經理專欄作家兼高級翻譯官。9年軟件行業從業經驗,涉獵海外最新創業、融資、產品類的資訊和方法論,喜愛結交各行各業的朋友,歡迎聯系。
本文原創發布于人人都是產品經理,未經許可,不得轉載。
??
不錯