SaaS产品怎么做需求分析?

8 评论 16986 浏览 209 收藏 17 分钟

需求分析是产品经理工作中的重要一部分,而对SaaS产品经理来说,因为业务的特殊性,所以需求分析更考验产品经理的基础能力比如还原场景中业务调研的能力、需求价值分析中对价值的界定等。

SaaS厂商的产品需求多数来自业务方真实场景,客户就是上帝不存在伪需求,产品经理多数抱怨自己只是需求的搬运工,处理需求比较被动,大多情况都是接收需求后为了赶项目进度直接动手做起来节奏看似时间紧凑,但事实往往事与愿违,一个功能反反复复不停不停打补丁,寻找源头常常是因为需求分析出现偏差,SaaS产品需求分析中存在一下问题:

1. 不会需求分析

Saas产品不能创造需求,需求大多来自客户实际工作中产生的业务际问题。产品经理缺乏了解相应的行业背景及业务链路的能力,接到需求后无从下手不知道该做什么,思维千头万绪不知道哪个方向开始思考;

2. 不分析全盘接收

产品经理很难设身处地的去体会用户的真实需求,无法判断需求是否符合真实业务场景,全盘接受领导安排的需求,直接照搬硬套竞品功能,功能上线不符合业务场景,功能上线使用感很鸡肋;

3. 不懂判断需求优先级

不同客户提出个性化需求太多,眉毛胡子一把抓需求来了就做,不知道怎么判断需求的优先级,开发计划天天延期;

SaaS产品业务链条长,缺少任何一个必备场景都无法完成闭环,产品经理如果没有对业务链条全面认知的能力,理解需求价值的能力,很难做到精准的需求分析。如果我们恰恰没有很深的业务背景以及闭环全链路思考的能力也不用着急,在工作中不管是新业务需求分析还是对细碎补丁的需求分析都可以从几个方面入手:

  • 第一阶段:回归业务场景,梳理场景需求清单;
  • 第二阶段:学会利用竞品,完善需求分析;
  • 第三阶段:理清需求价值,判断需求的优先级;

01 回归业务场景,梳理场景需求清单

1. 回归业务场景

SaaS 产品面对企业级用户,某种程度上来说是解决他们工作的问题, SaaS 产品不能创造场景,只能还原场景,我们需要大量的调研、分析,找出对方业务场景中的真实问题。如果收集的信息不全,上线功能无法交付使用,都会重新返工,费时费力。

举例说明:需求-支付方式增加储值卡

客户调研需求:储值卡作为支付方式有什么特殊要求?业务方会说:我看xx都可以用储值卡支付支付你按那个一个做或者是储值卡里有钱用户支付方便,用户方便回购率就高了。

合情合理需求明确,产品经理经过这样的调研开始动手画原型,支付增加储值卡方式功能上线收到很多负面反馈,原来很多用户会购买多张打折储值卡,支付时不可使用多张只能选择单张使用,忽略了使用规则。

真实场景很多用户购买多张储值卡目的是支付时享受更多的优惠,而支付时一个订单下只能用一张储值卡,用户非常疑惑并且反感这样的做法,业务方收到很多客诉,业务方意识到问题要求多张卡支付功能必须加急上线,此时产品经理也很委屈明明是按需求来的怎么上线效果这么差呢。

为什么会出现这样的问题的呢?

产品经理在需求调研中脱离实际场景,在动手画原型、写文档之前没有回归场景、认真的观察、思考找出用户面临实际情况到底是什么样。在调研中应明确在业务场景中为哪些用户在什么环境中处于什么样的动机,做了哪些动作达成了什么目的,5要素还原场景。

如:小李(用户)店庆时购买的储值卡(环境),单张面值500元打折后只需400元,于是购买2张面值500元储值卡花费800元(时机),小李去门店购买商品总额1000元,正好自己有2张面值500的储值卡用于支付订单,实付800元购买了总1000元商品(使用动作),小李算了一下使用2张储值卡共优惠200元非常划算(目的)。

产品经理具备回归场景的能力还不够,SaaS产品的业务链条长,缺少任何一个必备场景都无法闭环,SaaS产品经理还要具备梳理链条中全场景的能力,如何梳理全场景呢?场景需求清单是业务链条下场景拆分后需求的合集,帮助我们打破业务的壁垒梳理全场景业务需求。

