如何進階成為一個優秀的產品經理

一個稱職的產品經理該具備什麼能力,相信對於多數的 PM 來說,下面這張圖大家應該也都不陌生, 用最簡單的白話文來說,一個產品經理的工作就是在用戶體驗/商業思維/技術做中間整合的角色。

但是對於已經在從事產品經理的工作的朋友們,可能會比較疑惑的是我已經是這個角色了,那我該如何可以往下一個層級的 PM 去做努力,或是該具備什麼樣能力? 這篇文章主要就是想要分享一下我個人認為一個優秀的產品經理該具備的能力以及特質。

I. 產品經理最重要的特點

  • 溝通能力要好
  • 要很有邏輯性
  • 可以管控好時程

不能說這些答案有問題,但其實這聽起來更像是一個專案經理需要具備的技能,當然不置可否的台灣很多公司的 PM 都是產品 + 專案經理的工作混著做,而且要做什麼內容也常常是老闆說了算,因此不知不覺 PM 就變得越來越像是專案經理。

真正的產品經理除了需要具備以上的『基本』能力以外,更重要的能力應該是要做到下面幾件事情

1. 用戶優先

既然要做到用戶優先,那麼用戶的訪談、問卷調查、用戶行為的數據分析就不能少,我最近在協助公司面試產品總監的時候當我問到你如何判斷什麼功能是用戶需要的時候,有 candidate 的答案是:

『因為我的經驗很豐富,我多半的判斷都會是正確的』

這個答案一出來,我就直接判定 candidate 失格,憑著個人的感覺來做決定的人絕對沒辦法成為一個優秀的產品經理,優秀的產品經理永遠在思考的方向都是

我的用戶是誰?

我的用戶為什麼要用我的產品?

用戶是在什麼情境下來使用我的產品?

為什麼用戶不繼續用我的產品?

用戶的行為數據有沒有告訴我什麼 Insights?

2. 價值導向

你的考量應該是我的目標是什麼? 我的用戶需要什麼? 最重要的是什麼東西才真正的可以創造產品的價值,而對於該如何做,文章的後面會有更深入的探討。

3. 在對的時間點做出最適合的決定

優秀的 PM 永遠要從不同的利害關係人的目標以及期望中去做出正確的決定並且展開你的 roadmap ,即便這個最終的 roadmap 無法滿足全部人的期待,優秀的產品經理也必須去說服他的 stakeholders 。

II. 專注於最重要的事情

排序對產品最重要的問題

最理想的狀況下是公司有給產品團隊一個明確的目標去達成,這時候你就可以直接根據這個目標去決定這些不同的需求優先性,但若是不幸地公司也希望給你來決定的時候你就必須要先來判斷目前產品最需要被解決的問題為何? 這時候我會推薦使用 value vs efforts 再加上權重的概念來協助做判斷。

商業價值 x 權重 + 用戶價值 x 權重 / 開發成本 (時間)

先把每個需要被解決的問題列出然後加入其去計算出每一個問題背後的價值比,然後就可以做出排序,為什麼相較於傳統的 value/efforts 我會加入用戶價值以及權重的概念呢? 是因為有的時候某些功能雖然能創造出用戶愉悅感及滿意度提升,但對於商業上的價值是非常低的,因此會把這兩個 value 去做拆分。

另外由於公司策略上需求的不同,所以這兩個的權重也不能是一致的,比方說如果你所處的新創公司為了要募到下一輪的資金因此公司要在短期提升獲利能力的話,你就必須要適時地拉高商業價值的比重,不然如果你過分專注有利於產品長期利益的用戶價值的話,公司可能會先把錢燒光了而等不到回饋了。

排序功能開發的優先級

Reach(觸及用戶) x Impact(影響性) x Confident(信心) / Effort(成本)

雖然 Confident 可能會比較主觀,但是加入了 Reach 後,對於單一問題的解決方法上可以更加地容易判斷什麼樣的功能受惠的使用者更多,再搭配上 Impact 之後,就能確保團隊優先開發的功能項目對於產品 ROI 上是更高的。

