產品思維:簡介兩種產品規劃 — Product Roadmap vs. GIST Planning

你想像的產品規劃是什麼呢?到底怎麼開始又或是怎麼做呢?Product Planning(產品規劃),絕對是產品經理必備的高級技能。很多人想做卻很少人實戰,實戰了卻又半途而廢,真正檯面上真實案例有多少呢?

先說,在這領域個人還是新手,身邊越來越多人意識產品規劃的重要性,隨著「產品路線圖」出版,開始有人不斷討論、辦讀書會、分享會、開課等等,於是開始著手整理相關手中的資源。

促使我寫這篇文,除了看書籍、聽講、研討會等啟發外,主要看了此篇文章(Link)的緣故。翻著翻著,彷彿跟鄉民般湊熱鬧,看到兩種論述兩派人馬各有擁護或是反對,相關戰點覺得興奮有趣。

此篇文章主要分享下列內容(可直接點選連結跳到該段)
一、適合誰
二、簡介Product Roadmap(書籍內容)+ 延伸資料
三、簡介GIST Planning(文章內容)+ 延伸資料
四、兩種方法的異同之處
五、個人經驗與疑問
六、各種延伸閱讀與結論
有任何互動或想法,歡迎寄信聯絡我:tianchen.tw@gmail.com

由於產品規劃內容涵蓋深層知識,以下文章不闡述細節,但可以參考文中所附的連結自行研究

一、適合誰

無論身為設計師、工程師、產品/專案經理,有了「藍圖」,可以更清楚將大家繫在同條船上,知道我們該往哪裡去,而非像個無頭蒼蠅在茫茫產品規格海中四處亂竄,竄到組織績效不佳、產品推出失敗、使用者失望。

  • 產品經理 — 製作者。向團隊說明產品願景如何一步接著一步通往未來。
  • 產品核心團隊 — 參與者。確保大家都有共同的目標而不失焦。
  • 老闆與各利害關係人們 — 參與者,確保與產品經理站在同一陣線。

另外,非常喜歡此圖的描述,說明產品路線是著重在於「Product Strategy」,有著承上啟下之效。

  • 備註1:Vision 從企業、組織、產品願景的上到下儘管不同但緊密聯繫。
  • 備註2:Tactics 雷同平日作業的產品功能與發佈計畫等等。
source: https://roadmunk.com/guides/how-to-use-a-product-strategy-and-product-vision-to-plan-your-roadmap/

二、Product Roadmap

光是Product Roadmap就有不少人有不同意見,有些人認為是策略性文件,有些人認為是「比較漂亮的甘特圖」,而這邊介紹主要參考Product Roadmaps Relaunched

source: https://venngage.com/blog/product-roadmap/ 這是另外一派的看法,供參考

當我們在做產品開發前,很常使用Prototype(原型)來假設產品的最終型態,可能是wireframe或是mockup,避免最後開發的浪費。那為何我們在描述Product Strategy(產品策略)也不能如此呢?主要功用包含

  • Product Vision: 產品願景應該跟公司願景、組織願景相互搭配。
  • Outcomes: 產品成果不等於產品產出 (產出更像發布計畫)。
  • Tool: 清楚讓利害關係人跟你有共同想法(最困難,任何階段都需要逐步溝通再溝通)

主要與次要組成要素如下圖,在這專門描述幾點

  • Business Objectives: 產品完成後預計達到的「量化」效益,以及如何衡量你的進度指標。可使用OKR的Objectives和Key Results。
  • Themes: 最難的部分是如何拿捏「主題」的描述,寫得太清楚就如同規格描述,有違產品路線圖的方向指示。書中建議朝向「描述客戶需求」而非功能規格來思考,可使用User Journey/Experience Map、User Stories。
  • Timeframes: 不會是明確的日期。承諾明確日期也會有極大的可能會失準(身為產品團隊一定很有感受),因此只需描述長期的時間區間。例如以每季或每半年為單位、又或描述下一步、再下一步等進展。
整理自書中

延伸閱讀

1. 路線圖變動是不可避免的。路線圖完成當然不會跟當初想的一樣。客戶感到挫折,原因是因為他們以為不會改變。

2. 路線圖不是一連串有明確日期的產品規格、更不是發布計畫

借用講者的投影片,完整描述整個Product Roadmap的要素。source: iamctodd

三、GIST Planning

Product Roadmap不少人聽過,那GIST Planning到底是啥碗糕,這是一位前Google PM現在專職當顧問,寫篇受到滿多迴響的文章(SEO可能做得很好)。當然除了此方法,看不同種書也擁護類似的觀念,主要原因大概都是

  • 儘管你寫再多的Disclaimer,跟再多的人溝通,人性還是偏好「明確的日期與解決方案」。
  • 以年為單位的目標規劃太漫長,要更敏捷的短週期制定目標並審視。

仔細了解這類的方法,跟日常規劃產品功能相距不遠,重點擺在Goals還有Ideas。Goals 可以呼應我們前面所說的Business Objectives,促使大家都看到眼前豐厚的果實到底是什麼,對團隊對客戶對公司各有什麼好處,讓最終的產品開發達到應有的產品績效(Outcomes)。而Ideas則是基於目標後搜集各種點子(或許有人說點子沒什麼用,要真正時間才有意義),不預設立場的搜集,更重要的是不斷排序、不斷驗證。

