【文思不藏私】Product is hard

Vince Huang
Nov 7 · 3 min read

今晚參加了 ProductTank Taipei #19 — Product Is Hard — Marty Cagan,趁著記憶猶新,快速的紀錄一下重點。

前言

“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 product. And I think that’s 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 ofter don’t have a capable product manager. That’s a big problem in our industry, it’s not because of people aren’t smart or anything like that it’s that they haven’t been trained, nobody taught them how to do product”

這一段 Marty 說出他的擔憂,很多人談論如何訓練一位好的工程師或設計師,但卻很少人關注在如何訓練出一個夠格的產品經理。

“I found in our world has moved to agile, however they think that they go to a Certified Scrum Product Owner (CSPO) course and they think they’re a product manager and they’re not of course that doesn’t teach you the product owner responsibilities is about 5% of the product manager job so you should go to a CSPO course if you haven’t gone to one but that is not going to teach you how to be a product manager and that’s the real problem we have in our industry”

千萬不要以爲上過 CSPO 就會變成一位稱職的產品經理。

一些產品經理的共同問題(Common Problems)

Marty 首先先談到產品開發過程中在精實與敏捷上的一些挫折。

1. 精實與敏捷上的挫折感(Frustration with Lean and 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)
  • 減少浪費(We need to minimize waste)

這一部分可以參考『產品專案管理全書』中第七章,Mary 提到了作法不一定是敏捷或精實就是萬靈丹

而是本質上有沒有用三大原則運作:

  1. 一開始先處理風險,而不是留到最後才處理。
  2. 產品是大家合作定義及設計出來的,不是按順序開發的。
  3. 最後,重點是解決問題,而不是實現功能。

傳統的精實與敏捷(Conventional Lean and Agile)

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.

這邊我的理解,Marty 運用『設計與開發思維的雙軌並行』的概念解釋了『探索』(Discovery)與『交付』(Delivery)的思維是不同的,唯有團隊成員是一起進行『探索』,一起進行『交付』才會持續讓產品進化,而不是有一份看似『完美產品路線圖』(Perfect Product Roadmap)就可以打遍天下無敵手。如果希望有創新,在『探索』過程就需要持續的發想與嘗試,加速學習的速度,『探索』過程中的嘗試也許是浪費,但相對一個完美計畫經歷長時間的規劃與實作後卻在市場中發現不可行,這些浪費產生了學習的價值。

如果有團隊說他們將用四週做一個『最小可行產品』(Minimum Viable Product),這就是不『最小可行產品』(MVP),通常『最小可行產品』可能是用 4 小時 或 4 天就可以完成的。應該是以最小的時間,快速到市場驗證是否可行才是我們的目的。

在需求不明確,市場變化很大,『敏捷』是一個相對成本比較低的做法,這個做法是在『探索』階段運用成本較低的『雛形設計』驗證假設,找到有價值(Valuable)、有用的(Usable)、可行的(Feasible)與可行的(Viable)產品定位。探索過程中是尋找可能的解法,而非追求目標(Objective)。

在『交付』過程中,追求的是可靠的(reliable), 可擴展的(scalable), 可實作的(performant) 與可維護的 (maintainable)。交付過程中是無法浪費,需要有明確的目的,然後使命必達。

2. 功能團隊與產品團隊(Feature team vs. Product team)

如果你負責的是『元件團隊』(Component Team)、『功能團隊』(Feature Team)你就只是『專案經理』(Project Manager)、除非你負責的團隊是『產品團隊』(Product Team)你才有可能是『產品經理』(Product Manager)。

這一部分可以參考『產品專案管理全書』中第九章,Mary 提到『產品團隊是把一群專業技能和職責不同的人匯集在一起,讓他們真實擁有產品主導權(Ownership)』。讓團隊成員是為了產品願景,致力為顧客解決問題,而不是聽命行事。

3. Validation ideas vs. Discovering solutions

推薦了 Ben Horowitz 的兩本書『什麼才是最難的事?』(The hard thing about hard things)、『What you do is who you are』(上個月 2019/10/21 剛出版)。

團隊最大的功用並不是驗證想法,而是持續地找到最佳解法來解決問題,所以過程中的評量不該是驗證了多少次,而是最終有沒有解決用戶的問題產生價值。

4. Planning vs. Prototyping

計畫(Planning)是為了『交付』(Delivery),雛形設計(Prototyping)才是為了『探索』(Discovery)。一般常說的『最小可行產品』 (Minimum viable product)其實應該還在『探索過程』中,但很多人都在『交付』過程產生了『最小可行產品』,其實還蠻怪的。

