以SaaS产品为例,通过场景和价值判断需求
与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协议