编辑导语：SaaS是近年来比较火的一个话题，有不少企业都在SaaS这条赛道上展开了激烈的角逐，其中不乏也有巨头们的身影，因此也产生了不少的Saas产品经理。在客户越来越多的前提下，臃肿会是SaaS产品的最终归宿吗？

• “快做一下这个功能，客户说有了这个功能就和我们签约。”
• “这个功能什么时候做？客户这边很急，再不做就不用我们系统了！”
• “你们系统为什么连这么简单的功能都没有，这很影响我们的使用！”
• “这些是我从客户那里带回来的需求，你们设计实现一下。”……

Saas产品经理每天都要面对从四面八方传过来的声音。

一、需求从哪里来？

让Saas系统变得臃肿的需求从哪里来？

Saas的需求来源途径大致有以下几种：

1. 销售

销售在给客户介绍系统的过程中，客户经常会给出一些问题，最常见的问法就是“我们每天都要……，这个在你们系统上要怎么操作？”，如果系统暂不支持，那销售不会考虑客户的需求合不合理、符不符合产品定位，一定会让产品去实现，因为签单才是销售的唯一追求。

2. 客服

客服是和客户打交道最多的，当客户在使用系统时遇到问题自己无法解决时，一般会去问客服，如果客户的问题系统满足不了，客服就会记录下问题，将问题传达给产品。

每个客服都会固定负责一些客户的维护，客户的续费率与客服的绩效挂钩，当客户吵得比较凶时，客服自然就会来催产品经理，“客户真的很急！”。

3. 客户群

在客户群里，经常会看到客户在使用系统过程中的吐槽，大多数是系统体验不佳的地方，特别不满意时也会吵得比较厉害。于是在公司产品群里，时不时Boss就会一连发出n张客户群的截图，最后来一句短小精悍的“跟进一下”。

4. 客户成功

客户成功部门的职责就是帮助客户提供可复制的成功经营方案，在和客户接触的过程中，必然会听到看到客户的一些诉求，这时他们就会收集起来，一并提交给产品经理。

5. 客户拜访

公司的战略方向如果有一些新的功能要做时，就会涉及到了解客户的业务需求。产品是服务于业务的，产品功能脱不开客户的实际业务，这时产品经理就会通过电话拜访或现场拜访的方式去了解客户的实际业务，最终转化为具体的需求。

二、需求这么多，哪些做，哪些不做？

我们要知道，上面提到的需求并不是凭空产生，而是客户日常工作的业务链条中实实在在的场景中的需求。与C端产品不同的是，C端产品可以通过发散的思维创造场景，从而创造需求，而SaaS系统存在着业务壁垒，只能从业务中还原场景。

在对SaaS产品进行需求分析之前，我们需要回归场景，梳理并描绘出所有必备的业务场景，然后再判断场景中需求的价值，结合产品战略方向来判断该需求到底要不要做。

1. 判断该需求是否符合产品的战略发展及产品定位，不符合的需求坚决不做

举个例子，淘宝是给商家和买家制定规则，维护两者利益平衡的交易平台。如果有一大批商家均提出，希望可以修改用户的评价，淘宝会做这个需求吗？先来分析一下。

• 用户价值：帮助商家更好的维护店铺形象，提高商家的交易转化率；
• 商业价值：交易转化率提高，平台的交易金额增加，平台抽取的佣金增加。

乍一看这个需求的确具有用户价值和商业价值，但真的要做吗？

如果这样做了，对于成功的、做得很好的商家来说，是一种不公平，对于买家来说，是欺诈，完全违背了消费主张，同时违背了“淘宝是维护商家和买家利益平衡的平台”的定位，所以这个需求是坚决不能做的。

2. 分析需求的用户价值和商业价值

• 用户价值：和传统B端产品一样，Saas产品对企业来讲的3大核心价值：增收、将本、提效。
• 商业价值：能否给Saas企业带来收益，如促进客户续费或签约、增值服务、打通供应链为客户提供第三方货源从而抽取佣金……

既有用户价值，又有商业价值的：做；有用户价值，没有商业价值的：可做，但要考虑开发成本、开发风险；没有用户价值，有商业价值的：不做，不能为客户创造价值，就算做了客户也不会使用；既没有用户价值，又没有商业价值的：不做。

3. 侧重付费者的诉求，优化使用者的体验

