◆ 專案實際情況的真實痛點
在 《#080 定價，是最強的產品功能》，我們談到定價。當產品終於有了明確的價格，業務團隊就會開始拿著這套方案去市場上談客戶。這時候，PM 很快會遇到一種非常熟悉、也非常危險的場景。
業務主管興沖沖走進會議室，說某家大型企業對產品很有興趣，願意簽下一張 200 萬的年約。這個消息聽起來很振奮，尤其是在產品剛開始收費、現金流還不穩的階段，這樣的訂單很容易讓整個團隊精神一振。
接著，那句最麻煩的話就會出現。
但是，客戶希望我們補三個小功能。
這三個功能看起來通常都不大。可能是多一個專屬簽核流程、多一個客製報表、多一個特殊權限邏輯，或是讓某些欄位可以依照他們公司內部流程做例外設定。業務會說，只要做完，明天就能簽約。老闆會看著 PM，眼神裡很清楚，這張單不能輕易放掉。
PM 這時候通常會陷入兩難。
如果答應客製化，原本排好的產品 Roadmap 會立刻被打亂。團隊接下來幾個 Sprint，可能都要為這家客戶服務。更麻煩的是，這些功能一旦寫進系統，未來每次改版、測試、維護，都要考慮這家客戶的例外條件。
如果拒絕客製化，業務會覺得 PM 擋財路，老闆也可能覺得 PM 不懂商業現實。畢竟產品再有願景，也要先活下來。眼前有一張 200 萬的年約，誰敢輕易說不要。
這就是 SaaS 與產品型公司在變現初期最常見的陷阱。
一開始只是為了拿下一張大單，做了三個客製化功能。
半年後，另一家客戶又提出五個例外流程。
一年後，系統裡開始到處都是「只有某某客戶使用」的特殊邏輯。
產品表面上營收增加，底層卻逐漸變成接案系統。
這時候公司賣的就不再是可以複製的 SaaS，而是披著產品外皮的專案外包。
◆ 這篇文章不處理什麼
這篇文章不處理如何催 RD 週末加班，把客製化功能趕出來。那通常只是把短期商業壓力轉嫁給研發團隊，問題沒有消失，只是延後出現。
這篇文章也不處理如何寫一封漂亮的拒絕信給客戶。拒絕當然需要技巧，但在拒絕之前，PM 更需要判斷這個需求到底該不該接、能不能轉化、會不會傷到產品本身。
本文真正要處理的是一個更核心的問題：
PM 如何守住產品和專案的界線。
產品的價值，在於同一套能力可以被重複銷售、重複交付、重複維護。
專案的價值，則在於為單一客戶解決特定問題，交付內容通常高度客製。
兩者都可以賺錢，但商業模式不同。
SaaS 公司若用產品的價格，做專案的交付，最後會被維護成本吃掉利潤。
外包公司若用專案的邏輯，假裝自己在做 SaaS，最後會失去產品規模化的優勢。
所以，這篇文章要談的不是「客製化能不能做」，而是「怎麼判斷哪些客製化可以轉成產品能力，哪些客製化會讓產品開始變形」。
◆ 框架定義：邊際成本陷阱 × JTBD
要處理大客戶客製化誘惑，我會用兩個概念來看。
第一個是邊際成本陷阱。
第二個是 JTBD，Jobs-to-be-Done。
邊際成本陷阱：SaaS 最怕的不是客戶少，而是每個客戶都不一樣
SaaS 模式最迷人的地方，是它具備規模化的可能。
同一套產品，賣給第一個客戶要花很大成本；但賣給第十個、第一百個、第一千個客戶時，理想上不需要重新開發一套。這也是 SaaS 毛利結構能成立的原因。
但只要你開始為每一個大客戶硬寫專屬邏輯，邊際成本就會開始失控。
第一個客戶要特殊簽核。
第二個客戶要特殊報表。
第三個客戶要特殊權限。
第四個客戶要特殊資料格式。
每一個需求單看都不大，但全部加總起來，會讓產品底層變成一堆例外條件。這些例外條件不是一次性成本。只要存在，就會持續產生維護、測試、客服、文件與交接成本。
SaaS 的重點不是不服務大客戶，而是不能讓單一客戶的流程，變成整個產品的結構。
JTBD：客戶提出的是規格，真正要解的是任務
JTBD 的核心很簡單。客戶買產品，是為了完成某個工作任務。
客戶說想要一個專屬簽核流程，表面上看是功能需求。
但他真正想完成的任務，可能是確保主管知道這件事。
也可能是留下審核紀錄。
也可能是避免部門私下操作。
也可能是讓稽核時有資料可以追。
如果 PM 只看客戶提出的規格，就會被帶進客製化。
如果 PM 能看見規格背後的任務，就有機會用標準化方式解決。
例如客戶說要加一個專屬簽核流程。
你不一定要改核心架構。
也許可以用現有權限設定搭配通知。
也許可以用 Webhook 觸發 Email。
也許可以用 API 串接到客戶自己的內部系統。
也許可以把它設計成一個通用的「審核規則引擎」，未來所有企業客戶都能用。
PM 的責任，是把客戶的特殊規格翻譯成可擴充的產品能力。
如果翻譯不了，就要回到商業條件談清楚。這是專案，不是標準產品；它需要另外報價、另外排程、另外維護。
◆ 框架的三個判斷問題
當業務帶著大客戶需求回來時，PM 可以先用三個問題判斷，這張單是產品成長的機會，還是 SaaS 模式的陷阱。
Q1：通用性測試。這是他一家的痛，還是整個產業的痛？
第一個問題是，這個需求是否具備通用性。
如果這個功能開發出來，有許多同類型客戶也會需要，甚至願意付費，那它不一定是客製化。它可能是市場提前告訴你，Roadmap 上某個功能應該加速。
例如多層簽核、報表匯出、角色權限、API 串接、資料稽核紀錄，這些在 B2B SaaS 裡很常見。大客戶提出這類需求，不一定是壞事。它可能代表你的產品正在進入更成熟的企業場景。
但如果這個需求只符合某一家公司的內部流程、某一位主管的偏好，或某一套特殊表單格式，那就要很小心。這類需求做完後，很可能只有這家客戶使用，卻要由整個產品團隊長期維護。
PM 可以問：
如果這個功能完成後，我們能不能把它賣給其他同類型客戶？
這個功能是否能成為標準方案的一部分？
它是否反映產業共同需求，還是只反映單一企業習慣？
如果答案偏向後者，這就不是產品功能，而是專案需求。
Q2：邊際維護測試。這段程式碼會不會變成未來的技術債？
第二個問題是，這個客製化需求未來會帶來多少維護成本。
很多客製化在開發當下看起來很便宜。
加一個欄位。
多一個判斷。
寫一段例外流程。
為某個客戶做一個特殊開關。
但幾個月後，它會開始產生新的成本。
每次版本更新，QA 要確認這個特殊流程有沒有壞。
每次調整資料結構，RD 要確認這個客戶的報表是否受到影響。
每次新人接手，都要有人解釋為什麼系統裡有這段特殊邏輯。
每次客戶升級，都可能因為這段例外而產生新問題。
PM 必須問：
這個需求是否需要獨立測試？
未來每次改版是否都要特別確認？
它是否會讓資料結構、權限模型或流程邏輯變得更難維護？
三年後，這張單的收入是否足以支付這些維護成本？
一張 200 萬的年約看起來很漂亮，但如果未來三年吃掉 500 萬研發產能與維運注意力，它就不一定是好生意。
這不是反對大單，而是要把大單後面的長期成本算進來。
Q3：JTBD 替換測試。能不能用現有機制或標準化方式解決？
第三個問題是，客戶提出的規格，能不能用既有能力或標準化方式達成。
這一步非常重要。
因為客戶通常不會用產品架構的語言提出需求，他只會說他想要什麼。
他會說我要一個簽核流程。
我要一個特殊報表。
我要一個專屬欄位。
我要一套不同的權限規則。
PM 要先問，這個規格背後真正的任務是什麼。
客戶要簽核流程，可能是要通知主管。客戶要特殊報表，可能是要每週交差。客戶要專屬欄位，可能是要對應內部分類。客戶要特殊權限，可能是要降低誤操作風險。
知道任務後，才有機會找替代方案。
可以用現有功能組合解決嗎？可以用設定開關解決嗎？可以用 API 或 Webhook 串接解決嗎？可以用匯出資料後由客戶內部系統處理嗎？可以設計成所有企業客戶都能使用的通用模組嗎？
若可以，就不要急著寫專屬邏輯。
因為真正成熟的 PM，不是把客戶說的規格原封不動交給 RD，而是把客戶要完成的任務，轉成不破壞產品結構的解法。
◆ AI 協作 Prompt。讓 AI 幫你把客製化規格翻成標準化解法
當業務帶回一串大客戶需求時，PM 可以用 AI 協助做第一輪拆解。重點不是讓 AI 替你拒絕客戶，而是協助你看見需求背後的 JTBD，並找出不破壞核心架構的替代方案。
你可以這樣使用：
我是一名 SaaS 產品經理，目前面臨一個大客戶提出的客製化需求。
客戶產業：[填入產業]
客戶提出的特殊規格：[填入客戶原始需求]
我們目前的標準功能：[填入既有功能]
我們擔心的風險：[例如會破壞核心架構、增加維護成本、影響 Roadmap]請套用 JTBD（Jobs-to-be-Done） 理論，協助我分析：
- 客戶真正想完成的核心任務是什麼
- 這個需求是單一客戶特殊習慣，還是可能代表產業共通痛點
- 是否能用現有功能組合、設定、API、Webhook、資料匯出或第三方工具來達成
- 若必須開發，如何設計成通用功能，而不是客戶專屬邏輯
- 我可以如何向業務與客戶說明替代方案，避免讓客戶覺得我們只是拒絕客製化
這類 Prompt 的價值，是幫 PM 先把「客戶指定規格」拆成「客戶真正任務」與「可能解法」。
但真正的判斷仍然在 PM 身上。因為只有 PM 知道公司的產品策略、Roadmap、技術架構、客戶價值與商業壓力。AI 可以協助整理選項，不能替你承擔產品方向。
◆ 常見誤用提醒。不要相信「先 Hardcode，以後再重構」
面對大客戶大單時，團隊最容易說出一句很危險的話。
這次先寫死，之後再重構。
這句話聽起來很務實，實際上常常是技術債的起點。因為客戶一旦開始使用這個客製化功能，就會把它放進自己的工作流程裡。當它變成對方日常作業的一部分，後面要移除就會非常困難。
原本以為只是暫時寫死。
後來變成客戶不能沒有。
再後來變成每次改版都要特別測。
最後變成所有人都知道它很麻煩，但沒有人敢動。
更糟的是，這種 Hardcode 通常沒有完整文件，當初寫的人可能已經離開，後來接手的人只知道這段邏輯不能碰。於是，系統裡開始長出一塊又一塊不能碰的區域。
PM 要特別小心，「先做，以後再整理」不是不能說，但必須有明確條件。
至少要有：
- 到期日，這段臨時方案何時必須被移除或轉成標準功能
- 責任人，誰負責後續整理
- 成本紀錄，這次臨時方案未來會增加多少測試與維護成本
- 合約邊界，客戶是否知道這是專案型交付，不屬於標準產品能力
- 版本計畫，後續是否已經排入標準化或替代方案
如果沒有這些條件，所謂「以後再重構」，多半只是把今天的壓力交給未來的團隊。
◆ 廣三觀點 ＆ PM 現場用語
嗨，我是廣三。
我一直覺得，做產品最困難的，不是把東西賣出去，而是知道什麼錢不能賺。
這句話在產品剛開始收費時特別殘酷。因為團隊需要現金流，老闆需要看到營收，業務需要業績，PM 也希望產品被市場肯定。這時候，一張大單帶著客製化需求進來，很難不心動。
但壞的營收，會讓產品付出很高的代價。
短期看起來是大單，長期可能變成 Roadmap 被綁架。
短期看起來是客戶成功，長期可能讓系統長滿例外邏輯。
短期看起來是現金流改善，長期可能讓 SaaS 模式退化成接案模式。
所以，PM 要有能力問一個不討喜的問題：這筆錢，是不是會讓我們離產品化更遠。
這不代表所有客製化都要拒絕。
有些大客戶需求，確實能逼產品變成熟。
有些企業場景，確實能讓 Roadmap 更接近真實市場。
但 PM 要做的，是分辨這個需求到底是產業共通痛點，還是單一客戶的內部習慣。
如果要把這一篇轉成專案可以使用的說法，我會這樣講：
老闆、業務，這張大單的營收確實很重要。但如果我們為它寫進一段專屬邏輯，產品就會從可以賣給一千家企業的 SaaS，退回只能伺服單一客戶的接案系統。我建議先拆解客戶真正要完成的任務，優先用現有功能、API 或顧問導入方式解決。如果最後仍然需要開發，也應該設計成所有同類型客戶都能使用的標準功能，而不是修改核心底層架構。
這句話的重點，不是拒絕大客戶，而是保護產品的可複製性。
SaaS 真正值錢的地方，不在於你能為某一家客戶做到多特殊，而在於你能把某一類客戶的共同問題，用同一套產品反覆解決。
在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破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言