每周复盘与下一版决策
把数据、用户原话、成本和本周改动放在一起，只选择一个主要实验。
持续运营不是每周发布更多功能，而是持续缩短"发生问题—看见证据—做出调整"的时间。
判断一份周报有没有用，只有一个标准：它是否直接产生了下一周的优先级。
写完之后如果你还不知道下周先做什么，这份周报可以不写。
每周固定回答六个问题
- 本周有多少目标用户到达、激活、回来和付款？
- 最大流失发生在哪一步？
- 用户重复提到什么场景、阻力或价值？
- 哪项成本或故障异常？
- 本周做过什么修改，它影响了什么？
- 下周只验证哪个最重要的假设？
第三个问题要写用户原话，不要写你的总结。原话里的用词以后能直接用在文案上。
人数很少时写绝对数。 "2 人变成 4 人"比"增长 100%"诚实，也更不容易骗到自己。
固定时间，一小时
选一个固定的时间，比如每周五下午。写在日历上，当成会议对待。
不固定的复盘一定会被"这周太忙"挤掉，而越忙的那几周恰恰最需要复盘。
一小时是上限，不是目标。 数据少的时候二十分钟就够，别为了填满时间去做无用分析。
把工作分成四类
- 修坏掉的：支付、数据、安全和核心流程故障
- 补缺口：用户已经在主路径中遇到的阻塞
- 做实验：验证人群、价值、渠道或价格
- 偿还维护成本：升级、备份、监控和清理
新功能只能在前三类没有更高优先级时进入。
最容易被无限推迟的是第四类。
它没有用户在催，做完也看不到效果，所以永远排在最后——直到某次备份没有、某个依赖过期、某个证书到期，它一次性变成第一类。
每周留一点时间给维护，哪怕只是确认备份还在跑。
只选择一个主要变化
如果同时改首页、价格、注册流程和渠道，结果变化后无法判断原因。
每周确定一个主要实验，其他工作以修复和维护为主。
写清实验：
本周唯一实验
- 假设：____
- 改动：____
- 观察指标：____
- 时间窗口：____
- 继续/停止标准：____"继续/停止标准"要在开始之前写。 事后定标准，你总能找到理由说它成功了。
删掉不会改变决定的东西
写完周报，逐项问：这个数涨了或跌了，我下周会做什么不一样的事？
答不出来的删掉。留下的通常不超过五个数。
好看但不指导动作的图表是最贵的自我安慰,它消耗你的时间还让你感觉在管理产品。判断标准见埋点与数据看板。
建立决策记录
保留当时掌握的证据和为什么这样选。
日期 | 决定 | 当时的证据 | 当时的顾虑 | 后来的结果"当时的顾虑"这一栏最有价值。回头看时，不要把错误判断包装成"早有预料"——真正的积累是知道自己在什么信息下容易判断错。
比如你会发现自己总是高估功能的作用、低估流程摩擦，或者总是被单个用户的强烈需求带偏。这类模式只有靠记录才能看出来。
什么时候该停、该砍、该重来
复盘也要能得出"不继续"的结论：
| 情况 | 可能的动作 |
|---|---|
| 连续几个月没有付费用户，试过多个渠道 | 换方向 |
| 某个功能几乎没人用但一直在耗维护 | 砍掉 |
| 核心假设被证明错了 | 保留可复用的部分，重做 |
| 你自己已经完全没有动力继续 | 先停一段，别硬撑 |
停和砍不是失败，是把时间挪到更值得的地方。 一直不做这个判断才是真的浪费。
常见错误
周报写成汇报。 罗列一堆数据，没有一条产生动作。
没有固定时间。 忙起来就跳过，跳过两次就再也不做了。
同时改很多东西。 结果变化后无法归因。
事后定成功标准。 每个实验都"成功"了，但产品没进展。
只写自己的总结，不留用户原话。 用词被你的行业术语覆盖掉。
用百分比代替绝对数。 三个人变六个人被写成"翻倍增长"。
把决策记录写成正确性证明。 失去了唯一的复盘价值。
永远得不出"停掉"的结论。 时间被沉没成本绑住。
验收标准
- 有固定的复盘时间，写在日历上
- 六个问题每周都回答，第三题写的是用户原话
- 人数少时用绝对数
- 周报里的每个数都能对应一个可能的动作
- 下周只有一个主要实验，且开始前写好了停止标准
- 每周留了维护时间
- 有决策记录，含"当时的顾虑"
- 复盘时会认真考虑砍掉或停掉的选项
本章动作
用一页写完本周六个问题，删除所有不会改变决定的图表。最后只留下下周唯一的主要实验和验收日期。