作為 HoP，你多半已經知道 PM 在做什麼。但真正的關鍵問題是：你能清楚把 PM 的角色描述給你的 PM 聽嗎？ 這裡有個很大的差別——隱性理解（implicit understanding）與顯性描述（explicit role description）之間的落差。在被問到的當下、任何時間任何場合，都能脫口而出一份精確且一致的角色描述，是帶團隊的起點。

讀這一章時，作者建議準備一支螢光筆，把你同意的內容畫起來。讀完後，用自己的話寫下你對 PM 的定義——簡短、好記、好向他人解釋。一個產品團隊需要的領導者，心裡必須對「PM 該做什麼、不該做什麼」有清晰的圖像，而且不只是日常工作，還包含團隊、公司、產業三個層次的脈絡。

什麼是「產品」#

在談 PM 之前，得先把「產品」講清楚。聽起來簡單，但作者見過太多公司、HoP 與 PM 在這個定義上摔跤：

  • 一位 PM 被指派負責26 個他們各自稱為「產品」的東西，然後抱怨自己永遠排不出優先順序
  • 公司把 PM 切成「後端 PM」與「前端 PM」——前端 PM 只負責商店的店面呈現，卻很難把價值真正交到顧客手上

產品（Product）的定義：一個被創造並提供給某人的東西，能為顧客或使用者（市場）帶來價值。此外，它必須同時支持公司的需求與限制，讓生產持續運轉，長期足以自我養活（sustainable over the long run）。

產品的形式可以非常多樣：

  • 實體商品（洗衣精、這本書、Tesla）
  • 完全數位的產品（Netflix、線上課程）
  • 科技賦能、虛實整合的產品
  • 線上服務組合（Facebook、Salesforce）
  • 以網際網路作為行銷／銷售／配送通路的產品（Uber、Etsy）

作為 HoP，請花一點時間想清楚：你手上這個東西「真的是產品」嗎？值得配一位 PM 嗎？如果定義含糊，PM 永遠在打散仗。

什麼是「產品經理」#

最簡單的定義是：負責產品開發各個面向的人。但作者認為這句話沒有觸及 PM 工作的真正核心，於是引用 Marty Cagan 的定義：

It’s the product manager’s job to come up with a product solution that is valuable to the user, usable by the user, buildable by our engineering team, and still viable from a business perspective.

PM 的職責，是找出一個對使用者有價值、使用者能輕鬆使用、工程團隊做得出來、且商業上行得通的產品解決方案。

這四個面向各自對應一個風險，PM 的工作就是在其中找平衡（Figure 3-1）：

Figure 3-1: What I draw when I have to explain the job of the product manager

  1. Value risk（價值風險）：顧客會買單嗎？使用者會選擇用它嗎？
  2. Usability risk（可用性風險）：使用者能搞懂怎麼用嗎？
  3. Feasibility risk（可行性風險）：以目前團隊的時間、技能、技術，做得出來嗎？
  4. Business viability risk（商業可行性風險）：這個解決方案在業務各面向（法務、行銷、財務等）都行得通嗎？

過度偏重其中一個面向，其他面向就會翻車，產品也會失敗。

哪些人其實不算 PM#

對照上面的定義，下列角色嚴格來說都不是 PM：

  • 只替敏捷開發團隊維護 backlog、不做任何決策的人
  • 只蒐集全公司需求、把它們丟上 roadmap、在會議裡讓委員會 design by committee，自己不做決策的人
  • 只寫 concept，實際團隊在別處、而且要很久之後才會開始做的人

PM 的關鍵活動#

要在價值、可用性、可行性、商業可行性之間找到甜蜜點，PM 必須能夠：

  • 聆聽使用者、顧客、市場，理解他們的問題以及可能的解法（這是在產生價值）
  • 設計並執行多個實驗與原型，在真正打造前先測試假設與各種解法（最小化「把錯的東西做得很漂亮」的風險）
  • 交付價值並驗證使用者是否真的在用、在買（product-market fit）
  • 極大化價值、極小化打造成本，並確保勝出的解法能在合理時間內被團隊做出來
  • 交付產品並根據使用者回饋迭代、優化、甚至創新

產業裡會替這些活動冠上各種名稱：設計思考（design thinking）、產品探索（product discovery）、使用者研究（user research）等。但說到底都可以歸納成「PM 在做什麼」。

PMwheel：八項關鍵活動#

為了系統化評估一位 PM，作者設計了 PMwheel，把 PM 的活動拆成八個象限（Figure 3-2，詳細定義見下一章）：

Figure 3-2: Key activities in the PMwheel

  1. Understand the problem（理解問題）
  2. Find a solution（找到解法）
  3. Do some planning（進行規劃）
  4. Get it done!（把它做出來）
  5. Listen & learn（聆聽並學習）
  6. Team（團隊合作）
  7. Grow!（自我成長）
  8. Agile（敏捷）

活動 1–5 直接對應產品開發流程；活動 6–8 則是無法綁在產品製造流程上的通用 know-how：和團隊合作所需的能力（如 Tuckman 團隊發展階段、激勵）、自己持續學習成長的能力、以及在敏捷環境下運作的能力。

不論 PM 背景為何，他的工作都是……#

  • 降低「把錯的東西做得很漂亮」的風險
  • 把使用者真正想用的產品送到他們手上，提升他們的生活
  • 在既定限制與既定團隊下，想辦法把價值交付出來
  • 同時讓公司賺到足夠的錢繼續運轉

下一章會進一步拆解「好 PM」的定義，並協助你為自己組織中的 PM 量身打造判準。寫完自己的定義後，請回頭檢視、優化、記熟它——被問到時能隨口講出來。

延伸閱讀#

作者推薦的參考資料：

  • Martin Eriksson：an oldie but goodie
  • Marty Cagan：Behind Every Great Product
  • Ben Horowitz：Good Product Manager, Bad Product Manager
  • Jeff Patton：Product Management in an Agile Environment
  • Henrik Kniberg：The Role of the PO
  • 15 Things You Should Know About Product People
  • The Evolving Product Management Role

書：

  • INSPIRED — Marty Cagan
  • Product Management in Practice — Matt LeMay
Backward 快速團隊評估 定義你的「好」 Forward