把上线前假设改写成可观察项
上线前，很多判断来自路线图、测试和团队解释。正式运行后，同一判断应换成可复核的记录：功能是否被反复调用、谁在维护集成、故障由谁处理、成本落在哪一层。
我会把原尽调结论逐条翻出来，标记已验证、仍待观察和已经失效的部分。若只是往旧报告后面追加数据，原来的假设很容易躲在文字里继续生效。
CHECKPOINTS+哪些使用行为会自然重复+部署和升级由谁负责+异常是否留下可追踪记录+使用增加时哪项成本先上升
用户数量之外，先看工作流有没有留下来
上线活动、激励和合作发布都能带来访问。更值得追的是完整工作流：开发者是否完成第二次部署，集成是否跨过版本更新，机构试用是否进入下一道内部审查。
不同参与者的下一步并不相同。把他们塞进一条留存曲线，会把自然结束的试验和真正中断的使用混在一起。
故障记录比完美周报更有信息
早期产品出问题并不稀奇。研究要看的是团队怎样发现、说明、恢复并复盘，以及同类问题是否反复出现。没有异常记录，既可能代表系统稳定，也可能代表监测还没覆盖。
这部分我不愿只看一句“已经解决”。需要把影响范围、临时处理、根因状态和后续验证分开，未知就继续留着。
把支持成本单列出来
使用量增加时，基础设施、人工支持和定制需求可能一起上升。收入或活跃度没有回答这些工作由谁承担，也没有说明团队是在解决重复问题，还是不断手工补洞。
我会把可自动化的标准支持、需要工程介入的异常和单一参与者的定制要求分开。分类本身不判断好坏，但能看出产品是否逐渐变得更容易交付。
把支持动作连回原来的投资判断
市场进入、招聘、融资或产品调整都可以是合理动作，但它们解决的是哪条原始约束，需要说清楚。投后支持若与研究问题脱节，很容易变成一串忙碌事项。
一份更新后的记录应回答：什么证据变强了，什么假设被削弱了，团队接下来要验证哪一个最影响判断的问题。