《逃出 Build Trap》：功能越做越多，公司為什麼反而學得越少？

Marquetly 最可怕的地方，不是團隊做不出東西，而是它終於做出了所有人要求的東西，然後公司變得更糟。

先說清楚來源性質：Marquetly 是 Perri 為了串起全書而設計的 fictional/composite case。公司和人物不是單一真實個案；它的價值在於把她在多家公司、顧問案和產品職涯裡反覆見過的模式，濃縮成一個可追蹤的組織病例。

這家公司做線上行銷教育，訂閱制，收入曾經以每年約 30% 的速度成長。成長太快，公司短時間招了幾百人，導入 Scrum，把許多懂行銷但不懂產品的人轉成 product manager。CEO Chris 很焦慮，董事會也開始施壓；銷售團隊已經對企業客戶承諾了一串功能；CTO 認為需要更厚的 backlog；新來三個月的 VP Product Karen 手上有 20 個 direct reports，還要照顧一批剛轉職的 junior PM。

從外面看，這家公司什麼都有：市場、資金、敏捷流程、產品職稱、backlog、release 節奏。問題是，所有人對「最重要的事」都說不出同一個答案。CEO 說要回到 30% 的收入成長，CTO 說董事會關心 mobile strategy，Karen 說要吸引更多老師到 teacher platform，Sales 說要搞定 enterprise clients。每個答案都像是真的，但它們沒有被同一條價值邏輯串起來。

接下來的劇情很熟悉。公司同時開了 20 個大型專案，其中包括 mobile app、教師後台等本該由多個團隊承接的工作，卻往往只配一個 junior PM 和一支開發團隊。PM 們知道自己應該做 user research，但 deadline 和 bonus 綁著交付，他們很快又回到舊習慣：寫 user stories、催進度、把 sales promise 變成 backlog。

然後他們成功了。一個月內推出約 10 個新功能。管理層一開始很高興，覺得公司終於會 ship 了。

結果網站出問題，老師不知道新功能怎麼改變他們的工作，有人乾脆把課程下架；學生端幾乎沒有 adoption；收入成長沒有回來。這就是本書所謂的 build trap：公司把 output 誤認成 progress，把 release 誤認成 learning，把「有人要求」誤認成「問題存在」。

所以這本書表面上在講產品管理，實際上在講一家公司如何建立「反自欺」能力。Melissa Perri 的核心命題不是「多做 discovery」這麼簡單。她一開始也以為只要訓練 PM，Marquetly 就會好起來；後來才發現，只要獎酬、策略、預算、sales agreement、roadmap、管理節奏仍然獎勵交付，PM 再懂產品，也會被系統拉回接單員。

你可以把這本書讀成一個公式：

產品能力 = 角色能力 × 策略清晰度 × 學習流程 × 組織制度。

任何一項是零，結果都會接近零。

這篇專欄會用 Marquetly 作為主線病例，帶你看完整本書的脈絡：一家公司如何從「功能交付機器」轉成「價值學習系統」。中間會穿插書中的承重案例：資料平台做了 30 個功能卻只有極少數被穩定使用，Meghan 如何用一個人工實驗改善房貸申請，Netflix 為什麼能殺掉幾乎完成的硬體，Kodak 為什麼即使做了正確的用戶研究仍然錯失手機攝影。讀完你應該不只是知道 product-led 是什麼，而是能拿最近一個功能，診斷它到底是在創造價值，還是在製造被完成的幻覺。

一、功能不是產品的基本單位，價值交換才是

很多公司對產品有一個錯誤但很自然的想像：產品就是一組功能，產品管理就是決定下一批功能做什麼，然後讓工程準時交付。

這個想像之所以危險，是因為它把最容易看見的東西當成了真正重要的東西。功能可以被數出來，roadmap 可以被畫出來，deadline 可以被追蹤，demo 可以讓大家鼓掌。但客戶不為功能付錢，客戶為自己的問題被解決付錢。企業也不該為功能存在而高興，企業應該為功能改變了某個 business outcome 而高興。

本書的第一個基本模型叫 value exchange。客戶把錢、時間、注意力、資料、信任交給你，是因為你替他解決了一個問題；公司得到收入、留存、成長、資料或市場位置，是因為它用產品創造了客戶價值。價值不是公司單方面宣布的，也不是 roadmap 上的格子。價值存在於交換裡。

這就是為什麼 product 和 project 不一樣。Project 的成功是 scope、time、budget：有沒有照計畫完成。Product 的成功是 outcome：使用者行為、客戶成果、商業結果有沒有被改變。Service 則更進一步，包含產品之外的整體體驗、支援、流程與人。很多公司把產品當 project 管理，最後得到的不是產品能力，而是一堆準時完成但沒人需要的東西。

書裡有一個很尖銳的小例子。某企業資料平台已經做了 30 個功能，backlog 裡還有 40 個，團隊卻發現只有很少一部分功能被持續使用。正常的產品問題應該是：為什麼這些功能沒有用？我們是否理解了使用者的工作？是不是該停掉一些東西？但 build trap 裡的直覺是：還有 40 個功能沒做完，繼續排。

這不是工程團隊懶，也不是 PM 不努力，而是組織的成功定義錯了。只要公司把「交付更多」當成進步，它就會自然地生產更多。至於客戶是否真的得到價值，那是另一個會議再說的事。

Perri 把常見的錯誤產品導向分成幾種：

這張表的重點不是貼標籤，而是問一個更殘酷的問題：在你的公司，最後到底是誰的邏輯有決策權？

