如何規劃產品路線圖？

編者按：開發偉大產品很難。沒有一個負責迭代、質控以及用戶反饋的計劃就想開發出偉大產品幾乎是不可能的。所以我們才需要一幅精心打造的產品路線圖，而這正是Janna Bastow在行的東西。身為產品經理的她與人一起創辦了ProdPad，因為她根本找不到合適的工具來規劃和管理自己的路線圖和產品待辦事宜。她還是 產品人全球社區Mind the Product的聯合創始人。此文是她在接受Intercom訪談的 摘編 。

訪談內容的主要摘要如下：

1. 一個合適的從路線圖可以從兩個角度實現：它實現了大目標，并按照公司愿景而打造，但它同時可以足夠靈活，能適應市場的變化。

2. 邀請公司內不同地方的利益攸關者一起討論要開發什么，從而幫助你分析各種權衡和需求。為此，Janna推薦了一種被稱為產品樹的做法。

3. 避免針對特定日期調整路線圖；相反，要把你的路線圖在更短的時間窗口和更長的時間范圍之間進行拆分，這可以提供靈活性。

4. 隨著產品的發展，你將需要從列舉功能的待辦事宜清單的做法轉移到按照正在解決的問題來組織路線圖。

5. 如果功能請求與公司的產品愿景和目標不一致，那產品經理完全可以拒絕，哪怕對方是自己的老板。在這里測試和數據和產品經理最好的伙伴。

問：產品管理相對于設計和工程等而言是一個相對年輕的領域——而且大家進入這個行當的途徑也各不相同。你是怎么入行的？

答：我第一次從產品管理時實際上從未聽說過這個詞。我是一家技術公司的客戶支持代表，他們喜歡我這個角色，因為我可以匯報bug并跟客戶交談。我的老板有一天把我找過來說：“我想讓你當一名初級產品經理。”我的第一反應是，好的，我喜歡。但這是什么玩意兒？實際上我是Google之后才了解到我的發展路徑是什么，怎么才能做好這一新角色的。盡管我之前學習過商業并事先涉獵了一些技術和設計方面的知識，但實際上從未聽說過產品管理這個詞。但現在已經不一樣了。

問：你在為初創企業提供產品管理咨詢的時候，你總是從這個簡單的問題開始：你的產品要解決什么問題？那么是什么問題導致你要做ProdPad和Mind the Product？

答：兩個截然不同的問題。其一是我是產品經理，所以我想想別的產品經理學習，但是網上根本沒有多少資源。我的關系網絡里面當然也沒有太多的產品經理。于是我們幾個決定找一些人進來一起舉辦項目經理的活動。最初它就是一個產品智庫，大概有20人左右，然后慢慢地發展，最后就變成了Mind the Product。

至于ProdPad，我的出發點是身為產品經理我意識到手頭沒有做這件工作的工具。我得PowerPoint、電子表格等工具齊上陣。所以我和聯合創始人最后決定做ProdPad，這原來只是一個黑客項目，為的是幫助自己完成工作。我們是在幾年后才意識到這個東西值得分享給別的產品經理。

產品路線圖從何而來？

問：ProdPad的用途之一是幫助構建產品路線圖。對于要開發什么每一家公司都需要有計劃，但創建產品路線圖的辦法實在是太多了。你們在ProdPad是用什么來作為產品路線圖的輸入的呢？

答：好的產品路線圖從兩個角度實現。一個可以是自頂向下的方案，先概括你的愿景，你的目標以及滿足愿景需要采取的大步驟。你不能僅僅只進行自頂向下的產品管理，因為這意味著你沒有注意到市場上發生了什么。

所以你需要跟自底向上法糅合在一起，這種辦法會考察出現的所有機會：哪一個想法是你的團隊想出來的？哪些反饋是客戶提出的？你從觀察市場或者新客戶中學到了什么？通過融合這兩個你就創建出來的路線圖就既足夠靈活看根據市場情況作出變化，同時又可確保你在朝著愿景而開發產品并實現對公司很重要的大目標。

問：這些輸入里面有沒有哪些是更難管理或者平衡的？

答：大多數產品經理對于匯總客戶的想法和反饋都會遇到問題。把所有東西都放到一個地方、形成閉環并確保你開發的東西跟客戶相關并不容易。這是一個持續進行的循環，要不斷地回頭看，驗證你在做的事情，哪怕這件事情你一直都在驗證。你還是需要確保這是你要開發的合適的東西。

構建你的產品樹

問：在確定開發的優先次序方面，你采用了一種叫做產品樹游戲的做法。過程是怎么樣的？這種做法是如何發揮作用的？

答：產品樹游戲部分是受到了創新游戲背后那幫家伙的影響。您可以跟團隊、公司內部不同的利益攸關者甚至客戶一起玩這個游戲。你可以把團隊集中起來，收集來自于銷售、支持、開發等的不同觀點，然后在白板上畫出一棵大樹來。

樹的主干表示核心功能——這是絕對必備的功能，也是你手上現有的功能。樹枝表示你可以進入的不同領域，而樹根則表示開發這顆樹所需的基礎設施。讓每個人頭腦風暴一下，把想到的一切都寫在便利貼上。然后讓每個人把它貼到樹上，一起協商這些具體功能或者想法應該怎么發展。

一些東西可能是絕對核心，需要成為樹枝的核心基礎。這些東西就得先開發。其他的一些可能就含糊點或者考慮得更遠一點，這些就可以放到樹枝更遠一點的分支。作為根基的基礎設施也很重要，因為這是開發者有發言權的地方。你可能有個銷售說如果我們能夠實現客戶的這個視圖的話就好了。但開發者這時候可以站出來說：“如果我們想實現這個那就得做這個才能支撐這棵樹的發展。”然后解釋為什么你需要一個好的基礎設施。

你最后得到的就是一張樹，也就是你的產品樹的圖， 這棵樹是不是平衡馬上就可以一目了然。每個人是不是都決定朝著一個特定的方向發展？你的基礎設施是不是足以支撐眾多新功能需求的實現？這是讓大家參與到產品管理中來的一個很好的可視化方法，還可以看看在任何時候都在進行多少事情。

問：團隊多久需要做這么一次完整的流程？

答：可能不會多于6個月一次。路線圖的再思考我建議不要搞得比這還要頻繁。如果你隔幾個月就要更新一下路線圖的話，那愿景變化就太頻繁了。顯然小一點的調整會有（也沒問題），但我不建議頻繁大改。這會讓團隊成員無法真正理解你究竟想要去哪里。

問：畫完一次產品樹肯定會有很多東西要削掉。那誰來負責把這些概念放回路線圖，在它完成后誰有權看路線圖呢？

答：產品經理本身應該擁有路線圖。這個東西別人不應該隨意增刪，而管它的人也不應該隨便換。他們應該擁有路線圖，但他們還應該提供適當的透明度，要理解這是基于很多人的輸入做出來的，而不是產品經理一個人說了算。

你應該把整個路線圖展示給內部團隊看。產品經理了解到的有關即將發生的一切都應該讓未來要開發或者支持它的人提前知道。在向老板、董事會或者客戶展示路線圖版本時你可能會想削減一些東西。有時候是因為你不想泄露給競爭對手知道，因為你做的事情的確是很機密的。也可能是因為一些東西很普通，客戶或者董事會并不感興趣。路線圖的展示內外有別（稍微不同的版本區別）是很正常的，只要講述的故事基本一樣就行。

分配時間段而不是日期

問：你們的路線圖上面看不到日期。你曾經說過產品經理應該關注范圍更大的時間窗口。為什么要強調這一點？

