原则系列-2020年终章之SaaS能够走多远
2020年终于快要结束了,对于大多数人来说,今年是一个悲催的一年。但是作为SaaS赛道来说,从各种角度来看,今年来算是真正的元年,中国SaaS赛道跨越了鸿沟阶段,真正进入了大时代。
在这个大时代里,所有SaaS公司面临的一个严峻挑战是公司的可持续发展性,大批SaaS公司会从前期三五年的虚假繁荣中慢慢沉寂,被新兴的公司所取代,真正可以持续发展的SaaS公司会越来越强大,最终笑到最后,这个比例一定是很小的。
今天想跟大家讨论的是笔者觉得作为SaaS公司非常非常重要的一个话题,SaaS产品的可持续发展性。
不知道大家有没有发现发现一个有趣的现象,2000年前后几年,实际上在中国大量的管理软件公司成立,每个赛道都有相对比较优秀的几家公司,人事,CRM,ERP赛道都是如此,在市场上面也有相当的知名度。
但是20年过去了,我们看到每个赛道又开始有大量新的创业公司出现,占据了头条以及所有的目光,很多老牌的供应商仿佛从我们的视野里面消失了一般,他们还在吗?如果他们还在,为什么这么多年的客户,品牌,产品技术积累居然干不过新的创业公司呢?
实际现实是,这些公司很多还活着,依据老客户的维护费以及每年波澜不惊的新增活着,死不了,也活不好,也很难前进了。这几年我们很多新成立的SaaS创业公司实际上也在走他们的老路,正在走入泥潭,只是还需要几年的时间才能陷得和他们一样深,才能陷入一样的状况。
很多时候我们在评估一家公司的时候,我们看销售增长率,看续约率,看销售投入产出比。
但是在B端产品里面,特别是面向中大型客户的市场,很多时候销售是依靠资源驱动的,不是靠产品力,所以销售市场能力以及融资能力强的公司是容易拿到客户的,60分的产品打败90分的产品是常事(当然也有例外的场景,比如说笔者正在做的菜小秘,产品达不到很高的门槛,这群低文化老百姓是没有办法使用的)。
另外一点是B端客户在使用产品之后,三五年内是很难弃用的,因为弃用成本实在太高,做决策的人也很难打自己的脸,所以续约率在三五年内都是很高的。所以大家可以看到,只要有钱,有资源,我们这三个数据似乎很容易做起来,在投资市场也很受热捧,似乎产品只要马马虎虎,能够凑合用就行了。
我们在产品上面马马虎虎,我们不断的依据客户需求凑合粗糙的增加新功能,慢慢的我们的产品越来越臃肿,易用性越来越差,我们发现:
1: 新客户的实施周期越来越长,回款周期越长越长,很多尾款还收不到了。
2: 产品的新功能开发速度越来越慢,开发成本以及维护成本越来越高。
3: 产品越来越难用,客户在忍受了三五年之后,实在受不了,还是转投别人怀抱。
这个时候我们发现已经陷入泥潭,我们发现产品需要做一些减法,但是已经有一些量的客户在用了,我们做减法比登天还难;产品用户体验差,实施周期长,维护成本高,开发速度越来越慢,用户口碑越来越差,我们却也无能为力。
另外我们还不能速死,也很难发展,经过了很多年的挣扎,直到泥潭里面的泥没过头顶,也许我们内心终于松一口气,我们终于死了。
在中国,B端这块,大家都说重视产品,但是实际上一直最重视的都是销售。这么多年中国B端的产品力实质上是没有多少进步的。除了续约,增长,销售投入产出比等指标以外,笔者强烈建议所有的SaaS创业公司以及投资公司好好的去评估一下自家产品另外一个重要指标,那就是产品的可持续发展指数。
产品的可持续发展指数由很多因素决定,包括产品业务架构,功能架构,数据库架构,逻辑耦合度,产品易用性等一系列因素决定。
怎样实现产品的可持续发展是SaaS产研团队最核心的课题,笔者最近在崔牛会年会的产品闭门会以及人人年会上面做过一些关于可持续发展的产品原则的分享,再这里再整理分享一下这些原则:
1: 整个产品策略先做薄,再做厚,每个迭代做小,做少,做极致。
B端产品功能一旦被客户使用之后,做减法和调整难度是极大的。所以在每个迭代过程中,遵循一个原则,就是做小,做少,做极致,怎样控制需求以及设计的范围是对产品力一个很大的挑战。
另外一点对于B端产品产品就是不能先有再优,对于数据库设计,功能架构,页面架构更是要努力做到极致,否则后续调整成本是非常大的。
2: 做好架构设计,为产品的生长留下空间。
业务架构,数据库架构,功能架构是地基,地基错了上面的一切都是错的。
我曾经打过一个比方,C端产品更像是盖大平房,B端产品更像是盖小高楼,平房是很容易重构的,但是高楼的地基没有打好,后续的调整是毁灭性的,很多时候不得不推倒重来。所以如果我们真的要造一辆汽车,可能首先还是要先造一下发动机还有四个轮子,然后慢慢补充车窗,转向灯,车盖等物件。
作为B端产品来说,业务架构,数据库架构,功能架构极其重要,初创公司如果早期没有合适的人才,也应该找高手作为顾问来把关,否则浪费大量时间和金钱不说,后患无穷。关于怎样做B端产品的MVP, 我原来写过一篇专门的文章“关于如何定义B端产品的MVP”,有兴趣的关注一下SaaS产品说公众号进去阅读。
产品是不断生长的,要找到最好的分类以及架构方式,为产品的生长留下空间。
我们需要记住的一点就是产品是不断生长的,一点业务或者逻辑的增长,这一点业务或者逻辑都会不断的去进行生长,开枝散叶,最后变得非常复杂。
3: 让功能和数据来找用户。
精确的分发功能以及数据来给到每个场景下面的角色和用户。
很长一段时间,企业管理软件就是体验差的代名词,但是随着iphone以及移动互联网的出现,很多设计理念开始普及,B端软件的设计概念正在发生改变。
基于场景的简约式设计越来越普遍,整个思路从让用户去找功能和数据,变成了让功能和数据精确分发给每个场景下面的用户角色。在这个过程中,理解用户,理解场景变得非常重要。
做好系统首页以及每个模块,功能首页的设计。
我们要了解的一点就是B端产品可能功能非常多,但是每个角色每天高频使用的功能一定是很有限的,所以很关键的一点是做好首页的设计。
我们要了解每个角色每天最关心的数据,最高频使用的几个功能,一些关键的信息通知,以及建议需要做的事情,实际上将首页设计好,你会发现客户只需要通过几个首页就可以完成80%以上的工作,这样产品才能大幅降低学习成本。
4: 找到真实的需求以及长期的解决方案。
客户说的大多数都是期望的解决方案,要找到客户真实的需求。
很多时候我们都有这样的经验,客户很多时候提的需求都是他们希望的解决方案,不是真实的需求。
比如笔者最近碰到这样的一个需求,就是客户提出创建订单之后,需要手工去修改订单的时间,用户需求很强烈。
如果不做,客户不愿意继续使用系统。我们觉得很奇怪,了解真实的情况之后发现,原来客户经营的菜品很多,高峰期的时候特别忙碌,搜索菜品开单开不过来,所以都是事后录入订单,所以需要修改订单时间到真实的订单时间便于统帐。真实的需求实际上是客户要提升菜品很多的时候,需要提升开单时候选择菜品的效率。
找到长期的,产品级别的最佳解决方案,否则需求很容易项目制。
5: 区分需求的高低频,普遍程度,价值高低,做好主线,保证极端情况有路可走。
不要想面面俱到,必须要有所取舍。
低频,极端case不要想一定支持得非常友好,保证有路可走即可。
这里打一个简单的比方,比如说休假申请审批过程中,已经到了第二级审批人,这个时候申请人突然想修改申请单子,调整日期之类的,我们是否需要去支持一个审批过程中修改单子的功能呢?
这里的一个诀窍就是,对于低频极端case,很多时候需要产品功能和线下动作配合去解决,不要想所有动作都线上化。
6: 围绕场景,避免过度设计过度设计是对场景以及业务把握程度不够。
过度设计会导致产品体验不贴身,实施成本高的问题。
很多时候我们会走入一个误区,为了避免定制开发,我们很多时候将产品做得特别灵活,可配置性做的特别强,但是配置性做得特别强会带来一些问题,比如说开发成本高,实施成本高,实施周期长,用户体验不贴身。
就像做衣服一样,有的人胖一点,有些人瘦一点,为了做一件所有人都能穿的衣服,最后做了一件特别宽松的衣服,实际上这种衣服对于所有人都是不贴身的。在面向不同客户的时候,每个人的需求形状都是不一样的,有的是长方形,有的是正方形,有的是圆形,有的不规则,最简单的办法就是画一个大圆,把所有需求都满足。但是真正的高手是做一个最小形状的需求,刚好把所有形状都能包含,非常贴身,无法做减法的产品才是最高境界的产品设计。
为了追求灵活度,我们看到有些公司的产品的数据库都可以配置,最后导致的数据库字段意义无法固定,所有逻辑都要可配置化,这种后果是很恐怖的。
所以从长期的角度来看,所有的HR,CRM,ERP市场最终的格局是产品越来越垂直化,基于客户size有不同的产品线来满足,另外大的垂直市场的垂直SaaS都会有很大机会,垂直化细分化的产品一定是长期的大势所趋。
关于PaaS,在中国我并不看好,原因很多,可以以后单独写一篇。
7: 合并同类项,减少复杂度
每一条小的逻辑支线都会随着业务的发展不断生长,开枝散叶。
由于产品不断生长,前端设计也好,后端逻辑也好,尽量抽象合并,减少支线。
我们前端时间大热的所谓中台,核心逻辑其实也是合并同类项,实现共享,用这样的思想去做系统就好了,不要过分追求概念化。
8: 尽一切可能降低耦合度
耦合度的增加会导致产品的可维护,可扩展性变差。
尽一切可能让产品功能侧,逻辑层的耦合度降低。
C端产品更多面向是点状的需求,B端产品更多面向的是面状的需求,需求之间的耦合度极高,在进行产品设计开发的时候需要遵循降耦的原则,否则耦合度太高之后,后续的维护成本会非常高,产品的稳定性也会变得比较差。
9: 找到业务,产品,技术之间的最佳平衡点。
不能完全产品或者需求驱动。
综合考虑技术的实现成本,可扩展性,可维护性,找到最佳的平衡点。
作为SaaS,中国最缺的不是产品或者技术,而是能够快速理解业务,懂产品和技术类似解决方案架构师这样的复合性人才。
红旗能打多久,SaaS能够走多远,除了产品的定位,战略以外,产品的可持续发展指数是非常非常核心的。
因为这篇文章相对内容比较大,笔者计划组织一次线上直播会,主要是为了集中的回答一些读者的问题,希望参加的可以扫描加入下面的直播群。
END
欢迎大家添加我的微信:jianguzhuxin,交个朋友,或者扫描下方二维码:
李东林
菜小秘联创CEO
36Kr特约作家
SaaS产品说
SaaS产品说近期精选文章:
原则系列-如何解救一款难以持续的SaaS产品
原则系列-SaaS创业公司产研团队的组建
原则系列-如何保持B端产品的简洁
SaaS创业日记(一)北京行
原则系列-如何定义需求的优先级
原则系列-如何定义B端产品MVP(下)
原则系列-如何定义B端产品MVP(上)
原则系列-B端产品数据库设计的一些原则
原则系列-如何让B端产品像C端一样极致易用
原则系列-如何做B端产品的PMF
评论