对于Saas产品的客户，主要可分为付费者和使用者两部分，这两种群体会从不同的角度去看产品。

• 付费者，俗称老板，会希望Saas产品得安全性、规范化、过程可追溯等。
• 使用者，希望提高工作效率、方便易懂等。

从不同的角度去看问题就会避免不了产生分歧。

举个例子：我们日常使用的钉钉，相信不少人已经养成了早上到公司楼下打卡的习惯了吧，那么打卡这个功能对于使用者好用吗？有价值吗？显然是没有的，但是这是付费者想要的，让公司更加规范化、流程化，方便了付费者的管理。

付费者的诉求不得不做，但也不能让使用者太不满意，怎么办呢？–优化使用者的体验。如钉钉推出的极速打卡功能，上班前、下班前给使用者推送打卡提醒等等。

4. 需求优先级

谈及需求优先级，就会想到一个非常著名的需求分析模型：KANO模型，KANO模型体现了产品功能和用户满意度的非线性关系。

• 必备属性：产品必须具备的功能，就好比水杯必须可以盛水。当优化此需求时，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低；
• 期望属性：用户希望做的需求，当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低；
• 魅力属性：用户意想不到的，可以给用户带来惊喜的需求。如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升；
• 反向属性：用户根本都没有此需求，提供后用户满意度反而会下降；
• 无差异因素：无关紧要的需求，无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意。

其中优先级必备属性>期望属性>魅力属性，反向属性和无差异属性尽量不做。

三、个性化需求这么多，怎么做？

Saas的全称是Software as a Service，中文是软件即服务，可以看出Saas的本质其实是服务，客户并不情愿单纯为软件产品买单，但愿意为能解决问题的服务付费。

很多Saas企业容易错误的以为，只要做到或超越对标产品的水平，就能取得对标企业同样的成功，这在其他行业或许可行，但在SaaS领域则往往不灵。

那既然服务对于Saas企业如此重要，服务好就要满足客户提出来的所有要求，那客户提出来需求那么多，怎样才能让系统不会变得越来越臃肿？

1. 判断需求是否普适

判断需求真伪优先级后，定下来这个需求要做，那就先来判断一下这个需求是不是客户群体普遍适用的需求。若是则直接在系统原有的逻辑上加以修改或添加；若不是则根据需求的大小以及客户的类型来做进一步的判断。

2. 小客户设置

一般情况下小客户的个性化需求没有大客户的需求丰富复杂，大客户在很大程度上也会存在小客户的个性化需求，所以一般把小客户的个性化需求做成设置项。

例如积分系统有的客户想要积分到期自动清零，有的客户想要积分到期后减半，这时就可以做成下面的配置项，让客户自己去设置。

3. 中客户配置

每个中客户的个性化需求都可能存在不同，无法使用一套标准去满足所有的客户，这时一般会做成灵活的配置，让客户自己可以进行配置。这里的配置又可以分为功能的配置和系统的配置。

功能的配置：例如客户需要一个面向C端的商城，将自己的产品卖给自己的用户，不同的客户对商城首页展示风格和内容的要求不同，这时就可以将商城首页做成可配置的，提供不同的组件，banner、图片广告、橱窗等等，让客户去灵活配置。

有赞的商城首页配置

系统的配置：当客户的个性化需求与现有产品架构流程差别较大时，需要从系统层面来配置。

例如有的客户需要积分系统，有的客户不需要，这时就可以将积分系统得菜单设置成可配置的，新客户默认不显示积分系统菜单，若客户需要则由客服帮助客户打开，或者由客户自己在后台打开。

4. 大客户定制

一般情况下，大客户的需求是非常丰富且复杂的，如果把系统做成的大客户想要的样子，那估计中小客户就要崩溃了。

因为Saas企业往往比较担心大客户的流失，所以对大客户的需求比较重视，答应大客户的合理需求后，一般采用定制的方式去解决客户的问题，不会影响到其他客户的体验。

四、总结

看来，臃肿必然不是Saas产品的最终归宿，毕竟市场已经诞生了很多成功的Saas厂商，如北森、有赞等，相信这些公司一定有一套自己的需求管理标准，才能让自己的Saas产品好用、功能全但不臃肿。

最后，提出一个问题大家讨论一下，也是小编的困惑。大客户做定制的话，必然会增加系统的维护成本，那应该如何管理和维护给大客户定制的功能？

本文由 @宇先生 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议