先别急着加功能：我见过最惨的迭代，是首页多了一个大红按钮
去年4月我帮朋友看一个图片压缩工具，月活1.2万，付费率2.3%，客单价29元。 他听人说AI抠图是风口，就在首页顶部加了一个全宽轮播，还把原来的“批量改名”按钮从左上角挪到二级菜单。 灰度没做，直接全量。 结果3天后付费率掉到1.7%，客服工单从每天8条涨到41条，App Store多了17条一星，关键词包括“找不到”“改版垃圾”“还我旧版”。 第7天他把入口收回二级页，恢复旧按钮位置，只保留一个88×88的小图标，又灰度10%用户，第14天付费率回到2.4%。 这事让我确认：产品迭代最大的成本不是开发，是用户重新学一遍界面的成本。
对比Snapchat和微信7.0：大厂也翻车，但翻车方式不一样
2018年2月Snapchat改版，把故事和聊天混在一起，用户请愿超过120万人签名，Kylie Jenner发推说不再用，Snap市值当天蒸发约13亿美元。 这个案例可查，时间、金额、请愿数都有公开报道。 2018年12月微信7.0把界面变白、引入时刻视频，也被骂，但微信没有立刻回滚，而是靠后续7.0.3、7.0.4小版本把入口和权限提示磨平。 我的观点是：Snapchat错在改“关系链的排序”，微信改的是“视觉层”，前者动用户心智，后者动皮肤。 迭代深度不一样，回滚代价差10倍以上。
我自己的迭代清单：一次只动一个变量，灰度至少48小时
我现在给独立开发者做顾问，会让他们先写一张“迭代宪法”，不超过200字。 第1条：一个版本只允许一个核心指标变化，比如注册转化率、D7留存、客单价，不能同时改首页、定价和推送。 第2条：版本号跟用户感知挂钩，内部版本可以叫build 2314，但对外更新说明只写用户能感知的3件事。 第3条：灰度按5%、20%、50%、100%四档走，每档至少观察48小时，看崩溃率、P95接口延迟、D1留存、客服工单量。 第4条：回滚预案要写清楚，数据库迁移必须可逆，宁可分两次发，也别一次性删字段。 第5条：更新说明别写“优化体验”，写“批量改名按钮回到左上角”。
具体步骤：从用户骂声里拆出可执行的迭代需求
第一步，先看差评关键词。 把App Store、应用宝、小红书、客服聊天记录导出，按周分组，统计“找不到”“闪退”“广告多”“收费贵”各出现多少次。 第二步，别问用户“你想要什么”，问“你上次做这件事卡在哪”。 比如用户说想要批量导出，实际卡点是导出前要一张张勾选。 第三步，把需求写成假设：如果我把批量勾选放在列表顶部，那么30天内付费转化率提升0.3个百分点。 第四步，定样本量和观察期。 小产品别搞AB测试到95%置信度，你流量不够，先看200个用户、7天行为。 第五步，上线后24小时看技术指标，72小时看行为指标，14天看留存和口碑。 第6步，把这次迭代的失败点写进changelog，别只写成功。
最后说个反常识的：有些迭代应该故意不做
我越来越觉得，产品迭代不是“每周都要发版”。 如果你的月活不到5万，核心流程还没打磨到P95小于300ms、崩溃率低于0.1%，那优先修Bug，而不是加AI按钮。 用户不会因为你少发一个版本离开，但会因为找不到按钮离开。 我现在给项目定KPI，会加一条“回滚次数/发布次数”，如果超过20%，说明团队在拿用户当测试机。 真正好的迭代，是让老用户觉得“没变”，让新用户觉得“本来就这样”。 这话有点绕，但你做三次灰度就懂了。
