產品經理面試：如何決定是否下線一項功能？

題幹與適用情境

你負責一款 B2B 數據分析 SaaS。舊版「定時 PDF 郵件」功能只有 3% 的活躍工作區每月使用，但實際使用者包括 14 家企業客戶，合計占公司 ARR 的 18%。其中 9 家將在未來 6 個月續約。這項功能依賴舊渲染器，每季約耗費 3 人月維護，並產生 22% 的報表類客服工單。

公司已上線新的儀表板訂閱功能，可以覆蓋舊功能約 80% 的工作流程，但暫不支援自訂品牌與附件寄送。請決定應繼續 維護、重新投入、停止新增用戶，或最終下線舊功能，並說明需要驗證的數據、遷移方案、溝通節奏、成功指標與暫停條件。

題目中的數字都是面試假設，不是產業基準。3% 的使用率不能直接推出「應該刪除」，18% 的 ARR 也不能直接推出 「永遠保留」。候選人要辨識低採用率背後的依賴強度，比較保留與遷移的完整成本，並把一次不可逆的刪除拆成可以 驗證、可以暫停的決策階段。

2026 年的產品經理面試題庫仍會直接詢問候選人應改善哪個產品、取消哪個產品；產品面試評分資料也直接要求說明如何 依據數據下線功能、區分低使用與小眾高價值、處理阻力並降低用戶中斷。本題歸類為 product，因為核心考察能力是 產品組合取捨、客戶分群、生命週期決策與跨職能執行。

面試官考察點

第一，是否會先檢查數據定義。強回答會追問「3%」的分母是所有活躍工作區、具備該方案權限的工作區，還是已完成 設定的工作區；也會檢查郵件是否透過 API、管理員代發或其他未被埋點涵蓋的路徑觸發。錯誤分母或漏數會讓整個結論 失效。

第二，能否區分採用率與依賴價值。每月只寄送一次的合規報表可能頻率很低，卻是客戶完成稽核或董事會報告的關鍵 步驟。需要按工作流程關鍵性、替代難度、帳戶價值、合約承諾與續約時間分群，不能只看平均使用次數。

第三，是否比較多個真實選項。答案不應只有「保留」或「刪除」：

• 繼續維護現況；
• 投資修復或重做舊功能；
• 進入維護模式，停止新客戶啟用但繼續服務現有依賴者；
• 透過遷移橋接補齊替代方案缺口；
• 分階段下線，並為極少數客戶設定有期限的例外。

第四，是否把遷移當成產品交付。宣布日期不等於完成遷移。高品質回答會定義替代方案的能力差距、客戶負責人、數據 匯出、遷移工具、通知確認、支援路徑、分批關閉與回復門檻。

第五，能否處理商業與產品完整性的衝突。14 家客戶占 18% ARR，表示立即強制關閉風險很高；但它每年耗費約 12 人月維護，還阻礙新報表架構收斂。候選人需要提出目前建議與改變建議的證據條件，不能用一句「客戶重要」或 「技術債太高」結束。

回答前需要釐清的問題

• 3% 的分母與埋點可靠嗎？ 若只統計 UI 點擊，卻漏掉排程、API 或管理員設定，必須先修正數據再決策。
• 客戶用它完成什麼任務？ 合規封存、對外客戶交付、內部週報與偶爾試用的中斷成本完全不同。
• 14 家企業客戶的依賴深度如何？ 需要區分真實持續使用者、偶爾使用者與已可遷移但尚未行動者。
• 18% ARR 是相關收入還是可歸因收入？ 客戶使用該功能不代表全部合約價值都由它驅動，要確認取消意向、續約

風險與合約承諾。

• 替代方案缺少的 20% 是什麼？ 若自訂品牌與附件寄送是關鍵合約要求，80% 覆蓋不能支援下線；若能用短期

遷移橋接解決，結論會改變。

• 舊功能的完整成本是什麼？ 除 12 人月年度維護外，還要看事故、客服、安全、無障礙、基礎設施與阻塞產品

路線圖的機會成本。

