產品 PM 應具備的思考邏輯 — 以 17LIVE 產品經理團隊為例
對於一個產品經理來說，如果有人問你覺得 「產品經理的主要工作是什麼 ？」 應該多數人都能夠輕鬆回答以下的答案:
- 制定產品的藍圖及方向
- 提出產品需求並建立開發清單
- 決定產品開發需求的優先級
- 需求上線後的成效分析及改善產品
但如果再細問每一個內容的細項是怎麼被決定的，可能每一個人的答案就會因為背景、產業型態、公司組織的不同而給出不同的答案了。今天這篇文章就要來分享一下筆者的經驗以及整個 17LIVE 產品團隊是如何去應對這些執行項目。
制定產品的藍圖及方向
產品經理如果要可以制定出符合公司發展方向的 roadmap ，那麼清楚地知道公司目前所處的階段跟狀況就非常重要，基本上你服務的公司會屬於三種型態
1.新創公司
從 seed fund、angel fund、 Pre-A (angel為主) 資金為主的公司都算是新創時期的公司，在這個時期公司的產品經理必須要認知到他的任務就是在錢燒光之前找到市場的機會，搶時間搶市場並且隨時保持彈性。畢竟如果一個產品 launch 後市場反應很差的時候，就要隨時 pivot 改變產品策略及方向。也因此在新創時期的公司大概 roadmap 只能看到 1、2 個月內的計畫，連一個季度的產品藍圖都有點奢求了，更多的時候這個時期的產品團隊甚至是沒有產品藍圖的，一切都是以打游擊戰為主。
這個時期的產品開發大概都會以 MVP 為主，不停地試探市場的反應以及回饋，並確認產品的主力以及實際使用 TA 是誰，快速開發快速驗證並且隨時調整會是這個階段產品 roadmap 的最大特色。
在這個時期的產品經理會有另外一個特色，就是因為組織還小分工也不明確，很多行銷層面的工作可能也都是產品經理要兼任，像是 web 的 SEO (search engine optimization)、App 的 ASO (app store optimization) 等甚至到 new user acquisition 可能都會是你 roadmap 上的一個環節。
2.成長時期公司
從 VC (venture capital) 開始到 PE (private equity) 進來前，不論是 A 到 D 輪資金為主的公司應該都是屬於這個範圍，通常能夠突破 A 輪的公司勢必代表產品已經找到一條自己的路了，不管是有忠實的客戶或是穩定的變現模式。相較於純新創公司而言，此時公司的發展方向已經較明確，只是公司還在持續探索產品並期待能找出擴大公司營運的可能性。
通常處於這個時期的產品經理應該會很常聽到「技術債」這個詞，因為公司早期不確定能不能存活下來的情況下，很多基礎的 infra 勢必沒有這麼完善，而剛好如果所處的公司又一直在成長的狀況下，就很容易遇到技術債的狀況。
17LIVE 集團目前就處於這個階段，也因此產品團隊在制定 roadmap 的時候就需要同時顧及到幾個面向:
- 可以刺激變現以及提升用戶的留存的新功能
- 減少營運的成本 (internal tools)
- 增加自動化的可能性
- 持續優化產品基礎 (底層的 infra, 3rd party service, data tracking, DB etc.)
通常這個階段的公司在產品的 roadmap 上可能是以 3–6 個月居多，而在 17LIVE 的團隊中我們只會制定約每個季度的 global roadmap，而其中的內容跟方向則會依據整體公司的 OKR (objective and key results) 去做展開。
3.企業級公司
在企業級的大公司內常常可以見到 1–2 年的長期規劃的 roadmap ，而且由於公司產品已經處於很穩定的階段了，通常你要隨意的大幅度地去改變產品也會相當的困難。公司在這個時間常常對創新的 idea 都會要求 PM 要提出所謂的商業論證，這類型的評估常常會導致 PM 很難創新，因為很多全新的東西在做市場評估分析的時候會相當缺乏數據。
知道公司的核心價值跟目標清楚自己公司的定位後，再來就是要依據公司產品的核心跟目標去展開 roadmap，通常不論是何種產品的數位產品的使命大概不外幾種:
- 擴大用戶數成長 (提升 DAU/MAU、retention為關鍵)
- 找到變現模式 (提升 LTV、Pay rate、ARPU)
- 提升品牌知名度
- 企業數位轉型
一個成熟的產品經理在清楚地知道公司目前所處的階段以及產品目標後，就可以對應去展開 roadmap，要小心的是有些人會把預計要完成的優先項目直接列為 roadmap，但產品的藍圖應該更要是一個執行的大方向跟可期待看到的價值而非細節。
建立開發 Backlog
開始要建立 backlog 的時候要代表要提案了，這時候最重要的一件事情就是要先釐清我們產品的用戶是誰，以 17LIVE 的產品團隊來說我們的 TA (target audience) 就分為三種類型:
APP/Web 團隊
面向 To C 的一般用戶，因此我們會對用戶做量化的問券調查，也會做質化深入訪談，最後當然我們最在乎的就是用戶的相關行為數據的分析，藉此來了解用戶對於 17 產品的使用障礙以及可以優化的部分契機在哪裡。
HandsUP 團隊
面向 To B and to C，需要同時兼顧商店賣家以及觀看直播會想要下單的電商用戶，這時候產品經理除了要多跟業務一起實地拜訪客戶以外，也都多觀察客戶在直播拍賣時，一般買家在直播間內的反應跟回饋是什麼。
Internal System 團隊
面向內部營運團隊或是財務同仁等的 stakeholders，需要跟他們保持密切的往來並且熟悉他們的作業流程跟方式，才能知道什麼樣的產品最可以替他們解決問題。
在清楚的知道自己的 TA 之後就要去思考他們有什麼痛點，或是在產品上不夠直覺的地方，因為 PM 要能清楚的知道他提出的需求是在解決問題而非單純實現功能。多數的時候你的客戶提供給你的想法或是建議都是有問題的，可能是因為他們對技術不懂或是想得太淺，多半直接提出來的方案都沒有真正解決問題，因此透過溝通以及引導去了解用戶背後真正的問題，或是需要被解決的痛點常常才是產品經理的挑戰。
決定產品開發需求的優先級
在你洋洋灑灑地提了很多需求或是接收了很多需求後，對產品經理來說接下來面對的才是最大的課題 — 如何排定需求的優先級？
我不誇張..以我這幾年面試了無數的 PM candidates 後發現70%的人都沒有辦法在這個環節有很好的方法，因為多數人的開發優先序就是 stakeholders 說了算或是老闆說了算，反正既然需求都是隕石那也就沒什麼好排定優先級了…
個人推薦產品團隊可以使用的排定優先級的方法大概有4個:
- RICE
RICE framework 使用4個關鍵指標算出一個index
Reach(觸及) x Impact(影響) x Confidence(信心) / Effort(負擔) = 優先分數關於17LIVE 團隊如何使用 RICE framework ，可以參考 17LIVE App lead Zoe Huang分享的另一篇文章 『怎麼決定開發項目的優先序？』
2. Value and Effort
傳統的 Value and Effort 跟RICE很類似就是把 user story 的 value 去跟 effort 做比較，但是我以前在團隊內使用時會把 value 拆成兩部份 business value and user value，原因是有些 user story 可能只能提升用戶的體驗而非真正可以帶來明顯的商業價值，因此把這兩部分拆出來可以更能客觀地去做評估。
3. Buy a feature
這個方法比較適合新創小團隊，而且是跑真正的 Scrum (團隊有排序需求的自主性) 來使用，簡單來說就是針對開發的 User story 需要的 effort 給予一個價格(開發越久的越貴)，然後團隊每人給予一筆款項後團隊的人來決定在有限的預算下大家會想“先”買哪些需求。
4. Story mapping
如果當你的團隊要打造 0 到 1 的產品時，我個人覺得 story mapping 是最好的需求優化方法，簡單來說就是根據你的產品內 user journey 去提出每一個環節下最主要的功能把每一個步驟下個需求分為 must have 跟 nice to have 去做以後的迭代，透過這樣把 user journey 展開的方式去明確的知道這個產品內如果要讓用戶進來到離開要完成哪些 user story 。
需求上線後的成效分析及改善產品
產品經理另外一個挑戰就是功能上線後該怎麼樣去評估這個功能對產品是好還是壞？這個問題其實在功能上線前的時候就要先思考好，這個功能的目的是什麼以及他需要被觀察的數據指標為何？有沒有需要做 A/B 測試？數據如果最後發現不好的話後續的 action plan 又是什麼？
這些數據的分析跟驗證都是產品團隊在任何功能上線前先確認的，否則團隊很有可能會陷入做了很多需求卻不知道成效在哪的窘境，問到該如何變得更好，大家也沒有頭緒。
在 17 的產品團隊中，每週我們都會有例行的會議討論每一個需求的驗收標準跟它的指標數據是什麼？要不要做 A/B 測試等？並且也會每週跟 data team 聚在一起討論測試的結果以及是否還有更多的數據指標可以協助產品的成長。
