![](https://i-blog.csdnimg.cn/blog_migrate/1d16df302efa68bb50426c3fb58021ea.png)
写在前面
有这样一个场景
⽼板/⽤户:我有⼀个特别棒的想法,优先级很⾼,你赶紧把⽅案产做出来。
产品经理:保证效率!我⻢上就开始画原型,然后内部评审,接着推进开发。
这时候部分产品经理急于表现,需要将需求快速落地,第⼀反应就是开始执⾏,所以经常会发⽣⼀种情况,产品经理很努⼒的去做,把需求或想法百分百的去还原,但结果⽼板或⽤户体验完之后发现,这并不是我想要的功能。出现这种情况的原因是产品经理没有了解到这个需求背后的动机和⽬的,这是很多⼩伙伴容易出现的问题。而SaaS产品设计,不仅仅只关注设计,在此之前我们更要关注产品的定义。需要我们想清楚这个需求对应的场景是什么,场景中的需求价值是什么。之后才是结构化的框架把功能设计出来。
文章整体分为以下几个部分
1.SaaS产品设计痛点场景拆分
2.SaaS产品不同维度的认知
3.我们通过什么方式去理解业务
4.我们如何梳理业务判断需求价值
5.我们如何设计产品架构与功能
6.SaaS产品生命周期中的设计原则
以下,咱们一起进入正文~
1.SaaS产品设计痛点场景拆分
1.1.SaaS产品经理的工作方式
SaaS产品经理⼯作本质是从发散到收敛的⼀个过程。发散是指产品的定义,收敛是指产品的设计。但往往很多产品经理⼀上来就开始收敛了,开始画原型,好⼀点的产品经理可能先去思考这个功能影响的范围,影响的⾯。最后梳理出⼀个脑图,⽤这个脑图去跟开发去碰,但是⼀个优秀的产品经理除了⼀上来就收敛之外,其次需要我们思维先发散,最终产品定义这个场景对应的价值是什么。
1.2.SaaS产品理解业务是进⾏需求梳理与功能设计的前提
在这⾥在跟⼤家分享三个场景:
场景一:很多同学都是半路转⾏过来做SaaS产品经理,往往会遇到不知道如何去跟进⾏业的趋势,同时也不知道如何去做业务调研。⽽对于业务理解的⽋缺也直接影响到对应的产出,这时候根据对业务理解而设计的产品⽅案也会被吐槽,不懂业务。这种场景我相信很多SaaS产品经理都会有许多感触。【理解业务难】
场景二:很多产品经理由于之前经验习惯,专注思考单个场景下的⽤户价值,在这时候会导致在思考业务场景时经常出现遗漏,从而导致业务⽆法闭环,终端⽤户对产品感到满意,却没有直接转换成付费。【需求梳理不清晰】
场景三:产品经理进⾏了全盘梳理,理清价值之后,全身⼼投⼊产品设计中去,然⽽业务出现了⼀堆个性化需求,产品经理硬着头⽪单点设计,最后演变成定制化设计,导致产品逻辑异常复杂,研发成本也不断升⾼,终端⽤户在前端界⾯也会吐槽越来越复杂,不知道怎么⼊⼿了。 【功能设计复杂】
出现上面三种场景情况的原因是SaaS产品有⾮常强的业务壁垒,所以不同⾏业产品经理会出现隔⾏如隔⼭的情况,产品设计不清楚具体场景的痛点和难点。其次是SaaS产品业务流程是⽐较复杂的,看似简单的功能也会涉及多个⻆⾊,所以需要通盘考虑。最后SaaS产品个性化需求⾮常多,需要满⾜不同个性化需求,所以导致设计⽅案复杂。
所以接下来的文章也会围绕这三个场景去跟大家分享对应的产品方法论。
2.SaaS产品不同维度的认知
2.1.SaaS产品认知的歧义
很多⼈认为SaaS产品是toB产品,但从本身定义软件即服务来看,即没有说是toB也没有说是toC。而⼴义的SaaS定义是既有toB也有toC(比如印象笔记/⽯墨⽂档)。从软件交付⽅式来讲,SaaS本身作为一种交付模式,本身不存在toB或toC之分。从商业模式来讲,如果我们把toB产品定义为基于互联⽹提供服务,⽤以提升企业效率,增加企业收⼊的产品,那么SaaS产品可以算是B端产品的⼀个分⽀。
2.2.SaaS产品不同维度的认知
SaaS模式的出现很⼤程度上是顺应⽤户对数据安全和低维护成本的需求⽽衍⽣的。
SaaS产品划分:业务垂直型(提供⾯向特定业务的SaaS解决⽅案 ⽐如:crm erp等)、⾏业垂直型(提供⾯向特定⾏业的SaaS解决⽅案⽐如零售电商、餐饮、医疗、制造业)⾏业和业务之间肯定有交叉的,⼀个SaaS产品既会有特定的业务,也会⾯向特定的⾏业。