2. 梳理场景需求清单

基于对业务大量调研、分析、求证找到关联步骤/流程,根据流程还原每个流程下代表性场景,并拆解需求。梳理场景需求清单帮助我们梳理业务链条下全场景关系,避免遗漏影响业务闭环场景,简单来说可以分为一下3步实现:

  1. 梳理完整的业务流程
  2. 单个业务场景归类到流程
  3. 基于场景拆解需求

(1)梳理完整的业务流程

梳理清楚符合实际业务的流程图,完整清晰的流程图可以帮助我们全面了解业务链路,理清在不同阶段哪些角色解决怎样的问题,以及产生了哪些支撑业务体系的分支流程,在产品设计中近可能做到业务闭环。

举例说明:储值卡核心业务流程梳理

支付方式增加储值卡只是储值卡业务中核心一环,储值卡核心流程:制卡储值卡-激活储值卡-使用储值卡,如:

(2)单个业务场景归类到流程

SaaS需求场景来自业务方,业务方需求千差万别如果不做归类,散落的场景越多满足需求的功能也会不断叠加,功能越做越庞杂。将还原场景并收集整理归类到流程,完整的业务流程犹如骨架可以把多个场景串联起来形成结构化信息。

如储值卡业务中激活储值卡场景一:小李线上购买储值卡,作为生日礼物转增给好友,好友收到后在线下门店购买2件商品;

场景二:小丽公司发放2张储值卡用于年底福利,激活后在线上商城下单;

看似不同的场景,都可归类到购买卡-使用卡2个流程中。(场景二激活卡即产生购买卡订单订单金额为0)

(3)基于场景拆解用户需求

业务流程中的每一步都可以代表分支场景,每个场景包含用户、环境、时机、动作、目的不同,其中每个要素发生变化业务需求也不同,基于场景拆解用户的需求。

如:储值卡制卡阶段场景中用户和目的发生变化需求也不尽相同

场景一:周年店庆业务人员制作一批面值在100-1000元打8折出售的储值卡,提交财务审核才可上架用于线上会员购买。

场景二:制作面值500、1000元打4折实体储值卡作为年底员工福利发放,提交财务审核通过才可批量导出制成实体卡。

拆解需求:

1)业务人员

  • 设置储值卡基本信息;
  • 制卡管理;
  • 提交财务审核;
  • 加密批量导出制作实体卡卡号、卡密。

2)财务人员:审核实体储值卡信息

以此为例新业务可以按以上步骤梳理出场景需求清单,产品进入迭代也可以先还原业务场景,将场景重新进行分类整理,按照新的分类逻辑梳理场景需求清单。通过调研、回归场景、梳理情景清单获取需求,需求分析过程是不断的调研-分析-验证的过程,我们怎样判断调研、验证的结果都是正确的呢?竞品分析可以帮助我们解决此类问题。

02 学会利用竞品,完善需求分析

梳理业务流程还原业务场景前置条件是做了大量用户调研,在用户调研过程竞品分析始终贯穿其中,竞品分析不仅帮助我们验证需求的真实度还可以帮助我们梳理全场景,首先明确竞争分析的目的;

1. 竞品分析的目的

竞品分析的目的不是一劳永逸的照搬竞品的功能,而是通过竞品分析可以帮助我们打破业务壁垒的限制得出更合理的分析结果,验证需求的市场价值,以及更加完整的补充由还原场景分析得出的需求,需求在转化功能更合理,用户体验感更好。

举例说明:

业务需求增加储值卡支付方式,需求调研中发现出售储值卡储值的形式有多种其中:会员账号充值,购买储值卡绑定会员号两种形式最为普通,通过两种形式储值的竞品分析总结得出:购买储值卡形式可以绑定会员号自用或赠送好友,也可制成实体卡用于线下赠送,产品形态更灵活,市场上此类储值卡用户更亲徕。会员一次可购买多种储值卡更贴近业务需求,产品价值更高。

2.  选择竞品