5. Not Considering Alternative Solutions or Approaches

發想解決方案與規劃功能時,要時時提醒自己不是為了實現某些功能而是有沒有解決用戶的問題,有沒有為產品產生價值。

6. Not Thinking Enough about Ethical Risks

這部分我沒有太多印象。

7. Confusing Optimization with Discovery

這一部分可以參考『產品專案管理全書』中第 4 篇。在產品探索的過程中,需要的是快速嘗試更多的解決方案,測試的過程中要快且成本要低。所以在『探索過程』是為了要學習,因此『優化』並不是主要的目標。唯有確認出可以為產品產生價值的解決方案,找需要進行最佳實務(best practice)的優化過程。持續的 A/B Testing 才能找到好的解決方案。

8. Qualitative vs. Quantitative Learning

不要只是偏重量化的數據,而是量化與質化並重,才能讓產品產出最大效益。

這一部分可以參考『產品專案管理全書』中第 53, 54 章,Mary 提到『資料可以顯示發生了什麼事,但無法說明為什麼。我們需要質化技術來說明量化結果』。

9. Product Management Competence

  1. 對你的使用者及客戶有深厚的了解(Deep Knowledge of your User and Customer):最重要的一件事
  2. 對你的客戶產生出的資料有深厚的了解(Deep Knowledge of the Data those Customers Generate)
  3. 對你的商業目標有深厚的了解(Deep Knowledge of your Business):第二重要的事。
  4. 對你的產業有深厚的了解(Deep Knowledge of your Industry)。

個人覺得好的產品經理對『商業目標』(Business Value)與『目標受眾』(Target Audience)是必需要能掌控的。

10. Coaching Product Managers

Empowered Product Teams:

  1. 『跨職能團隊』(Cross-Functions): The team is staffed with competent people with character, covering the necessary range of skills.
  2. 『充分授權』(Empowered): The team is assigned problems to solve, and they are able to decide the best way to solve those problems.
  3. 『團隊當責』(Accountable): The team is accountable for solving the customer or business problem (outcome).

想了解更多『產品專案管理全書』的內容,可以參考我整理的書摘『Inspired ~ 書摘』。

Q&A

元件團隊的壞處

Marty 還在回答問題中有一句話讓我印象深刻『Engineering pool model is a terrible model』,簡單的說,他認為不同產品共用一個所謂的『元件團隊』(Component team)是一種災難。因爲現場發問的朋友就深陷其害(Sigh。

很多產品共用一個元件團隊的最大問題在於『開發人員對產品沒有歸屬感(Ownership),元件團隊只為了交付存在,今天做這個功能的人,不表示是之後維護這個功能的人,資源也只會花在投資效益最大的成長型(Growth)或維護型(Maintenance)產品,還是 Product Market Fit 階段的產品相對比較難搶到資源,也不容易有更好的解決方案產生。』

OKR

另外他還談到 OKR,『目標』(Objective)應該由高層定義,然後充分授權後,讓執行單位定義『關鍵結果』(Key Result),如果不能充分授權就是玩假的(Sign。

OKR 關鍵成果(Outcome)應該是衡量商業結果(Business Result),而不是衡量產出(Output)或任務。目標是需要透明化的,如果團隊不知道產品的營收就不會對產品的成敗有感,也不會做出最好的判斷,或者只能透過少數的資訊做出延遲判斷或不正確的判斷。

產品文件

有人問 Mary 對於寫產品文件的看法,Martry 的回答是『如果你的團隊都同處一地(co-locate)對文件的需求可能比較低,因為大部分的事都可以透過口頭討論找出資料。但是如果你的團隊是遠端(remote),這時候文件就相對重要。文件是活的,需要紀錄的是重要的事,能幫助傳承的事情,而不是防禦的效果,不然直接看 code 可以更快(誤。』

大家提問很踴躍,只是有很多是『大哉問』的等級。哈哈!

其實這次演講的內容大多與下面這則影片相同,這次錯過的朋友可以參考下面的影片。有興趣的朋友,這次演講的內容很多是書上提到的,可以參考書上的內容或 Marty 的文章。

有人已經整理囉,可以先參考 Ying @ Taiwan

【文思不藏私】

What I learned in Agile / Scrum?

Vince Huang

Written by

A Product Owner in software company, interests include agile/scrum, machine learning and mobile design. https://www.linkedin.com/in/kuoyuhuang/

【文思不藏私】

What I learned in Agile / Scrum?

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade