产品复盘 Skill

用途

功能上线后、项目结束后，做一次结构化复盘。核心认知：一次完整的复盘，比十次闷头干活更有价值。

复盘不是「写总结汇报」，而是「把真相摆到台面上，逼自己承认哪里错了、下次怎么改」。

复盘五问

上线后，用五个问题把整个过程过一遍：

1. 原本要解决谁的什么问题？（回看最初的目标）
2. 实际上用户用了吗？数据怎么样？（看现实，不看感觉）
3. 用户用了之后，真的变好了吗？有什么证据？（看结果，不看过程）
4. 和当初的预期比，差距在哪？为什么？（找偏差的原因）
5. 如果重来一次，我会怎么做？（沉淀成下次的改法）

复盘的三个层次

• 做对了什么：哪些动作有效，值得固化成习惯
• 做错了什么：哪些判断失误，要承认并纠正
• 下次怎么改：具体到「下次我会怎么做」，而不是「下次注意」

关键原则

• 数据优先于感觉：「我觉得效果不错」没用，拉数据看
• 诚实优先于面子：复盘是为了进步，不是为了好看
• 具体优先于笼统：「下次注意细节」没用，「下次验收前先列清单」才有用

输出模板

## 复盘报告

### 目标回顾
- 原本要解决：__________
- 预期的成功标准：__________

### 实际结果
- 数据：__________（使用率/完成率/结果指标）
- 和预期比：达成 / 未达成 / 部分达成

### 做对了什么
- __________（为什么有效：__________）

### 做错了什么
- __________（为什么失败：__________）

### 下次怎么改
- 具体动作：__________
- 沉淀成习惯/清单：__________

实战案例

一个「订单备注」功能上线后复盘：

• 做对了：调研扎实（确认了痛点真实）、被评审问倒后认真补了文档、亲自验收发现问题
• 做错了：需求文档漏了异常流程、排期拍脑袋、想当然加了没人用的「提醒」子功能
• 下次怎么改：每个需求先写「一句话说清给谁用」；文档必须单独写异常流程；上线前先定指标

常见错误

• ❌ 只写「做得好」，不写「做错了」——复盘变成表功
• ❌ 用「感觉」代替数据——「我觉得挺好」不是复盘
• ❌ 结论是「下次注意」，而不是「下次怎么做」
• ❌ 复盘完就完，不沉淀成清单和习惯——下次照样犯