產品專案管理大師 Marty Cagan “ Product Is Hard ”

做好產品難，做個好產品經理更難

However I spend a lot of time, we’re talking about product management for one main reason. It’s because there’s plenty of people to talk about design and really a lot of people that talk about engineering but almost nobody talks about the product. And I think that’s a big hole and it’s why well I make no secret of this there. I think the biggest problem in our industry is that we have capable engineers and capable designers but we often don’t have a capable product manager. That’s a big problem in our industry, it’s not because people aren’t smart or anything like that it’s that they haven’t been trained, nobody taught them how to do product

Marty 在剛開始先提出為什麼他要討論產品管理，因為有很多人討論設計、工程，但幾乎沒有人討論產品。而且他覺得目前最大的問題是我們有好的設計師、工程師，但往往沒有一個有能力的產品經理，不是因為他們不夠聰明，而是沒有人訓練他如何做好產品。

在這場演講裡， Marty 提出他經常看的問題。

精實與敏捷上的挫折感（Frustration with Lean and Agile）

敏捷與精實的核心原則（The Core Principle of Agile and Lean）：

• 產品發布應該小而頻繁：例如2週發布，而不是4個月才發布
• 團隊應該被授權和當責
• 為了創新，要學得快
• 減少浪費

不了解敏捷開發可以參考入門書《》()、《》

Discovery & Delivery

• Build the right product：我們要弄清楚要做什麼產品
• Build the product right：我們需要提供一個解決方案

以往 Discovery （探索）都是交給產品經理獨自判斷，接著再 Pass 給 Team 一起 Delivery （交付）。一般人都會認為 Discovery & Delivery 因為目的不同，應該各自分工，但 Marty 提到當團隊一起進行 Discovery，一起進行 Delivery 才會持續讓產品進化。

他也提到給團隊目標比給功能（Features）還要來得重要有意義。另外他也講到最重的是在 Discovery 時，我們的解決方案（solutions）是 Prototype 可以用4小時或4天就可以完成且快速進行市場驗證，而不是產品 MVPs ，且必須要有：

• 有價值的（Valuable） — Something that our customers will choose to use
• 可用性（Usable） — Easy to figure out how to use
• 可行性（Feasible） — Buildable using the technology stack and skills we have
• 可行的（Viable） — Workable for our stakeholders within our budget, legal, ethical, and repetitional constraints

然後試圖創造出我們計畫好的產品時， Delivery 則需要建立在：

• 可靠的（Reliable）
• 可伸縮的（Scalable）
• 高性能（Performant）
• 可維護性（Maintainable）

功能團隊與產品團隊（Feature team vs. Product team）

產品團隊（Product Team）是把一群專業技能和職責不同的人匯集在一起，但 Marty 提到組建這樣的跨職能產品團隊並不難，但難的是大多數團隊都沒有達到他所描述的三個目標：

• 讓團隊擁有產品主導權（Ownship）
• 捨棄掉80–90%創意
• 重視目標而不是產品路線圖

驗證想法與發掘解決方案（Validation ideas vs. Discovering solutions）

團隊最重要的工作並不是驗證想法，而是持續地找到最佳解法來解決問題，最終有沒有解決用戶問題並產生價值。

Marty 同時推薦 Ben Horowitz 兩本書《什麼才是經營最難的事？》(KOBO)、《What You Do Is Who You Are》(KOBO)

規劃 v.s. 原型（Planning v.s. Prototyping） 做產品最困難的一點是「最後產出的解決方案是否能解決用戶問題產生價值」，其實現實上並沒有時間讓團隊真正「想出」一個可行的解決方案。所以 Marty 建議花很少時間做規劃，可以用幾個小時產出原型設計（Prototyping）進行探索（discovery）去驗證規劃的原型是否可行。 計畫（Planning）是為了交付（Delivery），原型設計（Prototyping）才是為了探索（Discovery） 沒有其他方法的解決方案（Not Considering Alternative Solutions or Approaches） 遇到問題時我們可以很快想到一個解法，但問題是若這是唯一想到的解法且原型也沒辦法那麼快驗證價值，那該怎麼辦？ 其實 Marty 有講到解決問的方法有很多種，而且有時候想到的解法只是解決問題本身，不一定解決了用戶的「真問題」，所以要時常察覺我們不是為了實現功能而是要解決用戶的問題，有沒有為產品產生價值。 Marty 建議可以用「Opportunity Solution Tree」，一種快速、輕量級的方法，可以藉由他來規劃和思考我們方法。模式讓我想到跟「影響地圖 Impact Mapping」蠻像，我們在做產品規劃時也時常會用到。 沒有充分考慮道德風險（Not Thinking Enough about Ethical Risks） 當你的目標是黏著度提高，可是目標用戶是青少年時，他一天會花好幾個小時在你的產品上時（例如遊戲、娛樂類），這樣會是個好產品嗎？在道德抉擇裡，我們應該推出這樣的產品嗎？他也提到除非你是一個教育類型的產品。 另外他也提到合法和非法的道德兩難問題，這都是我們需要充分考慮的道德風險，沒有非黑即白的答案，只是我們會為用戶創造出什麼價值。將優化與發掘混淆（Confusing Optimization with Discovery） 為了實驗我們調整的東西是否能做得更好，優化是一種低風險的 A/B test 方法。但 Marty 也強調「在 Discovery 不要只專注於優化，而是要不斷創新，創造出更多的價值」。 質化與量化學習（Qualitative vs. Quantitative Learning） 不能只是偏重量化或質化資料，而是兩種並重。資料可以顯示發生了什麼事，但無法說明為什麼。我們需要質化技術來說明量化結果。 產品管理能力（Product Management Competence） 這是對產品經理（Product Manager）最重要的內容，Marty 提到最重要的4件事情： 對你的用戶及客戶有深刻了解（Deep Knowledge of your User and Customer）：最重要的事情，通常需要花2–3個月時間。 對你的客戶產生的數據有深刻了解（Deep Knowledge of the Data those Customers Generate）：他提到幾個用具，Web analytics tool、Data warehouse tool、Sales analytics tool。 對你的商業模式有深刻了解（Deep Knowledge of your Business）：第二重要的事，例如客戶如何付款、資金來源、成本結構、如何行銷、有什麼法律規範需要注意、跟合作夥伴的關係。 對你的產業有深刻了解（Deep Knowledge of your Industry）：例如競爭對手、主要趨勢（例如 Machine learning 是否跟你的產品有關？），必須關注的是未來發展，而不是現在狀況 指導產品經理（Coaching Product Managers） Marty 講了蠻狠的話有時候問題不出在產品經理，出在「產品經理的老闆」，指導產品經理是產品經理老闆最重要的職責，「你最弱的產品經理有多強，代表你就有多強」。 授權產品團隊（Empowered Product Teams），簡單三個測試： 跨職能團隊（Cross-Functions）: The team is staffed with competent people with character, covering the necessary range of skills. 充分授權（Empowered）: The team is assigned problems to solve, and they are able to decide the best way to solve those problems. 團隊當責（Accountable）: The team is accountable for solving the customer or business problem (outcome). 參考資料