Run a Retrospective That Changes Something
Added 2026-10-31
Organise around facts, causes and changes, outputting at most three changes.
We are running a project retrospective. I will give the timeline and results. Design a 45-minute session: 1) ten minutes of facts only (timeline, key numbers, no judgement); 2) twenty minutes on causes, separating process, communication, resources and external factors; 3) ten minutes to produce at most three actionable changes, each with owner and verification; 4) five minutes to agree how the next project will check they worked. Do not turn it into a blame session.
Site original
Chinese original
How to use
复盘如果没产出改变，就是聊天。
Try tweaking it
- Have it state how the hypothesis could be falsified before discussing execution.
- Split the plan into a one-week testable experiment.
What you should get
- A small testable experiment with a failure threshold
- Costs, risks, and what needs outside confirmation
Common mistakes
- Asking for a "full business plan" and getting unverifiable optimistic assumptions.
- No failure threshold, so you never know whether to continue.
How to check the output
- There is a clear failure threshold, testable within a week.
- Costs, assumptions and risks are listed separately.
Where it works
- Good for: turning business assumptions into a small testable experiment with a failure threshold first.
- Watch out: for pricing, contracts and legal points, treat output as a draft needing professional review.