• 是否存在安全、合規或數據完整性風險？ 嚴重風險可能要求加速關閉；一般維護成本則不能跳過合理通知與遷移。
• 合約與客戶通知有什麼限制？ 續約、服務條款與採購承諾會決定公告日期、例外與最終關閉節奏。

30 秒回答框架

「我不會根據 3% 使用率直接刪除，因為使用者包含占 18% ARR 的企業客戶，而且替代方案還有關鍵能力缺口。我會 先驗證埋點與分母，再按工作流程關鍵性、遷移難度、合約與續約風險對 14 家客戶分群。

依目前資訊，我會立即停止向新客戶銷售與啟用舊功能，讓它進入維護模式；同時用約 4 週的依賴盤點與遷移試辦， 確認品牌與附件缺口能否補齊。只有替代方案通過關鍵工作流程、數據匯出、可靠性與合約審查，而且高依賴客戶達到 預先定義的遷移門檻後，我才會宣布最終下線日期。

執行上會為 9 家近期續約客戶安排一對一方案，分批遷移並設定暫停門檻。若關鍵缺口無法合理補齊，或預期流失與 遷移成本高於可釋放的維護與機會成本，我會保留受限版本或重新評估重做，而不會按原日期強制關閉。」

分步驟深入解答

第一步：把「低使用」拆成可驗證的依賴。

先建立帳戶層級清單，而不是只看一張總體儀表板：

也要訪談未採用的客戶，確認原因是沒有需求、功能難發現、設定失敗，還是體驗不足。若低採用來自可修正的發現或 可靠性問題，而用戶需求仍強，重做可能比下線更合理。

第二步：定義硬門檻，再比較選項。

最終關閉前至少要通過以下門檻：

1. 使用數據涵蓋所有真實觸發路徑，沒有明顯漏數。
2. 合約、法務、合規與數據保留要求已審查。
3. 高依賴工作流程有可接受的替代方案或經客戶確認的遷移路徑。
4. 用戶可以匯出所需歷史數據，且團隊實際演練過匯出與復原。
5. 替代方案的可靠性、權限、無障礙與支援能力達到正式環境要求。
6. 每個受影響企業客戶都有負責人、狀態與升級路徑。

安全、嚴重可靠性或數據完整性問題可以縮短時間線，但仍要清楚說明原因與遷移辦法。某些公開 API 政策會規定明確 通知期；例如 Atlassian 對公開雲端 REST API 的一般規則是至少保留原形式 6 個月，並對關鍵安全、可靠性或數據 完整性問題設定例外。這是具體政策範例，不是所有產品功能都必須照搬的統一期限。

第三步：比較維護、重做、維護模式與下線。

AWS 的公開生命週期定義提供了有用語言：維護階段停止新增與強化，但繼續支援現有用戶；sunset 階段要求現有用戶 遷往替代方案，並有明確結束日期；最終關閉後不再提供服務。面試回答可以借用這個階段模型，避免把「宣布棄用」與 「立即刪除」混成一個動作。

依題目目前證據，建議先進入維護模式，再以遷移成功為條件推進下線。原因是 3% 的總體採用率與每年約 12 人月維護 支援減少長期投入，但 18% ARR、9 家近期續約客戶與 20% 能力缺口使立即關閉不可接受。

第四步：用可逆動作驗證結論。

在宣布最終日期前先做四件事：

1. 停止新客戶啟用，移除銷售材料中的舊功能承諾，避免依賴繼續成長。
2. 讓 14 家企業客戶完成工作流程核對，標記品牌、附件、數據保留與權限缺口。
3. 選擇不同依賴程度的客戶做遷移試辦，實際跑通設定、歷史數據匯出、寄送與客服流程。
4. 在專案啟動前寫下遷移門檻與暫停條件，防止團隊為了既定日期忽略失敗證據。

試辦不只測「新頁面能開啟」。需要對照同一任務檢查寄送成功、收件人體驗、附件與品牌正確性、權限、稽核紀錄、 失敗重試、客服工單與完成時間。若替代方案只覆蓋簡單客戶，80% 的說法仍未被驗證。

第五步：給每個群體不同的遷移路徑。

可以把帳戶分成四組：

