1／沒人想碰，是因為不痛不癢又沒人看
每個公司都有那種「不是核心產品，但又不能沒有」的系統。像是內部報表系統、金流稽核系統、客服介面……出了問題全公司都會罵，平常沒事卻沒人想維護。
工程師覺得維護沒成就感、改一點就可能踩雷；主管覺得沒有 KPI 貢獻不想投資；使用者報錯也常常說不清楚到底怎麼壞的。這種系統就這樣卡在半廢不活的狀態。
2／PM 可以做什麼？不是重做，是幫它重新「被看見」
我接手過一套內部系統，第一件事不是重寫，也不是催人修 bug，而是「讓它重新有價值感」：- 診斷現況：針對系統現有功能、使用者痛點、歷史維修紀錄做快速盤點，整理成 Miro 或 Notion 圖示化呈現。
- 找出影響面：將「不好用」具體拆成「影響哪些流程、浪費多少人力、錯誤率有多高」，讓主管可以從商業角度理解。
- 聚焦關鍵角色：不是要滿足所有人，而是要先找出關鍵使用者（通常是用最多、出錯最多、權限最高那群人），讓優化能有立即回饋。
3／導入「內部產品管理」的思維
即便是內部系統，也應該當成產品看待。
我用下面這個迷你 framework 協助團隊釐清優化方向：
- 目標（Goal）：系統存在的核心目的是什麼？效率？合規？紀錄？
- 用戶（User）：誰每天在用這套系統？角色職能是什麼？流程習慣是什麼？
- 痛點（Pain）：目前他們在操作上有哪些具體困難？（從工時、操作複雜度、錯誤率等角度盤點）
- 優先級（Priority）：有哪些問題其實可以 1–2 週就解決？有沒有 quick win？
把這些答案整理成一頁簡報，回報給主管，馬上讓「這系統不是垃圾」的觀感被翻轉。
4／用「技術債整理卡」幫工程師下手有感
另一個推進的關鍵是：讓工程師知道該從哪裡修起。
我會設計一張技術債評估卡片，內容包含：
- 影響功能：這段 code 影響哪些模組？
- 修改風險：是不是改了 A，B 也會壞？
- 維護頻率：這半年進這段 code 的次數？
- 回報頻率：這段功能被抱怨的次數？
用這種「理性 + 可量化 + 降焦慮」的方式，幫助團隊從看似一團混亂的 legacy 中挖出可以開始的切點。
5／讓冷門系統也能溫暖地活下來
PM 的價值，很多時候不是在打造新功能，而是讓那些「看似沒人要理的老系統」重新融入公司運作，回到能持續改善的軌道。
我們不一定要讓它變成明星產品，但可以讓它重新有生命、有邏輯、有文件，成為團隊信任的工具，而不是每個人都想逃避的負擔。
