在此之前，我創造了公平的產品策略，路線圖和項目甘特圖。現在我不再這樣做了，因爲我發現了一個更好的選擇。
首先，這是我以前做的事情：戰略→藍圖→項目計劃→執行，並不斷迭代。
這種形式的計劃需要花費大量的工作，並且只是讓所有利益相關者同意這是一項艱鉅的任務，但投資回報率非常低。而且這些計劃很快就會與現實脫節，因爲計劃越長越容易犯錯。我花了一段時間才意識到，我發佈的那天，我的花哨的路線圖和項目甘特圖已經過時了。此外，這個流程就像一個瀑布（不同於瀑布式開發），這意味着幾乎沒有靈活性的空間 ，流程頂部的變化會導致重新計劃和項目取消，並且在底部產生巨大的連鎖反應。敏捷開發解決了瀑布式開發的問題，但沒有改變計劃瀑布。然後，這對創新和文化產生影響，由於路線圖只允許在一些大型項目中被提供，因此您必須優先考慮並預先殺死許多潛在的好想法。在自上而下的組織中，贏家的想法來自管理層。在自下而上的組織中，獲得勝利的想法變得非常重要，因此推銷和炒作現在是強制性的產品管理技能。
那麼，還有什麼選擇呢？
GIST
這是我在谷歌工作時開始使用的計劃系統，多年來根據精益創業和敏捷開發的原則進行了進一步調整。我已將它介紹給多家公司，結果非常一致 - 輕量級計劃專爲變革而設計，降低管理開銷，提高團隊速度和自主性，更好地跨公司協調，最終提供更好的產品和解決方案。
該系統在其主要構建塊之後稱爲GIST：目標、思路、步驟-項目和任務。每個都有不同的計劃範圍和變化頻率，雖然我們可能會使用不同的工具來跟蹤這兩個指標，但它們共同構成了公司和團隊需要做的所有核心規劃。
目標
“如果你告訴別人目標在哪，但不知道如何達成目標，你會對結果感到驚訝” - George S. Patton.
大多數戰略計劃都犯了一個嚴重的問題 - 他們指定解決方案（使用技術X，與Y公司合作，發起國家Z）而不是目標。目標更能把控局勢，不需要太大的管理開銷，而且更加健壯，相比之下，解決方案可能會根據現場情況來來去去，但目標始終保持不變。
目標體現的原則是，他們根據預期結果描述公司戰略：我們希望在何處，何時以及如何知道我們達成目標。每當組織中的任何人想知道“我們爲什麼要做這個項目？”時，目標應該給出答案。我最熟悉谷歌的目標，每個季度我們都會以目標和關鍵結果（OKR）的形式精心闡述我們的目標。有些人認爲OKR是Google如此成功的原因之一。
想法
“如果你想要有好的想法，你就必須有很多想法。大多數想法都是錯的，你必須學習的是哪些東西要扔掉” - Linus Pauling
想法描述了實現目標的假設方法。這裏的關鍵詞是假設，因爲可以有很多想法去實現一個給定的目標，但最多隻有三分之一的想法會產生積極的結果（通常比例更差）。經驗豐富的領導者，產品經理和設計師的想法沒有比平均水平更好的成功率。
由於GIST中的原因，我們從不預先扼殺想法，我們將想法進行優先級排序，管理思想，或選出最容易被炒作/投放/政治化的想法。這就是我們所做的事情：
· 收集Idea Bank中的所有想法，最常見的是電子表格或數據庫，歡迎所有想法，Bank可無限期地持有數百個想法。
· 按優先順序將儘可能多的想法添加到測試中，這是Step-projects的工作。
步驟-項目
“思想大而起點小” - Google’s 8 pillars of innovation
選擇一個有前途的想法是很有誘惑力的，我們把它變成一個9-18個月的項目並開始執行。這是一個常見的錯誤，也是一個非常昂貴的錯誤，在一個未經證實的想法上度過幾個季度甚至幾年，這可能會在垃圾箱中投入大量資金，因爲大多數想法都不值得投資。
相反，我們將這個想法背後的大項目分解爲小步驟項目，每個項目不超過10周，並且一次執行一個。例如：草稿→原型→MVP→雛形→測試版→發佈
根據Lean-Startup的Build-Measure-Learn原則，每個步驟項目實際上都是一個測試這個想法的實驗。在一個成功的過程中，我們將在更長的時間內和更多用戶面前爲每個步驟項目提供一個更完整版本的想法。
最終產品通常比我們最初想象的要好得多。
由於步驟-項目非常小，我們避免了長項目的所有令人討厭的副作用，我們能夠以更低的投資和更快的學習來測試更多的想法。不起作用的想法會提前放棄，有效的想法會獲得更多投資。提出一個想法，隨着想法變成現實，並在幾周內不斷經受考驗，這對每一個參與者來說都是令人難以置信的自由和愉悅的。
任務
最後，每個步驟-項目都被分解爲小規模活動，我們稱之爲“任務”。敏捷規劃工具，看板和其他現代開發項目管理技術很好地涵蓋了該系統的這一部分。在這個級別上沒有什麼需要改變，唯一的區別是這些工具的頂層還是敏捷模式。
規劃週期
使用GIST進行規劃是多層次和反覆的：
· 目標通常設定爲一年或一年以上的時間 - 這是我們希望鼓勵長期思考的地方。它們在年初定義，每季度進行評估和調整，因爲我們也不想追求過時的目標。
· 不斷收集想法並確定優先順序。我們永遠不會停止尋找新的想法。
· 步驟-項目在季度開始時定義。該團隊選擇了本季度希望實現的目標和想法，並相應地定義了步驟項目。季度步驟項目列表（通常存儲在電子表格或數據庫工具中）每1-2周進行一次評估和重新確定優先級，與任務迭代計劃同步。
· 根據團隊的首選開發方法計劃1-2周的任務，例如Scrum sprint計劃，並每天進行調整。
在上面的例子中，團隊正在並行處理有關兩個目標的四個想法。Idea 2已成功完成第1步和第2步。Idea 3已經在其第一個步驟項目中失敗，因此被放棄，這爲其他3個想法做更多工作留出空間。
你還需要路線圖嗎？
我相信你不用。路線圖通常用於以下目的：
· 工作計劃- 希望到現在爲止我確信你不需要並且不需要路線圖。
· 內部溝通 - 我的經驗是，同事和董事會成員很容易理解並接受目標，想法和步驟項目的語言 - 這不是一個艱難的過渡，他們欣賞現實主義和真實性。當然，整個計劃系統應該對公司中的任何人和董事會都是可見的。
· 外部溝通 - 與客戶和合作伙伴對“正式路線圖”的期望可能最高。一如既往，我們的工作就是將討論從功能轉移到潛在需求。使用GIST，您可以給出答案，例如“我們的目標是在第三季度末之前處理產品間協作。我不能確切地說它將如何運作 - 我們正在考慮一些想法並保持敏捷，但我們應該在第二季度結束時獲得MVP。你想成爲一名早期測試人員並給我們反饋嗎？“運氣好的話，這比任何路線圖都要好。
譯者：MadPecker
原文作者：Itamar Gilad
作者介紹：Google product manager (Gmail, Youtube)
原文鏈接：https://medium.com/@itamargilad/why-i-stopped-using-product-roadmaps-and-switched-to-gist-planning-3b7f54e271d1
本人創業團隊產品MadPecker，主要做BUG管理、測試管理、應用分發， 網址:[www.madpecker.com]，有需要的朋友歡迎試用、體驗！
本文爲MadPecker團隊產品經理譯製，轉載請標明出處