7

SaaS 平台好心好意改个版，却被客户骂个半死！

 2 years ago
source link: https://www.woshipm.com/pmd/5745073.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

对于C端产品来说，改版宛如家常便饭，用户也对频繁的更新习以为常了。但对于SaaS产品来说，一次改版可能就会导致客户的业务无法正常运行。因此，SaaS产品的改版要慎之又慎。本文作者对此进行了分析，希望对你有帮助。

VrFd9KUx8O5z9m43EssF.jpg

这一篇也是对曾经踩过的坑的总结。

注意，这里说的改版主要是前台界面的新版本，而不是版本迭代升级。对于经历过 SaaS 从0到1过程的产品经理来说，相信和本人一样会踩过不少坑。因此，奉劝还处在 MVP 阶段的 SaaS 产品经理，请不要轻易改版！这一篇就是来劝退各位轻易改版的 PM 的。

一、SaaS 用户关注什么

对于 SaaS 软件，使用得最多的用户是客户的员工。我们作为打工人，同样也是自己公司的员工。因此，大家其实可以转换角色代入想想，你们自己用别人家的软件关注什么。一般来说，一家公司选定了 SaaS 软件后，在业务匹配上不会有什么问题，也就是软件本身是能够满足业务需要的。这个时候的用户其实最希望软件是稳定的、持续的。

先来说“稳定”这个点。稳定，其实可以理解为未来发生的事在预期范围内。对于使用软件的人来说，最基本的稳定诉求就是让我好好把这一天的工作做完，别给我添乱！

再来说“持续”这个点。持续，就是今天的状态可以在明天重复，在明天的明天也可以重复。说白了，就是不太希望发生改变。我们来看看如果使用的软件不具备稳定性和持续性的时候，员工A的“抓狂”的工作场景。

员工A：“哎呀！这个系统怎么啦？昨天明明是在这里的啊，怎么今天找不着了？赶紧问问系统的客服。”

客服：“哦！很抱歉，我们的系统昨天晚上做了优化升级，为了提高操作效率，将这个功能合并到 xx 里面了。您可以在 xx 里面找到它。”

员工 A：“没事搞什么升级嘛？！我这一上午的时间都浪费了，麻烦以后你们升级能不能提前通知一声？”

客服：“好的！好的！非常抱歉！”

上面的场景经常发生在系统“优化升级”改版后，破坏了用户使用的持续性，导致用户循着已养成的使用习惯却无法正常使用。稳定性自然不必说，出错的时候导致客户的业务无法正常进行，是会经常被客户吐槽“轰炸”的。我们曾经因为一次升级，导致的一个 bug 让全部客户业务受阻，结果就是客服被 N 个微信群的客户骂个半死。

二、导致改版的原因

一般来说，B 端产品要保持稳定性和持续性，以避免影响客户的正常业务和破坏用户已经养成的使用习惯。然而，为什么会需要进行改版呢？从原因上分析，一般来说有三大类。

1. 产品的“自嗨”行为

这种情况多有发生在 C 端转 B 端的产品经理身上。

C 端用户对新版本通常是有期待的，比如微信更新后就有不少公众号专门挖掘新旧版本的区别。而且，为了保持产品的新鲜度，C 端产品通常也有定期改版的诉求。如果改版做得好，甚至还会带来正面影响。

本人在做 C 端产品的时候，当时从2.0升级到3.0大版本的时候，虽然界面做了大变样，但是用户觉得新版本界面更好看，更酷了，反而获得了更多的好评。因此，C 端转 B 端的产品经理往往会放大改版带来的好处，以为改版是“好心好意”提升用户体验，而忽视实际的使用群体的差别。

2. 大客户的强势“逼迫”

这个大客户也可能包括公司内部的高管，比如爱“出谋划策”的老板。市场销售部门在推进与大客户签单过程中，往往会过渡承诺，说出“你们先试用，有什么不满足的地方我们可以让研发部门改”这类不靠谱的话来。结果，大客户在使用过程中，就会凭借他们的优势地位“逼迫”我们按照他们原有的使用习惯来修改界面或功能。如果没有好的应对策略，那么我们就不得不改版。

