ProductTank Taipei #19 - Product Is Hard - Marty Cagan
"Product is hard" 這題目也太精闢且血淚了，Marty Cagan 的引言是這樣講的：
We'll talk about politics, culture and even (process) religion. We'll discuss prioritization and decision making, especially when we don't have as much data as we'd like; handling very difficult people especially senior executives; managing conflict on the team; dealing with low morale; changing company culture; regaining control of your time, and picking your battles.這場難得的大師演講（雖然是英文），怎麼能錯過呢！ ProductTank Taipei 這次完全升級活動規模，舉辦了這場大型演講，sponser 都是響噹噹且深耕台灣的新創或高成長公司，包括大家熟悉的 Pic Collage、arc () x codementor、Mozillia（我有聽 ProductTank #13）、Pinkoi（我也有聽 ProductTank #14）和 Business Weekly。
Marty Cagan 的個人簡介，我直接取用主辦單位的介紹：
Marty Cagan, Founder and Partner, Silicon Valley Product Group
Before founding the Silicon Valley Product Group to pursue his interests in helping others create successful products through his writing, speaking, advising and coaching, Marty Cagan served as an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett-Packard, Netscape Communications, and eBay. As part of his work with SVPG, Marty is an invited speaker at major conferences and top companies across the globe. Marty is also the author of the book INSPIRED:How to Create Tech Products Customers Love which is now also available in Traditional Chinese.
https://www.books.com.tw/products/0010820309
https://svpg.com/inspired-how-to-create-products-customers-love/
Cagan 直接破題：「如果你做過產品，一定懂產品有多難做；如果還沒做過.....讓我們來聊聊做產品的難處。」
Marty 詢問了現場參與人的角色：
- Product Manager / Product Owner
- Designer
- Engineer
- Product lead
- Marketing
Cagan 闡述他為什麼要著重在 "Product Manager": People are talking about product "design" but people didn't talk about "product". That's a black hole.
而現實世界不是這樣的，做產品好難，很多課程教學怎麼「設計」，但很少課程教學「如何成為一個產品經理」，但產品經理對於產品的成敗至關重要－這也是 Marty Cagan 投入 Product Manager 培養課程的初衷。從 hp 到 Netscape，Cagan 說，做為 web browser 的領航者 Netscape 的工作環境和產品挑戰，是對產品經理非常好的育成。結束 ebay 的工作後，Marty Cagan 成立了 The Silicon Valley Product Group (svpg)。
Common Problems #1: Frustration with Lean and Agile
大家對 Agile 一定不陌生，但真正到執行和落實，卻有很大的難度。
The Core Principles of Agile and Lean:
- Releases should be small and frequent（最多兩週就要一個版本）
- Teams should be empowered and accountable
- We need to learn fast in order to innovate（採用 Agile 的團隊必須要「不斷不斷的提出創新」，而創新需要透過快速學習，才能得到養分進而產出。
- We need to minimize waste（MVP, the Minimal Viable Product - 另一個大家耳熟能詳的關鍵字，should be "prototype"）
Conventional Lean and Agile 的過程，並不是根據產品終點逐漸「長出全貌」，而是以一種「演化」的姿態，透過不斷的 try and error，調整設計，甚至調整目標，最終產出上市的產品很可能與最初的構想相去甚遠－但是實際、有用且可行。
The problem is that we have two very different tasks:
- We need to discover a solution that is valuable, usable, feasible and viable.
- We need to deliver a solution that is reliable, scalable, performant and maintainable.
Bring the right product, instead of make the product right.透過深度且縝密的產品思考，而非武斷地直奔既定終點，產品經理可以帶著設計、研發、行銷，創造「正確的產品」。
Marty Cagan 提到了最近在台灣也正夯的 OKR，定義出 Objectives，透過 prototype 來 "discovery" 來走向正確的產品，而非僅僅是 push 研發和設計 "delivery"（但研發和設計，仍要守住自己產出的品質）；但 Cagan 提及，時程的掌控非常重要，假如用 4 個月來 run MVP 流程，就停留了太久在 "Discovery" 的產品定義階段，到了 "Delivery" 的階段，就是進入 Product、Product / Market fit 的落地階段。
"Fake it until you make it."（我超愛上面這句）
若只是 "delivery" 未經深度思考的產品，那是 "output"，但若是真正經過反思、雛形、設計再創新的產品，是 "outcome"。
Common Problems #2: Feature Teams vs. Product Teams
Discovery 會是一個持續不斷的過程，在真正的好公司，例如 Microsoft，80% 以上的 ideas 會被放棄，僅有 10% 的創新會被實踐。產品經理在規劃產品時，要考慮諸多元素：
- Value
- Usability
- Feasibility
- Viability
產品經理要能理解、了解 Feature teams 的痛點、考量以及困難，才能建立良好的合作模式（但 Cagan 補充說明，Silicon Valley 其實有很多可怕的研發 team，不是大家想像中的隨處都是真強者）。
Common Problems #3: Validating Ideas (beginner product team) & Discovering Solutions (good product team)
Common Problems #4: Planning vs. Prototyping
愛因斯坦的名言：我花了 100 分鐘思考，但只花 10 分鐘執行。
每一個公司的時間都很寶貴，我們花了很多時間規劃，但沒有時間在執行前先嘗試「驗證」提案是否可行、可靠、有價值，而當研發資源花下去，卻發現錯誤想轉彎，已經需要付出更多的代價。
Cagan 問，台灣有多少公司使用 "Slack"？ 若公司不是一開始就使用 Slack 這個軟體，這個轉換應該會需要一點時間，但大家可以思考看看，這種轉換，一般都是怎麼發生的？
If you got a hard product problem to solve, spend more time to do "prototyping". MBA like "planning". They like "planning". But please do "prototyping".
請產品經理走向 designer、engineers 一起討論 solution 吧！不要只是關門悶頭「思考」自己的產品規劃，走向 feature team 一起用 "prototype" 驗證這些點子。
Every kind of good product teams, they have many types of prototypes.
Common Problems #5: Not Considering Alternative Solutions or Approaches
產品經理在規劃產品時，絕對不能只想一條路，需要同時發想 Plan B、C、D，而在進行這些發想和規劃的同時，都需要不斷檢視自己的「目的」，在發想和規劃的過程，校正自己前進的方向，但隨時因應突發狀況或驗證結果，調整前進的 solutions。
Common Problems #6: Not Thinking Enough About Ethical Risks
Cagan 提出一個「滑世代」的經典情境來闡述產品經理的道德抉擇：做為一個產品經理，設計出一個黏著度超高，讓青少年 (13 歲，例如)，一整天滑四五個小時手機的產品，這樣是一個成功的產品嗎？我們應該要同意推出這樣的產品嗎？
Common Problems #7: Confusing Optimization with Discovery (about creation)
Optimizations are low risk with A/B test, Cagan 強烈建議所有的產品團隊都要進行 A/B test。但要注意:
Don't just focus on optimization, keep doing creation.
Common Problems #8: Qualitative vs Quantitative Learning
當碰到了一個很重視數據的老闆怎麼辦？部分公司文化會過度注重「讓數據說話」，而忽視了質性研究報告的重要性，數據只能告訴我們一部分的「問題在哪裡」，卻不能告訴我們「問題是什麼」。
Common Problems #9: Product Management Competence
"Product Manager" is the job title. "Product Owner" is the role. You need to make sure the product manager is the product owner.
Product Manager Competence:
- Deep Knowledge of your User and Customer（一般來說要花三個月）Most important
- Deep Knowledge of the Data those Customers Generate
- Deep Knowledge of your Business Second important
- Deep Knowledge of your Industry
When is the last time you meet your customer?
When is the last time your CEO meets your customer?
做產品，必須要接觸使用者，才能真正了解使用者的需求，才能真正根據需求，創新、規劃出真正有價值的產品。"You have to go visit customers"，「然後你會了解，使用者跟你有 100 種以上的差異」，Cagan 邊講述他在 ebay 的出差感想邊笑著說。
B2B product 因為產品規模負責、龐大，了解使用者的過程，會遠難於 B2C product。
討論到 "Deep Knowledge of your Business"，Cagan 認為這對產品經理來說，是第二重要的核心能力和權限，必須要能對公司策略、經營有所理解，才能規劃出正確、有效且可行的產品－請大家多多跟老闆聊天，了解組織、公司策略。
若產品經理沒辦法獲得以上權限，在產品規劃的深度和準確度上，是很受限的。
Common Problems #10: Coaching Product Managers
有時候問題不出在產品經理，出在「產品經理的老闆」，You need to spend more time on coaching your product managers. 產品經理的養成，需要透過有效的 coaching。
Empowered Product Teams（體檢時間到）:
- Cross-Functional: The team is staffed with competent people with character, covering the necessary range of skills.
- Empowered: The team is assigned problems to resolve, 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).
It's not time to market, but time to money - solve the right problems. 上市前至少要解決 60% 的問題。
若上述三個條件都滿足的話，你有一個很強大也準備好了的 team，可以準備衝刺了！
Q&A
若團隊中的 feature team 成員（例如設計或研發），他們並不了解 customer，要怎麼幫忙想 solution 呢？
All you really need is 1 senior engineer for product solution instead of the whole engineering team.在尋找解決方案的過程中，不是讓「所有成員」都參與規劃，那沒有效率，需要找出核心、具備足夠 know-how 的各專業代表成員，加入問題解決方案小組，才能集合重要觀點，有效率地找出問題和解法。也有一個直接的做法－帶著 designer、engineer 直接現場做使用者觀察研究，讓核心成員「親身體驗」使用者的痛點。Minima 3 hours per week to understand your customer. 這問題點出了 Product Discovery 過程中的重點。
If you are a product manager of feature teams - "do your homework". 在做足準備後，走向 stakeholder 舉手提案，feature team 的有效解決方案提案，可以在產品部門與專業部門間建立信任關係。Part of your homework, really understanding your business work.
Documentation 很重要！文件要寫！規格要文件化！若核心成員坐在一起直接討論 prototype，對文件的需求相對小，但若協作的 team 並不在同一個地方工作，甚至遠端工作，文件在有效的溝通上，就扮演非常重要的角色。
另一種文件是「文件考古」，讓我們參考前人是如何發想或實踐的做為借鑑，如果缺少文件，就只能看著設計或是程式碼「猜測」，例如 trace 前輩的 source code（大家都懂這個痛），所以，為了後人著想，文件要好好寫，而且要 up-to-date 的寫。
Product Manager and Designer focus on "discover the solution". Engineers focus on "Build the delivery". 但兩者之間，需要頻繁的溝通 (especially during planning)，以確認彼此的想法和解決方案，是朝著同一個方向。
B2B product is hard to have alternative solutions. How to do?
For B2B products, we need to have more sense to make changes. 大型 B2B 產品開發週期長，因此在確定並實踐解決方案前，要經過更多的驗證，才能省去更高代價的重建或轉彎。Marty Cagan 建議看他的 "Gentle deployment technique" 了解更多相關討論。要如何定義 "Object" (OKR)
Cagan 說請 Feature team 定義 OKR 是很荒謬的：Please define your OKR, but wait, here is your roadmap.產品經理要能替 feature team 定義出合理的 objects，告訴 feature team "what's the most important task"，這是產品經理的職責。
What's the worst thing when the product manager trying to be the designer?
Need to adjust the plan, make sure all teams are doing what they really need to do.Year roadmap =/ Product Vision. Product Vision should be 3~5 years long. A roadmap is detail, and detail changed. Be flexible for the detail.
Let's google "High-integrity commitment" and get Marty Cagan's article, again :D
問題很多，答案很多，技巧很多，我們還是來看書/看文章吧。
Comments
Post a Comment