与C端产品不同，SaaS产品通过挖掘并实现业务场景中的需求而存在。那么做产品前，我们又要如何挖掘需求呢？笔者认为可以从回归场景与价值判断两部分做起。

在做SaaS产品的过程中，需求并不是凭空产生，而是业务链条中实实在在的场景中的需求。

与C端产品不同的是，C端产品可以通过发散的思维创造场景，从而创造需求。

而SaaS产品存在着业务壁垒，只能从业务中还原场景，并且需要将业务链条中的所有必备场景都还原出来，否则业务无法闭环，一旦上线，用户将无法使用甚至需要将整个产品推倒重来。

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

本文将结合美容院信息管理系统项目中的需求分析，从回归场景和价值判断两个方面阐述需求分析。

一、回归场景

1. 为什么需求要回顾场景

产品经理的工作中，可能经常会面临这样子的一种情况，老板提一个需求，说我们要上线一个抢购功能。然后在我们跟研发同学沟通的过程中，就老是被怼，“我觉得这个功能不应该做，我的数据库又要重构……，我觉得你这个抢购时间有问题……，我觉得人数限制应该是……，”巴拉巴拉一大堆，我们跟研发的吵得不可开交，谁也不服谁。

出现这种情况，除了产品经理自己没想清楚需求外，还缺少了一种共情的描述需求的方式，来跟研发、乃至老板、客户进行有效沟通。

因此我们需要寻找一种介于项目协同的角色之间，大家都能理解的，描述需求的沟通方式，回到场景，看用户面临的实际问题是什么，为什么会提出这样子的需求。

2. 通过场景7要素描绘场景

场景7要素指的是，「谁」在某一个特定「环境」下，出现了某一个特定的「时机」，为了达到某一个「目标」，做了一系列「动作」，跟某一「介质」发生了交互，完成了某一特定「任务」。

如：Coco是美容院美容顾问，今天在店里上班的时候，来了一位进店来的美女，为了留住这个客户，Coco将美女引到休息区并倒了一杯茶，开始用iPad给美女介绍自家的疗程，美女被其中的一个疗程吸引并决定做，于是Coco通过iPad下单，并带美女进了包间。

通过上面的描述，我们就可以和客户以及研发同学都能很好的沟通需求了。

对客户：我们的系统可以直接用户展示美容店内的疗程套餐，种类丰富多样且免除了传统的纸质手册的打印成本。顾客选择好套餐之后可以即时下单，下单信息同步到管理后台，美容师可以马上看到并准备好套餐所需的物品，提高了沟通效率。

对研发：我们需要创建套餐功能、套餐展示功能、套餐下单功能……

场景7要素所描绘的场景，主要是阐述了用户有怎样的需求，并通过怎样的解决方案达成了这个需求。

如：Coco的需求是为了留住客户促成下单，往深度需求来说就是通过下单提升自己的业绩。她的解决方案是尽心尽责的周到服务，以及对自家业务的专业度，通过系统进行下单，以留住客户。

3. 场景需求清单-描绘闭环业务链条上的全场景

通过对业务的调研，结合上述的场景7要素的描述，我们得到了场景需求清单。

当然，整个业务链条中的场景并没有那么少，这里罗列出的是核心的需求场景清单。B端产品研发成本过高，需要在过程中不断的试错，核心需求场景清单的特点是，清单中的场景能让业务形成闭环；清单中每一个场景都有清晰的串联关系。因此，通过核心场景清单，可以作为版本的迭代验证产品。

4. 小结

产品设计的过程往往是先做加法再做减法。将所有业务中的角色梳理清楚，深入场景分角色梳理各自的需求，尽可能多的收集，不用怕收集到的是错的，或者是伪需求，后期我们再通过需求的价值，判断该需求做不做、为谁做、谁先做等问题。

二、价值判断

1. 为什么要做价值判断

在我们做C端产品的时候，每天挂在嘴上的是用户体验，这就要求我们需求考虑极致的用户价值，以提升产品的用户量和用户活跃度。通常都是把流量做起来之后，才会考虑商业变现，可以说是对商业价值的考虑微乎极微。

而SaaS产品不同，SaaS产品天生就是靠卖产品给客户而赚钱的，因此在考虑用户价值的同时，更需要考虑需求对自身的商业价值。

2. 价值判断的两大原则

在我们对需求价值进行判断的时候，会通过价值判断的两大原则进行判断：

（1）宏观层面：产品的价值主张

产品的价值主张指的是，为特定的用户群体提供差异化的价值。价值主张是一个产品的方向和原则。

比如美容院信息管理系统，它的价值主张是：给美容院企业提供全链条的信息化管理服务。

（2）微观层面：需求的价值

需求的价值包括用户价值和商业价值

• 用户价值：该需求给产品的用户带来了业务闭环；给用户带来了便利性、安全性等效用；给用户带来了权威、身份认同等体验类价值。
• 商业价值：该需求能否促进客户的签单和续单，给企业带来收入；该需求能否采集到足够的业务数据反哺系统，以带来更大的价值。

下面来罗列一下美容院信息化管理系统中的一些需求，判断是否具有商业价值。