如果銷售說「這個客戶簽約要這個功能」，產品就做；如果 CEO 說「我覺得市場會要這個」，產品就做；如果工程說「我們終於可以用這個技術」，產品就做，那公司就不是 product-led。它只是在用產品部門執行別人的局部邏輯。

真正 product-led 的組織不是不聽 sales、leader 或 engineer。相反，它會把這些訊號放進同一個價值判斷框架：這個需求對應哪個客戶問題？這個客戶問題是否足夠普遍或重要？它和我們的 strategic intent 有什麼關係？我們怎麼知道它真的會改變 outcome？如果它只是服務某一筆合約，我們是否願意承認那是一個 custom service，而不是產品策略？

這裡要補一個常被誤會的點：product-led 不是「產品部最大」。它不是 PM 取代 sales，也不是 discovery 取代 strategy。它的意思是，公司以產品創造客戶價值作為實現商業結果的主要方式，因此產品判斷必須被放在組織決策的中心。

Marquetly 的災難就在這裡。它不是沒有功能，而是沒有把功能放回價值交換裡。老師到底卡在哪裡？學生為什麼流失？企業客戶真正要的是哪種能力？個人用戶的收入成長要靠 acquisition、retention，還是 new revenue streams？在這些問題被釐清前，功能越多，只會越遮蔽問題。

如果一家公司把 release 當成勝利，它就會在真正的比賽開始前宣布成功。

二、PM 不是小 CEO，而是未知管理者

理解 value exchange 之後，下一個問題是：組織裡誰負責守住這個判斷？

很多招聘文案喜歡說 product manager 是 mini-CEO。Perri 很反對這個說法。CEO 有人事權、預算權、組織調整權，PM 大多沒有。把 PM 說成小 CEO，聽起來很威風，實際上會製造兩種壞結果：一種 PM 真的以為自己應該命令團隊，變成小獨裁者；另一種 PM 發現自己根本沒有 CEO 的權限，只好退回寫需求和追進度。

書裡描述了三種壞 PM 原型：

第一種是 mini-CEO。這種 PM 把產品當自己的王國，把團隊當資源，覺得好點子應該由自己發出。問題是，產品的未知太多，一個人越自信，組織越少學習。

第二種是 waiter。這種 PM 像服務生，問 stakeholder 想點什麼菜，然後把需求送進廚房。這正是 Marquetly 大部分 product owner 的狀態：沒有 goal，沒有 vision，沒有真正的決策，只是在把別人的 wants 轉成 user stories。

第三種是 former project manager。這種 PM 最大的能力是控時程、控範圍、控資源。這些能力不是壞事，但如果它取代了產品判斷，PM 就會把 unknowns 當成可以靠計畫消滅的東西。

好 PM 的核心不是「提出最多點子」，而是管理未知。Perri 用四象限來講不確定性：known knowns、known unknowns、unknown knowns、unknown unknowns。產品工作的困難，恰恰在於你常常不知道自己不知道什麼。PM 的價值，是把模糊的不確定拆成可學習的問題，把風險從「一整個產品可能錯」降成「下一步要驗證哪個假設」。

所以好 PM owns the why，團隊共同決定 what。PM 不應該單方面指定解法，而是負責把 business goal、customer problem、data、market context、constraints 帶到團隊面前，讓設計、工程、stakeholder 一起找可行解。這也是為什麼 product owner 不是 product manager。Product owner 是 Scrum 裡的角色，負責 backlog 等事項；product manager 是職涯與能力系統，負責把產品放回商業與客戶價值裡。

這裡也能看出很多 Agile 轉型的盲點。Scrum 可以改善交付節奏，但它不會自動回答「什麼值得交付」。如果組織把 product owner 壓成 backlog owner，把 product manager 放在另一條線，甚至在大型框架裡把策略、需求、設計、交付拆到互不相干的角色，結果可能只是用 Agile 名詞重建 waterfall：大家跑得更快，卻仍然不知道為什麼跑。

書中 Meghan 的房貸案例，是好 PM 的小型標本。她在一家大型零售銀行做 consumer mortgage software，負責改善第一次申請房貸者的體驗。她不是先問「我們要不要把房貸申請數位化」，而是先對齊 business goal：提高第一次申請者完成申請的比例。當時 60% 的第一次申請者沒有在這家銀行完成流程，而是轉去競爭對手。

她接著去找原因。資料與訪談顯示，很多申請者卡在文件驗證：必須到分行找時間驗文件，太慢、太麻煩。更廣泛的 survey 顯示，有這個問題的人裡，只有 25% 完成申請。這時她才和團隊討論解法，並先做人工實驗：讓部分申請者用 email 交文件，由銀行人員人工審核。結果，這些新申請者完成申請的比例比原本高出 90%。第一版產品化時，他們還沒有做到全自動驗證，但已經把需要親自到分行驗證的 visits 減少 50%。

這個案例的 inspiration 不在「銀行做了上傳文件功能」。它真正證明的是：好 PM 會把一個 vague idea 變成清楚的因果鏈。

目標：提高申請完成率。
現況：60% 流失。
問題：文件驗證造成等待與摩擦。
證據：有此問題者只有 25% 完成。
實驗：人工 email + 人工審核。
結果：完成率顯著改善。
產品化：先減少 50% in-person visits，再往 AI、公證等方向迭代。

如果 Meghan 被交辦的只是「做一個線上房貸申請系統」，她可能會做出很大的系統，但不知道它有沒有改善完成率。好 PM 不是把 solution 做完，而是把 problem 和 outcome 鎖住。

