Lessons learned: definition
Lessons learned is the structured practice of analyzing a project, experiment or incident once it is over, in order to extract explicit, reusable knowledge. The goal is not to judge people but to enrich the team's collective knowledge: what worked, what failed, and what the team would do differently next time.
Why lessons learned matter
A team that never formalizes its lessons learns half as much as it thinks: each member draws private conclusions that stay in their head and leave with them. The article Why startups forget their decisions shows the decision-side version of this problem; lessons learned are the learning-side counterpart.
Done well, the practice prevents the same mistakes from being replayed, speeds up onboarding (new hires inherit the lessons, not just the rules), and turns failures into assets: a failed test that produced a clear lesson generated value.
What lessons learned are not
- Not a project report. A report tells what happened; lessons learned extract what should be remembered and changed.
- Not a blame exercise. A session that hands out blame produces defensiveness, not learning. The golden rule: analyze causes, not people.
- Not reserved for failures. Successes deserve the same analysis: knowing why something worked is the precondition for repeating it.
The practice also differs from its closest cousin, the post-mortem: a post-mortem is a lessons-learned format focused on a specific incident or failure, while lessons learned can cover any project, including successful ones.
How to run it in practice
A useful lessons-learned session has four steps:
- Reconstruct the facts: the timeline, the decisions made, the outcomes. Without shared facts, the analysis drifts into impressions.
- Analyze the gaps: what happened differently from the plan, and why? This is where the lessons come from.
- Phrase lessons as actions: not "communicate better," but "validate the brief with the client before production starts." A lesson that is not actionable is an opinion.
- Add them to the shared memory: a lesson that stays inside the session document is lost. It must join the team's memory and resurface at the next similar project. The post-mortem template structures the first three steps; for decisions that come out of the session, the decision record template takes over.
The weak point of the classic practice is step four: lessons get written, then never reread. A living memory like Verbasil addresses this by linking lessons, decisions and signals, and surfacing them when a similar topic comes back.
FAQ
What is the difference between lessons learned and a post-mortem?
A post-mortem is a specific lessons-learned format, focused on one incident or failure and run shortly after the event. Lessons learned is the general practice: it also applies to successful projects and routine experiments, on a rhythm less tied to urgency.
When should a team run a lessons-learned session?
At the end of any project or experiment the team wants to learn from: a launch, a channel test, a redesign, an incident. The right moment is close to the end of the episode, while the facts are fresh, but after things have calmed down, so that analysis wins over emotion.