SaaS创业日记之北京行

最近一年多因为创业，整天奔波忙碌，SaaS产品说的内容更新很难顾及，或者说很难有大块的时间来总结整理高质量的文章，很多读者和朋友催，我内心也惭愧。也在思考怎样用可持续的方式继续做一些输出，同时不影响平时忙碌的工作。

最后想到的方式是将菜小秘创业过程中一些有价值关于SaaS产品设计研发，运营增长，团队管理，融资相关的内容用日记的方式整理出来，文章结构如果基于主题的组织是相对比较花时间的，但是如果用日记的方式来组织的话，相对是比较轻松的。

 因为公事，周四下午出发去北京，这也是今年第一次过去北京，晚上到了西站，就近找了一家小宾馆住下，北京的防疫措施还是相当严格，入住宾馆需要填写很详细的信息，追踪过去14天去过的城市，还是相当麻烦。
第二天上午出门见了一下我们的一个老股东都总，对公司一些问题进行了探讨以及寻求资源支持。因为投资界今年很是冷清，很多投资人今年普遍比较有空了，都总除了投资项目，今年都有时间写自己的非洲往事系列文集，也经常打飞的去各个城市找朋友喝酒，文章＋酒＋好友，过的那是颇为潇洒豪迈。

下午去见了一个相熟的知名的投资机构，相谈甚欢。然后又去拜见了一下思远介绍的他在伯克利读书时的一个投资人同学Nick，介绍了一下菜小秘这个项目。在和二者进行沟通的时候有一个有意思的问题可以跟大家分享一下，就是说针对中小企业,单价比较低的SaaS普遍不被看好，菜小秘这个项目有什么特殊之处吗？
针对这个问题，这里也表达一下我的观点，实际上对于中小企业的通用SaaS赛道，我也是非常不看好的（当然中大企业的通用saas，近几年我也是不看好的），其原因有二：

1: 中小企业的核心诉求是赚钱，对于降本增效的产品的付费意愿不强。

SaaS类工具类产品的本质，是将线下业务线上化，核心是业务数据的输入以及输出。实际上对于输入这个环节，除非利用了AI技术自动收集数据，一般的SaaS产品在数据输入这个环节，效率是比不过excel等工具的，重点是在统计，查询等输出环节，软件要高效很多。

对于小公司来说，不像大公司的大业务量，业务量较小，实际上最后算下来这种降本增效的效果有限，用了软件，很多时候还不如线下灵活，对于中小企业来说，对于这类产品往往付费意愿不高。总体来说软件对于客户的价值来说，量化的赚钱>量化的降低成本>提升效率。

2: 中小企业的死亡率高，续约率很低。

中小企业的平均寿命只有2.3年，90%以上的中小企业会在5年之内消失，这样的死亡比例对于以续约率为核心指标的saas企业来说，是致命伤，基本上次年续约率达不到70%的软件已经不能称为SaaS了。

菜小秘切入的是一个很是特殊的场景，生鲜流通行业的一批市场的商行客户，对于菜小秘这个项目我觉得真正有意思的主要有三点：

1: 这个行业的赊欠场景普遍且严重

生鲜分为蔬菜，水果，水产，十万亿级别的市场。平均一个商行二个档口，每年7000万的销售额，基本上50%以上的比例都是赊销，加上生鲜的采购极其高频，基本一天一次，繁忙的场景加上低效的原始工具，导致赊欠记错，漏记现象严重，每年因为这个损失20-30万是正常现象。可以说没有赊欠这个特殊的场景，SaaS软件在批发这个行业基本上切不进去。

2: 商行的存活率极高

生鲜一级批发商行基本上是一个金饭碗，没有亏本的商行，换手率极低。拿武汉四季美市场举例，300家左右的商行，十年内换了主的商行不超过5家。

3: 网络效应
网络效应是SaaS可以在这个行业形成垄断，以及后续切入上下游供应链交易以及金融很重要的前提条件，否则如果只是做SaaS，那也是没有劲的，软件工具只是让核心数据上线的一个手段而已。

   周六的时候，因为订了晚上的车票，于是去找了正在做人事领域以及CRM领域创业的二个朋友，一个是人事领域创业的梁公军总，一个是致趣百川的何润总，分享了各自踩的一些坑以及一些经验的分享，一致的意见是创业最难的还是招人，特别是toB的优秀产品经理更是难找，是中国toB管理软件公司普遍的痛点。

这中间讨论的一个问题我觉得挺有价值，跟大家分享一下，就是怎样将一个已经有大量用户，但是随着业务发展产品变得复杂臃肿，产品体验开始变差的一个产品进行调整，一些想法整理如下：

首先是不要轻易推倒重来。

很多公司面临这个问题的解答就是推倒重来，特别是新来一个CTO,CIO的时候，一般就是给公司推倒重来的建议。然后招聘大量人员，花了一年多时间开发上线一个新产品，同时维护老产品，新的产品再花一年上几十家客户，最后二条产品都烂在那里，CTO,CIO混了二年拍拍屁股走人了，经过这二年的折腾，基本上公司就元气大伤，难以发展了，那这个事情应该怎样来做呢：

1: 首先是人的准备的问题。

有几个角色很是重要，一个是产品负责人，能够想清楚产品定位，方向，路径，知道怎样做好需求的取舍。
另外一个是功能架构师，能够找到最好的产品架构方式，保证随着业务的发展，产品的功能架构不需要太大调整。

还有一个是数据库架构师，国外这个岗位叫做Data Architect, 就是能够基于复杂业务做好数据库表格设计，数据库是管理类软件的基础设施，一旦做的差，后面极其痛苦，UI好改，逻辑层好改，但是数据库一旦要调整，就涉及到**迁移，涉及到逻辑层的调整，是极其复杂的。

当然，还需要有比较好的交互师，不要把所有功能平铺，知道根据动作的高低频，信息的重要度进行功能以及信息的有序，有轻重的分布。先找到这些重要的人，如果公司内部找不到的时候，也要找外部顾问，不要在人还不ready，轻易推倒重来，一定是死路一条。

2: 先将理想的产品形态大概设计出来。

不需要将所有的细节设计出来，但是产品的功能架构，系统架构，产品的核心数据库表格设计，首页以及少数核心功能的设计需要出来一个版本，做到心里有数，这个也是判断团队能力的一个参考值。

3: 基于前面二点来找到最佳的路径。

前面二点如果到了比较舒服的地步之后，就可以来判断，是要推倒重来，还是在原来的基础上面庖丁解牛，除非到了很严重的情况，我的一般建议是庖丁解牛，基于功能的重要程度，设计好优先级以及路径，一块块的来进行重写以及重构，这样整体风险可控，团队做的事情更为聚焦，从客户的角度来说体验的变化也不至于一下子大到不可接受。也避免后续复杂的数据迁移以及老产品下线。
一般没有能力做好庖丁解牛的团队，也很难做好推倒重来的新产品。

END

欢迎大家添加我的微信:jianguzhuxin,交个朋友，或者扫描下方二维码:

 李东林

菜小秘联创、

36Kr特约作家

SaaS产品说

SaaS产品说近期精选文章:

（原则）如何定义需求的优先级
（原则）如何定义B端产品MVP(下）
（原则）如何定义B端产品MVP(上）
（原则）B端产品数据库设计的一些原则

   钉钉，我劝你善良（一）

     
更多文章请长按二维码关注我们，实时了解最新SaaS产品技术深度分析：