可能有人會好奇為麼不直接用 RICE 來解決 high level 的問題優先級排序,主要是因為隨著產品越來越成熟使用者變多之後, Reach 可能會削弱了 Impact 的影響性,但是公司在找出產品的大方向上,會需要能找出與公司目標相近 Value 最高的,而不見得是最多用戶被影響的。

決定何謂最小可行性的功能

這時候 PM 可以使用 MoSCoW 方法來協助,把所有想做的內容拆分為下面的四個層面的內容,並且只實作 Must Have 的部分做為你個 MVP

Must Have -只要不做功能或專案就一定會失敗的功能

Should Have - 很重要的功能但是不會立即帶來負面影響

Could Have -純粹提升用戶體驗以及客戶滿意度的需求

Won’t Have

運用 MoSCoW 方法說起來好像很簡單,但是實際做起來可能有人又會遇到了問題是在於那到底什麼是 Must Have? 可以參考下圖的功能設計的金字塔,很多人在設計 MVP 會做成左側的部分去開發一個很完整的有效功能,而卻忽略了即便是 MVP 也要達到讓 users 覺得有價值有回饋的完整體驗。

Source: https://fonsekainnovations.com/what-does-mvp-mean/

舉例來說,如果今天你要實作一個 Loyalty Program 來提升用戶在你的產品內的留存,這時候你的 MVP 應該要具備的功能應該要有:

  1. 新功能的提示 - 如果沒有這塊用戶可能會連有這個新的 Loyalty Program 上線都不知道。
  2. 反饋提示 - 用戶完成消費後你應該要能讓他知道他的消費同時可以積點,讓他更能充分理解這個功能帶來的價值。
  3. 兌換功能 -用戶看到他的里程點數提升後,可以知道這個點數累積的好處,例如累積滿 100 點,就可以兌換 300 元折價券,讓用戶覺得這個功能是有價值並且會對他帶他幫助的。

不該在 MVP 內的功能則是:

  • 不同類型的會員等級 (要先驗證用戶在乎會員機制)
  • 不同類型的兌換機制 (要先驗證會員會想去兌換)
  • 時髦的 UI 顯示特效,例如每次查看累積點數的時候會跑動畫效果
  • 累積點數的歷史紀錄

最糟糕的 PM 就是把下面的功能全做完了,但是竟然沒做了簡單用戶提示結果導致功能上線後失敗,但完全無法找出原因是因為功能設計不佳還是用戶根本不知道有這個功能的存在。

III. 假設、驗證、分析

不管是開發一個新產品或是新功能,PM 都會對這個開發的項目有其假設並且透過驗證以及分析並不斷迭代達到預期的目標,這是每個做產品經理都該具備的能力,但是一個優秀的產品經理在設定評量指標的時候會同時評估長期的目標跟短期目標,對於功能上線後其他指標的影響性也會同時兼顧。

普通的產品經理在看數據的時候通常會比較是大方向的去觀察,譬如說一個產品重要的指標該是什麼?

多數的 PM 會回答 DAU、用戶留存、付費轉換率等

這個答案雖然沒有錯但因為這些指標都很難被影響,或是其可能影響的變因太多,所以通常這類型的低敏感度的指標比較適合作為整個大方向的戰略目標,但是每一個功能上線時,資深的產品經理會更在乎那些敏感度比較高也會間接影響關鍵指標的數據。

除了需要驗證的指標以外,一個有經驗的產品經理在上線一個新功能之後也會在乎其他的指標是否會被影響,畢竟不能因為目標是提升用戶留存,但是達成的同時卻降低了用戶的註冊率或是付費轉換等其他重要數據,如何選擇正確的指標以及判斷每個不同功能可能帶來的其他影響是一個優秀的 PM 必需具備的能力。

舉個例,面試時我一直很喜歡問面試者的一個問題是:

身為一個社群產品的 PM 如果你的目標是要提升平台上直播功能內的廣告被點擊率,你會怎麼做,原因為何?