选择竞品分析可以选择分析和核心用户群高度相同的直接竞产品分析,也要选择产品功能模块和服务流程比较相近的产品分析,通过研究不同竞品产品功能,颗粒度更细的还原场景,进而有助于梳理链条中的全场景;如在储值卡业务中购买储值卡,就会有预收款(实际为负债),储值卡使用会产生期初、期末金额属于FMS财务管理知识,需要选择财务方面竞品补充储值卡汇总报表方面需求。

03 理清需求价值,学会判断需求的优先级

1. 理清需求价值

SaaS产品价值分为两类:客户为产品或服务付出的成本所产生的产品商业价值,产品/服务的满足用户的需求带来的用户价值。产品/服务满足用户需求带了用户价值,用户价值进一步促成商家价值。

产品商业价值

带来收入,能不能促进客户签约,影响客户续约,采集更多的数据等属于产品的商业价值,例如:

  • 长期价值:社会价值、成本价值
  • 效益价值:销售成本、研发成本
  • 商家价值:获客、提升活跃、留存

用户价值

提供业务闭环符合使用逻辑;给用户带来愉悦,快乐、隐私等用户体验价值;便利性,安全性、经济性的效用价值等属于产品的用户价值,例如:

  • 用户增长:比如客户运营、销售渠道、营销活动、数据报表
  • 体验类价值:商家需求,客服咨询、认证流程
  • 经营管理效率:员工管理,商品管理、财务报表

举例说明

客户购买储值卡功能即储值卡产生了商业价值,用户为什么会购买储值卡功能?储值卡功能满足用户收拢资金的需求,给用户带来价值,在整条业务链条中不同需求带来满足不同用户的价值;用户价值满足又促进达成了产品的商业价值,

如:储值卡用户需求对应的价值,需求满足需求带来用户价值进而促进产品价值

SaaS产品需求判断:符合产品的商业价值又符合用户价值一定要做的,没有用户价值,无论商业价值多大不能做,有用户价值但商业价值很低需求需要慎重考虑可暂且不做。

2. 判断多个需求的优先级

KAKO模型判断需求的优先级,简单的把KAKO模型分为三类:基本型、期望型、兴奋型;

基本型:业务流程中不可缺少,让业务闭环的基本功能。

比如:使用打折出售的储值卡扣款规则,储值卡可作为组合支付其中的一种方式。

期望型:

用户需求满足之上,进一步提高用户的效率或帮助贡献收入。

比如:购买储值卡送优惠券帮助用户获客,后端增加储值卡销售数据分析帮助用户提高管理效率。

兴奋型:偏用户体验类需求。

比如:储值卡扣款短信提醒需求。

3. 不同类型需求优先级判断原则

  • 基本型:基本类的需求不存在优先级
  • 期望型:存在商业价值的优先,其他需求评估用户效用价值的影响面;
  • 兴奋型:存在商业价值的优先,其他需求评估用户体验价值的影响面;

判断需求的价值,学会 KAKO模型判断需求优先级帮助我们游刃有余的进行需求分析,梳理完成目标明确的需求,帮助我们合理协调开发资源,保障项目有序进行。

总结

从还原业务场景,梳理业务场景清单到判断需求优先级,走完了需求分析的步骤,豁然发现SaaS业务特殊,需求分析中还是考验产品经理的基础能力比如还原场景中业务调研的能力、需求价值分析中对价值的界定等。

SaaS端产品经理既要求有B端业务处理的能力,又要有C端产品经理极致的用户体验的思维,打铁还是自身硬,需求分析的过程也是产品经理不断精进的过程。

 

本文由 @L.雪学产品 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 一直很困惑如何还原业务方的使用场景

    来自福建 回复
  2. 选择竞品 能具体说说吗??看的不过瘾,举个例子说说呗

    来自福建 回复
  3. 这不是有赞产品总监的SaaS产品经理课程咩?总结的很清晰,赞👍

    来自广东 回复
  4. Kano模型还是Kako模型

    来自上海 回复
    1. Kano

      回复
  5. 感谢!我会继续努力总结功能工作中经验 和大家一起讨论

    回复
    1. 可以加个weix不

      来自广东 回复
  6. 这么好的文章没有人赞吗?

    回复