The typical project retro produces a familiar list: communication could have been clearer, the timeline was too tight, we should have caught that issue earlier. Everyone nods. The next project starts, and the same list resurfaces almost unchanged. The retro wasn't wrong — it just didn't produce anything the next project was structurally forced to do differently.
A retro that actually changes behavior needs to end with specific, assigned, checkable changes to process — not shared observations about what happened.
The difference between an observation and a change
- Observation: 'The client feedback rounds took longer than expected.' Change: 'Feedback deadlines now go in the project contract with a defined default-approval date if unanswered.'
- Observation: 'We didn't scope the CMS migration properly.' Change: 'Every project brief now includes a mandatory CMS/data-migration checklist before quoting.'
- Observation: 'Communication between design and dev was unclear.' Change: 'Design handoff now requires a recorded five-minute walkthrough, not just a Figma link.'
An observation describes what happened. A change describes what's different next time, checkable by looking at the process document rather than trusting everyone's memory.
Keep the list short
A retro that produces twelve action items produces zero, because nobody owns twelve things. Pick the two or three changes with the highest leverage — usually the ones that caused the most friction or the most hours lost — and make those the only outputs. Everything else stays as an observation, noted but not acted on this cycle.
The test of a good retro isn't whether the conversation felt honest — most do. It's whether, three projects later, you can point to a specific process document that changed because of it.