我在B端SaaS化路上,挖了多少坑

一、抽象化处理需求是悖论

这是书籍和经验造就的坑坑。

在很多的书籍或者方法论中,认为SaaS产品应该实现标准的需求,当遇到个性化需求的时候,要把它抽象化,抽象成很多企业可以共用的样子。

开始的时候我信了,数十次碰壁之后我发现,这可能也是中国没有一个可以走向世界的SaaS产品的原因原因之一。

聊聊第一个坑:我们做To B的SaaS服务,有一天,一个客户跟我说,我要看我们公司不同门店的数据,你帮我处理下吧。

那时候使用系统的基本都是餐饮类企业,调研了多家企业又分析了竞品,发现这是个标准需求呀,我们挺高兴,在系统里增加了一个“门店”的标签。

好多用户反馈,你们这个功能好呀,我都能按门店查询啦,再也不用导出来一点点对账啦……

随着业务发展,慢慢接入了好多房地产行业的用户,客户说,我得按小区统计数据,你们支持吗?

我们一看,这跟门店不是一个意思嘛,问人家门店行不行,客户说:我是小区,不是门店。

我们想,书上说了,要抽象,专门开了10次会议讨论,终于确定了一个词“业务类型”。

那时候觉得自己特牛,终于可以支持多个行业场景啦。什么餐饮门店、物业小区、建筑项目、不同业务线,都往上靠吧!

然后,业务又发展了,有了更多的合作伙伴,更多的行业使用这个产品。

于是,每天每天,电话、微信群、面对面会议,总有人问“业务类型”是什么呀?怎么用呀?

在同一个人第80次问我的时候,我哭了。边挠桌子边问:“姐,我如果让它叫门店你能理解吗?”

东北小姐姐扯着嗓门说:“那有啥不理解的呀,你早这么叫我都不问你。”

除了跪下,我还能怎么办……

这时候我不得不想,抽象,是不是错了。

如果同一个概念,门店就叫门店,小区就叫小区。

在客户使用系统前,选择下行业,系统根据行业区分后显示对应名词,是不是这个沟通和学习成本就没这么高了?

或者,还有哪些更好的方式,能即使用客户常用的名词,系统又能兼顾不同情况呢?

SaaS化,到底是把客户的需求抽象后实现,还是直接实现客户的需求,系统通过灵活的配置兼容多场景,低学习成本推广呢?

我倾向于后者。

这篇文章从写完到发布,经历了大约一个月左右的时间。

我在网络言论方面,是个胆子有点小的人,对于这种理论与实践冲突比较大的情况,总想多方位的求证,在不同的场景和行业里得到证实之后,才敢胡说八道。

在求证过程中,我发现有太多太多名词无法理解,因为用词不一致导致大量无效沟通甚至产品推进难度大的情况。

究其原因,是大家在常识方面不一致。

常识,让有些人心有灵犀,默契自成;常识,也让一些人,说着同一种语言却无法沟通。

不同地区、行业、职业、教育背景、原生家庭甚至不同性别的人,都各自有自己的常识。这些在C端产品中备受重视的客户细分,到了B端,因为业务的复杂性,有时候会被无意识的忽略。

尊重对方的习惯的时候,同样获得尊重。不论是人还是产品。

而抽象,属于一种融合,是进行了深入理解甚至逻辑处理后的结果。首先挑战人的习惯,其次挑战人的惰性,再次考验人的记忆力和理解力。

遇到类似问题时,多想几套方案,不局限于抽象,不拘泥于常识,也许会遇见更多的惊喜。

二、要解决某个场景下某个问题,而非支持某个功能

这个坑,部分原因来自公司的组织架构过于细碎,另一部分原因,可能来自于需求提出人及接收人的认知偏差。

我曾在一个产品群问小伙伴“你们公司有售前、需求分析师、产品经理”这些岗位吗?

有很多小伙伴所在的公司,都同时存在这三个岗位。

to B 的SaaS服务,常常会包含定制化,项目和产品并存。这种情况下,需要设计及处理某需求的人,接收到的需求,中间被转了多手的情况,屡见不鲜。

需求方需要从执行人或者子公司中将需求收集上来,这是第一波信息传递。这个时候,多数情况下还是在表述执行人在做某件事的过程中遇到了什么问题,期望得到解决。

如果需求方有IT部门,业务同事会将需求转达给IT部门,这是第二波信息传递。

之后,再由需求方的业务同事或IT同事将需求转述给供应商的销售或售前经理,售前经理再转述给需求分析师或产品经理,中间经过多次的信息传递。

产品经理听到的需求,很多时候会被表述为“希望支持一个功能,方便客户在做XX的时候更XX”。

中间夹杂了不知道多少人在听到需求时,下意识给出的解决方案。

如果做信息传递的所有人,对要使用的系统都充分理解,并行业知识扎实,所提出的解决方案很有可能是可用的,但这种情况极少存在。

所以,需求保鲜,是一种能力.

对需求的准确表达,能让SaaS路上的坑少很多。

有些需求,确实需要通过系统支持某个功能来实现,可是还有很多,需要通过服务、培训等等其他方式实现。

这在信息传递的过程中,常常被关注于系统的同事们忽略。

三、某个需求不管怎么实现,都觉得怪怪的,那可能不该你来实现

这是中台路上好大的一个坑。

不同系统间互相依赖,进度不同步,信息不同步,客户需求迫切等等原因,最容易孕育畸形。

中台是这几年才有的一个概念,概念提的很好,对公司的统一性管理,确实有效。

但因为它是新事物,产品的融合过程中,已有的业务系统,往往会比中台进度更快。

有些权限类需要用户体系中台实现的功能。客户马上就要用,中台还在开发基础功能,在中台重要紧急程度不够;在业务系统,重要紧急程度却极高,业务系统有时候不得不单独创造一个概念,先支持需求,让客户可用。

等后续中台跟上来的时候,发现业务系统的好些概念,跟中台的功能冲突;这时候再跟客户解释,可能已经解释不通。

怪胎,就这么产生了。

三国有言“天下大势,合久必分,分久必合”。

在产品发展过程中,总会包含很多阶段性产物。某一个阶段觉得很合理的场景,后续总觉得越看越怪,还找不到原因。

这时候,不妨跳出当前这个圈圈,到更大的圈子里俯瞰全局,也许只是路在别人的脚下而已。

四、加法做多了,容易找不到路

这是欲望的坑。

市场机会和开发周期是有限的,欲望是无限的,有时候,接受不完美,也是一种能力。
每一次新做一个产品,总有人觉得你描绘的,不是这个产品全部的样子。

期望你能描绘的更大更全更广阔。于是,本是想做一颗玻璃球,让娃娃在沙发上就能玩耍,公司的销售能力也是在这个程度。

可是,因为不够大不够全,可能最后变成了做一个足球。产品是做大了,好不好的不好说。问题是:去哪里找个足球场供娃娃踢足球呢?又去哪里找一起玩耍的小伙伴呢?

欲望可以有,梦想也是个伟大的词;一旦脱离了本心和能力范围,有可能连本可以走出去的那条路,最后都找不到了。

中国很多的企业,活不过五年。总结失败原因的时候,得有多少是因为产品越滚越大,获客越来越难造成的呢?

小而精未必不美。

精准定位、快速试错、逐次迭代,对于团队的资源使用情况及市场把握情况可能更合适。

 

作者:一米;公众号:产品人儿

本文作者 @一米

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部