• 已無真實使用：停止顯示，保留公告與數據匯出入口；
• 低依賴且替代完整：提供自助遷移與提醒；
• 高依賴但缺口可橋接：由客戶成功與產品團隊共同遷移；
• 受合約或關鍵缺口阻塞：進入有期限例外，明確補齊、續約或退場決策日期。

公告需要說明發生什麼、為什麼、最後使用日期、替代方案、遷移步驟、數據取得方式與支援管道。高價值客戶不能只收到 群發郵件；負責人要確認客戶已理解影響，並記錄是否接受遷移計畫。若功能包含 API 或自動化入口，也應在介面回應、 變更紀錄與開發者文件中提供可偵測的棄用與結束資訊。

第六步：設定階段門與暫停條件。

一個可執行的節奏是：

暫停條件包括：關鍵工作流程無法完成、數據匯出不完整、替代方案可靠性不合格、客服負擔明顯超出計畫、客戶取消 意向超出預設風險邊界，或出現未解決的合約與合規問題。暫停不等於無限期保留；團隊要重新選擇補齊缺口、延長某一 批次、提供有期限例外，或改變最終建議。

第七步：比較完整經濟性。

保留側至少包含每年約 12 人月維護、22% 報表類客服工單、舊渲染器的基礎設施與事故風險，以及工程團隊無法投入 新報表架構的機會成本。下線側包含替代能力開發、遷移工具、客戶成功與客服投入、短期雙軌運行，以及可能的折扣、 流失或合約補償。

18% ARR 不能全部記作「下線損失」。需要估計哪些客戶會因缺口取消、哪些會遷移、哪些只需要協助。也不能把 12 人月全部記作「下線收益」，因為新方案仍有維護成本。用情境區間比較：

• 關鍵缺口能否低成本補齊；
• 多少相關收入真正存在流失風險；
• 雙軌運行持續多久；
• 釋放的工程能力將投入什麼更高價值工作；
• 有期限例外是否會讓舊架構成本無法下降。

第八步：用遷移結果驗收，不用關閉日期驗收。

主指標應圍繞依賴工作流程遷移完成率，而不是公告寄送率。可以追蹤：

• 真實依賴帳戶與排程任務的遷移完成率；
• 新方案上的寄送成功率與關鍵任務完成率；
• 舊功能剩餘活躍使用與未確認帳戶；
• 報表類客服工單、遷移求助與升級事件；
• 受影響客戶的續約、取消意向與合約風險；
• 歷史數據匯出成功與數據保留完成情況；
• 舊架構事故、維護人月與最終釋放的工程能力。

最終關閉後還要刪除背景任務、入口、權限、功能旗標、文件、銷售承諾、客服手冊、監控告警與不再需要的數據副本， 並依既定保留規則處理歷史數據。只隱藏按鈕卻保留全部運行責任，沒有實現下線的主要價值。

高品質示範回答

「我會先挑戰 3% 這個數字。分母應該是具備權限並有相關報表需求的工作區，也要確認 UI 之外的排程與 API 觸發 有沒有漏數。接著我會把 14 家企業客戶按工作流程關鍵性、替代難度、合約承諾與續約日期分群，因為每月一次的 合規報表頻率低，但可能非常關鍵。

依目前資訊，我不會立即關閉。這項功能占用每季 3 人月並產生 22% 的報表類工單，長期保留有明顯成本；但使用者 占 18% ARR，9 家即將續約，而且替代方案缺少品牌與附件能力。我的建議是先進入維護模式：停止新客戶啟用與 銷售承諾，只修復嚴重問題，同時啟動依賴盤點與遷移試辦。

我會先確認品牌與附件是否為合約或關鍵任務要求，再讓不同依賴程度的客戶實際遷移。試辦要驗證寄送、權限、稽核、 失敗復原、歷史數據匯出與客服流程，而不只是功能清單。每個企業客戶都有負責人，近期續約客戶採一對一方案。

最終日期只會在替代方案通過關鍵工作流程、合約與合規審查完成、數據可匯出，而且高依賴客戶達到預設遷移門檻後 公布。執行時先遷移低風險帳戶，再處理企業帳戶；出現關鍵任務失敗、匯出不完整、可靠性問題或不可接受的取消風險 時暫停下一批。

