讀《跳脫建構陷阱|產品管理如何有效創造價值 (Escaping the Build Trap: How Effective Product Management Creates Real Value)》(上)

MH
11 min readFeb 28, 2023

前陣子想找些 PM 的書來看,看了好幾篇推薦書單,這本 <Escaping the Build Trap: How Effective Product Management Creates Real Value> 一再出現。老實說,當初是想看看近兩三年的新書,想說或許會有些新的主題、方法論或觀念可以幫自己「更新」一下,而這本書是 2018 年出版,雖然也不到很古老,但光是看標題本身,當下實在是沒太大興趣。

但再看了 Amazon 的讀者心得,有幾句推薦詞打動我了,比如:書中有很貼近實務的舉例不只是 to C 和 to B,也有說明內部產品如何應用此書生活化的詞語,讓這本書的內容活潑有趣……總之,最後就決定去找這本書來看。

這本書比想像中輕薄很多,200 多頁而已,且架構清楚、用詞簡單、句式也不複雜,讀起英文並不困難。不過,這本書也是有被翻譯成中文版,有興趣的人可以搜尋〈跳脫建構陷阱|產品管理如何有效創造價值〉。

我花了兩個週末把它讀完,過程中也有做筆記,寫下一些讀起來很有感覺的段落,下面會一一分享。但在開始前,先簡介一下這是一本什麼主題的書、我認為適合與不適合怎樣的人來看。

關於本書

這本書的作者 Melissa Perri 是產品經理出身,在多家公司任職過(所以他可舉出很多實務例子,不會顯得打高空),隨著資歷累積,他後來擔任一些公司的顧問,從旁指導公司的產品管理流程與策略。他自己也開創了一所 PM 線上學校 Product Institute 和 Podcast <Product Thinking>。

我後來也找了幾集 podcast 來聽,覺得他的 <Dear Melissa (Answering question)> 系列還不錯,會從讀者來信的實際問題著手,有幾段聽起來都蠻有共鳴。

回到這本書,這本書以一個大主題「好的產品管理,可以為公司創造價值」(反之則會掉進 build trap)為核心,再分別透過 4 個大章節輔助說明要怎樣做到「好的產品管理」,並以實例佐證「有了好的產品管理,就可以幫公司帶來價值」這個核心假設。這 4 個章節分別是:

  1. role:作為 PM,應該要做哪些事、怎麼定義好 PM 與不好的 PM?如何定位自己、建立怎樣的思維?
  2. strategy:什麼是策略?如何幫產品建立策略?有了策略後,應該怎樣落實?
  3. process:什麼是產品流程?產品管理的流程包含哪些元素?
  4. organization:一個以產品為重、產品導向的組織應該是什麼樣子?為什麼要以產品為重?

根據上述,應該也能看出這本書的書寫邏輯是先從每個 PM 自身出發,先把自己的信念 / 定位 / 核心價值建立好,再應用到組織上,進而去建立策略,並將策略落實到各種流程中。但當然憑一己之力還不夠,這些想法與做法都需要組織本身的支持,所以公司有沒有產品思維、對產品多重視,也是極其重要的元素。

誰適合 / 不適合閱讀這本書

這本書比較適合:

  1. 好奇「產品管理」是怎麼一回事的人
  2. 想從零建立產品管理觀念的人
  3. 想確認自己的日常 PM 工作是否有走偏的人
  4. 想驗證自己所處組織是否有產品觀念的人

這本書可能不太適合:

  1. 想解答特定產品 / 流程問題的人
  2. 想得到什麼新觀念或新方法論的人

簡而言之,這本書比較像是一個「產品導論」,用很簡單的語言與例子說明好的 PM 與產品管理流程是怎麼一回事。如果是自認對這些「基本觀念」已有掌握的人,閱讀這本書大概不會有太多新鮮感,可能也不會有什麼心得。

老實說,在大多數的時間,我的心得差不多就是這樣。不過看到某些段落時,還是會很有共鳴,所以整體看完,比較多是「複習」與「提醒」,而非「啟發」。至少以我個人來說,這本書能讓我好好提醒自己:工作上很多事情不是「做過就好」,而是要認真地去規劃、執行、盤點,工作不是為了做而做,而是為了產生價值而做,否則就會落到作者說的 “build trap”(後面詳提)。

但也因為要達到「言簡意賅」,所以每個部分都沒辦法說得太深刻 — — 比如書中有提到制定產品策略和數據指標,這兩個東西都可以再延伸很多細節,但礙於篇幅與本書主題,作者就沒有介紹到太詳細,所以如果想深入研究某些細節的人、有特定問題想要被解答的人,閱讀此書可能不會有太大收穫。

chapter 1:什麼是 “build trap”?

這本書的標題與內文會一再提到這個字,但到底什麼是 build trap(建構陷阱)?根據書中所述:

The build trap is when organizations become stuck measuring their success by outputs rather than outcomes.

書中也有介紹 outputs vs. outcomes 的區別:

- Outputs are easily quantified things that we produce — number of products or features, number of releases, or velocity of development teams.

- Outcomes are the things that result when we finally deliver those features and the customer problems are solved.

我的解讀是,當組織(公司也好、產品團隊也好)用「產出本身(量)」而非「產出帶來的價值(質)」衡量自身成敗時,那這個組織便掉進了建構陷阱。

比如說,如果老闆每天關心的是「這個功能什麼時候可以交付」、「今年 KPI 是要把 X 個產品推上線」,那他在意的就只是「完成了沒」,而非「這個功能 / 產品做得好不好、帶來什麼價值」。如此一來,產品團隊變得很像是「生產工廠」,老闆一個指令、下面的人一個動作,沒人在意為何而做、沒人在意做了之後會帶來什麼效益,大家就真的只是一起來消除待辦清單上的各種項目而已。