答：這把發生在發布計劃中的可交付成果區分出來。也就是那些馬上開發出來的東西。我們是按照日期開發但只會每隔2到4周推出一次，會進行若干次沖刺，除此以外的任何東西基于我們收到的反饋對變更都是開放的。還有根據競爭對手所做的事情、市場的變化情況，客戶向我們提出的需求等了解到的新東西。這讓我們可以更加靈活并根據我們看到的市場情況來做出變更。

問：我們寫了很多有關路線圖結構方面的東西，我們（Intercom）會展望6周到6年的情況。你們的組織原則是什么？

答：我們按照目前、近期、未來三個階段來規劃。一般而言，我們會展望2個月、6個月以及以后的事情。實際上這跟Intercom的做法沒有太大的區別。我們聽說別人的做法是分成現在、下一步以及未來三階段，或者333格式。形式不拘，具體看哪種做法最合適自己。

目前：特定范圍、關注的顆粒度領域、規范與設計、不那么靈活

近期：關注范圍廣、有一定的靈活性

未來：頂層設計、寬泛的范圍、靈活

有關路線圖大家往往會按照歷年去思考。他們看著路線圖會說：“這是今年我們可以做的事情，”然后就把此后的事情切割掉了。在現實當中，一個規模小一點產品還沒成熟的公司只能、也只需要看到未來3到6個月后的發生事情。他們沒錢再看到更遠的未來。他們還沒有客戶。而一家更成熟的公司可能會考慮2年、5年乃至10年后的事情。

路線圖的幅度應該取決于產品本身以及公司的成熟度。但是時間分割按比例縮小，而時間范圍按成熟度相應拉長的做法是很有意義的。

問：著眼于短期可交付成果時，顯然監控這個過程并了解什么樣的交付成果比較現實會容易很多。而對于那些幾年后的大圖景目標，多久需要進行修訂或者更新呢？

答：如果你改變了基本愿景的話更長期的那些東西就應該修訂。這個東西應該在公司層面去執行。3年后他們所設想的市場還存不存在？他們是不是還處在合適的位置？

一般而言隨著公司發展，如果他們取得成功的話，實際上是會打開思考更遙遠未來的能力的，這會讓他們對于改變原先要追求的東西、拿下更大的市場擁有更開闊的愿景。對于任何公司來說修訂自己的愿景都是很自然的事情，因此路線圖大概每年調整一下也是正常的。

衡量成功

問：在路線圖的事情上你跟很多初創企業都打過交道，你發現有哪些東西是他們需要避免的？

答：我發現產品經理或者小公司經常會犯的一個錯誤是一張路線圖由完全不同的功能構成。如果公司還年輕，剛剛才把MVP（最小可行產品）做出來，只有一小部分客戶提供給反饋的話，那么有一個小的待實現功能集一點問題都沒有。但慢慢發展下去你就會看到路線圖上黑壓壓的一大片功能堆積到一起，這時候你就開始需要把它們圍繞著待解決問題的類型按照主題進行分組了。

如果你正在開發MVP可能接下來大概會有10件左右的待辦事宜，但隨著你開始搭建更大的路線圖，你需要傳達的是一個更大的故事而不僅僅是“我們準備要發布這些功能，讓我們看看會發生干什么吧。”

問：大家可能會淪為功能清單受害者的原因之一是往往會往路線圖添加日期，以此作為展示成果的檢查清單。如果去掉日期的話產品經理如何才能衡量自己的成功并向領導層證明自己呢？

答：產品經理難以考核是出了名的。但是衡量產品的成功卻很簡單。產品流行與否有指標和目標——轉化率、收入或者增長目標這幾個尤其常見。

在這中間的產品經理并沒有很容易跟蹤的東西。跟開發團隊不同，他們不能按照完成的工單數或者工作時長來衡量。也不想銷售人員可以設定銷售目標額。他們也沒有支持人員的客戶成功指標。產品經理往往是把這些東西糅合起來一并衡量的，同時還包括他們在團隊當中工作得怎樣。所以對他們可能要進行360°的考核。