很多好的產品經理都可以說出幾個正確的思考邏輯下的答案:

提升廣告被播放的頻率

一進直播時就先播放廣告

根據用戶的輪廓提供更精準的廣告內容

設計更吸引人點擊廣告呈現方式

一個優秀的產品經理給出這些答案以外,也同時會主動關心用戶的觀看時長 / 留言比率 / 用戶繼續觀看直播的比例,因為除了得到你想要改善的目標之外,也要務必確認不能因為一個新功能而導致其他重要行為被改變,進而長期下來反而對產品有負面的影響。

優秀的產品經理在乎那些更細微敏感指標,以及其他可能的對產品造成負面的非預期影響

IV. 管理好你的利害關係人

制定你的 stakeholders 合作計畫

  • Who
  • 產品對他的目標影響程度
  • 對產品方向的決策影響性
  • 對產品的興趣程度

你可以用一張表把你的 stakeholders 用上面的方式列出後去制定跟他們互動的策略,如果 3 個指標都是高的人是你最先要關心的人,反之如果都很低的利害關係人你就可以放到比較後方去做 sync up,然後關於合作的方式也可以列出來

互動方式 (需要面對面會議討論或是只要持續更新狀況就好)

內容 (如果對方的目標跟產品有掛勾,那溝通內容就要包含相關數字)

頻率 (每週/每月/每季)

簡單來說優先 deal 那些對你的產品方向決策有影響性高的人,如果他們的目標跟產品的相依性又強他們也關心產品狀態的話,你就至少會需要每週跟這個 stakeholder 有直接面對面的會議比較好,而其他人或許則可以透過月報或是產品路徑圖的定期更新以及主動通知來讓這些厲害關係人保持在狀況內。

透明且有明確價值目標的產品路徑圖

一個完整的產品路徑圖應該要包含以下幾個部分:

  • 願景 (產品存在的理由)
  • 商業的目標 (提升 LTV or 增加新用戶數等)
  • 時程
  • 提供的價值(雖然是指針對目標下開發的功能,但更重要的是要讓其他人知道這個功能的產出是什麼? 例如: 如果開發項目是設計新用戶的 onboarding 機制,那麼這邊的提供價值就應該是『讓新用戶可以更容易地認識產品』)

傳統的 product roadmap 很常失敗的原因是因為『不切實際』,舉個例來說很多 PM 因為想要滿足 stakeholders 的期望,常常會把 roadmap 照著開發時程的預估去做很緊密地的排序,但是假設中間一個 MVP 功能上線後效果出乎意料的好,這時候可能團隊會更傾向進行功能的迭代而非馬上投入到下一個功能開發。

反之亦然,如果一個主要的功能上線後成效沒想像中的好,這時侯透過了用戶的反饋發現了原因,你會想要安排 enhancement 或是等到以後再做? 這些種種的不確定因素都會照成所謂提前安排的 product roadmap (其實是 release schedule) 最後實際有一半的項目無法完成,因此與其列出什麼時間會完成什麼『項目』,更好的是用能帶來什麼價值給產品,這樣才能確保自己與 stakeholders 的方向是在解決商業上的問題。

無止盡的學習

成為一個 PM 其實很容易,要從 0–1 的門檻也不高,但是要把產品真正的做到好取悅用戶並且同時滿足利害關係人的期待就非常難,但這些挑戰以及達成的成就感也是這個職位的魅力所在,相信大家一定都能達到,一起成為一個厲害優秀的 Product Manager !

熱愛科技以及新點子,期許成為一個全方位的 Product Manager,前17LIVE 資深產品總監,現任 Hahow 產品總監。歡迎交流! | Linkedin: https://www.linkedin.com/in/hao-mike-sun/

熱愛科技以及新點子,期許成為一個全方位的 Product Manager,前17LIVE 資深產品總監,現任 Hahow 產品總監。歡迎交流! | Linkedin: https://www.linkedin.com/in/hao-mike-sun/