傑文斯悖論：PM 優化功能後，成本反而增加？

WHY｜為什麼把產品做得更快、更好，有時候會帶來更多問題？

一個常見的假設：把功能做得更快、更簡單，節省用戶使用時間，產品成本也應該要跟著減少。

但是事實可能相反。

搜尋功能優化之後變得更有效率，搜尋一筆資料的成本降低了，但是搜尋功能提升之後，用戶使用搜尋功能的次數反而變多，結果伺服器總體成本上升。AI 工具讓寫作效率提升三倍，產出的內容量也增加三倍，團隊花在審查的工作量也跟著增加。

效率提升，造成使用量增加，整體的成本反而跟著增加。

WHAT｜什麼是傑文斯悖論？

傑文斯悖論（Jevons Paradox）由英國經濟學家 William Stanley Jevons 在 1865 年提出。他發現蒸汽機效率提升之後，英國的煤炭消耗量不降反升。

為什麼？因為效率提升讓每單位成本下降，低成本吸引更多人使用，總量因此增加。單筆省下來的成本，被增加的需求吃掉，甚至高於節省下來的用量。

這個現象也被稱為反彈效應（Rebound Effect），在能源、資源，以及產品領域都能觀察到。

在產品裡，「資源」換成了另一種形式

傳統傑文斯悖論說的是能源和原物料。到了產品裡，「資源」換成了用戶的時間、注意力和行為，以及系統的流量與成本。

當一個功能的門檻降低，使用量會超線性增長，這個成長，對產品有什麼影響？

HOW｜PM 怎麼把傑文斯悖論納入決策思考？

優化之前，先預測反彈

每次做效率優化，我都會和團隊進行這個討論：如果用戶使用這個功能的摩擦力降低一半，使用量會怎麼變？

如果預期使用量會增加很多，那麼基礎設施、支援能量、內容審查的容量，都要提前跟著規劃，不能用現在的使用量當基線。

把第二階效應寫進需求文件

PRD 裡通常只寫功能本身的預期效果，但傑文斯悖論提醒 PM 要多寫一行：如果使用量因為效率提升而增加很多倍，哪些部分會先出問題？

提前把這個問題帶進需求討論，讓工程和營運有機會準備，避免上線後因為高流量造成產品問題。

區分「效率」和「影響力」

優化的目的不同，反彈效應的意義就不一樣。想拉高使用量，反彈是你要的成長；想降低成本，反彈可能把省下來的全吃掉。分清楚優化的目的，再決定用什麼指標衡量。

開始練習

找一個最近做過或正在規劃的效率優化，做一個簡單的反彈分析：

1. 這個優化降低了什麼門檻？（速度、成本、步驟數）
2. 門檻降低之後，哪類用戶最有可能增加使用頻率？
3. 使用量增加兩倍，系統的哪個環節最先出問題？
4. 這個反彈是希望發生的（成長），還是需要提前預防的（成本失控）？

常見問題

傑文斯悖論是說優化沒有意義嗎？

不是。優化本身有意義，問題在於預測的假設。「效率提升 = 總消耗降低」通常是錯的，「效率提升 = 使用量增加」才更接近現實，規劃時用後者思考會更準確。

什麼樣的產品最容易出現傑文斯悖論？

邊際成本低、使用門檻高的產品優化後最明顯。例如 API 呼叫、搜尋功能、AI 生成工具，一旦速度或成本改善，呼叫量往往快速增長。

反彈效應一定是壞事嗎？

不一定。如果目標是拉高活躍度或使用頻率，反彈效應正是你想要的。問題在於很多團隊優化時沒有預期到反彈，導致基礎設施或支援能量跟不上。

PM 要怎麼在 roadmap 討論中帶入傑文斯悖論？

最簡單的方式是在評估優化項目時，把「使用量增加兩倍的情境」納入需求討論，讓工程和維運可以提前評估容量，而不只是評估功能可行性。

有沒有辦法減弱反彈效應？

有，但通常需要在設計層面介入，例如設定使用上限、分級定價、或是主動引導用戶在效率提升後做不同的事，而不是做更多同樣的事。