但個人能力仍然不夠。Marquetly 的 Karen 很努力，也很有產品 sense，但她只有一個人，帶 20 個新手 PM，還要面對 board pressure、sales promise 和 declining revenue。這就是書中 career ladder 與組織設計的意義：associate PM、PM、senior PM、director、VP、CPO 不是頭銜膨脹，而是不同層級的產品判斷。

越基層，越接近 tactical：理解問題、做研究、和團隊交付 outcome。越高階，越 strategic / operational：設計 product vision、portfolio、team structure、metrics、budget、cadence，讓多個團隊可以在同一方向上行動。CPO 的責任尤其不是「管所有 PM」，而是管理產品組合的經濟成果，能把產品決策翻譯成董事會與 CEO 能理解的財務和策略語言。

這也解釋了為什麼團隊不應該只圍繞 component 或 feature 組織。Marquetly 有 20 個 product teams，卻按元件與功能切開，結果四個 PM 都碰到 teacher platform，卻沒有人對整體 teacher experience 負責。大家都在局部優化，沒有人對 value stream 的 outcome 負責。

TransferWise 是反例。它用少量 product teams 圍繞 retention、new currencies、acquisition 等 strategic goals 組織，團隊可以跨產品做任何有助於 goal 的事。Pandora 也是一個證據：它曾用 40 位工程師支撐 7000 萬月活使用者，靠的不是每個地方都多派人，而是極端優先排序。

團隊結構會塑造行為。你把團隊按 component 切，大家就會保護 component；你把團隊按 feature 切，大家就會交付 feature；你把團隊按 value stream 或 goal 切，才有可能讓大家對 outcome 負責。

但再好的 PM、再好的 team structure，也不能在真空裡工作。如果公司只給功能承諾，不給方向，PM 最後還是會變回接單員。

三、策略不是計畫，是可部署的決策框架

很多公司以為 strategy 就是「未來一年要做什麼」。所以 strategy meeting 的結果通常是一份 roadmap、一堆 projects、一排 dates。這不是 strategy，這是願望加上工程排程。

Perri 借用 Stephen Bungay 的戰略思想，把策略理解成一種可部署的決策框架：它不是替每個團隊做所有決定，而是讓不同層級的人在不確定情境下，能做出一致的取捨。策略的價值，不在於它說得多完整，而在於它能不能縮小三個 gap。

第一個是 knowledge gap。高層永遠不知道一線知道的所有細節，一線也永遠不知道高層掌握的所有外部約束。你不能靠「把所有資訊往上報」解決，因為資訊永遠不完整。

第二個是 alignment gap。即使大家都知道目標，也可能對優先順序、原因、限制理解不同。Marquetly 的 CEO、CTO、Sales、VP Product 各說各話，就是 alignment gap。

第三個是 effects gap。你做了某件事，世界不一定照你的計畫反應。市場、客戶、競爭、技術都會讓結果偏離預期。

錯誤的管理本能，是用更多控制處理這三個 gap：更多報告、更多 approvals、更細的 roadmap、更長的 planning。結果一線更少自主權，高層更焦慮，組織更慢。

好的策略則相反。它承認 gap 不可能消失，所以提供足夠清楚的 intent 和 constraints，讓團隊在局部資訊裡做正確判斷。

這裡有一個常被漏掉的分別：operational framework 是讓公司日常運轉，strategic framework 是讓公司透過產品和服務在市場裡實現 vision。很多年度計畫把兩者混在一起，結果 strategy 變成營運清單。Perri 要的不是更漂亮的年度 planning，而是持續部署策略：資訊要向下流，讓團隊理解方向；也要向上、橫向流，讓高層和其他團隊知道一線學到了什麼。

策略部署其實是在不同層級講不同時間尺度的故事。高層可以講三到五年的市場故事，中層要把它翻成年度或季度的取捨，產品團隊則需要能在兩到四週內行動的故事。方向太細，團隊沒有 autonomy；方向太空，團隊不敢動。真正的自主不是「你們隨便探索」，而是被適當約束後，知道自己在哪個邊界內做判斷。

Netflix 的 Project Griffin 是書中的策略案例。Netflix 早期想要 lead streaming market，當時用戶在 laptop 上看串流並不理想，它於是投入多年做自己的 internet-connected device，也就是 Project Griffin。幾乎要 launch 前，Reed Hastings 決定停止，後來把它 spin off 成 Roku，轉而和 Microsoft 合作，六個月後 Netflix app 出現在超過 100 萬台 Xbox 裝置上。

這個案例常被講成「勇於殺掉 sunk cost」。但在本書脈絡裡，它更像是策略層級正確的例子：真正的 product initiative 不是「做一台硬體」，而是「讓用戶能在任何舒服的裝置上看 Netflix」。硬體只是 option。當 partner strategy 能更快達成 outcome，停止硬體不是失敗，而是回到策略。

這正是 Marquetly 原本缺少的東西。它以為 mobile app、enterprise feature、teacher backend 都是「重要專案」，但沒有人能說出這些專案如何連到同一個 business outcome。後來 Jen 進來擔任 CPO，第一週就發現 PM 連「為什麼做這件事」都答不出來，OKR 也多是 output 型，例如某日期前交付某平台。

Jen 的第一件大事，是把 strategy 從 feature list 改成層級清楚的 decision framework：

這個層級很重要。高層不應該把 option 當 strategy，否則團隊只是在執行 solution。團隊也不能把 vision 當 daily guidance，否則太抽象，無法取捨。好的策略部署，是把每一層都翻譯成下一層能行動的語言。

Marquetly 後來收斂成兩個 strategic intents。第一，進入 enterprise business，把企業收入從每年 500 萬美元提高到三年內 6000 萬美元。第二，讓個人用戶收入成長從 15% YoY 提高到 30% YoY。這兩個 intent 把公司從「什麼都重要」拉回「只有少數大事重要」。