对于上表所罗列的一些需求即对应的价值，我们可以看出，像发放优惠券等店铺营销模块，以及跨店储值等连锁店铺管理模块，可以摘取出来，跟标准版的产品差异开，客户需要通过付费升级才能获取的功能，便具有一定的商业价值。

价值主张是价值判断的第一原则，尽管我们需要尽可能满足每一个客户的个性化需求，但与产品但价值主张不一致的需求则坚决不做。

3. 如何判断需求该不该做

从上述价值判断的两大原则我们可以知道，需求该不该做，首先需要符合产品的价值主张，其次还需要判断该需求是否拥有用户价值和商业价值。

（1）符合产品的价值主张

我们曾经做过一个商城的项目，当时客户提出一个需求，希望展示在前端的商品销量可以后台修改。我们分析一下这个需求的价值。

• 用户价值：商家可以在后台修改商品的销量，则用户购买时可以产生一定的引导作用，对商家而言是有价值的。

• 商业价值：如果我们做了这个功能并设置成收费模块，则商家也会为了寻求更大的利益而选择付费，因此也有一定的商业价值。

但是，在我们做这个商城项目之前，我们订立的产品价值主张是：帮助中小型建材领域的商家成功。而修改商品的销量这个需求，对于一个成功的商家而言，是耻辱，对于消费者而言，是欺诈，完全违背了价值主张，因此，坚决不做这个需求。

（2）需求的价值

当一个价值符合产品的价值主张之后，我们可以进入下一步，判断该需求的用户价值和商业价值。这里使用象限法进行分析，将商业价值设置为横坐标，用户价值设置为纵坐标，得出如下图。

• 需求1：既有用户价值也有商业价值，要做。
• 需求2：用户价值很高但是没有什么商家价值，这种需求要谨慎考虑，可以从开发的难易程度，以及投入产出比等方面考虑是否要做。
• 需求3：既没有用户价值也没有商业价值，不做。
• 需求4：商业价值很高但是几乎没有用户价值，鸡肋功能，无法创造用户价值，则没有用户使用，即便是再高的商业价值，也是一场空，这种需求也不做。

4. 如何衡量不同角色的需求冲突

在需求分析阶段，常常会遇到需求冲突的情况，使用者和管理者的冲突尤为明显。

管理者的诉求是规范化、流程化、过程可追溯、杜绝损害公司利益的事发生。

使用者的诉求是方便高效、省事，最好还能在某些方面获得一些利益。

比如在做美容院信息管理系统的时候，在疗程下单的时候，店长想要有拍照上传的功能和协议签署功能，美容顾问需要在做疗程之前跟顾客拍照，并需要顾客签字。当疗程做完之后，需要再次为顾客拍照并上传。而实际访谈美容顾问时，美容顾问则希望流程能简单一点，有些步骤可以跳过，因为线下的操作已经够繁琐了。

通过对业务的深入了解我们获悉，做疗程前后进行拍照，是需要给顾客看疗程前后的对比效果，签署协议是为了防止顾客因疗程效果不佳而产生纠纷。

如果做这个功能，则会使美容顾问的工作变得繁琐。但如果不做这个功能，店长就无法使自己的服务标准化、流程化，可能就不会为这个产品付费。

因此，综合考虑之后，我们侧重付费者的诉求，优化使用者的体验。这个功能我们需要做，但是在操作流程上尽可能的让用户的任务路径更短，比如下单直接唤起相机等。

5. 如何判断需求的优先级

判断需求的优先级，这里需要引入一个需求分析模型：KANO模型。

KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

• 必备型：满足业务闭环的基本需要，如果有，用户也不会很满意，但如果没有的话，用户满意度为负数，用户就不会使用我们的产品。
• 期望型：已经满足基本需求的情况下，如果有该功能，用户满意度就会上升；如果没有该功能，用户满意度就会下降。
• 惊艳型：本来用户没有这个期望值的，如果有，用户会感到很惊喜，会觉得该产品体验很好。

那怎么使用KANO模型来判断需求的优先级呢？

（1）将需求按照KANO模型进行分类

我们还是以美容院信息管理系统为例：

将上表进行整理得到下表：

（2）不同的类型中判断需求优先级

• 必备型：必备型是是业务闭环的最小需求集合，所有的需求都要做，因此不存在优先级。
• 期望型和惊艳型：存在商业价值的优先考虑，其余的考虑对用户的效用价值。

总的来说，判断需求优先级，首页代入到KANO模型中，将所有的需求按照KANO模型进行分类，然后按照必备型需求>期望型需求>惊艳型需求的优先级进行排序。

然后分层次，判断每个层次中的需求，商业价值大的优先于商业价值小的，其他的则按照对用户的效用价值进行排序，最终获取需求优先级排序表。

三、总结

本文通过回归场景和价值判断这两个方面，对需求调研过程中收集到的需求进行了全面的分析。

首先使用场景7要素的描述方式，结合调研结果，输出场景需求清单。

其次通过价值判断的两大原则——产品的价值主张和需求的价值，判断需求要不要做，该如何权衡需求冲突。

最后通过KANO模型，来分析需求的优先级，回答哪个需求先做的问题。

做完这一步，产品经理就可以组织开需求评审会了。

作者：客者Aven；公众号：超越产品思维

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

题图来自Unsplash，基于CC0协议