以SaaS产品为例通过场景和价值判断需求Word格式.docx

以SaaS产品为例通过场景和价值判断需求Word格式.docx

《以SaaS产品为例通过场景和价值判断需求Word格式.docx》由会员分享，可在线阅读，更多相关《以SaaS产品为例通过场景和价值判断需求Word格式.docx（10页珍藏版）》请在冰豆网上搜索。

然后在我们跟研发同学沟通的过程中，就老是被怼，“我觉得这个功能不应该做，我的数据库又要重构……，我觉得你这个抢购时间有问题……，我觉得人数限制应该是……，”巴拉巴拉一大堆，我们跟研发的吵得不可开交，谁也不服谁。

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

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

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模型是东京理工大学教授狩野纪昭（NoriakiKano）发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

必备型：

满足业务闭环的基本需要，如果有，用户也不会很满意，但如果没有的话，用户满意度为负数，用户就不会使用我们的产品。

期望型：

已经满足基本需求的情况下，如果有该功能，用户满意度就会上升；

如果没有该功能，用户满意度就会下降。

惊艳型：

本来用户没有这个期望值的，如果有，用户会感到很惊喜，会觉得该产品体验很好。

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

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

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

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

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

必备型是是业务闭环的最小需求集合，所有的需求都要做，因此不存在优先级。

期望型和惊艳型：

存在商业价值的优先考虑，其余的考虑对用户的效用价值。

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

期望型需求>

惊艳型需求的优先级进行排序。

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

三、总结

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

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

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

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

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

作者：

客者Aven；

公众号：

超越产品思维

@客者Aven。

题图来自Unsplash，基于CC0协议