产品迭代总是越改越烂？我用三年数据复盘发现：砍功能比加功能更重要

过去三年我一直在维护一个B端SaaS工具，用户量不高，但付费意愿极强。刚接手时每两周发一个小版本，每月一个大版本。前半年团队热情极高，每次迭代都塞进新功能：自定义报表、批量导入、权限分组、消息通知模板……版本号从0.8一路飙到2.4。但数据很打脸——第6个月开始，月活下降12%，试用转付费率反而从5.1%跌到3.2%。更诡异的是，核心功能的日均使用时长也从8.7分钟降到6.2分钟。我们以为的功能越丰富、用户越喜欢，实际上用户根本找不到他们最常用的那个按钮了。

后来我翻了整整一年400多条工单和用户访谈记录，发现一个被忽略的事实：用户提得最多的不是“我想要XX功能”，而是“以前那个XX挺好用的，为什么现在找不到了”或者“新版结构太乱，我每次都要多按两次”。这让我意识到迭代的核心矛盾不在速度，而在认知偏离——产品经理在办公室想象的需求，和用户每天肌肉记忆里的操作路径产生冲突时，迭代越快，流失越快。

我做过一个极端实验：把某版本里3个非核心功能（快捷键配置、深色模式、数据导出格式选择）全部移到二级菜单，同时保留入口。结果一周后相关工单量上升200%，但主流程完成率反而提升了15%。这说明什么？用户不是讨厌新功能，而是讨厌被强迫感知新功能。于是我定了一条铁律：任何迭代不得改变用户已习惯的主路径结构。如果必须调整，至少要保证老用户能在一屏内找到原入口，并且提供“回到旧版”的切换开关，保留至少14天。这个开关被我们内部叫做“功能回收站”。

然后我重新设计了下半年的迭代策略：双周迭代只做微调，季度版本才允许做结构变更。每次大版本上线前，必须完成三件事：第一，从现有功能里砍掉或降级至少2个功能；第二，输出一份“被砍功能的影响名单”，列出受影响的工作流和对应的替代操作；第三，在旧版本全量推送一种“临时回滚”提示。把这三件事落地后，数据开始反向变化。到第18个月，月流失率从5.4%降到2.7%，付费转化率回升到5.8%。更意外的是，我们只删了一个数据看板样式，就有3个企业客户发邮件来说“终于不用纠结选哪个视图了”。

当然不是所有减法都成功。我曾经试图砍掉一个只有7%用户使用但每天必用的“数据修复”插件，结果付费用户投诉当天就来了十几条，甚至有客户直接电话过来问是不是要跑路。于是我明白，高频小功能不能只根据使用率判断。我后来用两个维度做减法：一是操作频次，二是替代成本。低频且替代成本低的，直接砍；高频但替代成本高的，保留并优化。真正的垃圾功能不是用得少，而是用的时候让人停卡超过5秒的功能。现在我每次迭代评审会问团队四个问题：这功能省了用户多少秒？这功能会不会让老用户重新学习？如果明天删掉它，谁会骂我们？这个骂声中，哪一个是我们的核心付费用户？回答完，该砍的从不手软。

最近第19个月迭代时，我们把版本号从2.4直接改为4.0，不是加了什么惊天动地的新东西，而是把首页标签从13个缩到5个，把设置页面层级从4层压到2层。上线后第二天，有个两年没主动发过反馈的用户在群里说：“终于像个工具了，不像是俄罗斯方块了。”这句话比一切KPI都让我踏实。如果让我给同行一个建议，那就是：别再纠结你的迭代速度是否够快，先统计一下你上一个版本砍了多少功能。如果答案是零，建议你把下一篇产品周报的标题改成“本周上线了零个新功能，但想通了五个为什么不做”。