概念地圖・產品退場計畫
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
產品退場計畫：兩條曲線交叉時，該啟動退場
客服信箱裡連續二十天冒出同一個問題：那個舊版本還修不修。沒有人回答——因為沒有人被指派去回答。公司裡沒有任何一份文件，寫著它什麼時候該收。產品退場計畫（Product Sunset and End-of-Life）畫的就是那份缺席的文件：一條從宣布停售、停止新客、停止更新走到終止支援的時間軸，每個節點都標清楚該先通知誰、要留多長緩衝；底下再疊兩條會交叉的曲線——剩餘營收一路往下，維持支援的單位成本一路往上。交叉之後，這個產品開始倒貼。
四個節點，各要給多長緩衝
先把圖上那條時間軸攤成文字。每一列都要回答三件事：這一步實際切掉什麼、誰會第一個被影響、要留多久才算有交代。
| 節點 | 這一步實際切掉什麼 | 該先通知誰 | 緩衝區間（示意） |
|---|---|---|---|
| 宣布停售 | 對外承認這個產品有終點，價目表與提案簡報同步撤下 | 通路、業務、客服，順序排在對外公告之前 | 數週到數月，愈是專案型銷售愈長 |
| 停止新客 | 關掉購買與新約入口，裡面只剩既有客戶 | 潛在買家、官網、還在跑的行銷素材 | 數月，等在途商機走完 |
| 停止更新 | 功能凍結，只留資安與致命錯誤的修補 | 付費用戶、整合商、寫進合約的服務水準條款 | 數月到一年，看合約怎麼寫 |
| 終止支援 | 伺服器、授權驗證、客服窗口一起關閉 | 企業合約客戶、主管機關、資料要搬走的人 | 一年以上也常見，而且多半不由你決定 |
四列讀下來會浮出一件事：緩衝長度多半由合約與法規決定，你真正能排的只有順序——先讓誰知道、後讓誰知道。順序排錯的代價，通常比日期抓錯還貴：業務在客戶那裡聽到自家產品要收，信任就從那一刻開始漏。
該不該按下那個公告，兩條曲線說了算
一、剩餘營收要先扣掉「只是還沒被搬走」的那部分。帳上還在收的錢，不等於這個產品還在賺。有一種營收是客戶自己都忘了取消的訂閱，有一種是綁在整包大合約裡、單獨拆出來根本站不住的附加項。把這兩塊標出來，往下那條線通常會比你以為的更陡。自問：如果明天就讓客戶重新選一次，這筆錢還會留下來嗎？
二、維持支援的成本，要把被綁住的人算進去。直接成本很好抓——伺服器、授權、客服工時。真正貴的是那位「只有他懂那套舊架構」的工程師：他每個月被抓去救火的時間，不會出現在任何一張成本報表上，卻等於新產品少了一個人。把那段時間換算成人力成本填進去，往上那條線才是真的。自問：這個產品每個月綁住幾個人？他們原本該在做什麼？
三、交叉點只是訊號，日期還要另外排。兩條線交會的那一刻，只代表這個產品從此開始倒貼——它要觸發的是「啟動退場程序」這個動作，離「明天關機」還很遠。從訊號亮起到終止支援，中間還隔著宣布停售、停止新客、停止更新三個節點，動輒好幾個月。把交叉點直接當成關機日，是這張圖最常被誤讀的地方。自問：訊號亮起之後，誰負責把那四個節點的日期排出來？
四、緩衝長度先問合約與法規，再問自己。純免費的工具、有付費用戶的訂閱、簽了年約的企業客戶、受主管機關管的服務——同樣四個節點，四種完全不同的緩衝。企業合約可能白紙黑字寫著支援年限，特許行業可能規定公告要提前多久、未消耗的預付款怎麼處理。這些是外部給你的邊界，先讀完再排時間表。自問：有沒有一份合約或法規，已經替某個節點定好最短緩衝了？
一家遊戲代理商的停止營運公告，把時間軸走一遍
- 交叉點浮出來：一家代理海外手遊的台灣發行商，某款上線四年的遊戲月流水只剩巔峰的一小截，付費玩家縮到幾百人。營運與客服固定要留兩個人、外加工程師每個月處理原廠版本更新的相容問題。帳面還沒虧，人力早就倒貼
- 宣布停止營運：公告發出的同一天，儲值入口關閉——這是原廠與主管機關雙邊的要求。內部順序是先通知客服與社群小編，備妥問答稿，再對外貼公告。客服比玩家早一步知道
- 停止新客：從各大 App 商店下架、停掉所有買量與網紅合作。這一步幾乎沒有爭議，因為新玩家進來只會多一個要退費的人。最乾淨的一刀
- 停止更新：改版凍結，只留登入與金流的修補。爭議在這裡爆開：官方活動月曆已經排到下一季，玩家把那張月曆當成承諾。凍結的是版本，斷掉的是預期
- 終止支援：伺服器關閉、客服窗口結束。線上遊戲的定型化契約對停止營運本來就有公告期與未使用點數處理的要求，這段緩衝不是發行商自己抓的。法規給的期限，比內部想收的日子長得多
這條線走完，真正值得記住的接縫在第二步與第四步之間。停止營運的公告一發，玩家最先問的往往是「我儲進去的錢怎麼辦」——那筆錢在會計上是負債，在玩家心裡是資產。發行商如果只排了關機日、沒排退費與資料保存的窗口，公告發得再早都會被當成落跑。另一個接縫是那位工程師：他被綁在這款遊戲上的四年裡，公司少開了幾個新代理案，這筆帳從來沒人算過，卻是交叉點真正的斜率來源。退場公告難按，多半卡在沒有人願意承認那個人早就該被放走。以上為說明結構用的示意情境，僅供理解框架之用。
這條時間軸什麼時候會騙你
- 成本那條線最容易被畫得太平。直接成本有帳可查，機會成本沒有。工程師被抓去修舊系統的半天、產品經理每個月開的那場沒有結論的維運會、業務被問到舊產品時支支吾吾的那五分鐘——這些都不會進成本中心。於是曲線畫出來很和平，交叉點被推遲到一個不存在的未來，而真實世界裡它半年前就交叉了。畫的時候寧可把人力成本估高一點，錯的方向至少是安全的。
- 剩餘營收裡可能藏著別人的合約。一個看起來只剩三十萬年營收的舊產品，拆開來發現有二十萬來自同一家企業客戶，而那家客戶的新產品年約是兩百萬——舊產品是那份大約談判時被塞進去的甜頭。單獨看這條曲線，它早該退場；放回客戶關係裡看，退場等於在續約桌上遞刀給對方。曲線衡量得了產品，衡量不了關係。
- 公告本身會讓曲線立刻變形。這張圖的兩條線都假設「什麼都不做」的走勢，但按下公告的那一刻，走勢就換了一條。營收可能斷崖式歸零，也可能反過來，冒出一波把庫存掃光、把年約續到底的搶購。同時成本那條會先跳高——遷移支援、退費作業、客服暴量，退場期的單位成本往往比維持期還貴。用交叉點決定要不要啟動可以，用它去預測啟動之後會怎樣，不行。
痛點視角：那份沒人想按的公告
退場計畫最難的部分，不是關掉那個產品。
是承認當年那個判斷已經走完了。公司裡幾乎每個舊產品都有一位「爸爸」——他當年扛過它、靠它升過職，公告等於在同事面前替自己的作品寫訃聞。所以那份文件沒人寫，那個問題沒人回，客服信箱裡的同一句話問到第二十天還懸著。這張圖畫得出兩條曲線什麼時候交叉，畫不出那位主管願不願意在會議上第一個開口。P.A.I.N. 裡的痛，在這裡是雙份的：外面有一群還在用的客戶怕自己被丟下，裡面有一個人怕自己被否定——而只要裡面那份痛沒被處理，時間軸永遠排不出來。真正把退場推動起來的，往往是有人把「誰在等它下架」這句話問出口。等的人一被指認出來，那份公告就有了收件人，也就有了非發不可的理由。這週找出公司裡最老的那個產品，走去問問看：誰在等它下架。
關於產品退場，常被問到的幾件事
產品退場要提前多久公告？
沒有一體適用的天數，先看三件事：合約怎麼寫、有沒有主管機關管、客戶要花多久搬家。純免費工具的緩衝可以短到數週；簽了年約的企業軟體，合約裡的支援年限就是下限；受監理的服務則由法規決定公告期與善後義務。實務上比較安全的做法，是先算出「最慢的那個客戶把資料搬走要多久」，再往上加一段，那才是終止支援日該擺的位置。排日期的起點在最慢那個客戶的處境，而你的行事曆只能跟著走。
停止更新和終止支援有什麼不一樣？
停止更新是功能凍結：不再有新功能、不再跟進新機型或新版作業系統，但資安漏洞與致命錯誤還修，客服也還在。終止支援才是真的斷線：伺服器關閉、授權驗證失效、客服窗口收掉，出事沒有人接。兩者中間那段常被低估——對客戶而言，停止更新那天產品就開始老化，第三方整合一個一個失效，體感上比公告更痛。把這兩個節點寫成同一件事，是退場計畫最常見的簡化錯誤。
只剩少數客戶還在用，可以直接關掉嗎？
人數少不代表關掉便宜。要先問那少數人是誰：如果他們是營收貢獻很小但在業界很有聲量的老客戶，關掉的成本會以口碑的形式回來；如果他們的資料鎖在你的格式裡搬不走，那就不只是商業問題。比較務實的做法是替這群人準備一條專屬出口——搬遷工具、匯出格式、一段人工協助期，甚至一份轉去新產品的優惠。人少反而讓客製化的送別變得可行，這是大規模退場沒有的餘裕。
怎麼判斷該退場的是整個產品，還是某個舊版本？
看維持成本集中在哪裡。如果九成的支援工時都花在舊版本的相容問題上，而新版本本身健康，那要退的是版本，時間軸照樣走四個節點、只是範圍縮小。如果連新版本的營收都撐不起它自己的維護，那才是整個產品的問題。分不清楚時有個粗略的檢查：把舊版本假想成已經關閉，剩下的部分還值不值得投人？答得出來就知道該切哪一刀。
這條時間軸解決的是「什麼時候該收」，如果你的問題還停在「它現在走到哪」，可以先看產品生命週期那張圖；至於那位被舊系統綁住的工程師，他每個月付出去的代價，技術債的利息算的是同一筆帳的另一半。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。