对于C端产品来说，改版宛如家常便饭，用户也对频繁的更新习以为常了。但对于SaaS产品来说，一次改版可能就会导致客户的业务无法正常运行。因此，SaaS产品的改版要慎之又慎。本文作者对此进行了分析，希望对你有帮助。
这一篇也是对曾经踩过的坑的总结。
注意，这里说的改版主要是前台界面的新版本，而不是版本迭代升级。对于经历过 SaaS 从0到1过程的产品经理来说，相信和本人一样会踩过不少坑。因此，奉劝还处在 MVP 阶段的 SaaS 产品经理，请不要轻易改版！这一篇就是来劝退各位轻易改版的 PM 的。
对于 SaaS 软件，使用得最多的用户是客户的员工。我们作为打工人，同样也是自己公司的员工。因此，大家其实可以转换角色代入想想，你们自己用别人家的软件关注什么。一般来说，一家公司选定了 SaaS 软件后，在业务匹配上不会有什么问题，也就是软件本身是能够满足业务需要的。这个时候的用户其实最希望软件是稳定的、持续的。
先来说“稳定”这个点。稳定，其实可以理解为未来发生的事在预期范围内。对于使用软件的人来说，最基本的稳定诉求就是让我好好把这一天的工作做完，别给我添乱！
再来说“持续”这个点。持续，就是今天的状态可以在明天重复，在明天的明天也可以重复。说白了，就是不太希望发生改变。我们来看看如果使用的软件不具备稳定性和持续性的时候，员工A的“抓狂”的工作场景。
员工A：“哎呀！这个系统怎么啦？昨天明明是在这里的啊，怎么今天找不着了？赶紧问问系统的客服。”
客服：“哦！很抱歉，我们的系统昨天晚上做了优化升级，为了提高操作效率，将这个功能合并到 xx 里面了。您可以在 xx 里面找到它。”
员工 A：“没事搞什么升级嘛？！我这一上午的时间都浪费了，麻烦以后你们升级能不能提前通知一声？”
客服：“好的！好的！非常抱歉！”
上面的场景经常发生在系统“优化升级”改版后，破坏了用户使用的持续性，导致用户循着已养成的使用习惯却无法正常使用。稳定性自然不必说，出错的时候导致客户的业务无法正常进行，是会经常被客户吐槽“轰炸”的。我们曾经因为一次升级，导致的一个 bug 让全部客户业务受阻，结果就是客服被 N 个微信群的客户骂个半死。
一般来说，B 端产品要保持稳定性和持续性，以避免影响客户的正常业务和破坏用户已经养成的使用习惯。然而，为什么会需要进行改版呢？从原因上分析，一般来说有三大类。
这种情况多有发生在 C 端转 B 端的产品经理身上。
C 端用户对新版本通常是有期待的，比如微信更新后就有不少公众号专门挖掘新旧版本的区别。而且，为了保持产品的新鲜度，C 端产品通常也有定期改版的诉求。如果改版做得好，甚至还会带来正面影响。
本人在做 C 端产品的时候，当时从2.0升级到3.0大版本的时候，虽然界面做了大变样，但是用户觉得新版本界面更好看，更酷了，反而获得了更多的好评。因此，C 端转 B 端的产品经理往往会放大改版带来的好处，以为改版是“好心好意”提升用户体验，而忽视实际的使用群体的差别。
这个大客户也可能包括公司内部的高管，比如爱“出谋划策”的老板。市场销售部门在推进与大客户签单过程中，往往会过渡承诺，说出“你们先试用，有什么不满足的地方我们可以让研发部门改”这类不靠谱的话来。结果，大客户在使用过程中，就会凭借他们的优势地位“逼迫”我们按照他们原有的使用习惯来修改界面或功能。如果没有好的应对策略，那么我们就不得不改版。
这个也是比较常见的一个改版的原因。在早期的产品设计中，往往是基于 MVP 设计，而没有充分考虑 B 端业务的场景复杂性。结果就是，随着客户的增多，收到的优化改进建议也就会越来越多 —— 最终为了后续产品更好地符合市场需求，不得不进行大版本升级。
分析了导致改版的原因，我们也就可以对症下药了。
对于“自嗨型”产品经理，请务必保持对改版的敬畏之心。首先，先评估是否真的有改版的需要。其次，如果要改版，也多采纳关键用户的建议。最后，在界面上最好是做渐进式改版，如果确实无法渐进式改版，一个比较好的做法是新旧版并行一段时间。很多 B 端软件发布新版后都提供了“回到旧版”选项，然后统计根据新旧版使用的比例，再确定什么时候停止旧版。
这里特别要注意的是，更新版本前最好提前告知客户，更新后也要第一时间告知客户新旧版本的区别。
对于大客户的强势改动需求，个人的建议是首先甄别客户需求。
如果需求可以纳入标准版本中，那么可以纳入到正常产品升级中；如果是个性化的诉求，那么最好是提供可配置能力，通过个性化配置满足不同客户的个性化需求。此外，如果这个需求确实超出了产品设定的边界（比如你是做 HR SaaS 的，客户说能不能做个 OA 系统这类），那么还是需要明确拒绝。SaaS 产品还是要保持定力，守住边界。
对于产品设计缺陷，其实从MVP 到 PMF 阶段，难免会经历这样的过程。
个人的经验是，在早期的时候，充分的调研十分必要。一方面是调研行业用户群体特征，方便针对这类用户群体制定前端界面和交互标准，避免后期的界面元素和交互进行大的调整；另一方面是竞品调研，尤其是竞品的关键业务设计。通常，行业深耕多年的竞品已经摸透了这个行业，他们的很多业务流程设计是值得参考的。最后，最好能够邀请到行业的用户参与原型测试或评审，他们可以在早期提供很多非常有价值的建议，从而避免产品和实际业务场景、使用习惯脱节。
除了上述的三点之外，另外一个避免改版的关键因素就是产品经理的架构设计能力。如果产品的架构设计前瞻性比较好，那么扩展性会比较强。典型的情况就是个性化配置这种设计 —— 很多 SaaS 产品由于资源紧张而不会考虑个性化配置这种设计。结果就是，随着客户的增加不得不不断增加各类“补丁”满足不同客户五花八门的需求。
对于个性化配置的设计，个人的经验就是，既然是SaaS 平台，就不应该帮助客户固定业务规则，业务规则制定的能力应该交给客户。
举个例子，收款后系统自动出具收据似乎是能够提供效率的功能，但是实际上有些客户不想每单都开具收据。如果系统设定死了自动出具收据，就必然无法满足这部分客户的需求。因此，合理的设计是提供一个开关，由客户决定是否开启自动出具收据。
既然是SaaS 平台，就不应该帮助客户固定业务规则，业务规则制定的能力应该交给客户。
如果 B 端产品大版本升级界面大变样的话，保证你会被客户的唾沫星子淹死！这是因为， B 端产品和 C 端产品有很大的不同。
大部分 B 端产品设计是提升工作效率的，而往往每日重复的工作最容易用软件来提升工作效率。这也意味着 B 端产品的用户每天使用某些功能的频次非常高，以至于很容易养成固定的使用习惯。改版就意味着打破了用户的使用习惯，实际上就是在给用户的工作“使绊”。因此，再次奉劝各位 SaaS 产品经理，改版要慎重！改版要慎重！改版要慎重！
作者：产品海豚湾；公众号：产品海豚湾（ID：pm-dophin-bay）
本文由@产品海豚湾 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。