你用什么來創建和管理產品路標？以你的經驗來看，有咩有比較好的資源如網站或書籍可以讓我學到豐富的東西？

我搜羅了一番，找到了很多高大上的圖形實例，但我并不確定那些是對的，抑或它們又是否可以更加細致一些呢？我想要找到一種可以更好理解并學習展現、管理數據的有效方法。

我的前雇主并不太在意這個東西，我都是自己學習。依照我們的開發計劃，路標規劃包含了很長的BUG列表和新功能。我一般使用Word來建立一張以季度為單位的表，把每個季度我想開發的主要功能（和要搞定的大BUG）列出來，我把它們稱為“新發布”，我會基于我沒有完成的開發和一些運營中的非理性決策去不斷調整這張列表。（Chris?Garby）

我了解你的痛苦！我也bug和新功能過載的路標規劃。我花了很長時間才搞清楚為什么會這樣。因為路標規劃出錯是不可避免的，原因是你不可能在一個文件中將未來18-24個月的事計劃到一個非常細致的程度。

首先，不要把你的路標規劃想象成一個甘特圖。這是個很容易犯的錯，因為大多數人喜歡用項目管理的工具或技巧去做路標規劃。我的ProdPad聯合創始人，SimonCast，曾經說過：切勿用項目管理的工具來做產品管理。

把你的路標規劃看做是一個戰略性的溝通文檔。他的作用就是向你的股東和團隊展示你的產品愿景是什么，以及其背后的原動力是什么。而不是一個你用來展示你狂拽酷炫的開發計劃的工具，它不需要包含你的BUG列表也不需要你要發布的一些小功能。

更現實一點，作為一名產品經理，你在開發過程中也許確實有一串bug和小功能需要呈現。這無可厚非，但記住一點（當你幫開發團隊把一個個小功能輸入輸出他們的Kanban/Sprint/Backlog或是什么其他計劃），你是在做一個項目經理或是一個產品的直接擁有者，而不是一名產品經理。路標規劃是產品管理的文檔，是獨立的。

別考慮日期。你根本無法預料幾周后的某個交付日期確切是哪一天，比如一個sprint開發周期是多長，或者不管你的項目在你的團隊面前多么清晰多么時間充裕，你都沒必要去設定圖一個日期。在路標規劃中注明日期，如果是像”Q3?2013“這樣模糊的日期，并不會幫助你建立產品交付的預期，還會導致股東的責難和非議。但理想情況下，如果你是個牛逼的產品經理，你會覺得你對一個產品會有一個大概的估計，并能夠堅持執行，但是，你的估計真是糟透了（這是我推薦大家讀的一本叫REWORK的書中講的）。你根本不知道有什么BUG會冒出來并打亂你的計劃，就算你按時完成了，在”Q3?2013“那個時間點你的產品策略也還是要根據市場、用戶、競品等因素去調整。

把你的路標規劃當做一種指導，盡力保持每位成員在規劃下工作，而不是一個嚴格的項目計劃。就像Steven?Johnson說的：我覺得可以分享我的路標規劃……只要客戶和銷售人員明白這個路標規劃只是個計劃而不是個承諾就好。

對于其他的好資源，有些牛人可以關注一下：