每季度砍功能:你的SaaS需要做减法
每季度砍功能:大多数 SaaS 产品里,使用率不到10%的功能比比皆是。为什么每个季度下线一个功能,就能让你的产品多年保持锋利、易于演进、好维护。
每季度砍功能:每个季度下线一个功能——产品里使用率最低的那个。大多数产品都带着一条长长的功能尾巴,在典型的一个月里,使用它们的用户不到百分之十,而其中每一个都会给你日后的每次改动增加负担。每季度砍掉一个,是让独立开发的产品保持紧凑、能持续演进多年的纪律。
下面讲为什么功能臃肿的代价比你想的更高、这个季度仪式怎么运作、为什么做起来很难受,以及如何区分一个死掉的功能和一门死掉的生意。
没人使用的功能背后的隐性成本
看看你的仪表盘里的功能使用情况。对产品里的每个功能,典型的一个月里实际使用它的用户占多大比例?只要跑一次,你就会发现那条长尾:用户使用率不到百分之十的功能。
这些功能感觉是免费的。它们已经做好了,已经上线了,就放在那里。但它们在持续消耗你,因为每次你改动产品里的其他东西,都得确保没有弄坏这些长尾功能——而这种维护成本会在代码库的整个生命周期里不断累积。每一个死功能,都是对每一个活功能永久征收的税。
对独立创始人来说,这笔税比团队更重,因为你就是整个维护部门。花一个小时让使用率只有百分之五的功能继续活着,就是少了一个小时去做那个能带来收入增长的实验。
每季度砍功能:砍功能的仪式
这条纪律简单到一段话就能说完。每个季度:挑出使用率最低的功能。把下线的消息告知依赖它的少数用户。然后移除它。
效果立竿见影,而且会不断累积。代码库变得更简单。产品变得更锋利。维护负担下降。你接下来开发的功能会落在一个更小、更干净的系统里——这意味着它交付得更快,出问题更少。
把它排进日历,就像周一的指标复盘一样:每年四次砍除,提前排定,不容商量。如果你等到一个功能"明显"死掉才动手,你会永远等下去,因为没有哪个功能会宣布自己的葬礼。
本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →为什么砍功能在心理上很难
这不是技术问题,而是情感问题。你在那个功能上花过时间。你记得开发它的那一周,记得要求它的那位客户。而且总有某个地方的某个用户,每次你移除任何东西时都会抱怨。
这是困住创始人的不对称:移除带来的抱怨比臃肿带来的抱怨更刺耳,尽管臃肿造成的累积伤害更大。移除今天只产生一封愤怒的邮件;臃肿则会产生一个更慢的产品、更慢的交付,以及一个没人愿意重构的代码库——无形地分摊在接下来的三年里。
还是要砍。能砍掉自己功能的创始人,才能让产品保持紧凑、持续演进。做不到的创始人,他们的产品会变成历史决策的博物馆。博物馆是个很适合参观的地方。却是个很糟糕的、一个人维护的地方。
转型还是耐心:当问题不是一个功能,而是整门生意
有时,使用数据提出的问题比"这个季度砍哪个功能"更大。有时它暗示,目前这门生意的架构行不通。砍掉一个功能和砍掉一个方向是不同的决定,数据会告诉你你面对的是哪一种:
| 数据显示什么 | 意味着什么 |
|---|---|
| 一个低使用率功能;核心指标健康 | 砍功能——季度仪式就能处理 |
| 进入平台期,但激活率健康、流失率低、推荐虽慢却真实 | 耐心——继续执行;大多数平台期是耐心的信号,而不是转型的信号 |
| 多次修复新手引导后激活率仍持续偏低;留存工作对流失率毫无效果 | 转型信号 |
| 客户反馈持续指向你的产品难以解决的问题;市场比你想象的小 | 转型信号 |
纪律在于诚实地看。诱惑在于继续推进现有的东西,因为你已经投入了时间,而改变方向感觉像失败。数据不在乎沉没成本。而且转型不是失败——它是把你学到的一切应用到一个更锋利的赌注上。大多数成功的企业在早期至少转型过一次,因为第一个想法很少是对的那个,即使它已经被验证过。验证告诉你问题是真的;开发告诉你你的解决方案对不对。在你开发任何东西之前,同样的诚实也适用——这就是何时该放弃一个创业想法。
相反的纪律同样重要:知道什么时候不该转型。每三个月就转型一次的创始人,什么也做不成。激活率有问题、流失率又高的平台期是转型信号;基本面健康的平台期是耐心信号。如果你不确定属于哪一种,就把诊断做成结构化实验——反复修复新手引导却始终无法提升激活率,这件事本身就是数据。
12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →常见问题
我该如何决定砍哪个功能?
看使用数据,而不是凭感情。衡量典型的一个月里有多少比例的用户使用每个功能,按升序排列,下线名单最末尾的那个。大多数产品都有一条使用率低于百分之十的长尾——这条尾巴就是你接下来几个季度的砍除队列。
如果移除功能时客户抱怨怎么办?
会有人抱怨——每次你移除任何东西,总有人抱怨。直接告知依赖该功能的少数用户,给他们预留通知期,然后继续推进。移除带来的抱怨比臃肿带来的抱怨更刺耳,但臃肿造成的累积伤害更大;今天一封邮件,胜过一年后停滞的产品。
我的 SaaS 应该多久移除一次功能?
每季度一个。提前排定,就像你的周一指标复盘一样。每年四次砍除,足以让维护负担持续下降、产品持续演进——又足够稀疏,让忠实用户从不觉得脚下的地面在移动。
我怎么知道该转型而不是砍功能?
功能问题是局部的:健康指标之中的一个低使用率功能。转型信号则是系统性的:多次修复新手引导后激活率仍持续偏低、留存工作对流失率毫无效果、反馈指向你的产品无法解决的问题,或者市场比你想象的小。别忘了还有一个制衡:每三个月就转型一次的创始人,什么也做不成。
你到底被困得有多深?
完成职场窒息指数——这项免费测评告诉你是否已准备好成为独立创业者。