◆ 專案實際情況的真實痛點
在 《#081 客製化的誘惑》，我們談到大客戶客製化的誘惑。當一張高金額合約擺在眼前，客戶同時提出幾個專屬流程、幾張專屬報表、幾項例外規則時，團隊很容易把這些要求視為成交前的必要讓步。短期來看，這是營收；拉長時間來看，這些例外邏輯往往會逐步改寫產品的本質。
到了 #082，我們需要把視角再往上拉。許多客製化失控、Roadmap 失焦、技術債堆積，表面上是需求管理問題，深層來看，常常是公司沒有釐清自己究竟在用哪一種商業模式賺錢。
有些公司對外宣稱自己是 SaaS 產品公司，但 PM 的行事曆裡，排滿的是 A 客戶的客製功能上線日、B 客戶的驗收會議、C 客戶的專屬報表確認。業務銷售的是客戶提出的功能承諾，PM 負責拆解需求與追蹤進度，RD 則不斷完成一項又一項專屬交付。
這樣的團隊通常不缺產出。每天都有會議，每週都有新需求，每個月都有客戶要驗收。年底回頭看，營收可能確實增加了；同時增加的，還有人力成本、溝通成本、維護成本與客服成本。每多接幾個客戶，就需要更多 PM 協調、更多 RD 維護、更多 QA 測試、更多客服回應。毛利率沒有跟著營收改善，團隊也逐漸陷入長期消耗。
這種狀態下，公司名義上在做產品，實際上比較接近外包接案。
許多 PM 的誤區也出現在這裡。他們以為把規格寫清楚、把 Jira Ticket 排好、讓功能準時上線，就是在做產品。這些能力當然重要，但它們主要服務的是「交付」。產品管理還有另一層任務：判斷這件事是否能重複賣給更多客戶，是否能降低未來交付成本，是否能累積為可規模化的價值。
當產品公司長期用專案思維運作，最後通常會得到兩個結果：一個是越來越厚的客製化邏輯，另一個是越來越薄的利潤。
◆ 這篇文章不處理什麼
這篇文章不談 PMP 考試，也不教你如何畫甘特圖、控管風險或管理時程。這些都是專案管理的重要能力，在外包、系統導入、企業整合等場景裡，也有其必要性。
這篇文章也不比較 Scrum 與 Waterfall。開發流程的選擇，會受到團隊成熟度、產品階段、交付模式與客戶關係影響，不存在單一標準答案。
本文處理的是更底層的問題：商業模式的差異。
PM 必須清楚知道，做專案和做產品，賺錢方式完全不同。
做專案，收入來自一次性交付。
做產品，收入來自可重複交付的價值。
這個差異若沒有想清楚，後面的決策都會失準。客製化要不要接、Roadmap 怎麼排、技術債要不要還、團隊人力要不要擴編，都會受到影響。
理解這個差異，PM 才會知道為什麼有些錢不能賺，有些功能不能做，有些客戶即使很大，也不適合讓他決定產品方向。
◆ 框架定義：專案思維 × 產品思維
專案思維和產品思維的差異，不在職稱，也不在開發流程，而在商業邏輯。
專案思維：賣的是時間、勞力與交付承諾
專案思維的核心，是在一段明確期間內，完成一組明確交付。它通常有需求範圍、交付日期、預算限制與驗收標準。
這種模式很常見，也有其合理性。軟體外包、系統導入、活動網站、企業內部工具、客製化系統，大多都仰賴專案模式運作。
專案成功的標準通常包括：
- 是否如期交付
- 是否符合規格
- 是否通過驗收
- 是否控制在預算內
- 客戶是否接受成果
這是一種線性生意。想取得更多收入，通常就要接更多案子；接更多案子，就需要更多人；人變多，管理、溝通、交接與品管成本也會跟著上升。
因此，專案思維本身沒有問題。它適用於範圍明確、預算明確、交期明確的一次性交付。真正的問題，是產品公司以為自己在經營 SaaS，日常運作卻完全採用專案思維。
產品思維：賣的是可複製的價值
產品思維的核心，是找到市場中的共通痛點，設計一套可以重複銷售、重複交付、重複維護的解法。
產品不會因為某一次交付完成就結束。它需要持續迭代、持續驗證，並透過更多使用者、更多客戶、更高留存與更高續約，逐步建立長期價值。
產品成功的標準通常包括：
- 留存率
- 付費轉換
- 續約率
- LTV
- CAC
- 毛利率
- 核心功能使用率
- 可規模化程度
這是一種有機會形成規模化收益的生意。同一套能力若能賣給一千家公司，邊際交付成本就會逐步下降。這也是 SaaS 模式真正有吸引力的原因。
前提是，產品必須保護標準化。只要每一位客戶都需要一套專屬流程，SaaS 的邊際成本優勢就會消失。
兩種思維的差異
| 面向 | 專案思維 | 產品思維 |
|---|---|---|
| 收入來源 | 一次性交付費 | 訂閱、續約、升級、擴張 |
| 成功標準 | 驗收通過 | 留存、變現、可規模化 |
| 需求來源 | 單一客戶指定 | 市場共通痛點 |
| 成本結構 | 人力隨案子增加 | 邊際成本逐步下降 |
| PM 重點 | 範圍、時程、預算 | 價值、取捨、商業結果 |
| 主要風險 | 利潤被工時吃掉 | 初期驗證不足、方向錯誤 |
這張表真正要說明的是：兩種模式都可以成立，但不能混著做。
若公司選擇做專案，就應該用專案報價、專案合約、專案交付與專案驗收來管理。若公司選擇做產品，就必須保護可複製性、共通痛點與長期毛利結構。
最危險的狀況，是用產品價格賣專案服務。客戶以為自己買到 SaaS，團隊卻在背後用外包模式服務他。前期成交容易，後期才發現利潤被維護成本吃掉。
◆ 框架的三個判斷問題
當團隊開始感覺自己越來越像接案公司時，PM 可以用三個問題進行檢查。
Q1：邊際成本測試。接更多客戶，人力會不會等比例增加？
第一個問題是，每增加一批客戶，團隊是否也必須跟著擴張。
如果每多 10 家企業客戶，就需要多 2 位 RD、1 位 PM、1 位客服處理客製化需求，代表交付成本沒有下降。若每一位客戶上線，都要重新討論流程、重新調整報表、重新設計權限、重新安排專屬驗收，這家公司銷售的就不是標準化產品。
產品模式的目標，應該是讓下一個客戶的交付成本逐步下降。
早期導入成本高可以理解。團隊需要建立標準流程、調整產品能力、理解客戶類型。可是經過幾輪之後，如果每一位客戶仍然需要大量人工介入，就必須重新檢查商業模式。
PM 可以問三個問題：
下一個客戶，是否能用更低成本交付？
這次完成的能力，是否能讓下一批客戶更容易上線？
團隊正在累積產品能力，還是在累積客製化責任？
當每一次成交都讓團隊變得更沉重，營收成長未必是好消息。
Q2：需求來源測試。你是在回應單一客戶，還是在理解市場共通痛點？
第二個問題是，需求從哪裡來。
專案思維常見的句型是：客戶 A 說他要這個功能，所以我們要做。產品思維則會追問：這是不是同類型客戶都會遇到的問題。
這個差異非常關鍵。
單一客戶提出需求，通常是從自己的流程、組織、權限與歷史習慣出發。市場共通痛點，則是跨越多個客戶後，仍然反覆出現的問題。
例如：
- 客戶 A 要一張專屬報表，這可能只是他們內部會議格式。
- 若多數企業客戶都需要追蹤相同營運指標，這就可能是產品報表模組應該強化。
- 客戶 B 要特殊簽核流程，這可能只是他們公司流程複雜。
- 若許多企業都需要降低操作風險與留下審核紀錄，這就可能是權限與稽核能力不足。
- 客戶 C 要某個欄位名稱客製化，這可能只是內部習慣。
- 若不同產業都需要可配置欄位，這就可能是產品應該提供設定能力。
PM 的工作，不是把客戶需求原封不動交給 RD，而是理解需求背後想達成的目的，再判斷它是否能轉成標準化能力。
只是照客戶說的做，PM 會變成需求轉發者；能把需求轉成共通解法，才是在做產品。
Q3：AI 工具化測試。你做的工作，是判斷，還是搬運？
第三個問題，是 AI 時代特別需要面對的問題。
AI 會讓許多標準化的專案交付工作快速工具化。初版規格整理、會議紀錄、任務拆解、Jira Ticket 草稿、測試案例初稿、文件摘要，甚至基礎程式碼，都會比過去更容易產出。
這不代表 PM 不重要。真正的變化在於，只做資訊搬運的 PM，價值會快速下降。
PM 要問自己：
我是在整理資訊，還是在做判斷？
我是在追進度，還是在排商業優先順序？
我是在轉述客戶需求，還是在拆解市場共通痛點？
我是在把需求塞進 Sprint，還是在決定哪些需求不該做？
如果你的工作主要是把客戶說的話整理成規格、把規格拆成任務、把任務追到上線，AI 工具會越來越接近這些工作。
如果你的工作是判斷哪一類痛點值得產品化、哪一種需求會破壞 SaaS 模式、哪一個功能能帶來長期留存與變現，那 AI 只是工具，不會取代你的商業判斷。
AI 時代的 PM，價值不在於比誰更會交付，而在於誰更能判斷什麼值得交付。
◆ AI 協作 Prompt。讓 AI 幫你檢查需求清單的專案化純度
當需求清單裡混入太多大客戶客製化、業務指定需求或臨時交付項目時，PM 可以讓 AI 協助做第一輪分類，判斷哪些需求具備產品化潛力，哪些需求正在把團隊帶向專案外包。
你可以這樣使用：
我是一名 SaaS 產品經理，目前團隊下個月準備開發以下 5 個需求。
請協助我用「專案思維 vs. 產品思維」的框架進行檢查。
需求清單如下：
[貼上需求內容與來源，例如：大客戶 A 要求專屬報表、業務要求增加競品功能、客服回報多數企業都需要稽核紀錄]請扮演一位嚴格的 SaaS 產品總監，針對每一項需求分析：
- 這是單一客戶需求，還是市場共通痛點
- 它是否能被設計成標準化產品能力
- 它是否會增加未來交付與維護成本
- 它對留存、續約、升級或新客拓展是否有幫助
- 如果它偏向專案需求，應該如何改寫成具備規模化商業價值的產品功能
最後，請協助我把這 5 個需求分成三類：
- 應該進入產品 Roadmap
- 應該改成專案型報價
- 應該拒絕或暫緩
這類 Prompt 的價值，是協助 PM 先拆出需求的商業屬性。最後判斷仍要回到公司策略。有些專案型需求雖然不適合放進產品，也可能值得用專案報價承接。重點在於不要混淆，不要把專案成本塞進產品維護裡。
◆ 常見誤用提醒。用了 Jira 跑 Sprint，不代表就在做產品
許多公司導入 Jira，開始跑 Sprint，每天站立會議，每兩週發版，就以為自己已經具備產品思維。這是一個常見誤會。
工具不會改變商業模式。Sprint 不會自動帶來產品化，Jira Ticket 也不會讓客製化需求變成標準功能。
如果每個 Sprint 裡塞的，都是單一客戶的專屬願望，團隊只是用敏捷方式在做接案。
如果每次版本更新，目的都是通過某家客戶驗收，團隊只是把專案交付切成兩週一包。
如果 Roadmap 永遠被最新成交的大客戶重排，產品策略其實不存在。
敏捷是執行框架，產品思維是商業判斷。兩者不能混為一談。
真正的產品思維，不看你用什麼工具，而看你的需求選擇是否正在累積可複製價值。若沒有累積，工具越有效率，反而只會讓產品更快變成外包系統。
◆ 廣三觀點 ＆ PM 現場用語
嗨，我是廣三。
台灣很多 PM 的辛苦，來自角色混在一起。名片上寫的是產品經理，實際上每天可能同時在做專案經理、商業分析師、系統分析師、客服窗口，有時候還要兼半個業務。
這不完全是個人問題。許多中小型團隊本來就沒有完整分工，PM 需要補位，也需要承接許多灰色地帶。真正重要的是，PM 心裡要清楚，自己此刻正在處理的是哪一類工作。
你是在做專案交付，還是在經營產品。
你是在滿足單一客戶，還是在累積市場共通能力。
你是在把事情做完，還是在讓產品更容易被重複銷售。
專案經理對交付負責。產品經理對商業結果負責。這句話不是用來區分職位高低，而是提醒 PM，不同角色背後有不同責任。專案交付做得好，客戶會驗收；產品經營做得好，公司才有機會取得規模化收益。
AI 越來越強之後，「把事情做完」的門檻會持續下降。更稀缺的能力，是判斷。判斷哪些需求值得做，哪些錢不能賺，哪些功能會破壞產品結構，哪些痛點可以被設計成可重複交付的能力。
如果要把這一篇轉成專案可以使用的說法，我會這樣講：
團隊們，我們最近花在特定客戶需求上的工時，已經佔了總產能的 70%。如果繼續用專案思維接單，研發資源會被客製化需求消耗，公司也享受不到 SaaS 產品邊際成本遞減的優勢。下個季度，我建議把需求重新分成三類：能賣給整個產業的通用模組，走產品 Roadmap；只服務單一客戶的需求，改成專案報價；無法形成商業價值的項目，暫緩或拒絕。
這句話的重點，不是反對客戶需求，而是讓需求回到正確的商業模式裡。
PM 真正要守住的，不是交付量，而是產品的可規模化價值。這一點守不住，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破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言