做SaaS產品，應該要像醫生一樣

在SaaS產品管理的世界裡，產品經理常常需要面對複雜的客戶需求和多變的市場環境。本文將透過類比醫生的工作，深入探討SaaS產品經理如何在有限的資源和條件下，像醫生一樣“有時去治癒，常常是幫助，總是去安慰”。

———— / BEGIN / ————

做SaaS產品就像做醫生，這是我做三年SaaS產品經理的最大感受。

“To cure sometimes, to relieve often, to comfort always.”

翻譯過來就是：“有時去治癒，常常是幫助，總是去安慰。”

這句話源自美國醫生愛德華·利文斯頓·特魯多（Edward Livingston Trudeau，1848-1915）的墓誌銘。

具體來說就是：

“有時去治癒” ：主要表達了醫學的侷限性。醫生並不能治癒所有疾病，有些疾病即使經過治療也無法完全康復。因此，“治癒”是一個偶然的結果，需要豐富的科學知識和實踐積累，但並非醫生工作的常態；
“常常是幫助” ：醫生的主要任務是透過問診、查體、藥物、手術等方式幫助患者緩解病情。這種幫助包括對患者身體和心理的支援，使患者能夠更好地面對疾病；
“總是去安慰” ：安慰是醫生工作中不可或缺的一部分。醫生不僅需要關注患者的生理健康，還要關心患者的心理狀態，透過語言和行動給予患者溫暖和支援，幫助他們建立信心，減輕病痛帶來的心理負擔。

第一次聽到這句話，是幾年前在一個職場類綜藝節目中，陶勇醫生所分享。

當時，作為一名旁觀者，對他的經歷產生了些許感慨，以及感受到了一名醫生的無奈，卻不像如今這般地感同身受。

時隔多年，它就像一個迴旋鏢，迴旋到了自己。

為什麼這麼說？

理想一天 VS 現實一天

做SaaS產品經理前，期望專注於解決“大問題”，期望專注於產品經理的本職工作不被打擾，期望解決所有客戶的問題。

理想一天的工作狀態是：

09:50：到公司，洗個杯子，泡杯茶或咖啡；
10:05：開啟電腦，清晰羅列今天的關鍵事項；
10:10：開始設計產品原型，一直無人打擾至午飯；
12:00：跟小夥伴一起去樓下商場，吃個便餐；
12:40：飯後跟小夥伴在公司附近的公園溜達一圈；
13:10：回到工位午睡；
13:55：醒來後，洗把臉繼續開始工作，順便更換一杯茶；
14:05：基於原型寫需求文件，一直無打擾至晚飯前；
18:00：定個外賣，吃完飯後，自行樓下溜達20分鐘，呼吸下新鮮空氣，順便聽一聽喜歡的播客；
19:00：回到工位，把剩餘文件寫完；
20:15：關機，洗刷茶杯回家。

真實一天的工作狀態是：

09:50：到公司，沒時間洗杯子
10:00：第一個會議：跟客戶A開會溝通疑難問題的解決方案或二開定製需求；
11:00：會議結束，跟客戶溝通不順暢，因雙方對需求的理解差異以及期望值的差異（甚至被客戶質疑專業性），緊急整理新的解決方案；
11:05：抽空洗個杯子，泡杯茶，開啟釘釘後，4-5個人在找你。或問產品邏輯，或問需求排期，或問昨天說的二開需求的方案反饋等；
11:30：回覆完所有使用者的資訊後，終於有個片刻，可以重新梳理會議內容
12:00：午飯時間
13:00：午飯回來，看10分鐘騰訊體育新聞
13:30：醒來，繼續梳理上午客戶A的解決方案；
14:00：跟另一個客戶B約定的會議時間到，又是一個新客戶的疑難問題；
15:30：經過1個多小時溝通，無法有效排期，產生新待確認的事項，必須下班前給客戶一個最終反饋；
16:00：客成找你溝通一個客戶馬上續費，卻卡在了某些需求上，看是否可排期；
16:10：跟客成溝通完畢，群裡訊息有研發同學在@你，研發中的專案，有個規則描述不清楚，需要補充；
16:30：確認完規則後，插空繼續梳理客戶A的解決方案。遇到卡點，只能留作待辦，預約研發同學時間，屆時一起溝通下技術實現方案與工作量；
17:00：客服發過來一個問題連結，問你是否可排期解決？研發同學無法決策
17:15：確認完問題後，回覆客服按新需求提至需求池，後續排期最佳化；
18:00：終於梳理完了客戶A的解決方案，讓客成預約客戶明天二次確認的時間；
18:30：晚餐。同時，收到了客戶C的會議邀約，明天下午10:00溝通需求，實施階段卡住了，可能影響尾款回收；
19:00：開始梳理客戶B的疑難問題；
20:00：梳理完了，同步客成解決方案，讓其轉述給客戶B；
20:30：下班時間到了，今天計劃要做的調研、原型、方案，依然是待辦狀態，默默把它們挪到明天；

