產品經理不是專案經理

Marty Cagan 在這本書裡反覆強調的一件事，大概就是這個：Product Manager 跟 Project Manager，是兩個完全不同的角色。

聽起來很基本，對吧？但在台灣的軟體團隊裡，這兩個角色混在一起的狀況，多到數不清。產品經理變成了「開票機器」——老闆說什麼就做什麼，工程師要什麼規格就寫什麼規格。

但產品經理的核心責任，是確保團隊做的東西值得做。

不是確保東西做完，是確保做的東西有價值。

這個區分很重要。因為它改變了整個團隊的工作方式。當 PM 只是在管進度的時候，沒人在問「為什麼要做這個」。大家都在忙，卻沒人知道忙完之後會怎樣。

Discovery 跟 Delivery 是兩件事

Cagan 說，產品開發有兩個階段：Discovery（發現）和 Delivery（交付）。大部分團隊把幾乎所有資源都放在 Delivery——寫 code、測試、上線。但真正決定產品成敗的，是 Discovery。

我們最大的風險，不是做不出來，而是做出來沒人要。

之前讀《Lean Startup》的時候，也碰過類似的邏輯。Eric Ries 說的 Build-Measure-Learn，本質上就是在講 Discovery 的重要性。只是 Cagan 把這件事講得更具體——他說，Discovery 不是開會討論，而是用 prototype 去測試四種風險：價值風險、易用性風險、技術可行性風險、商業可行性風險。

很多產品死掉，不是因為技術不行，而是一開始就沒人要。

Empowered Team vs. Feature Team

Cagan 另一個讓我印象深刻的區分，是 Empowered Team 跟 Feature Team。

Feature Team 是什麼？就是老闆或 stakeholder 開出一張功能清單，團隊負責把它做出來。團隊沒有決策權，只有執行權。

Empowered Team 不一樣。他們被賦予的是「問題」，而不是「解法」。團隊自己去研究、測試、決定怎麼解決這個問題。

讀到這段的時候，腦子裡閃過的是我們團隊在兩年前做的一個決定。那時候，我們硬是把老闆開的功能清單打回去，說「讓我們先花兩週搞清楚用戶到底在痛什麼」。當時壓力很大，但事後來看，那兩週省下了後面三個月的時間。

被賦予問題的團隊，跟被賦予答案的團隊，心態完全不同。

一個在思考，一個在執行。而思考的那個，往往更有動力，也更有創意。

產品願景是北極星

有趣的是，Cagan 雖然強調團隊自主，但他同時也非常重視願景。

他說，好的產品願景應該要能回答：三到五年後，我們想為用戶創造什麼樣的世界？

這跟 OKR 的邏輯很像。願景是方向，策略是路徑，功能只是路上的石頭。如果沒有願景，團隊很容易陷入「每個 sprint 都很忙，但一年過去不知道自己在幹嘛」的狀態。

產品願景讓團隊知道為什麼而戰。

我一直覺得「願景」這種東西是虛的，是貼在牆上給投資人看的。但看完這本書才發現，願景其實是給團隊用的。它讓每個人在做決策的時候，有一個可以參照的標準。

產品經理要保護團隊的時間

最後一個我想分享的點，是關於 PM 的角色定位。

Cagan 說，好的 PM 會成為團隊的盾牌。擋掉不必要的會議、擋掉沒價值的需求、擋掉那些「反正先做做看」的功能。

PM 的工作不是說 Yes，而是知道什麼時候該說 No。

這件事說起來容易，做起來很難。因為說 No 會得罪人。老闆會不開心，stakeholder 會抱怨。但如果 PM 什麼都答應，團隊就會被壓垮，產品就會變得什麼都有、什麼都不精。

某種程度上，這跟《Essentialism》說的是同一枚硬幣的兩面——少即是多，但少需要勇氣。

這本書讀完之後，我開始重新思考自己在團隊裡的角色。

不是問「我今天做完了什麼」，而是問「我今天擋掉了什麼」。

📚 書籍資訊

書名：矽谷最夯的產品專案管理全書
作者：Marty Cagan
核心主題：如何打造真正被賦權的產品團隊，做出用戶想要的產品

#263《矽谷最夯的產品專案管理全書》

🎯 核心重點 (TL;DR)