如何進階成為一個優秀的產品經理
一個稱職的產品經理該具備什麼能力，相信對於多數的 PM 來說，下面這張圖大家應該也都不陌生， 用最簡單的白話文來說，一個產品經理的工作就是在用戶體驗/商業思維/技術做中間整合的角色。
但是對於已經在從事產品經理的工作的朋友們，可能會比較疑惑的是我已經是這個角色了，那我該如何可以往下一個層級的 PM 去做努力，或是該具備什麼樣能力? 這篇文章主要就是想要分享一下我個人認為一個優秀的產品經理該具備的能力以及特質。
I. 產品經理最重要的特點
首先來談談產品經理最重要的特點是什麼? 有時候在面試的時候我也會問面試者這個問題，通常對於比較資淺的 candidate 來說我常常會聽到以下幾個答案:
- 溝通能力要好
- 要很有邏輯性
- 可以管控好時程
不能說這些答案有問題，但其實這聽起來更像是一個專案經理需要具備的技能，當然不置可否的台灣很多公司的 PM 都是產品 + 專案經理的工作混著做，而且要做什麼內容也常常是老闆說了算，因此不知不覺 PM 就變得越來越像是專案經理。
真正的產品經理除了需要具備以上的『基本』能力以外，更重要的能力應該是要做到下面幾件事情
1. 用戶優先
達到這一步的優先條件是定義清楚誰是你的用戶? 如果你是做 To C 那麼 end users 就是你的用戶，但是如果你是做 B2B2C 那麼你的客戶以及他的使用者就有可能同時都成為用戶。另外在做某些特殊產品時要注意你的關鍵決策者是誰? 他的目標以及痛點又是什麼? 比方說如果你的產品是做 K12 的教育產品，雖然孩童是主要的使用者，但是真正的關鍵決策者卻是父母，身為一個好的產品經理這時候就要除了學習者的角度去設計產品以外，也要同時去思考父母的痛點以及他會願意付費的理由是什麼?
既然要做到用戶優先，那麼用戶的訪談、問卷調查、用戶行為的數據分析就不能少，我最近在協助公司面試產品總監的時候當我問到你如何判斷什麼功能是用戶需要的時候，有 candidate 的答案是:
『因為我的經驗很豐富，我多半的判斷都會是正確的』
這個答案一出來，我就直接判定 candidate 失格，憑著個人的感覺來做決定的人絕對沒辦法成為一個優秀的產品經理，優秀的產品經理永遠在思考的方向都是
我的用戶是誰?
我的用戶為什麼要用我的產品?
用戶是在什麼情境下來使用我的產品?
為什麼用戶不繼續用我的產品?
用戶的行為數據有沒有告訴我什麼 Insights?
2. 價值導向
除非你的產品不需要迭代，否則產品經理永遠都在決定到底要做什麼事情為優先。對於公司來說你該考慮的不是我想要做什麼? 或是誰誰想做什麼? 老闆想做什麼?
你的考量應該是我的目標是什麼? 我的用戶需要什麼? 最重要的是什麼東西才真正的可以創造產品的價值，而對於該如何做，文章的後面會有更深入的探討。
3. 在對的時間點做出最適合的決定
要做到這件事情其中一個重要部分就是要學會說『不』! 產品經理因為公司的階段不同或是產品生命週期的不同，都會有不同重要的事情要去完成，但同時間可能營運單位、行銷單位、老闆們或是親愛的客戶們都會有著不同的需求以及想法，如果你的策略只是把這些需求排時間去完成的話，那可能對你來說就是個警訊。
優秀的 PM 永遠要從不同的利害關係人的目標以及期望中去做出正確的決定並且展開你的 roadmap ，即便這個最終的 roadmap 無法滿足全部人的期待，優秀的產品經理也必須去說服他的 stakeholders 。
II. 專注於最重要的事情
決定開發的優先序一直以來都是產品經理最重要也最困難的挑戰之一，目前已經有很多成熟方法來協助產品經理做這些事情了，但是不同的方法使用的情境可能也會不盡相同，這個部分就是希望來分享一下如何可以善用這些方法去達到不同的效果。
排序對產品最重要的問題
Marketing team 想要請你協助把 acquisition 的通路跟轉換做好，你想做忠誠度計畫提升留存而同時營運單位希望你做一個功能去提升用戶的付費轉換率， 這時身為一個產品經理該如何決定優先性?
最理想的狀況下是公司有給產品團隊一個明確的目標去達成，這時候你就可以直接根據這個目標去決定這些不同的需求優先性，但若是不幸地公司也希望給你來決定的時候你就必須要先來判斷目前產品最需要被解決的問題為何? 這時候我會推薦使用 value vs efforts 再加上權重的概念來協助做判斷。
商業價值 x 權重 + 用戶價值 x 權重 / 開發成本 (時間)先把每個需要被解決的問題列出然後加入其去計算出每一個問題背後的價值比，然後就可以做出排序，為什麼相較於傳統的 value/efforts 我會加入用戶價值以及權重的概念呢? 是因為有的時候某些功能雖然能創造出用戶愉悅感及滿意度提升，但對於商業上的價值是非常低的，因此會把這兩個 value 去做拆分。
另外由於公司策略上需求的不同，所以這兩個的權重也不能是一致的，比方說如果你所處的新創公司為了要募到下一輪的資金因此公司要在短期提升獲利能力的話，你就必須要適時地拉高商業價值的比重，不然如果你過分專注有利於產品長期利益的用戶價值的話，公司可能會先把錢燒光了而等不到回饋了。
排序功能開發的優先級
如果你透過了上面的方法已經找到了對產品現階段而言最需要解決的問題為何的話，下一步應該就是要發想你的 backlogs 並且排序他們的重要性，針對功能的優先級我會推薦 RICE 來協助:
Reach(觸及用戶) x Impact(影響性) x Confident(信心) / Effort(成本)雖然 Confident 可能會比較主觀，但是加入了 Reach 後，對於單一問題的解決方法上可以更加地容易判斷什麼樣的功能受惠的使用者更多，再搭配上 Impact 之後，就能確保團隊優先開發的功能項目對於產品 ROI 上是更高的。
可能有人會好奇為什麼不直接用 RICE 來解決 high level 的問題優先級排序，主要是因為隨著產品越來越成熟使用者變多之後， Reach 可能會削弱了 Impact 的影響性，但是公司在找出產品的大方向上，會需要能找出與公司目標相近 Value 最高的，而不見得是最多用戶被影響的。
決定何謂最小可行性的功能
最後如果是已經確認了方向以及要實作的功能後，就開始要準備實作的計畫以及撰寫 PRD 了，我相信大家都知道任何的開發都是充滿著不確定性地風險，所以如何透過打造 MVP (Minimum Viable Product) 去給市場做驗證以及提供回饋再來進行迭代一直是現在軟體產品一貫使用的方式，但是到底該如何定義 MVP 又是一門藝術，做太大深怕測試失敗，但如果做得太小可能用戶根本又沒感，到底該怎麼辦?
這時候 PM 可以使用 MoSCoW 方法來協助，把所有想做的內容拆分為下面的四個層面的內容，並且只實作 Must Have 的部分做為你個 MVP
Must Have －只要不做功能或專案就一定會失敗的功能
Should Have － 很重要的功能但是不會立即帶來負面影響
Could Have －純粹提升用戶體驗以及客戶滿意度的需求
Won’t Have
運用 MoSCoW 方法說起來好像很簡單，但是實際做起來可能有人又會遇到了問題是在於那到底什麼是 Must Have? 可以參考下圖的功能設計的金字塔，很多人在設計 MVP 會做成左側的部分去開發一個很完整的有效功能，而卻忽略了即便是 MVP 也要達到讓 users 覺得有價值有回饋的完整體驗。
舉例來說，如果今天你要實作一個 Loyalty Program 來提升用戶在你的產品內的留存，這時候你的 MVP 應該要具備的功能應該要有:
- 新功能的提示 － 如果沒有這塊用戶可能會連有這個新的 Loyalty Program 上線都不知道。
- 反饋提示 － 用戶完成消費後你應該要能讓他知道他的消費同時可以積點，讓他更能充分理解這個功能帶來的價值。
- 兌換功能 －用戶看到他的里程點數提升後，可以知道這個點數累積的好處，例如累積滿 100 點，就可以兌換 300 元折價券，讓用戶覺得這個功能是有價值並且會對他帶他幫助的。
不該在 MVP 內的功能則是:
- 不同類型的會員等級 (要先驗證用戶在乎會員機制)
- 不同類型的兌換機制 (要先驗證會員會想去兌換)
- 時髦的 UI 顯示特效，例如每次查看累積點數的時候會跑動畫效果
- 累積點數的歷史紀錄
最糟糕的 PM 就是把下面的功能全做完了，但是竟然沒做了簡單用戶提示結果導致功能上線後失敗，但完全無法找出原因是因為功能設計不佳還是用戶根本不知道有這個功能的存在。
III. 假設、驗證、分析
不管是開發一個新產品或是新功能，PM 都會對這個開發的項目有其假設並且透過驗證以及分析並不斷迭代達到預期的目標，這是每個做產品經理都該具備的能力，但是一個優秀的產品經理在設定評量指標的時候會同時評估長期的目標跟短期目標，對於功能上線後其他指標的影響性也會同時兼顧。
普通的產品經理在看數據的時候通常會比較是大方向的去觀察，譬如說一個產品重要的指標該是什麼?
多數的 PM 會回答 DAU、用戶留存、付費轉換率等這個答案雖然沒有錯但因為這些指標都很難被影響，或是其可能影響的變因太多，所以通常這類型的低敏感度的指標比較適合作為整個大方向的戰略目標，但是每一個功能上線時，資深的產品經理會更在乎那些敏感度比較高也會間接影響關鍵指標的數據。
除了需要驗證的指標以外，一個有經驗的產品經理在上線一個新功能之後也會在乎其他的指標是否會被影響，畢竟不能因為目標是提升用戶留存，但是達成的同時卻降低了用戶的註冊率或是付費轉換等其他重要數據，如何選擇正確的指標以及判斷每個不同功能可能帶來的其他影響是一個優秀的 PM 必需具備的能力。
舉個例，面試時我一直很喜歡問面試者的一個問題是:
身為一個社群產品的 PM 如果你的目標是要提升平台上直播功能內的廣告被點擊率，你會怎麼做，原因為何?
很多好的產品經理都可以說出幾個正確的思考邏輯下的答案:
提升廣告被播放的頻率
一進直播時就先播放廣告
根據用戶的輪廓提供更精準的廣告內容
設計更吸引人點擊廣告呈現方式
一個優秀的產品經理給出這些答案以外，也同時會主動關心用戶的觀看時長 / 留言比率 / 用戶繼續觀看直播的比例，因為除了得到你想要改善的目標之外，也要務必確認不能因為一個新功能而導致其他重要行為被改變，進而長期下來反而對產品有負面的影響。
優秀的產品經理在乎那些更細微敏感指標，以及其他可能的對產品造成負面的非預期影響IV. 管理好你的利害關係人
就某種層面來說，這個環節或許重要性更高，很多優秀的產品經理把文章上面提到的事情全部都做到了，但就是因為跟 stakeholders 的關係上沒處理好，導致最終不管是在 roadmap 的訂定上或是需要其他團隊協助上還是失敗了，又或是在推進產品方向時很容易會遭到利害關係人的杯葛以及反對，因此跟你的 stakeholders 取得良好的共識是非常重要的。
制定你的 stakeholders 合作計畫
首先把 stakeholders 明確地定義並列出來:
- Who
- 產品對他的目標影響程度
- 對產品方向的決策影響性
- 對產品的興趣程度
你可以用一張表把你的 stakeholders 用上面的方式列出後去制定跟他們互動的策略，如果 3 個指標都是高的人是你最先要關心的人，反之如果都很低的利害關係人你就可以放到比較後方去做 sync up，然後關於合作的方式也可以列出來
互動方式 (需要面對面會議討論或是只要持續更新狀況就好)
內容 (如果對方的目標跟產品有掛勾，那溝通內容就要包含相關數字)
頻率 (每週/每月/每季)
簡單來說優先 deal 那些對你的產品方向決策有影響性高的人，如果他們的目標跟產品的相依性又強他們也關心產品狀態的話，你就至少會需要每週跟這個 stakeholder 有直接面對面的會議比較好，而其他人或許則可以透過月報或是產品路徑圖的定期更新以及主動通知來讓這些厲害關係人保持在狀況內。
透明且有明確價值目標的產品路徑圖
很多人會錯誤地以為產品路徑圖就是單純的 Release Plan，上線的時程固然是產品藍圖中的一部分，但是更重要的是透過產品藍圖來與利害關係人溝通你的產品策略和價值並進而達成一致的認同感。
一個完整的產品路徑圖應該要包含以下幾個部分:
- 願景 (產品存在的理由)
- 商業的目標 (提升 LTV or 增加新用戶數等)
- 時程
- 提供的價值(雖然是指針對目標下開發的功能，但更重要的是要讓其他人知道這個功能的產出是什麼? 例如: 如果開發項目是設計新用戶的 onboarding 機制，那麼這邊的提供價值就應該是『讓新用戶可以更容易地認識產品』)
傳統的 product roadmap 很常失敗的原因是因為『不切實際』，舉個例來說很多 PM 因為想要滿足 stakeholders 的期望，常常會把 roadmap 照著開發時程的預估去做很緊密地的排序，但是假設中間一個 MVP 功能上線後效果出乎意料的好，這時候可能團隊會更傾向進行功能的迭代而非馬上投入到下一個功能開發。
反之亦然，如果一個主要的功能上線後成效沒想像中的好，這時侯透過了用戶的反饋發現了原因，你會想要安排 enhancement 或是等到以後再做? 這些種種的不確定因素都會照成所謂提前安排的 product roadmap (其實是 release schedule) 最後實際有一半的項目無法完成，因此與其列出什麼時間會完成什麼『項目』，更好的是用能帶來什麼價值給產品，這樣才能確保自己與 stakeholders 的方向是在解決商業上的問題。
無止盡的學習
除了文章內上述的能力之外，我想對一個優秀的產品經理來說最後也是最重要的就是無止盡的學習以及吸收新知識，當要做成本分析或是新的商業模式時，你可能要懂一些財會概念，又有的時候你可能要對技術稍微有一些基礎的理解，隨著科技的日新月異以及市場不斷地改變，想要成為一個厲害的 Product Manager 絕對是要不停地持續學習。
成為一個 PM 其實很容易，要從 0–1 的門檻也不高，但是要把產品真正的做到好取悅用戶並且同時滿足利害關係人的期待就非常難，但這些挑戰以及達成的成就感也是這個職位的魅力所在，相信大家一定都能達到，一起成為一個厲害優秀的 Product Manager !