書裡有一個很刺眼的反例：一家 5000 人公司有 80 個 strategic intents，最後整家公司一季只能 ship 一個 feature，因為所有人都被攤薄。Perri 的意思不是大公司只能做三件事，而是最高層級的 intent 必須少，否則每個團隊都能替自己的工作找到合理藉口，組織就失去取捨能力。

Product vision 和 portfolio 也在這裡登場。Product vision 定義這個產品如何替使用者創造價值，不應該細到列功能，而應該說清楚主要能力和價值主張。Portfolio 則回答更高階的問題：我們的多個產品如何形成一個價值系統？每條 product line 的獨特價值是什麼？什麼東西應該停止？要留多少 capacity 給 innovation？

Amazon Echo 的例子證明，創新不是「有空再做」。Amazon 不是等團隊忙完日常 roadmap 才探索 voice control，而是在 portfolio 裡配置空間，讓秘密團隊多年探索 Alexa 和 Echo。所謂沒有時間創新，很多時候其實是沒有在 portfolio 裡做出取捨。

策略如果不能落到團隊每天的選擇，它就只是高層比較漂亮的願望。相反，當 vision、strategic intent、initiative、option 層層清楚，團隊就能用自己的專業回答：現在最大的障礙是什麼？下一步最便宜的學習是什麼？

這就是 Product Kata 的位置。

四、Product Kata：把建造改造成學習循環

Product Kata 是本書的操作核心。它不是表格，也不是 rituals，而是一種思考習慣：在每一輪行動前後，問同一組問題。

1. 目標是什麼？
2. 我們現在在哪裡？
3. 最大障礙或問題是什麼？
4. 下一步要怎麼嘗試解決？
5. 我們預期會發生什麼？
6. 實際發生了什麼，我們學到了什麼？

這六個問題看起來簡單，真正困難在於順序。大部分公司會跳過前四題，直接從「下一步要做什麼」開始。Product Kata 強迫你先把 direction、current state、obstacle 說清楚，避免把第一個 solution 當成事實。

Marquetly 的個人用戶收入案例，完整示範了這個循環。

公司 strategic intent 是把個人用戶收入成長從 15% YoY 提高到 30% YoY。團隊一開始有很多想法：要不要 free account？要不要 discount？要不要找更有名的老師？這些都可能對，但沒有一個能在當時被稱為「正確解法」，因為團隊還不知道收入問題的結構。

他們先把收入拆成三條路：acquire more individual users、retain existing individual users better、create new revenue streams for existing users。

接著看 acquisition funnel。網站流量有，但從訪客到付費轉換低。團隊用一個 exit poll 工具問準備離站的人為什麼不註冊，一週內得到超過一百個回覆。結果不是大家想像的「沒有 free trial」：約 55% 說找不到足夠多新型行銷方法的課程，例如 social media；另有 25% 想轉職進入行銷，但看不到這些課程如何證明自己獲得能力。

另一組看 retention。六個月後只剩 40% 的人留下。團隊追問 100 位近期流失者，90% 說自己把有興趣的課上完了，剩下內容不夠新、不夠吸引。

這時候，acquisition 和 retention 指向同一個問題：內容供給不足，尤其是新興行銷主題。於是產品 initiative 出現了：增加關鍵主題的內容，藉此吸引新用戶並留住現有用戶。書中一處估算這個 initiative 可能帶來每月 265.5 萬美元個人用戶收入；後面 Karen 在 business case 裡又用較保守或不同口徑說，增加內容可能帶來每年 800 萬美元收入。重點不是記住哪個數字，而是看見數字如何迫使團隊把「多做內容」變成可評估的投資。

可是「內容不夠」仍然不是可執行問題。要有更多課程，就要有更多老師或更高的老師產出。Christa 的團隊開始看 teacher side，發現 baseline 很糟：只有 25% 開始做課的老師最後發布課程，只有 10% 會發布第二門課，平均要 61 天才發布，超過 75% 開課者最後沒有發布。

現在團隊有了短期 team goal：先把課程發布率提高到 50%，第二門課提高到 30%。注意，這不是終局 business outcome，而是能在較短週期裡觀測的 product outcome。Product Kata 需要這種中間層，否則 team 永遠等不到 revenue 才知道自己有沒有走對。

這裡也帶出本書的 metrics system。Outcome 不是口號，必須被拆成層級：

好指標不是拿來報喜，而是拿來改變決策。Perri 提醒，單一指標常常會互相破壞。只看 acquisition，可能買來不會留下的用戶；只看 retention，可能犧牲新客成長；只看 revenue，可能壓低長期滿意度。這就是她強調 leading / lagging indicators、Pirate metrics、HEART framework、metrics platform 的原因。它們不是潮流名詞，而是避免團隊用 vanity metric 自我催眠。

Metrics platform 尤其重要。沒有穩定的資料平台，團隊就無法在每次 release 後看到 outcome，只能回到「我們至少 ship 了」。Marquetly 後來能在 QBR 討論 acquisition、retention、課程數，是因為它開始把 product outcome 放進管理節奏。

Product Kata 的真正美感，是它把「做產品」改寫成一串可追蹤的學習階梯。Marquetly 教師端不是一次跳到「做影片剪輯功能」，而是連續縮小未知。

第一輪，他們只知道 baseline 很差：發布率 25%，第二門課 10%。所以先訪談 20 位老師，得到一串問題：轉課、匯入內容、audio options、定價、學生需求 feedback。這一輪的學習不是答案，而是問題地圖。

