在SaaS产品管理的世界里，产品经理常常需要面对复杂的客户需求和多变的市场环境。本文将通过类比医生的工作，深入探讨SaaS产品经理如何在有限的资源和条件下，像医生一样“有时去治愈，常常是帮助，总是去安慰”。

做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倍工资）；
• 同理，如果是工作日遇到节假日，或节假日遇到工作日/公休日，逻辑一致。

解决方案虽不完美，却也是解决方案，比“总是去安慰”的接受度好一点。

缓和医疗 VS 客户成功

现代医疗的发展趋势是高度专业化和精细化，每个医生对自己岗位范围内的病痛负责。比如外科医生负责外科相关，肿瘤医生负责治疗肿瘤等。

当医生对重大疾病（尤其是肿瘤、癌症等）无能为力时，对病人及其家属是乏力的、无奈的，他们既回天乏术，又需快速进入下一个病患的治疗时，是没有时间精力来解决病人和家属的问题的。

比如面对死亡的恐慌、无助，以及面对病痛的苦痛等复杂情绪，进而让病人和家属一并陷入绝境。

医疗缓和的出现，有效解决了这个问题。

什么是缓和医疗？

百度百科的定义是：

缓和医疗是临床医学新发展的一个分支，是为无法耐受高强度治疗的患者解决身体、心理、社会、灵性等层面的痛苦，追求临终的安详与尊严.

它既不让末期病人等死，也不建议他们在追求“治愈”和“好转”的虚假希望中苦苦挣扎，更不期望他们假“安乐死”之名自杀，而是要在最小伤害和最大尊重的前提下让他们的最后时日尽量舒适、宁静和有尊严。

简单来说，它有三个重要的原则：

1. 重视生命并承认死亡是一种正常过程；
2. 既不加速，也不延后死亡；
3. 提供解除临终痛苦和不适的办法。

比如在面对无法救治的重大疾病时，“如何跟病人同步病情”、“家人如何面对并处理重疾病人的心理与身体情况”、“是否治疗，还是回家，谁能给出专业意见”等。

主治医生遵循“术业有专攻而有心却无力”的状态，无法有效提出“解决方案”，只能病人与家属自行解决，可大多数人都是第一次做病人或病人家属，谁可以帮他们呢？

这就是缓和医疗医生的必要性，它有效解决了高度精细化分工下的医疗体系所带来的“弊端”，让医生专注于“有时去治愈”，而把“常常去帮助”和“总是去安慰”交给更专业的医疗人员完成。

这个过程像极了SaaS产品经理在面对退费客户时的样子。

一方面重视客户并承认客户流失是正常过程，一方面又期望提供解决方案，挽留客户。当回天乏力时，最多只能帮助客户保留或转移关键数据，希望“下次再见”。

SaaS产品体系中，实际是有专门的“缓和医疗”体系的（即客户成功）。即当客户签约后，每家客户都分配一名单独的客户成功顾问，负责客户所有的日常问题的解答与处理，让客户更好使用系统提效。

可每位客户成功同时负责数十家（甚至上百家）客户，同时对其专业能力（尤其是沟通能力、问题解决能力等）的要求，导致服务质量参差不齐。

结果只能倒逼SaaS产品经理，必须同时具备“缓和医疗”和“医生”的职责。

当客户成功无法给客户提供“帮助”和“安慰”时，将对应问题转移至让SaaS产品经理。

先探寻“治愈”的可能性（即寻求功能排期，或付费定制开发），无果；

再寻求“帮助”（即无法排期，是否可提供别的解决方案），直至产品经理都没办法，则由Ta对客户进行最后的“安慰”，就像医生对病人宣布“死亡”一样。

你还能怎样？

面对问题，解决问题，这是产品经理的天命。

具体来说：

第一，重新定义解决方案。

产品经理的本质是解决方案提供者，而对解决方案的定义，决定了你对问题的解决率。

一般情况下的解决方案，我们会定义为：通过系统功能迭代，有效解决客户问题的方案，这是狭义的，也是理想的状态；

更广义、更现实的解决方案的定义是：一切有效解决客户问题的方式方法，都是解决方案。包括但不限于：

• 通过系统标准化功能迭代解决；
• 通过自研或付费定制插件解决；
• 通过建议客户优化业务流程、调整业务规则解决；
• 通过安排专人（客户实习生或SaaS企业客服人员）手工处理（尤其是低频/小批量操作）；
• 通过与客户充分沟通后，清晰且真实表达困难、问题等，并对客户情绪完成安抚进行解决；
• 等等。

第二，面对现实，接受现实。

产品经理（尤其是SaaS产品经理）的主要工作，从来不是画原型、写需求文档、上线功能等，而是解决客户问题。

每天无人“打扰”，沉浸式地专注于自身“工作范围”内的工作，在现实世界中几乎不存在，从心底接受现实，才能更好的应对现实。

第三，寻求系统性解决方案。

每天陷入日常繁琐的工作状态，疲于应对，一定无法有效解决大多数客户的问题，而解决方案就是探索结构性的系统性方案。

尤其是个性化的需求、复杂的产品规则、不确定的制度等，总让你应接不暇，而其中关键就在于寻求个性化需求的系统性解决方案。

比如开始建设PaaS平台或AI写代码+插件平台或低代码配置平台等。