逃出 Build Trap：公司真正要學會的，不是更快交付，而是更準確地創造價值
來源：
build-trap-main.sdpub與整理後主文 digest。原始主文約 55,390 words，本篇控制在遠低於 1/5 的長度內。本文是中文重編排專欄，保留核心論證、案例與框架，但不作為原書逐字替代。
很多公司以為自己有產品管理，因為它們有 backlog、有 roadmap、有 scrum、有一群 title 叫 product manager 或 product owner 的人。可是 Melissa Perri 在《Escaping the Build Trap》真正指出的問題是：公司陷入 Build Trap 時，並不是缺少開發流程，也不是缺少 idea，而是整個組織把「做出東西」誤認成「創造價值」。一旦 feature shipped 變成成功指標，公司就會越來越擅長交付，卻越來越不擅長判斷什麼值得交付。
Build Trap 的危險在於，它看起來很像進展。團隊忙碌，release 很多，roadmap 被填滿，sales 有東西可以賣，管理層有進度可以檢查，績效表上也有勾選完成的項目。但真正的問題通常在 release 之後才出現：客戶不使用，使用者不滿意，收入沒有改善，產品越來越複雜，團隊越來越疲乏。這不是執行力不足，而是價值判斷系統壞了。
書中的 Marquetly 是這種病的縮影。這家公司做線上行銷教育，成長曾經不錯，後來卻開始被 enterprise 客戶承諾、sales 壓力、董事會預期、年度目標和一堆 feature list 拉扯。產品經理原本開始學習研究使用者、做實驗、理解問題，但公司沒有給他們足夠空間。高層想看到出貨，bonus 綁定交付，sales 已經把東西賣出去了，deadline 也寫進合約。於是大家回到最熟悉的動作：寫 user story、排功能、趕上線。結果某次 release 推出十個功能，管理層一度很高興，之後網站開始壞、老師覺得功能干擾核心工作，最後幾乎沒有人使用那些新功能。公司得到了 output，卻沒有得到 outcome。
這是全書的第一個基本區分：output 是產出物，outcome 是產出物造成的結果。功能數量、release 次數、velocity、完成 story points，都是 output。客戶問題被解決、使用者行為改變、留存改善、收入成長、學習速度變快，才是 outcome。產品管理的工作，不是把 output 打包得更漂亮，而是讓公司能夠穩定找到、驗證、交付 outcome。
Perri 把公司與客戶之間的關係稱為 value exchange。客戶有問題、需求、欲望；公司提供產品或服務去解決它們。只有當客戶感受到價值，才會把價值回流給公司，可能是金錢、資料、知識、信任、口碑或留存。很多公司把這個交換看反了，以為只要多做功能，就自然會得到價值。於是它們把容易測量的 output 當成 value 的 proxy。這個 proxy 一旦被寫進績效、預算、roadmap 和獎金制度，就會開始塑造所有人的行為。
因此，Build Trap 不是產品團隊自己的問題，而是組織系統問題。你不能只教產品經理做 discovery，卻仍然用出貨數量評估他；不能要求團隊實驗，卻要求他們年初承諾年底會交付哪些功能；不能說 customer-centric，卻不讓工程師、設計師、產品經理接觸客戶；不能說要創新，卻在失敗後懲罰最早揭露錯誤的人。
書中把非 product-led 的公司分成幾種常見型態。Sales-led 公司讓合約承諾決定產品方向。早期創業公司為了活下來，圍繞大客戶客製是可以理解的，但如果一直如此，公司會變成一間偽裝成軟體公司的客製服務公司。Visionary-led 公司靠少數天才決策前進，運氣好時威力巨大，但它把創新能力押在一個人身上，無法穩定複製。Technology-led 公司被新技術牽著走，做出很酷但市場不需要的東西。Product-led 公司不同：它以產品成功作為公司成長和價值創造的核心，將產品策略對齊 business outcome，再讓團隊探索哪些 problem 和 solution 最能推動這些 outcome。
這個轉變之所以困難，是因為產品開發本質上充滿未知。書中借用 known knowns、known unknowns、unknown knowns、unknown unknowns 這套分類來說明產品管理的專業性。法規、既有數據、關鍵客戶明確限制，可能是 known knowns；我們知道需要理解但還沒理解的問題，是 known unknowns；經驗帶來的直覺，常是 unknown knowns，它有用但也可能藏著偏見；至於 unknown unknowns，則是團隊還不知道自己不知道什麼。產品經理的價值，就在於辨識哪些假設最危險，哪些問題該先問，哪些直覺要被資料檢驗，並透過探索縮小未知的範圍。
這也重新定義了產品經理。很多公司把 product manager 想成 mini-CEO，但產品經理沒有 CEO 的權限，不能任意調人、調預算、改組織。把 PM 當 mini-CEO，容易養出自以為擁有答案、對團隊頤指氣使的人。另一個極端是 waiter：stakeholder、客戶、老闆點什麼，他就送什麼，沒有目標，沒有判斷，只是在 backlog 裡整理需求。第三種錯置是 former project manager：只問何時交付、誰負責、進度如何，卻沒有能力回答為什麼要做、對誰有價值、怎樣才算成功。
好的產品經理真正擁有的是 why，而不是獨裁式的 what。他要理解市場、使用者、商業模式、公司策略、技術限制，然後把這些資訊合成一個方向，帶著團隊一起找到值得做的事。產品經理不是唯一有 idea 的人，而是能幫團隊辨識哪些 idea 值得驗證、哪些假設最危險、哪些問題最值得解決的人。他不是團隊的大腦，而是讓團隊的大腦能對準問題的人。
這也解釋了為什麼 Perri 一再區分 product owner 和 product manager。Product owner 是 Scrum 裡的一個角色，負責 backlog、user stories、priority 和驗收；product manager 是一個職涯與專業，負責判斷市場、客戶、商業目標、產品方向與成功方式。公司如果只訓練人寫故事，卻不訓練他們做 product management，就會得到大量忙碌的 backlog 管理者，而不是能創造價值的產品領導者。這也是她主張要建立產品職涯階梯的原因：APM、PM、Senior PM、Director、VP Product、CPO 每一層的工作重心不同，越往上越需要把產品投資、組合風險、公司策略和董事會語言連接起來。
書裡的 Meghan 案例很好地說明這件事。她在銀行負責首次房貸申請流程，目標不是「把申請流程數位化」這種 feature mandate，而是提高首次申請完成率。她先看資料，發現大量申請者中途流失，再訪談那些沒有完成的人，發現文件驗證與分行預約是核心阻力。她沒有立刻要求工程團隊打造完整線上系統，而是用人工方式讓部分申請者先以 email 提交文件，觀察完成率是否改善。實驗證明問題被正確識別後，團隊才逐步往線上驗證系統演進。這就是產品經理該做的事：從 business goal 出發，理解 user problem，用最小成本降低不確定性，再把 solution 帶向可擴展。
產品經理再好，如果組隊方式錯了，也很難發揮。書中批評 component team：有人負責登入 API，有人負責某個技術元件，結果即使那個元件沒有最重要的問題，團隊仍然要找事做。更好的方式是圍繞 value stream 或目標組隊，讓團隊能對完整價值負責。TransferWise 的案例是按 retention、新幣種、新用戶取得這類 strategic goal 組隊；Pandora 以小團隊和季度取捨支撐大規模產品，靠的是嚴格優先順序而不是無限擴編。這個觀點對很多公司很刺耳：你以為缺更多團隊，其實可能是組織切法讓每個團隊都只能局部最佳化。
要讓這種產品管理成立，公司需要策略，但 Perri 對策略的定義很尖銳：策略不是詳細計畫，而是可部署的決策框架。很多高層說要 strategy，其實只是想要一份 plan：三個月內做什麼、哪個頁面長什麼樣、後端怎麼建、哪天上線。這種要求通常是管理者面對不確定性的焦慮反應。他們想填補 knowledge gap，所以要求更多細節；想填補 alignment gap，所以給更多指令；想填補 effects gap，所以加更多控制。但越是這樣，團隊越沒有空間根據學到的東西調整。
真正好的策略要解決的是方向與自主性的關係。完全沒有方向，團隊會害怕，因為什麼都能做；方向過度具體，團隊只剩執行，無法學習。好的 strategy deployment 會在不同層級給出不同粒度的故事：公司有 vision，接著有少數 strategic intents，產品線有 product initiatives，團隊探索 options。高層不該把 feature list 往下丟，而該說清楚公司現在最重要的 outcome 是什麼、為什麼重要、有哪些限制。下一層再把它翻譯成更短時間尺度、更接近使用者問題的目標。
Marquetly 後來能改變，是因為新的 CPO Jen 先把「公司到底要什麼」釐清。她發現 leadership 對優先順序沒有共識，產品經理也說不出為什麼做手上的東西。公司原本的 OKR 看似現代，其實仍是 output-oriented，例如交付某平台第一版、某日期前上線。這種 OKR 只是把 feature list 換一種格式。真正的 strategic intent 應該是高層級、少數、結果導向，能讓整家公司聚焦。例如 Marquetly 後來設定兩個主要方向：大幅擴張 enterprise revenue，以及讓 individual user revenue growth 回到更高水準。這些不是功能，而是 business movement。功能要從這些方向往下推導。
這裡還有兩個容易被忽略的層次。第一是 company vision。好的 vision 不是牆上的句子，而是能讓不同產品線做出一致取捨的方向。Amazon 的公司願景能同時約束零售、Prime、Fulfillment、影音與裝置，因為它把「如何替顧客創造購物與發現價值」放在核心。第二是 product vision。產品願景不能寫成 feature specification，而要說明使用者問題、價值主張與主要能力。Amazon 常用 press release 方式描述新產品：先從使用者問題和未來結果寫起，再倒推產品該長成什麼樣。這種方法防止團隊太早被 solution 綁住。
Product portfolio 則是更高階的取捨問題。公司不只要問單一產品該怎麼贏，還要問不同產品如何共同推動公司策略。創新不是「等大家有空再說」；沒有空通常代表管理層沒有真正做取捨。Amazon Echo/Alexa 的例子說明，若公司相信某個新機會能支撐未來策略，就需要給專門團隊足夠時間和空間探索，而不是要求它在日常 feature factory 的縫隙裡自然長出來。Spotify 的 DIBBs 也有相同精神：用 data、insights、beliefs 形成 bets，讓投資與學習在一個可溝通的框架裡發生。
這裡出現全書最重要的操作框架：Product Kata。它承接 Toyota improvement kata 的精神，把產品工作變成一個循環：理解方向，掌握目前狀態，找出阻礙目標的最大問題，選擇下一步實驗，預期會發生什麼，觀察實際發生什麼，然後把學習回饋到下一輪。Product Kata 的價值不是讓團隊看起來很 lean，而是避免團隊在錯的階段使用錯的工具。還不知道問題時，不該急著做 solution experiment；問題已經很清楚且有成熟 best practice 時，也不必假裝一切都需要發明。
Perri 把產品流程拆成三段：problem exploration、solution exploration、building and optimization。Problem exploration 是找出真正阻礙 outcome 的問題。這不是 usability testing；usability testing 是看使用者能不能用某個方案，problem research 是在還沒有方案時理解使用者處境、痛點與根因。Marquetly 的 Christa 想增加老師上架課程的比例，不是先做新功能，而是先訪談與觀察老師，發現影片剪輯是讓老師無法完成課程的重要阻礙。這個問題定義讓後面的 solution 有了方向。
Solution exploration 則是用最小成本學習哪個方案值得擴大。Perri 對 MVP 的理解很乾淨：重點不是 minimum product，而是 minimum effort to learn。Concierge experiment 可以先用人工完成結果，學習服務流程與客戶反應。Christa 團隊就先手動幫老師處理影片，證明移除剪輯負擔會提高課程發布率。Wizard of Oz 則讓使用者感覺背後有完整系統，但後台先用人力支撐；Zappos 早期測試線上買鞋需求，就是先用簡單網站接單，再由創辦人手動去買鞋寄出。Concept testing 則用 landing page、prototype、影片或高接觸展示測試需求；Dropbox 早期用影片傳達同步體驗，GiveVision 用 Android 手機和 3D 列印裝置模擬智慧眼鏡，都是為了在投入大量成本前先學到關鍵答案。
不是所有 solution 都該自己打造。當團隊已理解問題後，還要判斷 build、partner、buy：自己建、找夥伴，或購買/收購現有能力。Marquetly 在影片工具上不是一開始就重寫整個系統，而是先驗證老師端問題，再測第三方工具，最後才走向整合 Budapest 的影片編輯軟體。這條路線之所以重要，是因為 product-led 不等於「所有東西都自己做」，而是用最能推動 outcome 的方式解決問題。
但探索不是永遠探索。當團隊有足夠證據，就要 building and optimization。真正的 Definition of Done 不該是「功能上線」，而是「功能達成它該造成的 outcome」。第一版上線只是讓假設進入更真實的環境。若沒有達到成功標準，就要優化、調整、甚至撤回。這對很多公司很刺耳，因為它們習慣把 release 當終點。但在 product-led 組織裡，release 只是學習循環的一部分。
在 building 階段，團隊需要把學習整理成共同理解。Christa 團隊用 North Star document 把問題、方案、成功因素與預期 outcome 描述成整個公司都能理解的方向，再用 story mapping 把使用者行動拆開，決定第一版該包含什麼。這裡的重點不是文件本身，而是讓團隊在同一張地圖上做取捨。Cost of Delay 則幫助他們判斷哪些能力延後會造成最大損失。音訊與圖片剪輯對大多數老師更關鍵，就先做；少數人需要的影片 splicing 若會多花一個月，就不應拖慢第一版。優先順序不是誰聲音大，而是延遲會造成多少 outcome 損失。
這套流程需要 metrics 支撐。產品團隊要能區分 lagging indicators 和 leading indicators。收入、留存、 churn 重要，但常常太晚才反映結果；activation、engagement、happiness、task completion、特定使用行為，可能更適合短週期學習。書中提到 Pirate Metrics 和 HEART Framework，不是因為每家公司都該照抄，而是提醒產品經理要把抽象目標拆成可觀察的行為變化。Pirate Metrics 追蹤 acquisition、activation、retention、referral、revenue，適合看使用者生命週期；HEART 補上 happiness、engagement、adoption、retention、task success，更適合評估某個產品或功能的使用者體驗。沒有指標，團隊只能憑意見爭論；有錯的指標，團隊會有效率地走向錯的地方。
流程再好，若組織制度不改，還是會回到 Build Trap。所以全書最後一部分其實是最重要的：product-led organization 要有能保護 outcome thinking 的環境。第一個環境條件是溝通節奏。領導者如果看不到進度，就會回到舊習慣：要求更多規格、更多承諾、更多控制。產品團隊需要用合適的 cadence 展示 outcome progress。Quarterly business review 看 strategic intent 和財務結果；product initiative review 看 options 與 initiatives 的進展；release review 則只溝通確定要交付給客戶的內容。透明不是為了報告，而是為了換取自主。
第二個條件是 roadmap 要從交付承諾變成策略溝通工具。傳統 roadmap 像 Gantt chart，最容易被 sales 拿去承諾客戶，最後把產品團隊鎖死。Product-led 的 roadmap 應該說明 theme、hypothesis、goal、success metrics、目前階段。Experiment、Alpha、Beta、GA 這些狀態能幫公司分清楚什麼能對外承諾，什麼還在學習。這不是要產品團隊躲開 sales，而是要建立 working agreement：sales 需要東西可賣，product 需要不被未驗證承諾綁死。
第三個條件是 product operations。當公司只有幾個產品團隊，大家走到旁邊問一下就能知道進度；當公司有數十、數百個團隊，strategy cadence、roadmap、analytics、實驗記錄、目標追蹤、sales enablement 都會變成巨大協調成本。Product ops 不是替團隊決定 roadmap，而是建立輸入輸出的標準、資料管線、會議節奏與透明度，讓產品組織能規模化運作。它是一個效率引擎，不應膨脹成另一個指揮官僚層。
第四個條件，也是最容易被忽略的，是 incentives。公司說要 outcome，但 bonus 綁 feature；說要 learning，但績效看年度承諾是否全部交付；說要品質，但年底為了勾完 scorecard 亂推東西。這時員工不是不懂正確做法，而是被制度逼著做錯事。Perri 提醒，獎懲制度會比口號更誠實。若 sales 的收入完全依賴簽約額，他就會傾向過度承諾；若產品經理的獎金綁上線，他就會傾向忽略研究與驗證。要逃出 Build Trap，公司必須獎勵解決問題、產生 outcome、學習使用者、殺掉錯誤 idea，而不只是交付更多東西。
第五個條件是 safety。產品實驗不是鼓勵失敗，而是用更小、更早、更便宜的方式避免巨大失敗。真正糟糕的不是一個小實驗失敗，而是公司花了數年和大量資金才發現方向錯了。Netflix 的 Qwikster 是一個大型公開失敗；但 Netflix 沒有因此停止創新，而是從中學習，後來繼續押注自製內容。安全感不是讓人隨便做，而是讓人能在合理邊界內測試假設、揭露壞消息、根據證據改變路線。
第六個條件是 budgeting。年度預算最容易製造 output trap：年初用不足資料寫 business case，全年照 roadmap 花錢，年底若沒花完或沒交付，就影響明年資源。這會導致荒謬行為：即使團隊發現某東西不該做，也會因為預算與承諾而繼續做。Product-led budgeting 更像 VC 投資：先給少量資金探索，證據變強後追加，若無法證明價值就停止，把資源轉給更有機會的地方。預算不該綁死專案，而該推動產品往下一個可驗證階段前進。
最後一個條件是 customer centricity。這不是把「以客戶為中心」寫進價值觀，而是讓組織真的靠近客戶。Amazon 的例子說明客戶中心可以成為整個公司決策的北極星；John Deere 的例子更具體：工程師即使原本不了解農業，也被鼓勵去農場看客戶如何工作，甚至親身參與。產品不是在會議室裡被想出來的，而是在理解使用者生活與工作脈絡後被發現的。
因此，《Escaping the Build Trap》不是一本只寫給產品經理的書。它其實寫給 CEO、CPO、CTO、sales leader、finance、HR，以及任何會影響產品團隊行為的人。產品團隊是否能做好產品，取決於他們是否被放在一個允許他們做好產品的系統裡。錯的人在錯的位置、錯的策略粒度、錯的指標、錯的獎金、錯的預算節奏、錯的 roadmap 溝通，都會把聰明人推回 output mode。
如果要用六個問題診斷一家公司是否 product-led，可以問：上一個功能 idea 是誰提出的，團隊是否能說清楚 why？最近一次殺掉的產品或想法是什麼？產品經理上次和客戶談話是什麼時候？當前目標是否是 outcome 而非 output？團隊現在談的是使用者問題還是要交付的功能？產品經理在組織裡是被尊重的領導者、被動接單者，還是被制度消耗的人？
真正逃出 Build Trap 的公司，最後會長得很不一樣。高層不再把策略寫成 feature list，而是提供清楚的 intent。產品經理不再靠權威推 idea，而是靠問題、資料與實驗帶領團隊。工程與設計不再只是接需求，而是參與理解問題。Sales 不再用未驗證 roadmap 換合約，而是與 product 有清楚承諾邊界。Finance 不再用年度專案預算鎖死學習，而是分階段投資已驗證機會。HR 和 leadership 不再獎勵出貨數，而是獎勵 outcome、學習與正確地停止錯誤方向。
這本書最有啟發的地方，是它把「做產品」從一套 team process 拉高成 company operating system。Build Trap 看似發生在 backlog 裡，其實源頭常在董事會壓力、sales incentive、預算流程、策略溝通、職涯設計、領導者焦慮。當公司只修 Scrum 或只訓練 PM，它只是修表面。真正的改變，是讓整個公司從「我們要交付什麼」改問「我們要讓什麼結果變成真；目前最大的未知是什麼；下一步最便宜的學習是什麼」。
這個轉變不浪漫，也不只是文化宣言。它需要公司願意殺掉不工作的 idea，承認不知道答案，讓團隊接觸客戶，用資料對抗意見，用小實驗對抗大賭注，用持續策略對抗年度劇場，用 product ops 支撐透明度，用 incentives 校正行為。它的本質是把公司從 feature factory 變成 learning system。
讀完《Escaping the Build Trap》，最該留下的不是某個框架名稱，而是一種警覺：每當組織開始慶祝「我們做了多少」，卻很少追問「它造成了什麼改變」，Build Trap 就已經在門口。逃出去的方法也不是少做事，而是更嚴格地把每件事連回價值。產品不是公司交付的東西；產品是公司學習市場、解決問題、交換價值的方式。能不能把這套系統建起來，才是一家公司是否真正 product-led 的分水嶺。