先说结论：迭代不是越快越好，是在用户认知账户里扣钱
2019 年我在一家做 B 端排班工具的小公司，团队 11 个人，产品、前端 3、后端 4、测试 2、设计 1。我们当时迷信“两周一个版本”，连续 7 个版本改了导航栏：侧边栏改顶部、顶部改图标、图标又塞进“更多”。开发觉得每次只动 1-2 个入口，很小；但客服工单从每周 43 张涨到 119 张，30 日留存从 28% 掉到 19%。有个客户在电话里说：“你们不是迭代，是每天把我办公室桌子换个方向。” 那次之后我才承认，发版次数不是速度，是用户要重新学一遍的成本。后来我们把节奏改成 6 周一个火车版本，每周只修 P0/P1，发布说明必须配 15 秒 GIF 和 3 步路径，工单 4 周后回到 31 张，留存回到 27%，没有靠一个新功能。
我的独立观点：每次迭代都在收“迭代税”，分三笔
很多人聊产品迭代，只看研发吞吐：故事点、燃尽图、发布频率。我现在会先算“迭代税”。第一笔是学习税：用户要花多久找到旧功能；第二笔是习惯税：肌肉记忆被打破后误操作率；第三笔是信任税：上次更新丢过数据、改过价格、关过入口，这次他就不敢用。小步快跑不是错，错在把“开发成本低”当成“用户成本低”。比如改一个按钮颜色，开发 0.5 人日，用户学习税可能接近 0；但把“导出报表”从一级菜单挪到二级，开发 1 人日，学习税可能让 30% 的老用户一周内找不到。大版本也不是原罪，低频、重决策、数据资产深的产品，憋 8-12 周做一次迁移，反而比每周打扰更尊重用户。判断标准不是团队想多快，而是用户迁移成本能不能被一次引导消化。
一个能落地的判断表：4 个维度打分，选节奏
我后来用一个土办法，4 个维度各 1-5 分，总分 4-20 分。维度 1 使用频率：每天 3 次以上记 5 分，每周 1 次记 3 分，每月 1 次记 1 分。维度 2 操作路径深度：核心任务 1 步完成记 1 分，2-3 步记 3 分，4 步以上记 5 分。维度 3 数据资产：无历史数据记 1 分，有个人配置记 3 分，有团队协作和权限记 5 分。维度 4 习惯强度：用户用了 6 个月以上记 5 分，3-6 个月记 3 分，3 个月内记 1 分。总分 16-20：别两周一小改，用 8-12 周大版本+迁移向导+旧入口保留 2 个版本。总分 11-15：用 4-6 周火车版本，Feature Flag 控制，每次只改 1 个核心路径。总分 4-10：可以 1-2 周小步快跑，但发布说明也要写人话。注意，这个表不是算命，是逼团队把“用户要不要重学”放到排期会上说。
具体步骤：从需求到灰度，我现在的 7 步流程
第 1 步，定迭代主题，一个版本最多 3 个，超过就砍。第 2 步，写迁移说明，不许写“优化体验”这种词，必须写“原来在哪里、现在在哪里、点几下”。第 3 步，埋点先上，至少埋 4 个事件：入口点击、任务完成、失败原因、帮助中心搜索词。第 4 步，灰度发布。移动端 Google Play 可以按 1%、5%、20%、50%、100% 分阶段，Apple 审核通常 24-48 小时，急也没用；Web 端用 Feature Flag 按用户 ID 尾号放量，先 5% 内部，再 20% 种子用户，再 50%，最后全量。第 5 步，看 4 个硬指标：崩溃率低于 0.5%，P95 接口延迟低于 800ms，核心任务完成率不低于旧版 95%，7 日留存不低于旧版 -1 个百分点。第 6 步，准备回滚，数据库变更必须可逆，开关默认关，回滚时间目标 10 分钟内。第 7 步，发版后 72 小时收反馈，客服、应用商店评论、社群、访谈各抽 10 条，不只看 NPS。
对比一下：小步快跑、火车版本、大版本，各自适合谁
小步快跑适合高频、低路径、低数据资产的产品，比如天气、计算器、简单打卡。它的优势是试错快，A/B 测试容易跑出 p<0.05；但缺点是用户被反复打扰，通知一多就卸载。火车版本适合 SaaS、协作工具、有权限体系的产品，固定 4-6 周发一次，中间只发 hotfix。它的优势是用户有预期，团队有节奏；缺点是紧急需求要等，容易养出“插单文化”。大版本适合低频、高价值、强习惯产品，比如财务、医疗、工业软件。它的优势是一次性做迁移引导，旧版可以并行 2-3 个月；缺点是研发周期长，市场窗口可能错过。我见过最糟的组合，是低频产品用周更，高频产品用年更。前者把用户当测试机，后者把用户当库存。真正要对比的不是“快和慢”，而是“用户迁移成本”和“业务验证速度”哪个更贵。
指标和坑：别只看 DAU，也别把 NPS 当唯一真理
我现在会同时看三层指标。第一层，系统健康：崩溃率、ANR、P95、错误率、回滚次数。第二层，行为迁移：旧入口点击下降、新入口点击上升、任务完成率、平均完成时长、帮助中心搜索量。第三层，态度：NPS、CES、应用商店 1-2 星评论关键词。HEART 框架可以用，但别搞成 20 个指标的大表，小团队选 5 个就够。A/B 测试要注意样本量，基线转化 20%、想提升到 22%，每组大约要 3200 个样本，统计功效 80%，显著性 p<0.05，不然今天涨明天跌都是噪声。还有一个坑：灰度太慢也会死。我见过一个版本 1% 放了 14 天，最后全量时竞品已经上了同类功能。我的建议是 5%-20%-50%-100% 四档，每档至少观察 24 小时，核心指标没崩就往前推，别把灰度当拖延症。
最后回答几个用户常搜的问题
“产品迭代多久一次合适？”没有标准答案，但我给一个起点：高频工具 1-2 周，SaaS 4-6 周，低频重决策 8-12 周。 “小版本总被用户骂怎么办？”先别加功能，把旧入口保留 2 个版本，发布说明配 GIF，客服话术统一。 “大版本怎么防流失？”提前 2 周站内信+邮件，给 3 步迁移向导，旧版并行 60-90 天，数据一键导入。 “怎么说服老板不要周更？”拿 4 个数字：客服工单、30 日留存、任务完成率、回滚次数。我们那次就是从工单 43 到 119 才说服的。 “迭代评审看什么？”看假设、指标、回滚预案，不看 PPT 动画。产品迭代这事，说到底不是比谁发版多，是比谁在用户耐心用完之前，把价值送到他手上。