但為什麼公司會變這樣呢?作者在 <why build trap happens?> 小節提到兩個主要原因:

  1. Company wants to fast-follow its competitors on every feature it released
  2. Company overpromises during the sales process, giving customers whatever it takes to get the contract signed. There is no strategic choice to build what would scale for many clients

這應該蠻多人看到都會很有感……當公司沒有核心價值或信念時(或者處在競爭很強烈的市場中),看到競爭對手做了什麼,就會因為自己沒有而感到焦慮,然後決定趕快「跟上腳步(照抄功能)」。

有的公司懂得包裝、懂得怎麼把這些抄到的功能扣回自己的產品核心價值,最後能將這些新功能發揚光大、不落入「為了做而做」的惡性循環;但有的公司不懂這些、也不在乎這些,那就會淪為跟進者,永遠只能跟著市場老大走,沒辦法開創新的路線、建立自己的定位與價值。

另外就是在業務驅動或利益關係人驅動的組織裡,組織或產品團隊本身話語權不足,沒辦法決定產品走向,只能看客戶要什麼,就跟著做什麼。

作者有列出各種驅動類型的組織,比如:

  1. Product-led(後面會再詳述)
    - companies that optimize their products to achieve value
  2. Sales-led
    - contracts define their product strategy
    - it’s ok to start off as sales-led when it’s necessary to get revenue to survive
    - sales-led leaves no room for product teams to strategize or explore what could push the company further
  3. Visionary-led
    - example: Apple
    - visionary-led is not sustainable as innovation needs to be baked into the system so that one person is not the weakest link.
  4. Technology-led
    - has the latest and coolest technology, but suffers from a lack of a marketing-facing, value-led strategy

其實這也是我在做某幾個內部產品時,能夠很確切體會到的感受。即使內部產品也可以做到「重視使用者體驗」、「幫使用者帶來效益」,但內部產品有很多類型的使用者,只是礙於「老闆」是裡面話語權最大的使用者,所以他的意見更有重量,拿 1000 個基層員工的使用體驗和 1 個高階主管或老闆的使用體驗來比,很多時候可能是得先處理老闆的需求 — — 即使這個需求就真的只有老闆一人需要。

chapter 2:產品經理的定位與類型

講完了 build trap 的定義與成因,再來就是先從「個人」出發:作為一名 PM,該怎麼做或者不該怎麼做,才能讓團隊走在更合理的產品開發路上呢?作者是這樣定義 “bad product manager archetypes” 的:

  1. the mini-CEO
    CEOs have sole authority over many things while product managers cannot especially don’t have authority over people. They need to influence people to actually move in a certain direction. product manager’s job is to produce value not developing own ideas.
  2. the waiter (order taker)
    Product managers go to stakeholders, customers, or managers, ask for “what do you want”, and turn those wants/specific solutions into a list of items to be developed. there is no goal. there is no vision. there is no decision-making involved.
  3. the Project Manager
    The project manager project managers are responsible for the “when” while product managers are responsible for the “why”

個人覺得第一點 “mini-CEO” 蠻有趣的。許多人都說 PM 就是個小型的 CEO,但作者的立場是:PM 怎麼可能可以是小型 CEO?一來 CEO 對於很多人事物都有實質管理權(而 PM 並沒有,這也是很多人說的:PM 必須要在沒有管理職權的情況下,試圖「影響」他人決策),二來 CEO 在更高的角度,需要幫組織或產品有更清晰的想法,而 PM 的角色則是落實這些想法,並產出對應的價值。

如果把這兩者混為一談,的確是有點怪異,畢竟兩者的管理範圍與階層差很多,實際上能發揮的空間也很不一樣。不過,認為「PM 就是個小型的 CEO」的人也可能說,”mini-CEO” 是組織對於 PM 的「期許」而非「要求」,如果只是希望 PM 能拉高格局思考,那或許就會讓這個說法比較合理吧。

講完不好的 PM 典型,再來作者也有說明 “a great product manager” 應該是在動手建造功能前,能夠思考並回答這些問題:

  1. Why do we do this?
  2. What’s the desired result that we hope to achieve?
  3. What does success look like?
  4. What happens if we make it but nobody uses it?
  5. How are we mitigating this risk?

簡而言之,就是透過不斷地自我詰問,讓產品的樣貌越來越清楚、越來越立體,而不是以一句「因為公司想要做」或「因為老闆說要做」而再次掉入 build trap。

我之前也寫過幾篇 PM 定位的文章,有興趣可以參考:

1. 什麼個性的人適合當 PM?PM 需要具備哪些人格特質?

2. 身為一個 PM,你基本上要具備的技能有… from 行銷人視角

3. 我們到底要 PM 幹嘛?PM 到底可以為公司帶來什麼?from 行銷人視角

4. 為什麼什麼事情都要問「為什麼」?職場裡的「以終為始」

中場休息

怕這篇文章太長而導致不易瀏覽,或者讓人感到不耐、難以吸收……所以這邊先暫停一下,剩下 3 個章節留到下篇〈讀《跳脫建構陷阱|產品管理如何有效創造價值 (Escaping the Build Trap: How Effective Product Management Creates Real Value)》(下)〉。

--

--

MH

做過公關、數位行銷,2020 年轉職成為產品經理,2021 年跑到新加坡繼續當 PM。歡迎在文章留言或私信交流:mhmedium90@gmail.com (轉載文章請附原標題&原文網址即可,不用特別來信洽詢囉!謝謝)