◆ 專案現場的真實痛點
在 #076，我們談的是如何判斷一個不再具備明確商業價值的舊系統，是否應該中止、收費，或重新設計變現模式。到了 #077，問題會更貼近每一位 PM 的日常。因為多數產品真正的沉重，不一定來自一整套殭屍系統，而是來自一個又一個被留下來的小功能。
產品上線三年後，最常見的畫面是這樣。左側選單越來越長，後台設定越來越多，表單欄位越來越細，原本簡單的流程開始長出許多分支。業務說某個客戶需要 A，老闆說競品有 B，我們也不能沒有，行銷說下個活動需要加 C。每一次新增看起來都合理，沒有一個需求荒謬到可以直接拒絕，但幾年下來，產品卻逐漸變得臃腫、緩慢、難以理解，也難以維護。
更麻煩的是，團隊通常很習慣做加法，卻很少有人負責做減法。新功能上線，會有掌聲，會有成果展示，會有版本公告。舊功能移除，通常只會帶來疑慮、反彈與客服壓力。
於是，很多功能就這樣被留了下來。即使全站只有少數用戶使用，即使它已經不再符合產品主線，即使每一次版本發布都必須多花時間測試它，團隊還是傾向讓它繼續存在。
問題在於，只要功能存在，它就不是零成本。它會佔用文件、測試、客服、研發維護與產品理解的成本。新用戶會因為過多選項而迷路，QA 每次回歸測試都必須確認它沒有壞，RD 在修改相鄰模組時也必須顧慮它是否受到影響。表面上只是多一個小功能，實際上是產品長期持有成本的一部分。
功能蔓延的可怕之處，不在於某一個功能本身很糟，而在於它讓產品逐步失去重心。當每一個小功能都有留下來的理由，最後整個產品就會失去取捨。
◆ 這篇文章不處理什麼
這篇文章不是要教你 UI 收納術。把不常用的功能藏到深層選單裡，讓畫面看起來比較乾淨，並不代表問題被解決。只要功能仍然存在，測試成本、維護成本、相容成本與客服成本就仍然存在。眼不見為淨，不等於產品變健康。
這篇文章也不是鼓吹極簡主義。不是所有客製化都不該存在，也不是所有低使用率功能都必須立刻停用。有些功能雖然使用者少，但服務的是高價值客戶；有些功能使用頻率低，但一旦需要時非常關鍵，例如資料匯出、權限稽核或安全設定。
本文真正要處理的是，PM 如何在產品持續擴張後，建立一套可被溝通的減法判斷。
哪些功能只是低使用率，但仍有戰略價值。
哪些功能不只低使用率，還持續消耗團隊資源。
哪些功能看似無害，實際上正在讓產品體驗、測試範圍與維護成本變得更沉重。
也就是說，本文要談的不是「如何讓畫面更簡潔」，而是「如何判斷一個功能是否仍值得被產品長期持有」。
◆ 框架定義：奧卡姆剃刀與功能持有成本
處理功能蔓延時，我會先借用一個很古老、但在產品管理裡非常有用的原則，叫做奧卡姆剃刀定律。
它的核心精神是，如無必要，勿增實體。
放到產品管理裡，可以轉換成一句更直接的話。
如果一個功能對核心價值的貢獻有限，卻持續消耗產品與研發資源，就應該被重新評估。
這裡的重點不是追求少，而是追求必要。少不一定好，必要才重要。功能多不一定錯，沒有判斷地增加才是問題。
每一個功能都帶有持有成本。只要它還存在，團隊就必須為它承擔幾種成本。
- 理解成本
使用者必須理解這個功能是什麼、何時使用、和其他功能差在哪裡。 - 測試成本
每一次版本發布，QA 都必須確認它是否仍然正常，尤其當它和其他模組有關聯時。 - 維護成本
RD 修改相鄰功能或底層架構時，必須考慮它是否受到影響。 - 客服成本
只要有人使用，就可能有人詢問、抱怨、要求修正或延伸。 - 產品複雜度成本
功能越多，產品越難被理解，新用戶越難看出主線。
奧卡姆剃刀提醒 PM，產品不是功能越多越成熟。成熟的產品，反而通常更清楚自己不做什麼。最好的產品，不是沒有東西可以再加，而是沒有明顯多餘的東西還留在裡面。
◆ 框架的三個判斷問題
當團隊討論某個功能是否應該保留、調整或停用時，PM 可以先用三個問題判斷。
Q1：貢獻度測試。它在 80/20 法則的哪一邊？
第一個問題是，這個功能到底貢獻了什麼。
PM 可以先看幾個最基本的指標。使用率是多少，使用者是否集中在特定客群，是否帶來營收，是否影響續約，是否支援某個重要流程，是否有明確的戰略意義。
如果一個功能的使用率長期低於 3% 或 5%，也沒有明確營收、續約、轉換或策略價值，那它就不應該因為「有人可能會用」而自動保留。
這裡要特別小心，不是所有低使用率都等於沒價值。
例如後台的權限稽核功能，使用頻率可能不高，但對企業客戶非常重要。
例如資料匯出功能，平常不常用，但在對帳、稽核、交接時可能是關鍵需求。
所以，真正要問的不是「有多少人用」，而是：
這個功能是否對重要使用者、重要流程或重要收入有實質貢獻？
若答案是否定的，它就應該進入停用評估。
Q2：核心路徑測試。沒有它，使用者還能完成主要任務嗎？
第二個問題是，移除這個功能後，使用者是否仍能完成核心任務。
如果某個功能不存在，使用者就無法完成產品的 Aha Moment，或無法完成登入、下單、付款、交付、協作等主流程，那它即使用率不高，也不能輕易處理。
但如果這個功能只是提供某種特殊操作，而使用者可以透過更通用的功能達到相近目的，那它的必要性就必須重新評估。
很多產品的功能蔓延，來自一種常見情況。早期為某個客戶做了特殊功能，後來又為另一個客戶做了另一個特殊版本。時間久了，產品裡出現多種相似但不完全相同的操作。使用者看不懂，客服講不清楚，RD 也不敢動。
這時候，PM 要問的是：
這個特殊功能，是否能被更通用的流程取代？
它是否真的不可替代，還是只是歷史客製化留下來的分支？
如果一個功能只是把主流程拆出一條邊緣支線，而這條支線使用者少、維護成本高、又能被通用流程替代，那它很可能就不是產品能力，而是產品包袱。
Q3：維護成本測試。留下它的代價有多高？
第三個問題是，這個功能繼續存在，團隊要付出多少成本。
有些功能看起來沒什麼問題，因為它平常不太出事。真正的成本，會出現在每一次版本發布、每一次架構調整、每一次流程變更時。
例如一個只有 2% 使用者在用的舊報表功能，每次發布新版都要多花半天做回歸測試。
一個已經很少被使用的客製化欄位，讓資料庫結構一直無法整理。
一段舊流程因為某些歷史功能而不能調整，導致新功能開發必須繞開它。
這些都是功能持有成本。
PM 可以請 RD、QA、客服一起估算幾個問題。
- 每次版本發布，這個功能需要多少測試時間
- 過去半年，它產生多少 Bug 或客服問題
- 它是否阻礙新功能開發或架構調整
- 它是否需要額外文件、教學或客服說明
- 它帶來的價值，是否高於上述成本
若一個功能創造的價值很低，卻持續增加測試與維護成本，那它就不只是「沒什麼用」，而是在稀釋團隊的資源效率。
◆ 案例分析：技術展示不等於產品競爭力，產品競爭力也不等於短期營收
談功能停用或產品線收縮，很容易落入一種錯誤理解。好像只要一個功能或產品沒有立刻賺錢，就代表它沒有價值；又或者，只要它曾經展示過很強的技術能力，就應該一直保留。
這兩種看法都過度簡化。
比較完整的判斷，應該同時看三件事。
第一，它是否具備產品競爭力。
也就是使用者是否真的形成穩定需求，是否願意持續回來，是否願意為此付出成本。
第二，它是否具備商業轉換能力。
也就是它能不能形成營收、續約、付費升級、導流或其他可衡量的商業價值。
第三，它是否值得繼續配置資源。
也就是把團隊、算力、維運、行銷、客服等資源放在這裡，是否比放到其他產品或功能上更值得。
以 OpenAI 的 Sora 作為外部可觀察案例來看，這件事很有代表性。OpenAI 在 2025 年 9 月發表 Sora 2，將它定位為具備更高物理準確度、更真實、更可控，並支援同步對話與音效的旗艦影音生成模型；但公開資訊也顯示，Sora 產品已於 2026 年 4 月 26 日後不再提供，而 Sora 2 相關影片 API 與模型也排定在 2026 年 9 月 24 日停止服務。這些公開訊息至少說明一件事：即使是技術力很強、話題聲量很高的產品，也仍然可能面臨產品線取捨。(OpenAI)
同一時間，OpenAI 也推出 ChatGPT Images 2.0，並在 API 文件中提供 GPT Image 2。官方介紹強調其文字渲染、多語支援、情境理解與視覺生成能力，而 API 文件也將 gpt-image-2 列為最新的 GPT Image 模型。這讓外部觀察者至少可以看見一種產品資源重新配置的可能方向，也就是將資源集中到更容易整合進 ChatGPT 核心使用情境、也更容易形成高頻需求的能力上。(OpenAI)
需要注意的是，我們不能從外部資料直接斷言 OpenAI 內部的營收判斷或組織決策原因。但作為 PM 的產品觀察案例，它提醒我們一件事。技術展示能證明能力，卻不一定等於產品競爭力；有話題不代表有穩定需求；能吸引試玩，不代表能形成長期使用；能產生聲量，不代表值得長期配置資源。
這也是功能停用與產品線收縮最困難的地方。你不是在判斷它有沒有亮點，而是在判斷它是否值得繼續投入。
◆ 遊戲公司的現場經驗。低營收不一定代表產品失敗，可能是行銷沒有打到對的人
我過去在遊戲公司時，也看過類似的資源判斷邏輯。
當一款遊戲的營收無法支撐營運成本時，團隊通常不會立刻做單一結論。比較成熟的做法，是先降低維護人力與產品資源，再重新評估它到底是產品本身沒有競爭力，還是市場推廣沒有找到真正的受眾。
這兩者差別很大。
如果產品本身仍有競爭力，只是行銷推廣沒有打到正確族群，那問題不在產品，而在定位、通路、素材、受眾與轉換漏斗。此時過早停用產品，反而可能是錯殺。
但如果產品的核心循環不成立，留存不穩，付費轉換弱，玩家回來的理由不足，那就不能只怪行銷。這時候再增加投放，很可能只是用更高的成本證明同一件事：產品本身沒有足夠吸引力。
因此，產品競爭力不能只靠團隊感受判斷，也不能只看短期營收。至少要看幾組核心數據。
- 留存指標
D1、D7、D30 留存是否穩定。若新玩家第一天、第一週就大量流失，通常代表核心體驗沒有形成足夠吸引力。 - 核心循環指標
使用者是否願意重複進行產品最重要的行為。遊戲裡可能是每日任務、關卡推進、裝備養成；工具產品裡可能是建立專案、產出報表、重複查詢或協作。 - 付費指標
付費率、ARPU、ARPPU、LTV 是否有機會支撐獲客成本與維運成本。如果使用者願意玩，但不願意付費，問題可能在商業設計；如果願意付費的人太少，問題可能在價值感與付費時機。 - 獲客與回收指標
CAC 是否長期高於 LTV。若每帶進一位使用者都賠錢，而且留存與付費沒有改善跡象，就不能只靠「再投一波看看」延長產品生命。 - 自然成長與口碑指標
是否有自然流量、社群討論、推薦、創作、玩家自發分享。若完全仰賴廣告流量，且停投後立即歸零，就代表產品還沒有形成自我擴散能力。 - 客群匹配指標
不同受眾分群的留存與付費是否差異明顯。如果某一類玩家或使用者表現特別好，代表產品可能不是沒有競爭力，而是尚未找到對的市場切入點。
也就是說，PM 在判斷一個產品或功能是否該退場時，不能只問「它現在賺不賺錢」。更重要的是，它是否有可被證明的改善空間。
如果數據顯示產品核心循環成立，只是受眾錯置，那應該調整行銷策略。
如果數據顯示留存、付費與核心行為都不成立，那就應該更早面對停用或資源轉移。
這就是產品競爭力的鑑定。它不是單一指標，也不是主管喜不喜歡，而是用留存、核心循環、付費、獲客回收與受眾分群，去判斷一個產品是否仍值得被投資。
◆ AI 協作 Prompt。讓 AI 幫你擬定功能日落計畫
當 PM 準備停用某些低使用率、高維護成本的功能時，最困難的通常不是判斷，而是溝通。你需要說服內部團隊，也需要給既有使用者足夠的預告與替代方式。
這時候，可以用 AI 先協助整理一份功能日落計畫。
你可以這樣使用：
我是一名產品經理，目前準備停用系統中 3 個使用率極低，但維護成本很高的邊緣功能。
目前資料如下：
- 功能 A 使用率：[填入數字]，每次版本測試需額外花費 [填入時間]
- 功能 B 使用率：[填入數字]，過去半年產生 [填入客服或 Bug 數量]
- 功能 C 使用率：[填入數字]，目前已有替代流程 [填入替代方案]
業務部門擔心停用後會引發少數客戶反彈。
請套用 奧卡姆剃刀定律 與 變革管理 的原則，協助我擬定一份功能日落計畫，內容包含：
- 給內部團隊的數據說服邏輯
- 給既有客戶的停用預告信綱要
- 如何引導客戶使用替代方案
- 停用前、停用中、停用後的風險控管清單
- 客服常見問答草稿
這類 Prompt 的價值，是幫 PM 先把停用功能這件事，從「突然拿掉」變成「有計畫地轉換」。
但真正的判斷仍然在 PM 身上。因為只有你知道，哪些客戶必須提前溝通，哪些功能雖然低使用率卻有合約義務，哪些替代方案尚未成熟。
◆ 常見誤用提醒。靜悄悄地移除功能，往往會引發更大的信任危機
有些 PM 在決定停用功能後，為了避免麻煩，會選擇低調處理。
例如不公告、不預告，只是在某次版本更新後，把功能入口拿掉，期待沒有人發現。
這通常是一個危險做法。
即使使用率很低，也不代表沒有人依賴它。少數使用者可能把它放進自己的固定流程裡。你突然拿掉，對大多數人可能沒有感覺，但對那一小群人來說，這就是工作流程被中斷。
更嚴重的是，使用者不一定只是抱怨功能消失。他會開始懷疑產品是否可靠。今天這個功能無預警不見，明天是不是別的功能也會消失。如果企業客戶把你的產品放進工作流程裡，這種信任感很重要。
因此，停用功能必須像發布新功能一樣被認真對待。至少要有幾個基本動作：
- 預告期，讓既有使用者有時間調整
- 替代方案，讓使用者知道未來可以怎麼做
- 客服說法，讓第一線能清楚回應
- 資料處理方式，說明舊資料是否保留、是否可匯出
- 正式停用日期，避免使用者一直處在不確定狀態
移除功能不是偷襲使用者，而是管理一次產品能力的轉換。你可以做減法，但不能破壞信任。
◆ 廣三觀點 ＆ PM 現場用語
嗨，我是廣三。
很多 PM 在職涯前幾年，成就感通常來自把功能做出來。做出一個新模組、完成一個新流程、讓版本多了一項可展示的東西，這些都很有成就感，也很容易被看見。
但做到後面會發現，加功能考驗的是執行力，停用功能考驗的才是判斷力。
因為加功能通常比較容易討好所有人。業務覺得客戶被回應，老闆覺得產品有進展，團隊也能看到新產出。停用功能則不同。你必須面對少數使用者的不滿，也必須說服內部團隊，為什麼這個功能不值得再佔用資源。
這也是 PM 成熟度的差別。初階 PM 容易把產品想成願望清單，盡可能滿足更多要求。成熟 PM 則會開始看見，每一個被留下來的功能，都是公司未來要持續支付的成本。
真正的產品主導權，不只在於你能推動哪些新功能，也在於你敢於判斷哪些功能應該退場。
如果要把這一篇轉成專案現場可以使用的說法，我會這樣講：
數據顯示，這個功能目前使用率不到 3%，但每次發布新版本，QA 都必須額外花半天測試相容性。為了把資源集中在能帶動營收與核心體驗的主力功能上，我建議啟動這個邊緣功能的日落計畫，並在下個月正式停止維護。
這句話的重點，不是為了簡化而簡化，而是把產品資源重新放回真正重要的地方。
功能可以增加，也可以退場。真正成熟的產品，不是功能越來越多，而是每一個留下來的功能，都有足夠清楚的存在理由。
在AI時代，AI可以幫助我們思考、提出方法和高效執行，那PM的價值還剩下什麼？
AI可以在很短的時間內給出很多的解決方案，但是決定是哪個方案的，終究是「人」。
而這個「決定方案」的能力，並不是上幾門課就可以養成，是需要時間打磨，經過各種磨難才能累積下來的。
而我希望能做的，就是透過這些文章分享這20年來經歷過的大小事，多多少少可以幫助一些AI時代下的年輕PM。
如果對於這樣的文章覺得很有意思，不妨訂閱我的文章，這樣你就不會錯過任何一篇PM的辛酸血淚。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言