3. 早期产品设计的缺陷

这个也是比较常见的一个改版的原因。在早期的产品设计中，往往是基于 MVP 设计，而没有充分考虑 B 端业务的场景复杂性。结果就是，随着客户的增多，收到的优化改进建议也就会越来越多 —— 最终为了后续产品更好地符合市场需求，不得不进行大版本升级。

三、如何避免大的版本改动

分析了导致改版的原因，我们也就可以对症下药了。

对于“自嗨型”产品经理，请务必保持对改版的敬畏之心。首先，先评估是否真的有改版的需要。其次，如果要改版，也多采纳关键用户的建议。最后，在界面上最好是做渐进式改版，如果确实无法渐进式改版，一个比较好的做法是新旧版并行一段时间。很多 B 端软件发布新版后都提供了“回到旧版”选项，然后统计根据新旧版使用的比例，再确定什么时候停止旧版。

这里特别要注意的是，更新版本前最好提前告知客户，更新后也要第一时间告知客户新旧版本的区别。

对于大客户的强势改动需求，个人的建议是首先甄别客户需求。

如果需求可以纳入标准版本中，那么可以纳入到正常产品升级中；如果是个性化的诉求，那么最好是提供可配置能力，通过个性化配置满足不同客户的个性化需求。此外，如果这个需求确实超出了产品设定的边界（比如你是做 HR SaaS 的，客户说能不能做个 OA 系统这类），那么还是需要明确拒绝。SaaS 产品还是要保持定力，守住边界。

对于产品设计缺陷，其实从MVP 到 PMF 阶段，难免会经历这样的过程。

个人的经验是，在早期的时候，充分的调研十分必要。一方面是调研行业用户群体特征，方便针对这类用户群体制定前端界面和交互标准，避免后期的界面元素和交互进行大的调整；另一方面是竞品调研，尤其是竞品的关键业务设计。通常，行业深耕多年的竞品已经摸透了这个行业，他们的很多业务流程设计是值得参考的。最后，最好能够邀请到行业的用户参与原型测试或评审，他们可以在早期提供很多非常有价值的建议，从而避免产品和实际业务场景、使用习惯脱节。

除了上述的三点之外，另外一个避免改版的关键因素就是产品经理的架构设计能力。如果产品的架构设计前瞻性比较好，那么扩展性会比较强。典型的情况就是个性化配置这种设计 —— 很多 SaaS 产品由于资源紧张而不会考虑个性化配置这种设计。结果就是，随着客户的增加不得不不断增加各类“补丁”满足不同客户五花八门的需求。

对于个性化配置的设计，个人的经验就是，既然是SaaS 平台，就不应该帮助客户固定业务规则，业务规则制定的能力应该交给客户。

举个例子，收款后系统自动出具收据似乎是能够提供效率的功能，但是实际上有些客户不想每单都开具收据。如果系统设定死了自动出具收据，就必然无法满足这部分客户的需求。因此，合理的设计是提供一个开关，由客户决定是否开启自动出具收据。

既然是SaaS 平台，就不应该帮助客户固定业务规则，业务规则制定的能力应该交给客户。

如果 B 端产品大版本升级界面大变样的话，保证你会被客户的唾沫星子淹死！这是因为， B 端产品和 C 端产品有很大的不同。

大部分 B 端产品设计是提升工作效率的，而往往每日重复的工作最容易用软件来提升工作效率。这也意味着 B 端产品的用户每天使用某些功能的频次非常高，以至于很容易养成固定的使用习惯。改版就意味着打破了用户的使用习惯，实际上就是在给用户的工作“使绊”。因此，再次奉劝各位 SaaS 产品经理，改版要慎重！改版要慎重！改版要慎重！

作者：产品海豚湾；公众号：产品海豚湾（ID：pm-dophin-bay）

本文由@产品海豚湾 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏，鼓励TA抓紧创作！

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK