时间: 2021-08-03 08:30:52 人气: 9 评论: 0
编辑导语：SaaS是近年来比较火的一个话题，有不少企业都在SaaS这条赛道上展开了激烈的角逐，其中不乏也有巨头们的身影，因此也产生了不少的Saas产品经理。在客户越来越多的前提下，臃肿**是SaaS产品的最终归宿吗？
Saas产品经理每天都要面对从四面八方传过来的声音。
让Saas系统变得臃肿的需求从哪里来？
Saas的需求来源途径大致有以下几种：
销售在给客户介绍系统的过程中，客户经常**给出一些问题，最常见的问法就是“我们每天都要……，这个在你们系统上要怎么操作？”，如果系统暂不支持，那销售不**考虑客户的需求合不合理、符不符合产品定位，一定**让产品去实现，因为签单才是销售的唯一追求。
客服是和客户打交道最多的，当客户在使用系统时遇到问题自己无法解决时，一般**去问客服，如果客户的问题系统满足不了，客服就**记录下问题，将问题传达给产品。
每个客服都**固定负责一些客户的维护，客户的续费率与客服的绩效挂钩，当客户吵得比较凶时，客服自然就**来催产品经理，“客户真的很急！”。
在客户群里，经常**看到客户在使用系统过程中的吐槽，大多数是系统体验不佳的地方，特别不满意时也**吵得比较厉害。于是在公司产品群里，时不时Boss就**一连发出n张客户群的截图，最后来一句短小精悍的“跟进一下”。
客户成功部门的职责就是帮助客户提供可复制的成功经营方案，在和客户接触的过程中，必然**听到看到客户的一些诉求，这时他们就**收集起来，一并提交给产品经理。
公司的战略方向如果有一些新的功能要做时，就**涉及到了解客户的业务需求。产品是服务于业务的，产品功能脱不开客户的实际业务，这时产品经理就**通过电话拜访或现场拜访的方式去了解客户的实际业务，最终转化为具体的需求。
我们要知道，上面提到的需求并不是凭空产生，而是客户日常工作的业务链条中实实在在的场景中的需求。与C端产品不同的是，C端产品可以通过发散的思维创造场景，从而创造需求，而SaaS系统存在着业务壁垒，只能从业务中还原场景。
在对SaaS产品进行需求分析之前，我们需要回归场景，梳理并描绘出所有必备的业务场景，然后再判断场景中需求的价值，结合产品战略方向来判断该需求到底要不要做。
举个例子，淘宝是给商家和买家制定规则，维护两者利益平衡的交易平台。如果有一大批商家均提出，希望可以修改用户的评价，淘宝**做这个需求吗？先来分析一下。
乍一看这个需求的确具有用户价值和商业价值，但真的要做吗？
如果这样做了，对于成功的、做得很好的商家来说，是一种不公平，对于买家来说，是欺诈，完全违背了消费主张，同时违背了“淘宝是维护商家和买家利益平衡的平台”的定位，所以这个需求是坚决不能做的。
既有用户价值，又有商业价值的：做；有用户价值，没有商业价值的：可做，但要考虑开发成本、开发风险；没有用户价值，有商业价值的：不做，不能为客户创造价值，就算做了客户也不**使用；既没有用户价值，又没有商业价值的：不做。
对于Saas产品的客户，主要可分为付费者和使用者两部分，这两种群体**从不同的角度去看产品。
从不同的角度去看问题就**避免不了产生分歧。
举个例子：我们日常使用的钉钉，相信不少人已经养成了早上到公司楼下打卡的习惯了吧，那么打卡这个功能对于使用者好用吗？有价值吗？显然是没有的，但是这是付费者想要的，让公司更加规范化、流程化，方便了付费者的管理。
付费者的诉求不得不做，但也不能让使用者太不满意，怎么办呢？–优化使用者的体验。如钉钉推出的极速打卡功能，上班前、下班前给使用者推送打卡提醒等等。
谈及需求优先级，就**想到一个非常著名的需求分析模型：KANO模型，KANO模型体现了产品功能和用户满意度的非线性关系。
其中优先级必备属性>期望属性>魅力属性，反向属性和无差异属性尽量不做。
Saas的全称是Software as a Service，中文是软件即服务，可以看出Saas的本质其实是服务，客户并不情愿单纯为软件产品买单，但愿意为能解决问题的服务付费。
很多Saas企业容易错误的以为，只要做到或**越对标产品的水平，就能取得对标企业同样的成功，这在其他行业或许可行，但在SaaS领域则往往不灵。
那既然服务对于Saas企业如此重要，服务好就要满足客户提出来的所有要求，那客户提出来需求那么多，怎样才能让系统不**变得越来越臃肿？
判断需求真伪优先级后，定下来这个需求要做，那就先来判断一下这个需求是不是客户群体普遍适用的需求。若是则直接在系统原有的逻辑上加以修改或添加；若不是则根据需求的大小以及客户的类型来做进一步的判断。
一般情况下小客户的个性化需求没有大客户的需求丰富复杂，大客户在很大程度上也**存在小客户的个性化需求，所以一般把小客户的个性化需求做成设置项。
例如积分系统有的客户想要积分到期自动清零，有的客户想要积分到期后减半，这时就可以做成下面的配置项，让客户自己去设置。
每个中客户的个性化需求都可能存在不同，无法使用一套标准去满足所有的客户，这时一般**做成灵活的配置，让客户自己可以进行配置。这里的配置又可以分为功能的配置和系统的配置。
功能的配置：例如客户需要一个面向C端的商城，将自己的产品卖给自己的用户，不同的客户对商城首页展示风格和内容的要求不同，这时就可以将商城首页做成可配置的，提供不同的组件，banner、图**广告、橱窗等等，让客户去灵活配置。
有**的商城首页配置
系统的配置：当客户的个性化需求与现有产品架构流程差别较大时，需要从系统层面来配置。
例如有的客户需要积分系统，有的客户不需要，这时就可以将积分系统得菜单设置成可配置的，新客户默认不显示积分系统菜单，若客户需要则由客服帮助客户打开，或者由客户自己在后台打开。
一般情况下，大客户的需求是非常丰富且复杂的，如果把系统做成的大客户想要的样子，那估计中小客户就要崩溃了。
因为Saas企业往往比较担心大客户的流失，所以对大客户的需求比较重视，答应大客户的合理需求后，一般采用定制的方式去解决客户的问题，不**影响到其他客户的体验。
看来，臃肿必然不是Saas产品的最终归宿，毕竟市场已经诞生了很多成功的Saas厂商，如北森、有**等，相信这些公司一定有一套自己的需求管理标准，才能让自己的Saas产品好用、功能全但不臃肿。
最后，提出一个问题大家讨论一下，也是小编的困惑。大客户做定制的话，必然**增加系统的维护成本，那应该如何管理和维护给大客户定制的功能？
本文由 @宇先生 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