如果覺得這些詞有些抽象,或許可以嘗試換個名詞來理解。

  • Idea banks = Product backlogs?
  • Project plans = Sprint?
  • Tasks = Action items/To-Do-Lists?
source: 整理自 Slides 投影片的內容

延伸閱讀

四、兩種方法的異同之處

就目前的理解,這兩種方法目的都是為了讓大家更能理解「為何產品要這樣麼規劃」、「為何產品要存在」。若真要用一句話區別:

  • Product Roadmap: 大方向的產品策略原型,提供給團隊「未來的大概路徑」,而這路徑要怎麼走、何時抵達我不能保證,但可以確定我們一定會達到彼此相信的目的地。(怎麼聽起來有點像政治人物的__話)
  • GIST Planning:能真正落地的產品規劃步驟,明確說明我們在每個階段要做到什麼內容。
此圖是個人根據前一張投影篇改造整理,若覺得有誤歡迎指教。

五、個人經驗與疑問

Q1: 不就跟甘特圖差不多的東西嗎?有什麼特別好說嘴的!

「時程類」產品規劃為何不該用甘特圖,尤其是軟體開發,這太多文章和書籍闡述,就不贅述。但可以確定的是Product Roadmap產品路線圖「不是甘特圖」,更「不是敏捷開發計畫」。這一切真的真的真的都是為了讓團隊成員知道我們為何而戰、為誰而戰!

甚至…個人覺得這規劃出來後,應該抖大的寫在辦公室顯眼處,讓你我每天都能明確看到彼此的目標,不至於每天不知為何忙碌沒意義的事情,當你打造對使用者對組織有用的產品,工作才是真正的有趣。

Q2: 到底用哪種模型比較好啊?聽說用xxx工具製作更好啊!

可以嘗試觀察每個組織的每個利害關係人,都有習慣的「被溝通工具」,身為產品經理,應該是最要理解為何要做這產品的人,必須「不厭其煩」的使用各種技巧提醒團隊產品規劃的初衷。這兩種方法個人相信是可以混合使用,甚至共同使用,取決於要在什麼時機點拿出來。

而無論是Trello、Google Sheet、PowerPoint/Keynote、Post-it等等,只要能達到目標的都是好方法。可能有些人說某某工具就事拿來追蹤使用啊,根本不能表達前後邏輯,這就端看每個人使用這工具的實戰經驗心得了。重點是不要拘泥於他人的範例,隨著組織敏捷唄。

Q3: 沒用的拉!不過是紙上談兵,你以為高層會聽你的嗎?成員還是會當耳邊風的啊

有沒有遇到以下幾種情況

  • 僅限「自己團隊使用」而不拿給高層看,又看不懂還會嘰嘰歪歪。
  • 你懂我懂大家都懂,我們說過就好,不用寫出來拉。

隨著時間推移,大家的共識會逐漸模糊,記憶也不見得可靠,最好還是記錄在某個地方讓你我都知道。太晚拿給高層看,驚喜都變成驚嚇,最後導致隕石式開發法讓一切毀滅!

這時很欣賞書中的一種模式 — Shuttle Diplomacy(穿梭外交),很費時但很有效。與其一次性找大家「公告」而意見不合無疾而終,不如逐個擊破的找各個利害關係人,更深層的了解想法,這方法有點像是使用者訪談的探索呢!

Q4: 我又不是主管(CEO/CPO/Product Director/Product Leader),學這個沒用拉

如果主管太忙,有空可以嘗試自己寫寫,不斷地寫不斷深入了解為何產品要存在,也能嘗試拿成品「向上溝通」。幫助主管,就是幫助公司與團隊。

如果主管或是團隊真的沒人在意,都一笑置之,那至少至少至少,自己還是保留一份,時時刻刻存在自己的腦袋裡,默默地像團隊成員「傳教」,幫助團隊成員有共同想像,就是提升你平時工作的效率。

產品經理是編劇、導演更是演說家,如何成功讓團隊有向心力做事,取決於說故事的能力 — 邏輯性、故事性。

六、各種延伸閱讀與結論

目前之所以定義為高級技巧,都會延伸一堆參考書籍與方法論,非短時間能消化理解。而這兩種方法的好與壞,可能需要一年半載不斷推敲與親身實踐後,才能深入感受各中奧妙。

以下分享給大家延伸內容,都是不同書籍不斷引用的相關概念。

也附上網友細心整理過去工作坊的部落格筆記

最後觀察,坊間針對這類技能極少課程或工作坊,或許是太過高深太過困難,也或許是沒人拿捏得準這該怎麼傳授技巧,又或許是實戰經驗不夠豐沛。如果可以,讓我們從現在開始嘗試實踐,彼此分享的所學所得!

好的…長文至此(?),期望有更多高手相互指教,未來有新的想法也多多補充在相關文章中。

如果你喜歡這篇文章,歡迎多拍拍手👏,讓我們多多互動。
1. 👏[1個拍手] — 如果你單純路過
2. 👏👏[2-N個拍手] — 如果你喜歡這篇文章
3. 👏👏👏[50個拍手] — 如果你希望看到類似的內容
有任何互動或想法,歡迎寄信聯絡我:tianchen.tw@gmail.com

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.