學會如何說“不”

問：你寫過一篇很棒的文章：《你的老板有沒有綁架你的路線圖？》。我們討論了很多產品經理必須對請求說不的事情。那他們究竟應該如何對老板說不呢？

答：產品經理經常需要對老板說不的主要有兩件事情。一是對指定日期說不。短期的預期是你要就這一日期給出一個范圍，比方說大概一個月左右做出來。這是在你的團隊能夠洞悉所發生的事情基礎上做出的。但從長期來看，需要指出的是像資源這類的東西是未知的。因此這兩個都不能確定日期。

你可以對著老板說：“你要求的是一個一年半載后的時間點。我們不知道團隊規模能有多大。我不知道我們是否拿到那筆錢或者找到合適的人。這種情況下我怎么能給出具體日期呢？”

另一件可能需要說不的未必就是功能方面的事情。利用像產品愿景、目標這樣的東西去指出一個東西是否與之一致是很很重要的。如果你感覺不一致就要提出質疑。詢問為什么他們認為某個東西很重要。你可能要指出你的HiPPO（拿錢最多的人的觀點）愿景跟你的不一樣，這種情況下這個問題要比特定功能方面的問題要根本性得多。

你還可以利用測試和數據來支撐自己。如果你只是用觀點對抗HiPPO，你會輸掉。但如果你可以測試和證實某個東西是否有效，或者以他們預期的方式推動事情進展，那你可以先做再致力于開發更加宏大的東西。

問：無論是從領導還是客戶的角度，你在ProdPad時什么時候會對功能請求說是？這些請求需要符合什么標準？

答：最起碼要有一個以上的客戶提出了請求，然后這個東西必須符合我們的愿景。它還必須切合我們正在盯住的更廣泛的主題。此外這里還有一些直覺的因素。我們會跟客戶交談，找出他們想做什么，然后提出“這個東西我們是不是也覺得對我們或者其他客戶有用？這個東西是不是也應該符合我們做的別的東西？”這樣的問題。

這可以啟發很多的交流。只要我們從客戶那里打聽到了新東西，我們就會去找其他客戶詢問是否遇到類似問題。要找出困擾他人但我們可能此前從未聽說過的問題。結果往往是一位客戶請求的東西在其他客戶那里也會有類似額度需求，這樣的話路線圖就值得為之留出一席之地。

其他

問：你怎么知道什么時候該推出新版本而不是逐步發布許多的改進？

答：當我們意識到原有架構不足以支撐新的客戶規模、在性能上難以實現更加穩定更快時，我們覺得最好的辦法還是搭建新的平臺然后互補迭代前端。

問：產品管理方面最近有哪些觀點和哪些人值得留意？

答：隨著產品管理的演進最近我們看到對產品管理的領導藝術情調得很多——也就是產品管理當中的人的管理方面，要有一支產品人團隊。大家可以關注一下Pluralsight的CXO Nate Walkingshaw。實際上他寫過一本有關產品領導力的書。我在Mind the Product的聯合創始人Martin Eriksson也值得留意。

問：你怎么看AI未來幾年對產品管理的影響？

答：這是個好問題。我們曾經討論過人工智能會如何取代產品經理的事情。爭論的焦點是產品管理是否天生就是一個需要創意的領域，所以一直都需要有人的參與，還是從理論上來說這個東西可以被機器人替代。實際上我們并沒有得出結論，但我認為隨著時間轉移我們將看到產品管理很多簡單乏味的工作會被取代。產品經理大量時間將花在簡化規范或者針對此前產品經理做過的同樣事情設計實驗上面。現有產品人和產品團隊可用的工具比以前多多了，這可以幫助他們把更多精力聚焦到提出更大的問題解決真正問題上面而不是整天寫規范。

 

 

來自：http://36kr.com/p/5064475.html