过去三年，我给自己的产品做了87次版本发布——平均每4天一个版本。最初我很兴奋，Roadmap排得满满当当，团队像打了鸡血一样。但后台数据像一盆冷水：30日留存从49%一路掉到26%，付费转化率徘徊在1.2%不动。我开始认真翻看每一次迭代记录，发现我们做了大量“看起来很努力”的功能：一个在线协作工具，我们加了实时投票、白板涂鸦、会议纪要模板、甚至一个宠物养成彩蛋。用户没用，我们却以为用户还没发现。直到我把版本发布频率和留存曲线叠在一起，才发现一个残酷的真相：我们迭代越快，用户流失越快。那可能是我们做过的最蠢的决定——把发布数量当成产品进步的唯一标准。
我用两种迭代模式做了深度复盘。功能迭代，典型的路径是：用户抱怨“为什么没有XX功能”，或者竞品上线了XX模块，于是我们排期、开发、全量发布，然后下个版本再来一轮。它的KPI往往是“本季度发布功能数”或“版本按时完成率”。价值迭代则完全不同：它会先定义某个核心场景（比如“新建文档并完成协作”），然后埋点分析每一步的流失点，通过优化路径、删减干扰项来提升任务完成率。举个例子，同样一个文档编辑器，我们花三周做了“在线投票”功能，上线两周使用率0.4%，而把保存按钮从图标改为文字并高亮，修改两行代码，文档创建成功率提升了8%。功能迭代是忙着制造新岔路，价值迭代是盯着清除路障。
我想把这两种迭代的代价称之为“迭代负债”。不是技术债务，而是产品演进过程中，每一次新增功能、每一次交互改动，都会给用户增加认知负担，给后续维护增加上下文切换成本。我算过自己产品的迭代负债：功能数从18个增加到47个，平均操作步数从4.2步变成6.7步，核心任务（新建项目并邀请成员）的完成率下降到了原来的60%。我把公式简化成：迭代负债 = (功能数 × 平均操作步骤 × 认知负荷) / 核心任务频次。当分子增长快于分母，负债就失控了。功能迭代的投入产出是线性递减的：第10个功能带来2%的活跃提升，第20个功能只能带来0.5%，到第30个功能反而使活跃下降。而价值迭代的收益是复利式的：每次砍掉一个干扰项，核心路径的转化率提升2%，下个月再砍一个，再提升1.8%，留存率环比增速稳定在5%左右。我们用了半年时间，将功能数从47个砍到28个，核心任务完成率从60%回升到83%，NPS从-5变成23。
如果你也想转，给你一套我们验证过的方法。第一，启动“功能减脂周”——不要直接删除功能，把它们全部收进“更多”菜单里，保持入口存在，观察一周内的点击量。如果点击率低于总使用量的1%，就彻底移除。第二，每个迭代版本只允许绑定一个北极星指标，比如“周内完成一次有效协作的用户数”或者“新建文档后2小时内的编辑时长”。指标不是虚荣的MAU，而是与用户核心价值直接挂钩的行为。第三，把用户反馈拆成两层：抱怨和请求是线索，但它们指向的可能是错误的解决方案。一个客户说“我想要截图批注功能”，但通过录屏发现，他真正的问题是不知道如何把图片插入文档并拖动位置。你需要的不是新功能，而是优化已有的图片组件。第四，在灰度发布时，不要只对比崩溃率，要对比“核心任务完成率”和“任务平均用时”。我们有一次灰度把某功能从三级入口提到首屏，结果入口点击率涨了70%，但搜索使用率下降12%——用户被新的路径带走，反而绕了远路。第五，建立“迭代负债登记表”，每个功能上线时记录它带来的附加操作步骤和需要用户重新学习的成本，当负债指数超过某个阈值（我们设定为1.5），就必须砍掉一个老功能来抵消。
写了这么多，我最想表达的是：真正的迭代不是更快，而是更少。用户需要的从来不是更多的选项，而是更确定的路径。下次你的老板问“这个版本做了什么新功能”，你可以回答“这个版本我们删掉了三个功能，但核心任务完成率提高了5%”。我当时就是这样说的，老板沉默了两秒，然后点开了数据分析后台。现在那条留存曲线，已经重新爬回40%了。迭代的目的不是证明团队在跑，而是让用户脚下的路越来越清晰。少做，是在给产品的未来留白。
