What the Army's After-Action Review Can Teach SaaS Product Teams
Four plain questions, asked right after the work is done, turn every launch into a lesson.
Most teams ship something, glance at the numbers and move on to the next ticket. The lessons stay in a few people's heads, and the same mistakes come back three launches later.
The U.S. Army uses a simple habit to avoid this: the after-action review. It is not a report or a blame session. It is a short conversation held as soon as possible after a training exercise or operation, while memories are still fresh.
What is an after-action review?
An after-action review is a guided discussion where everyone who took part answers the same four questions. The goal is to learn, not to grade people. Rank and job title matter less than what each person saw.
| Question | What it uncovers |
|---|---|
| What was supposed to happen? | The plan and the shared expectations |
| What actually happened? | The facts, from several points of view |
| Why was there a difference? | Causes, not culprits |
| What will we do next time? | One or two concrete changes |
Why does it work so well?
Three things make the review useful instead of awkward:
- It happens right away. Details fade within days, so the review is held while people still remember them.
- It focuses on what, not who. Asking "why was there a difference" points at the plan, the tools and the conditions, which makes people willing to speak up.
- It ends with an action. Every review closes with a small number of changes that someone owns.
The point is not to find out who was wrong. The point is to find out what we will do differently tomorrow.
How can a SaaS team run one?
You do not need a new tool. Book 30 minutes within two days of a launch, a sprint review or a round of usability tests, and invite everyone who worked on it: design, engineering, product and support.
- Restate the goal. Read out the success metric and the user problem you set out to solve.
- Lay out the facts. Show the real numbers, a few session recordings and support tickets. Let each person add what they saw.
- Ask why, three times. For each gap, keep asking why until you reach something the team can change.
- Pick one or two changes. Write them down with an owner and a date, and check them at the next review.
What should you avoid?
- Waiting until the end of the quarter, when nobody remembers the details.
- Letting the most senior person speak first and set the story.
- Ending with a long list of ideas and no owner for any of them.
The habit is small, but it compounds. Teams that review every launch stop repeating the same mistakes, and their onboarding, dashboards and pricing pages get better one honest conversation at a time.