第二輪，他們以為最大痛點是「把內容放進系統」，於是和老師一起處理上傳。結果老師交來的素材暴露了真正瓶頸：未剪輯影片、分離音軌和零散素材。也就是說，系統上傳不是核心障礙，影片製作才是。

第三輪，他們驗證規模。調查顯示，90% 老師把影片剪輯列為最大障礙，耗時可達兩個月。這時問題才從「某幾位老師的抱怨」升級成「值得產品投資的普遍障礙」。

第四輪，他們用 concierge 人工幫忙剪輯，想知道去掉剪輯工作是否真的能讓老師發布課程。14 位裡預期 10 位一月內發布，結果 12 位發布；同時學到，光有剪輯還不夠，老師也需要影片製作 guide。

第五輪，他們測可規模化解法。40 位老師試用 Budapest 軟體，預期 20 位一月內發布，結果 30 位發布。這時他們才有資格把討論帶到 buy / partner / build 層級，因為風險已經從「這是不是問題」一路降到「這個工具能不能規模化整合」。

這條學習階梯就是全書的微縮版。它示範了 product management 和 project management 的差異。Project management 會問：「影片剪輯功能什麼時候做完？」Product management 會問：「我們怎麼知道影片剪輯是障礙？怎麼知道老師願意用？怎麼知道這個解法值得投資？怎麼知道上線後 outcome 真的變了？」

問題探索還有一個常見陷阱：把 solution 寫成 problem。有人說「我們需要 custom dashboard」，真正問題可能是某個角色在決策前看不到異常訊號；有人說「我們需要女性職涯 mentoring app」，研究後可能發現目標族群並不想要 app，而是需要可信任的機會、社群或制度支持；有人說「加一個 chatbot」，問題可能只是客服分類和資訊架構混亂。好的 problem statement 不能長得像功能要求，它要說清楚誰在什麼情境下卡住、造成什麼後果，以及為什麼值得現在解。

從這裡你也能看出，Product Kata 不是叫你凡事都 A/B test。相反，Perri 一直提醒 context matters。當問題已知、解法也明顯，就直接做，做完後量測；當問題未知，先做 problem exploration；當問題已知但解法未知，再做 solution exploration；當解法已經初步可行，才進入 build and optimize。

好的產品組織不是永遠在實驗，而是知道自己在哪個不確定階段。

五、實驗不是 MVP 崇拜，而是用最便宜的方法買知識

Product Kata 找到問題之後，下一個危險是：團隊太快愛上第一個解法。

Perri 對 MVP 這個詞很警惕。很多公司嘴上說 MVP，實際上只是「第一版少做一點」。這仍然是 build trap，因為它的目標還是 ship，只是 ship 得比較寒酸。真正的 experiment 是 build to learn，不是 build to earn；它的重點不是把產品縮小，而是用最少成本回答最危險的問題。

Marquetly 的教師端案例很清楚。Christa 一開始以為問題是「把內容放進系統很難」。如果團隊直接做上傳功能，可能會花幾個月改善錯的地方。後來他們和老師一起處理內容，才發現老師丟來的是未剪輯影片、分離音檔、各種素材，真正瓶頸是做出可上課的影片。老師是行銷專家，不是影片剪輯師；有人花兩個月、80 小時以上卡在這裡。

第一個解法不是寫程式，而是 concierge experiment：人工幫老師剪影片。這個方法完全不可規模化，但正因為不可規模化，它便宜、快、能貼近用戶。團隊用兩位剪輯師支援約 14 位老師，預期一個月內 10 位發布，結果 12 位發布。這證明「去掉影片剪輯負擔」確實能促成發布，也讓團隊學到老師還需要 guide，知道怎麼做出好影片。

接著才是可規模化測試。Karen 找到 Budapest 一家公司，有簡單易用的影片剪輯軟體，能加背景音樂、剪接影片、同步外部音軌、加文字 overlay。風險變成：老師能不能自己使用？團隊讓 40 位老師試用，30 分鐘 onboarding，加一份 guide，預期 20 位一個月內發布，結果 30 位發布。

這組數字改變了 investment decision。Karen 面對高層時不是說「我們想做影片剪輯功能」，而是說：我們已經知道內容不足影響 acquisition 和 retention；知道教師發布率只有 25%、第二門課只有 10%；知道影片剪輯是主要障礙；知道兩個小實驗把發布率推到 75%；知道自己 build 要一年以上，買或收購 Budapest 幾個月內能出第一版。最後 Marquetly 先談 bulk license，兩個月後提出收購，一個月後完成交易。

這就是實驗最強的地方：它不只是幫 PM 找解法，它改變了資本配置。產品發現不是研究部門的前戲，而是投資決策的風控。

書裡還有幾個實驗類型值得記住：

GiveVision 的案例尤其值得拿來反駁「我們這行不能實驗」。這家公司想做幫視障者辨識世界的眼鏡，但真正硬體開發週期長、不可快速迭代。團隊先觀察視障者日常，發現他們需要辨識公車號碼、營養資訊、貨幣、顏色等。接著用 Android phone 跑軟體，用 3D printer 做一個把手機固定在頭上的假眼鏡，讓使用者戴著測。外觀很粗糙，但它回答了最重要的問題：使用者到底需要哪些資訊？軟體用什麼方式回報才有用？

這個案例的 inspiration 是：實驗不等於網頁 A/B test。實驗是把未知變成可觀測。只要你能找到更便宜、更早、更低風險的方式觀察真實行為，你就在做產品實驗。

不過，本書也沒有把實驗神化。Perri 明確說，有些事不需要 robust experimentation。比如你已經知道某個 help desk call 是因為按鈕沒出現，解法也明確，那就修掉，再量測 call 是否下降。產品方法不是形式主義。把每件小事都拖進實驗流程，也是一種新型浪費。