這就是真實的SaaS產品經理常態化的一天，跟客戶溝通需求和解決方案是“主要工作”，而畫原型、寫文件是“附帶工作”。

如果用一個“嚴謹點”的數字化表達：“主要工作”可能佔據60%以上時間精力，“附帶工作”佔30%，而其他工作（如專案管理/需求管理等）佔剩餘的10%。

每天馬不停蹄，卻非如沐春風。

像個醫生一樣做SaaS產品

當面對客戶問題時，“有時去治癒”是常態，“常常是幫助”也是常態，“總是去安慰”更是常態。

“有時去治癒” ：SaaS產品是標準化產品，註定瞭解決方案的侷限性。比如客戶問題有現成解決方案或排期時，對產品經理與客戶是最理想的狀態，而它卻只是“有時”而已；
“常常是幫助”：SaaS產品經理的主要任務是透過對客戶業務、場景、需求、問題的溝通，用各種方式方法解決客戶問題。這種幫助不侷限於產品功能迭代或系統層解決方案，而是包含對客戶的規則的重新制定、管理理念調整的建議等；
“總是去安慰”：對客戶的安慰是不可或缺的工作，卻也是作為產品經理（尤其是像我這種不善於說“軟話”和拒絕的人）最難的部分。客戶對你的期待是問題的解決方案，TA付費的目的也是你能解決問題，而不是獲得安慰。

舉個例子。

客戶A是製造業客戶，因管理理念原因，他們一線員工遇到夜班跨不同日期型別時，必須將工時分別進行核算，不能全部歸屬於夜班當天。

比如週五夜班20:00-次日08:00，則20:00-次日00:00屬於工作日工時（1倍工資），次日00:00-次日08:00屬於週六公休日加班工時（2倍工資）

同理，週日夜班20:00-次日08:00，則20:00-次日00:00屬於週日公休日加班工時（2倍工資），而次日00:00-次日08:00屬於週一的工作工時（1倍工資）。

客戶當時找到我時，已被此問題困擾兩月有餘，在公司內部一直承擔了巨大的壓力——主張採購的SaaS系統，卻不能解決問題，導致一直沒有使用系統。

之所以被困住這麼長時間，原因在於現有標準化產品，無法自動進行工時分拆（比如週五夜班工時完全歸屬於週五的工作時長），而內部實施同學跟產品經理反饋時，因需求屬於個性需求，實現成本高（3-5人團隊投入1個月以上），故無法有效排期。

直到“實在沒辦法”，才預約了一次會議，期望探尋對應解決方案。

如果要徹底“治癒”它，必須透過功能迭代的高成本方式，而考慮到機會成本和需求通用性，如果客戶不願意二次付費，幾乎無法排期解決；

客戶接受了選擇了“尋求幫助”——只要能解決問題，哪怕是手工操作也願意接受。

最終提供了“幫助”型的解決方案：把一個夜班拆分為兩個不同班次，雖增加了排班工作量和複雜度，卻也可解決問題。

具體來說：

如果是工作日（週五）跨休息日（週六），則週五安排20:00-次日00:00的出勤班次（計為工作時長，1倍工資），週六安排00:00-次日08:00加班班次（計為加班時長，2倍工資），其中週五的下班跟週六的上班免打卡，保證員工只需打卡2次即可；
如果是休息日（週日）跨工作日（週一），則週日安排20:00-次日00:00的加班班次（計為加班時長，2倍工資），週一安排00:00-次日08:00出勤班次（計為工作時長，1倍工資）；
同理，如果是工作日遇到節假日，或節假日遇到工作日/公休日，邏輯一致。

解決方案雖不完美，卻也是解決方案，比“總是去安慰”的接受度好一點。