A lessons learned template is a short form you fill in after a project to record what went well, what didn't and what to change next time. Asana's five-step process is identify, document, analyse, store and retrieve. The last two steps are the ones that make the form worth filling in.
Most teams know they should do this. The trouble is that the notes get written, filed and never seen again, so the same mistakes come back on the next job. Asana's point is that when you write down what went wrong, you're leaving a route around that problem for whoever comes next.
The form to copy
Keep it to these rows. Every one exists so that somebody can act on it later:
| Question | What to write | Why it matters |
|---|---|---|
| What went well? | Specific things worth repeating | Good habits get lost as easily as bad ones |
| What didn't go well? | What happened, without naming and shaming | Asana says this creates a roadmap for future teams |
| What caused it? | The underlying reason, not just the symptom | You can't fix a symptom for next time |
| What should change? | One clear action for each cause | A lesson without a change is only a complaint |
| Who owns it? | One name and a deadline | Atlassian's retrospective guidance says to assign owners and deadlines |
| Where's it stored? | The exact location of this document | Asana wants it in a central place everyone can reach |
| When's it read next? | The project or kickoff that will reopen it | This turns a record into something people use |
Copy this template
LESSONS LEARNED
Project name and date of this review
People who contributed
What went well: two or three specifics worth repeating
What didn't go well: two or three specifics, describing the event and not the person
What caused it: the underlying reason for each one
What we'll change: one action for each cause
Owner and deadline: one name and one date for each action
Stored at: the shared folder or tool where this lives
Read again at: the next similar project's kickoff, and who'll bring it
Asana's five steps, in plain terms
- Identify. Send a short survey to everyone on the team, not just the leads, straight after the project or a major phase, while it's still fresh. Then host a live session built around three questions: what went right, what went wrong and what could be improved?
- Document. Write up the survey results and session notes. Asana's full report format has an executive summary, a summary of findings, the surveys and detailed recommendations.
- Analyse. Look for patterns and useful insights. Mid-project, you apply them to the upcoming phases. At the end, you use them to strengthen the next initiative from the start.
- Store. Put the report in a central repository that everyone can reach, such as your project management tool.
- Retrieve. Before you plan a similar project, search for past reports so you don't repeat the same mistakes.
Asana's guide also says you can capture lessons at any point in the timeline, not only at the end, and it suggests aiming for at least one session per project. On a long job, I'd run one at each big phase, since nobody remembers month two by the time month nine comes round.
The steps almost everyone skips
Identify and document get all the attention because they feel like the work. Store and retrieve are where the process usually breaks. A lessons learned document nobody can find at the start of the next project is a diary, not a process.
Asana's retrieve step is the one to take seriously. It says these reports should sit in a central source of truth that project managers can review before they begin planning. So I'd make it part of kickoff: the first agenda item on any new project is to read the notes from the last similar one. It takes ten minutes, and it's the difference between a file and a habit.
Actions have the same problem. Atlassian's tip is to enter them straight into whatever system you plan work in, not leave them on a sticky note, so they're already part of the plan. That works for a small business just as well as for a software team. A task board, a shared list or an AI assistant for project work can all hold them, as long as somebody's name is on each one.
Same meeting, different names
You'll see this session called several things. Asana's guide compares the common formats, and also mentions the after-action review as another name:
| Name | Commonly used by | Main focus |
|---|---|---|
| Lessons learned | General project teams | Insights across all project phases |
| Retrospective | Scrum and Agile teams | How the last sprint performed |
| Postmortem | Various project teams | Project outcomes after completion |
Don't get stuck on the label. As Asana says, the important thing is to capture the information and share it with everyone.
Running the session
Atlassian's retrospective play is written for sprint teams, but the shape works for any group, and as of Nov 2026 it says a retro can be as short as 45 minutes. Here's how I'd borrow it:
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
- Invite the right people. Atlassian lists the product owner, the Scrum team, the Scrum Master and stakeholders. For a marketing campaign, that means whoever did the work and whoever signed it off.
- Start with the wins. Atlassian's first move is to celebrate what went well, and it makes the harder conversation easier.
- Then talk about what didn't work. Everyone should feel welcome to contribute, so keep it on events rather than individuals.
- Finish with actions. Thank everyone and share a summary of the key takeaways and actions.
If your team's small or spread out, and everyone's already sharing updates in writing, an async check-in format can feed this meeting so you aren't relying on memory.
Honest view: is it worth the time?
The risk is that it becomes a ritual. If you fill in the form because the process says so and nothing changes, it's box-ticking, and your team will notice fast. It can also slide into blame if nobody's steering it.
The upside is simple. It saves you paying for the same mistake twice, and a shared format means anybody picking up the next project can see what happened last time without having to ask around.
I'd keep it to the one-page form, make one person responsible for each action and skip the long formal report unless someone needs it. Then I'd judge the whole thing by a single question: did anybody open it at the next kickoff? If they didn't, fix that before you change anything else.
Frequently asked questions
What is a lessons learned template?
It's a reusable form for recording what went well on a project, what didn't and what to improve next time. Asana describes lessons learned as documented insights that give your whole team a resource for future projects.
When should you run a lessons learned session?
Asana says you can capture lessons at any point in the project, and suggests sending the survey straight after the project or a significant phase. Atlassian says retrospectives work best at the end of each sprint if you're working in sprints.
What's the difference between a retrospective and lessons learned?
They're close cousins. Asana's comparison says Scrum and Agile teams use retrospectives to review sprint performance, while general project teams use lessons learned to capture insights across all phases.
Who should attend?
Asana says to include all team members, not only the leads. For sprint retrospectives, Atlassian lists the product owner, the Scrum team, the Scrum Master and stakeholders.
Where should you store lessons learned?
Asana says to use a central repository that's accessible to everyone, such as a project management tool. I'd also link to it from your kickoff checklist, so it's easy to find when it's needed.