真正的判斷是：這裡最大的未知是 problem、solution、scale、technical feasibility，還是根本沒未知？方法要跟未知類型匹配。

還有一個常被忽略的細節：experiment 要 close the loop。你要告訴參與者你在測什麼、何時結束、下一步會怎麼處理。尤其 Wizard of Oz 看起來像真產品，若長期放著，風險很高。好的實驗不是偷偷欺騙客戶，而是在合理期待下，用有限暴露換取學習。

學到解法後，才進入 build and optimize。Marquetly 收購 Budapest 後，Christa 的團隊開始整合影片剪輯能力。這時就不是隨便把工具塞進平台，而是建立 North Star、畫 customer journey、做 story mapping、用 Cost of Delay 和 value/effort 切第一版。他們定下第一版 success criteria：

• 一個月內，被目前正在創課或開始創課的老師中 75% 採用。
• 課程發布率從 25% 提高到至少 60%。
• 建立新課的時間從三個月降到一個月內。

請注意，這才是真正的 Definition of Done。Done 不是 code merged，不是 released，不是 marketing announced。Done 是 outcome 到位。Perri 引 Jeff Gothelf 的一句短話很狠：「Version 2 is the biggest lie in software development.」很多團隊說第一版先上，第二版再改；結果第一版上完就被拉去下一個功能，永遠沒有第二版，也永遠不知道第一版有沒有成功。

Marquetly 的第一版上線後，採用率只有 60%，沒有達到 75%；但採用者的發布率達到 75%。這是一個非常好的 product moment。壞團隊會說「功能上線成功，採用者表現很好，慶祝」。好團隊會說「採用率沒到，去找沒採用的人」。Christa 的反應正是後者：繼續診斷障礙。

這個習慣才是 Product Kata 的終點。不是填完一張板，而是 PM 自然會問：下一個問題是什麼？我們還需要學什麼？

六、產品驅動組織：讓 outcome thinking 活得下去

到這裡，很多人會以為本書已經講完了：有好 PM、有策略、有 Product Kata、有實驗，就能逃出 build trap。

Perri 說，還不夠。

因為 Kodak 也做過正確的 discovery。她在 Cornell 參與過 Kodak Research Laboratories 的創新專案，時間是 2007 到 2008 年，iPhone 剛出來，手機攝影與社群分享正在改變市場。她的團隊訪談年輕使用者，研究他們如何在線下互動、線上分享、控制照片可見範圍，最後提出 Kodak 應該把相機技術整合進手機，或者把技術提供給手機製造商，也看到手機端照片編輯、地理標記、分享控制等機會。

今天看，這些洞察全都對。只是後來做出來的不是 Kodak，而是 Instagram、Apple、Android、Facebook。Kodak 不是沒有 research，不是沒有創新小組，不是沒看到問題。它的 innovation lab 和公司策略、預算、執行資源脫節。團隊提案後，Kodak 說還在找 team 和 budget；而年度預算節奏意味著至少還要等幾個月。對快速變化的市場，這就是太晚。

Kodak 案例的殘酷之處在於：做對產品方法，仍可能輸給組織系統。Discovery 如果沒有 strategy 承接，沒有 funding 機制，沒有 portfolio 空間，沒有能把洞察轉成行動的 team，就只是漂亮報告。

因此，本書最後一部分講 product-led organization。它不是 PM 部門改革，而是讓 outcome thinking 能在組織裡活下去的制度。

第一個制度是 cadence and communication。高層焦慮，常常不是因為討厭 autonomy，而是因為看不到 progress。當 progress 只能用 shipped features 表示，大家就會回到 output。Marquetly 後來設計不同層級的 review：

這些會議的目的不是增加流程，而是用 outcome 替代 output 作為可見性。Chris 之所以以前會催功能，是因為他看不到學習和 outcome；當 Karen 能在 QBR 說明影片剪輯軟體帶來 150 門新課、acquisition 從 15% 到 25%、retention 到 60%，而且預計一年半內提前達成 goal，高層就比較能忍住不插手每個 feature。

第二個制度是 Living Roadmap。傳統 roadmap 像 Gantt chart：某日期交付某功能。這種 roadmap 一旦被 sales 拿去承諾客戶，就變成產品團隊的債務。Perri 建議 roadmap 要表達 strategy 和 stage，而不是 feature promise。它通常包括 theme、hypothesis、goals/success metrics、stage、milestones。

Stage contract 可以這樣理解：

這張表能解決 product 和 sales 的老問題。Sales 不是敵人，Sales 需要東西可以賣。但 product 必須和 sales 約定：GA 或成熟 Beta 可以放進 sales roadmap；Experiment 和 early Alpha 不是欠客戶的交付承諾。否則 sales-led 會不斷把未知變成合約，把合約變成 roadmap，把 roadmap 變成 build trap。

第三個制度是 product operations。當 product teams 超過少數幾個，光靠 CPO 和 VP 靠記憶追進度不可能。Marquetly 後來在 CPO 下設 chief of staff 和兩人小組，負責 strategy cadences、analytics tracking、outcome reporting、roadmap/status/capacity/cost reporting、product analytics platform、experimentation tracking、sales enablement、training/coaching。

Product ops 的邊界很重要。它不是 PMO 指揮中心，不替團隊決定 roadmap，不規定團隊怎麼做 discovery；它建立輸入輸出的系統和模板，讓資料、節奏、會議、roadmap、實驗結果能被看見。團隊組成可以混合 project managers、product people，必要時加少量 developers 來串接工具。Perri 曾在有 350 個 Scrum teams 的公司導入 product ops，重點不是把這個部門養大，而是盡量把可自動化的報告、資料收集和流程摩擦自動化掉。好的 product ops 是讓產品人更專注於產品判斷，而不是讓大家多填表。