經濟上我會比較保留舊架構的 12 人月年度維護、客服、事故與路線圖機會成本，和補齊替代方案、遷移、雙軌運行與 潛在流失成本。18% ARR 不會全部流失，12 人月也不會全部變成淨收益，因此會用區間與客戶證據更新結論。

如果關鍵缺口可以合理橋接，我會推進分階段下線；如果缺口是無法替代的合約要求，或遷移造成的預期損失持續高於 釋放價值，我會保留受限版本或重新評估重做。關閉後還要清理任務、程式碼、文件、銷售材料、告警與數據責任，確保 團隊真的退出舊架構。」

常見錯誤

• 看到 3% 就決定刪除 → 分母、頻率與工作流程關鍵性可能被誤讀 → 先驗證數據，再按依賴強度分群。
• 看到 18% ARR 就永久保留 → 相關收入不等於可歸因收入，且技術與機會成本會持續累積 → **驗證真實取消風險

並比較完整經濟性。**

• 把 80% 覆蓋當成可以遷移 → 缺少的 20% 可能正是合約或合規阻塞項 → **逐個工作流程驗證，不用功能數量

代替。**

• 只給保留或刪除兩個選項 → 忽略維護模式、遷移橋接與有期限例外 → 把不可逆刪除拆成階段決策。
• 先公布日期再設計替代方案 → 團隊會被日期綁架並忽略失敗證據 → 先定義門檻、試辦與暫停條件。
• 給所有客戶寄同一封郵件 → 高依賴企業客戶需要確認影響、負責人與升級路徑 → 按依賴與商業暴露設計溝通。
• 用公告寄送率衡量成功 → 客戶可能收到消息卻沒有完成遷移 → 追蹤工作流程遷移、任務成功與護欄指標。
• 關閉 UI 後停止專案 → 背景任務、程式碼、數據、文件與銷售承諾仍會產生責任 → 完成全生命週期清理與復盤。

追問及應對

追問 1：最大客戶表示下線就會取消合約，怎麼辦？

先驗證這是明確的取消條件、談判立場，還是對遷移風險的擔憂。拆出客戶真正無法替代的工作流程、合約條款與收入 暴露，再比較補齊缺口、提供遷移服務、有期限例外或保留受限版本的成本。單一大客戶可以改變節奏，但不能自動取得 無限期例外；任何例外都要有價格、支援邊界、負責人與結束條件。

追問 2：舊渲染器出現嚴重安全漏洞，還能按原遷移節奏嗎？

不能機械沿用原時間線。安全負責人先評估能否隔離、修補或限制暴露；若風險無法接受，應停止新任務、縮小可用範圍， 甚至加速關閉。同時仍要提供數據匯出、替代流程與明確說明，並記錄為何縮短通知期。緊急風險改變節奏，不會消除 客戶遷移責任。

追問 3：替代方案長期只能覆蓋 80%，應該放棄下線嗎？

先判斷缺口對應多少真實依賴工作流程，以及補齊方式是否會形成另一套舊系統。若品牌與附件可以透過窄遷移層解決， 仍可繼續下線；若缺口涉及無法替代的合規或核心交付，建議會轉向保留受限版本、重做關鍵能力或選擇其他替代方案。 「80%」本身不能決定方向。

追問 4：使用數據不可靠，但工程團隊急著刪除舊程式碼，怎麼推進？

先停止擴大使用面，並用日誌、排程、API 呼叫、客服紀錄、客戶成功資訊與帳務帳戶交叉核對。可以在低風險帳戶上 做可復原的隱藏或遷移試辦，但不能在依賴未知時永久刪除。若短期仍無法建立可信清單，應把數據不確定性視為阻塞項， 而不是把「沒看到使用」當成「沒人使用」。

追問 5：有兩個客戶要求永久保留舊功能，是否建立專屬版本？

比較專屬版本帶來的收入與長期分支成本，包括安全修復、基礎設施、值班、測試與人員知識。優先提供標準替代、付費 遷移或有期限例外。只有合約價值與策略意義能持續覆蓋獨立運行責任，而且公司願意把它當成正式產品承諾時，才考慮 長期專屬版本；不能把臨時例外悄悄變成無期限遺留系統。