當做功能幾乎免費：路線圖該從排隊表變成取捨聲明

過去二十年，產品路線圖真正的功能，其實不是「規劃」，是「配給」。工程資源永遠不夠，所以要排序、要卡季度、要有人被告知「這季輪不到你」。整套流程——需求評分、優先級矩陣、季度規劃會——都是為了處理同一件事：稀缺。

然後這個前提在這兩年被悄悄抽掉了。當一個原本要兩週的功能，現在一個下午就有能動的版本，排隊的意義就消失了大半。多數團隊的直覺反應是加速：既然做得快，那就多做一點。但這裡有個沒被檢查的假設——實作成本崩跌，不等於功能的總成本崩跌。

便宜下來的只有實作，另外三項成本一毛沒少

生成式工具壓低的是「把想法變成可運行程式碼」這一段。但一個功能從上線到退役，成本至少還有三塊，而這三塊跟誰寫的、寫多快，幾乎無關：

• 使用者的注意力：每多一個入口、一個選項、一個通知，就多一次認知負擔。介面是零和的——你新增的那一格，是從既有功能的曝光裡挖出來的。
• 維護與支援：上線之後的除錯、相容、客服解釋、資安檢查、文件更新、教育訓練。這是一條長尾費用，而且會隨功能數量非線性增長。
• 定位的一致性：產品每多做一件「反正也做得出來」的事，使用者腦中對你的那一句描述就模糊一分。外送平台長出訂閱、廣告版位、生鮮、金流之後，那句話會愈來愈難說完整。

換句話說，AI 讓你更快抵達的，是成本結構裡最便宜的那一段；而它加速累積的，是最貴的那三段。

產能過剩的組織，會用忙碌掩蓋沒有取捨

過去說「不」有一個天然的擋箭牌：沒有資源。業務要的功能、老闆想試的點子、客戶臨時提的客製，最終都會被工程排程擋掉一部分——那不是好的決策機制，但它至少是一道濾網。

現在這道濾網不見了。每個需求都可以「順手做一下」，於是每個需求都被做了。半年後，產品變成一台什麼都能做、但沒有人說得清它是什麼的機器；團隊看起來從沒這麼有生產力過，卻說不出上一季真正改變了哪個指標。

這裡的斷點值得說白：交付變便宜的時候，最先失效的不是工程能力，是決策紀律。稀缺會逼人排序，充裕不會——充裕只會讓沒有想清楚的組織，更快地把混亂具體化。

該換的不是工具，是路線圖的輸出物

多數團隊面對這個變化，換的是工具：更快的原型、更自動的需求整理、更聰明的優先級評分。但問題不在算得不夠快，在算的東西已經不是瓶頸了。

真正該改的是路線圖這份文件本身。它過去回答的問題是「我們要做什麼」——那是一份排隊表；它現在該回答的問題是「我們決定不做什麼、以及為此承擔什麼」——那才是一份策略。

檢驗方式很簡單：把你的路線圖給一個外部的人看，他能不能指出你放棄了哪些機會？如果通篇只有要做的事，那份文件就沒有攜帶任何判斷，只是把待辦事項按時間攤開而已。

明天就能做的三件事

• 在路線圖加一欄「已否決」：寫下這一季被否決的三個需求與否決理由。取捨要能被追溯，才可能被挑戰、被修正；只記錄做了什麼的組織，永遠學不會為什麼不做。
• 每個新功能上線時，同時寫下退場條件：例如「上線 90 天後，若周活躍使用低於某門檻即下架」。沒有退場條件的功能不會消失，只會沉澱成維護債，並在兩年後變成沒人敢動的地雷。
• 估算改用「首年總持有成本」：開發工時 ＋ 預估客服量 ＋ 文件與教育 ＋ 相容維護。用這個數字排序，AI 省下的時間才會被放到值得的地方，而不是單純被換成更多功能。

留一個沒答完的問題

如果做出功能這件事幾乎免費，那你的產品還剩下什麼是別人抄不走的？功能顯然不再是答案——真正抄不走的，可能是那幾個你願意公開講、而且長期不改的取捨：我們不服務誰、不進哪個市場、不加哪種功能。

所以問題可以收得更近一點：你上一次在會議上明確說出「這件事我們永遠不做」，是什麼時候？如果想不起來，那你的產品現在的樣子，恐怕不是你決定的，是需求排隊排出來的。