第四個制度是 rewards and incentives。這可能是全書最現實的一章。Perri 講過一家公司，每年 bonus 綁 corporate scorecard，而 scorecard 上多是 deliverables。到十二月，如果大家還沒交付，就停下真正重要的事，開始做任何能勾選 box 的東西；一月再回頭拆爛 code。每個人都知道荒謬，但每個人的收入都綁在上面。

這就是 build trap 的社會學：不是大家不知道 outcome 重要，而是說真話會被懲罰，交付無用功能會被獎勵。

Sales incentives 也是同理。如果銷售收入高度依賴簽約佣金，就容易 overpromise roadmap、賣給錯誤客戶、帶來高 churn。Perri 建議把 retention 也納入 sales 成功指標，讓銷售不只為簽下合約負責，也為客戶是否適合、是否留下負責。

如果你不是高層，也不是完全無能為力。書中有個 PM 的 bonus 綁在某個產品上，但她用 division strategy 和初步資料向老闆說明那個產品可能不該繼續做。結果不是被懲罰，而是雙方同意用兩個月 sunset，PM 被轉到更重要的產品。這個案例的重點不是「勇敢講話就會成功」，而是 push back 不能只靠情緒，要帶著 strategy、data 和替代方案去改變獎懲邏輯。

第五個制度是 safety and learning。這不是慶祝失敗。Perri 很明確：失敗本身不是成功，沒有學習的失敗只是失敗。Product-led organization 要鼓勵的是小範圍、低成本、可 rollback 的學習，而不是大張旗鼓地把未驗證想法推向市場。

Netflix 的 Qwikster 是一個反例：2011 年 Netflix 想把 DVD business 拆成 Qwikster，市場反應災難，用戶生氣、取消訂閱、媒體批評，最後快速 rollback。這件事真正的教訓不是「Netflix 很勇敢」，而是它本可用更小的方式測水溫。實驗是風險管理，不是創意儀式。

Perri 自己也有一個更小的正例。她曾在 celebrity e-commerce 公司測一個想法：讓名人在首頁像 Twitter 一樣發訊息，以增加銷售。團隊花兩天做小範圍測試，一週後發現沒有增加銷售，於是改成 email 溝通，銷售提高三倍，還省下約 25 萬美元開發成本。這就是向老闆爭取安全感的好方式：不是說「請相信 discovery」，而是說「我們用小成本省掉大錯誤」。

第六個制度是 budgeting。年度預算很容易把公司鎖進 build trap。書中一位金融服務公司 CTO 說，他們每年請 VP 提 business case，排成年度 roadmap，年底沒交付會影響下一年預算。結果是：即使團隊找到更便宜的方法，或發現產品不該做，也得把錢花完，否則明年被懲罰。

Product-led budgeting 更像 VC 分段投資：先給小錢買 discovery，證據變強再給更多錢做 first version，再根據 adoption/outcome 決定 scale。書中的示意是：一條新產品線可以先拿 5 萬美元探索市場和問題；證明機會存在後，再拿 25 萬美元做更深入探索或早期開發；等小規模版本真的被採用，才回來申請百萬級資金去 scale。

這裡的管理節點不是年度預算會，而是 portfolio distribution 和 product initiative review。公司先決定整體 portfolio 要把資源放在哪些產品線、哪些已知機會、哪些新探索；然後在 initiative review 裡根據 certainty toward outcomes 加碼或停止。領導可以設定邊界，例如某個 experiment 最多花 10 萬美元，學到什麼再回來談。這比年初用低證據 business case 一口氣決定全年 feature list 健康得多。

最後一個制度是 customer centricity。這不是牆上寫「以客戶為中心」。Amazon、Netflix、Zappos、Dollar Shave Club、Disney 等公司之所以強，是因為高層和制度都讓客戶問題持續進入決策。John Deere 的例子很好：它讓工程師和 PM 去真實農場看農民工作，因為城市來的工程師不會自然理解農業細節。更重要的是，即使公司遇到經濟壓力，PM 仍被允許拜訪客戶。這才叫制度化。

把這些放在一起，你會看到 product-led organization 的完整形狀：

這張表也讓我們回頭理解 Marquetly 的轉型。它不是「找到影片剪輯功能」而已。它是從角色、策略、流程、制度一起改：補 CPO Jen 和資深產品人；把 20 個 component teams 改往 value stream；用兩條 strategic intents 聚焦；用 Product Kata 找教師端瓶頸；用 experiments 支撐 buy/partner/build 決策；用 QBR、initiative review、living roadmap、product ops 讓 outcome 被管理；用獎酬、安全感和預算邊界避免團隊被拉回 output。

幾年後，Marquetly 達成兩條 strategic intents，最後被大型教育公司收購。這不是因為它學會某個框架，而是因為它改變了自己判定進步的方式。

七、這本書真正的反常識：不要愛上產品，愛上問題

如果只讀成方法論，這本書會顯得有點「產品管理大全」：strategy、PM role、metrics、Kata、roadmap、ops、incentives、budgeting，全都有。但它其實有一條更尖銳的精神線索：產品人最大的誘惑，是愛上自己正在做的東西。

愛上 feature，會把上線當勝利。
愛上 roadmap，會把承諾當策略。
愛上 process，會把跑完流程當學習。
愛上 experiment，會為了實驗而實驗。
愛上自己的判斷，會把 data 當裝飾。

