【PM 總動員】如何成為合格的產品經理?必須理解的三大核心與案例
【PM總動員】是產品三眼怪的每月定期客座單元,挖掘邀請海內外業界產品開發相關領域的大大們和大家分享!本月邀請到的是 Pinkoi 的 Product Manager Jason,他曾在 KKTV 擔任 Growth Team Lead,也是 ProductTank Taipei 的組織者之一,豐富產品經驗的他此篇將和大家分享 PM 打造產品的三大核心,與 Pinkoi 是怎麼做的。
怎樣是個合格的產品經理?
其實我沒有完整的答案,如同成功的產品沒有萬靈丹、沒有標準答案,合格產品經理 (Product Manager, PM) 的標準也很多元。每家公司面對獨特的處境,對產品經理的期待也很獨特,很少有完全相同的標準。
那你何必寫這篇文章?
首先,我自己在應徵 PM 工作,或代表公司面試應徵者的時候,時常遇到這個痛點: 你我兩個腦袋中的 PM ,是指同一個角色、同一份工作嗎?正因為「合格產品經理的標準也很多元」,造成大家對 PM 的定義不儘相同,所以這篇文章希望帶給大家一個「判斷框架」,作為溝通媒介。
其次,我自己在 PM 的學習旅途上,雖然發現 PM 該學的東西無邊無際,但還算有個「分類方法」。以前,當每次覺得自己快要合格的時候,又突然發現「因為還不懂這個,所以不夠格」,然後覺得挫折。自從得知、整理出分類框架後,心態就變成「在這類工具箱中,又多了一把刀」的「蒐集感」,所以這篇文章希望帶給大家這個分類框架,讓我們都能像打遊戲一樣蒐集寶物、湊齊裝備。
最後,我也想以現在任職的 Pinkoi 公司為案例,和大家分享我們如何設定產品經理的職責領域。
怎麼看待 PM 的職責?
先釐清一件事: 這裡的「產品經理」是指「運用電子硬體、數位軟體、網際網路等相關科技」來「打造產品」的「科技產品經理」,不是金融產業、快速消費品產業、零售產業的產品經理。
我用以下框架,判斷一個產品經理的職責領域,也用同一個框架來區分產品經理的能力類別。這個框架可以叫做 PSS (Problem-Strategy-Solution),或叫做 DHD (Discovery-Hypothesis-Delivery)。PSS 用來判斷「職責領域」,而 DHD 用來區分「能力類別」,互為表裡、一體兩面。
這個分類方法,對應了三個打造產品的核心活動:
- 問題探索 (Problem Discovery): 探索市場與顧客的問題,聚焦在關鍵的需求
- 策略假設 (Strategy Hypothesis): 面對尚未滿足的需求,假設解決問題的路徑,成為決策判斷的依據
- 方案交付 (Solution Delivery): 交付產品方案到顧客手中,推到市場上獲取商業價值
在產品迭代週期中,這三個活動可能交錯出現,也可能同時出現。產品經理在每個週期會偏重不同的活動,也許先偏重在問題探索與策略假設,然後偏重在方案交付。
如何探測一個團隊,對產品經理的定位與期待?可以試著從「你們的產品經理,如何分配時間?」,或從「你們的產品經理,需具備哪些能力?」的角度切入,然後將獲得的資訊套入這三大核心活動。舉例來說:
- 某個硬體團隊認為 PM 應該花絕大多數的時間在 Solution Delivery
- 某個軟體新創團隊認為三者的時間要盡量均衡
- 某個跨國瀏覽器公司認為要偏重 Problem Discovery 和 Strategy Hypothesis
- 另一個軟硬整合的系統服務商則用三個人分別承擔三類職責,但彼此略有重疊
對於產品經理自身來說,常見的學習路徑是: 要先大致掌握 Solution Delivery ,再盡量掌握 Problem Discovery,最後再盡力掌握 Strategy Hypothesis。我也是這個學習路徑,最近才剛摸到 Strategy Hypothesis 的邊緣。那麼,接下來就用常見的學習路徑,依序大致介紹。
Solution Delivery 方案交付
產品經理基本的職責是: 要排除產品上市過程中,所有交付的障礙與困難。
方案交付需要許多技能,例如: 專案管理、開發時程安排、體驗設計、品管與測試、在地化與國際化、上市發布計畫、溝通協調,等等等。方案交付的過程必然仰賴很多角色的團隊協作,產品經理不可能精通所有專業,但要根據團隊現狀來補位。例如,當團隊沒有 QA 品管與測試夥伴時,產品經理就得自己做。有些公司會額外安排一個角色,負責方案交付,這個人的職稱可能是: 交付經理 (Delivery Manager)、發佈經理 (Release Manager)、計畫經理 (Program Manager)、或專案經理 (Project Manager)。
Problem Discovery 問題探索
產品經理的另一個職責是: 要降低產品開發到上市過程中,導致產品失敗的關鍵風險。
有這四大關鍵風險:
- 實行性風險 (Feasibility Risk): 團隊確知需求,但手邊並沒有解決問題的技術,或技術尚未成熟,就是「我們知道要做什麼產品,但是做不出來」的狀況
- 易用性風險 (Usability Risk): 顧客想用這個產品,但不知如何使用,或太少人克服使用門檻,就是「產品做出來了,但是好多顧客看不懂、不會用」的狀況
- 價值風險 (Value Risk): 這個產品並沒有解決顧客需求,為顧客帶來價值,就是「產品做出來了,某些顧客也會用了,但後來都不繼續用,因為沒有滿足需求」的狀況
- 商業可行性風險 (Business Viability Risk): 這個產品對公司沒有商業價值,或無法在市場競爭中存活,就是「產品做出來了,顧客也愛用,但是無法賺錢,或拿不到更多預算與資金,或無法贏過競爭者」的狀況
當我自己覺得能大致掌握 Solution Delivery,也體驗過產品推上市的過程後,發現「產品仍然很容易不成功」。不管交付的品質做多好、設計做多好、開發流程多完善,終究失敗,原來是我們太晚認清以上風險。
問題探索需要的技能,例如: 用戶訪談與研究、問卷調查、競品與市場研究、線上隨機實驗(A/B testing)、易用性測試,等等等。如同方案交付,問題探索的過程也要仰賴很多角色的團隊協作,但因為多數公司還不夠認清這些風險的威力,所以這也是產品經理最常下海補位的工作。少數公司會搭配一些角色,和產品經理一起探索問題,例如:用戶研究員 (User Researcher)、易用性工程師 (Usability Engineer)、產業分析師 (Industry Analyst)、資料分析師 (Data Analyst),等等。
Strategy Hypothesis 策略假設
產品經理的最後一個職責是: 要避免團隊失焦發散的狀況,並降低團隊自信過剩或信心殆盡的情形。
Strategy Space 是 Problem Space 和 Solution Space 取交集的結果,且要轉成一個讓大家「相信我們能夠解決問題」的濃縮論述,但同時也是個假設 (Hypothesis),以假設的心態讓大家「有信心又戰戰兢兢」。這裡的策略可以位於不同的公司/組織層級中,要看產品經理的職責範圍,但對策略的思考框架基本上類似。
而一個完整的策略假設,需要包含以下三大核心元件:
- 1/ 問題診斷: 限縮過、解析過的問題描述,以及自己對這個問題的診斷,要能短時間內讓人理解「這個問題為何重要、如何嚴重,有哪些背景成因」
- 2/ 指導原則: 根據現有資訊,我們假想「能讓產品成功」的指導原則,能幫助我們在過程中做決策,並防止我們做出「跟問題本質相衝突」的決策,切此避免失焦
- 3/ 連貫的草案: 要能初步描述一個「可能的方案」,當作具體例子、初步討論的基礎,而且能扣緊指導原則與問題診斷,達成協調一致的聚焦效果,但也要和團隊強調「這只是草案」,保留嘗試空間
大部分人們廣泛傳播的策略,其實都可說是某種「指導原則」。舉例來說,「低價搶市」(如亞馬遜)和「補貼擴張」(如蝦皮)被認為是兩種有助於增加市佔率的策略,但換個角度看,其實也是在「投資與花費」相關決策上的兩種指導原則。低價搶市下的投資與花費追求「長期營運效率」的最大化,而補貼擴張則追求「短期擴張速度」的最大化,甚至願意犧牲營運效率。必須把每個指導原則(人們口中的策略),放到問題情境裡面,才好判斷是否管用;只看「指導原則」而忽略「問題診斷」的策略思維,是盲目走向消亡的主因之一。
因為策略假設很抽象,因此需要以很多種表現方式來具體化,產品經理也要具備運用這些方式的技能,例如:
- 顧客用途: 用來表現問題診斷,或用來定義需求
- 優先序列: 是一種指導原則,可以是需求或功能的優先性排序,表示若我們按照這個優先性擴充產品、解決問題,就有機會成功,因此可作為決策依據,引導聚焦
- 目標層級: 也是一種指導原則,可以是一個或一組目標,表示若我們達成這些目標,就有機會成功,因此可作為決策依據
- 路線圖: 用來表現連貫的草案,進一步把「優先序、目標、或方案主題」表現在「時間區間」上,引導時間分配,並協調彼此的行動
我們時常認為,策略假設是創辦人、執行長、產品長、或最終管理層的職責,只在少數狀況會交給產品經理。但其實,在產品經理的日常工作中,有很多機會鍛鍊我們在策略假設的能力,小至安排開發項目的優先序列,大至提出未來幾季的產品路線圖。
當我自己覺得能大致掌握 Problem Discovery 之後,接著遇到的痛點是「難以傳播問題探索獲得的學習」,因此難以在團隊中落實。如此一來就沒有降低風險的效果,團隊也難以體會問題探索的價值。
產品經理必須取捨探索後的收穫,濃縮成一段策略假設,以說故事的方式傳播在團隊中,並在各式決策點,重複取出具體化的指導原則,才能確保我們能落實彼此協調的解決方案。
有點抽象?來看 Pinkoi 如何做
以我目前任職的 Pinkoi 為例,來介紹產品經理的角色。Pinkoi.com 是亞洲領先的設計購物網站,販售設計商品、數位創作、體驗活動,並網羅海內外優質設計師群,堅持用好品味、客製化的獨特設計,實現每個人對生活詮釋的想像,也讓每個送禮時刻更加獨一無二。
在 Pinkoi 我們有 Product Design Team (PDT) 和 Engineering Team (Dev) ,產品經理屬於 PDT,和產品設計師、視覺設計師、用戶研究員、在地化語言專家 (L10n) 同部門。Pinkoi 目前沒有根據產品切分常態存在的團隊,而以動態編組隊友的「專案團隊」運作,每個專案有一位專案負責人 (Project Owner, PO)。通常根據專案特性,選派特定專業的隊友兼任。舉例來說,可能有這幾類專案:
- 行銷活動(線上、線下): 可能由行銷的隊友擔任 PO
- 外部合作夥伴、服務方案: 可能由商務發展、設計師關係的隊友擔任 PO
- 串接外部服務(金流、物流): 可能由工程師隊友擔任 PO
- 電商平台的體驗流程或基礎建設改善: 可能由設計師隊友、工程師隊友、產品經理擔任 PO
我們通常會屬於二個專案團隊,每個專案短的話 1–3 個月,中等的 4–9 個月,長的 10–18 個月但目前很少見。在這種狀況下,PM 產品經理通常就是全職擔任 PO,可能要擔任二個專案的 PO。以我自己來說,在三類職責(Problem Discovery / Strategy Hypothesis / Solution Delivery)的時間分配,大概是 2 比 3 比 5。因為有用戶研究員、產品設計師、資料科學家一起做問題探索,所以能花 20% 的時間做到一定程度。因為 PM 也兼任 PO,我們也沒有 QA 測試隊友,所以要花 50% 的時間維持專案運作的步調、做很多溝通協調、上線部署前的測試,但也因為隊友都很主動積極、團隊體質健康、溝通暢通,所以不用花超過 50% 的時間。
這樣運作方式的優點,對公司來說可以彈性調度資源,對 PM 來說可以接觸不同的問題與產品區塊、很新鮮很有挑戰。至於缺點,對公司來說是不利於「需長期發展」或「重要但不緊急」的目標,規模擴大時可能難以累積特定領域的知識,對 PM 來說,則是溝通和團隊磨合上格外費心,因為人員時常重組。
以 Pinkoi 的組織架構、對產品經理的職責定義,讓產品經理和擔任 PO 的隊友,都有空間均衡發展三類職責範圍、技能裝備,是個有利產品經理成長的環境。此外,在 Pinkoi 可以跟相當主動積極的隊友合作,可以在公司很認真維繫的團隊文化中做好事情,這對產品經理來說都非常重要。剛好,Pinkoi 正在招募各項職缺,如果你想在這樣的環境中工作,歡迎與我們聯繫 ☎️ !如果你覺得某個朋友很適合,請務必幫我們分享給他 📣!