Perri 最後說她早期學到的是 humility。產品經理不是 big idea generator，而是 bad idea terminator。她有一句短話可以當全書的警語：「Data beats any opinion every time.」

這句話不是叫你迷信數據。書中反覆提醒，數據要有 context，指標會互相傷害，vanity metrics 會騙人。它真正要說的是：產品工作要把意見放到世界裡受測試。你可以有強烈觀點，但觀點必須願意被客戶行為、商業結果、實驗證據修正。

這也是為什麼本書不是純粹的 discovery 崇拜。它反對的是自欺，不是執行。做出東西仍然重要，但 build 的目的要被改寫：不是為了完成，而是為了推動 outcome；不是為了證明我們很忙，而是為了讓世界產生可觀測的變化。

我會把全書壓成三句話：

第一，功能只是候選解法，不是價值本身。
第二，產品管理的核心是把未知變成可學習問題。
第三，只有當策略、獎酬、預算、roadmap、sales、ops 都支持 outcome thinking，產品方法才活得下去。

這裡也要補上對本書的限制。Perri 的模型非常適合軟體、SaaS、數位平台、成長型公司，以及任何能較快取得用戶 feedback 的產品環境。它對硬體、醫療、基礎設施、政府、強合規產業仍然有用，但不能機械套用。那些環境的 experiment 會更慢、更貴、倫理和法規邊界更強。你不能用「快速學習」當作逃避專業責任的藉口。

另外，outcome 也可能被濫用。錯誤的 outcome metric 會比 output metric 更危險，因為它看起來更高級。只追短期 conversion，可能毀掉信任；只追 retention，可能做出上癮設計；只追 revenue，可能服務錯誤客戶。Product-led 不是「所有東西量化」，而是讓判斷接受證據約束，同時保留倫理、品牌、長期策略和客戶尊重。

還有一個現實限制：product-led 需要 leadership patience。Marquetly 能轉型，是因為 CEO 最後願意讓團隊用 outcome 和 learning 說話。如果高層每兩週就因為看不到 feature 而重排方向，Product Kata 只會變成一場表演。

這些限制不削弱本書，反而讓它更可信。真正成熟的產品觀，不是拿一套方法征服所有場景，而是知道方法在什麼條件下有效。

八、拿最近一個功能來驗屍

讀完《Escaping the Build Trap》，不要問「我們是不是 product-led」。這個問題太容易變成文化口號。拿最近一個上線功能來驗屍，答案會誠實得多。

你可以問六組問題。

第一，這個功能原本要改變哪個 business outcome？是 revenue、retention、activation、cost、risk、customer satisfaction，還是 strategic positioning？如果答案是「因為客戶要求」「因為老闆說要」「因為 roadmap 上有」，那它一開始就沒有被放進價值交換。

第二，它對應哪個具體 customer problem？不是「使用者需要 dashboard」，而是「使用者在什麼決策中看不到什麼資訊，導致什麼成本」。不是「老師需要上傳工具」，而是「老師因影片剪輯耗時 80 小時，導致課程發布率只有 25%」。

第三，上線前最危險的假設是什麼？你們用什麼證據降低它？如果沒有假設，只有 spec，表示團隊把未知偽裝成需求。

第四，什麼情況下你們會殺掉、縮小或轉向？如果沒有 kill criteria，所有功能都會自然活下去，最後產品變成無人整理的倉庫。

第五，上線後哪個 outcome 真的變了？如果只知道「已上線」「bug 不多」「客戶有看到」，那只是 release review，不是 product learning。

第六，如果答案不好看，組織會獎勵誠實學習，還是懲罰沒有照計畫交付？這題最關鍵。因為 build trap 從來不只是 PM 的知識問題，而是組織的獎懲問題。

如果這六題答不出來，下一步也不一樣。沒有 business outcome，就先回 strategy 和 metric ladder；沒有 customer problem，就做 problem exploration；沒有危險假設，就開 risk workshop，把 desirability、viability、feasibility、usability 拆開；沒有 kill criteria，就補 roadmap stage 和 success metric；上線後沒有 outcome，就補 analytics 和 release review；答案不好看卻沒人敢承認，就不是產品流程問題，而是 incentives 和 safety 問題。

上面是我的「單一功能驗屍」應用版。Perri 在附錄給的是公司層級診斷，我把它們改寫成更直接的版本：

如果你只能帶走一個操作，我會建議帶走這個「功能驗屍」。因為它逼你穿透所有漂亮詞：Agile、OKR、roadmap、MVP、product-led、customer-centric。這些詞都可能是真的，也都可能只是 build trap 的新包裝。

Marquetly 後來真正逃出的，不是一套流程，而是一種自欺。它不再用「我們做了很多」安慰自己，而是開始追問：世界因為我們做的東西發生了什麼改變？

這也是本書留給產品人、創業者、管理者最重要的提醒。

公司不是因為做得慢才掉進 build trap。很多時候，公司是因為做得太快、太順、太會交付，才沒有時間問自己：我們到底有沒有創造價值？

來源與覆蓋說明

本文使用完整書籍內容作為來源，而非只依賴章節摘要。原始書籍內容約 328,653 字元；本文約為原文 1/5 以下，目標是提供核心論證與主要方法的理解替代，而不是文本替代：保留核心論證、主要框架、承重案例、方法與組織條件，但不重現原書的章節敘事與表達順序，也不替代原書更完整的操作細節與原文表達。

引用策略：全文以轉化、重建與評論為主，只保留少量短直接引文作為概念證據。未使用私人筆記或公司內部脈絡，因此可進入公開發布審核。