Does your company have a hard time repeating product success? Do you find that your team continuously repeats the same weak processes or mistakes that lead to lackluster outcomes? Are you on a team that avoids confrontation and constructive collaboration to keep churning out features?
It is difficult for companies to foster an environment that gives their employees the confidence to challenge norms, speak up about issues, and actually make changes to processes that improve the quality of work they release.
There needs to be a way for team members to collaborate together after decisions, big or small, and identify how their processes contributed to their successes and failures. And that’s where after action reviews (AARs) come in.
In this article, we’ll talk about what AARs are, how AARs can help improve product management, and how to conduct them!
Simply put, AARs allow teams to review decisions after they are made. They can then evaluate the outcomes and make any necessary adjustments to future decisions or processes to increase the likelihood of product success in the future.
Essentially, AARs are like if a retrospective and a post-mortem had a faster-moving, more collaborative, and versatile baby. You can smack an AAR at the end of any action, not just product-related ones, to analyze your success and continually improve your processes.
An AAR consists of four parts:
These questions are meant to stimulate productive and valuable conversations between team members to identify missed opportunities, stale processes, blockers, wins, and more to improve team functions and have better outcomes in the future.
AARs can transform a reactionary company into a proactive one by allowing teams to learn and understand how their decisions and actions impact the business and its objectives. It is only when you review the outcomes of your actions that you can make meaningful changes to repeat successes and eliminate the possibility of failure.
AARs matter to product managers because they help the product organization achieve success on purpose. It is essential that product teams achieve product success on purpose so that it’s repeatable and scalable.
If you are playing a guessing game by throwing spaghetti features against a wall, seeing what sticks, and not identifying what works, doesn’t work, and why, then you risk wasting valuable time and money building the wrong thing.
If you do not constantly try to improve your processes and learn from your mistakes, you not only run the risk of transforming into a feature factory (if you aren’t one already), you run a greater risk of increased attrition. We are human beings at the end of the day — social creatures who rely on community, collaboration, and consistent improvement to feel good about our work. If we don’t constantly improve and adjust our work in a constantly-evolving world, we won’t be able to keep up, build the right things, or retain good talent.
There are several benefits to holding AARs, including:
The best thing about AARs is that you can do them at any time. You don’t have to wait until the end of a sprint as you do for retrospectives and you don’t have to wait until the end of a product launch as you do for post-mortems.
You can conduct an AAR after any action or decision you see fit and while you are building and experimenting. This makes AARs extremely agile and the perfect companion for a fast-moving product manager looking to quickly improve their performance as well as their team’s performance.
What’s more is that an AAR doesn’t only have to apply to product decisions.
You can use AARs to enhance your relationship with sales — an often neglected and difficult relationship to manage for product. Slap an AAR at the end of a big sales demo so you can collaborate with the sales team, discuss how it went well, and identify room for improvement.
The best part about an AAR, in my opinion, is that they are flexible but give you the valuable time you need to converse and collaborate with other team members with whom you typically may not spend as much time.
Spending more time with teammates in an open, collaborative, and safe space not only allows you to gather valuable information about your team, but also allows you to get more market and customer information you may not be privy to firsthand.
You can even use AARs by yourself after an executive presentation or product kick-off call to create space for introspection and identify areas for improvement. My first executive presentation was an actual nightmare in comparison to how they go now, and it’s not because I just shrugged my shoulders and hoped the next one went better.
It takes a conscious effort to improve and it shouldn’t be just limited to your team’s performance. With AAR, it no longer has to be a guessing game on how to improve and you can use these for your personal and professional benefit!
The questions that make up an AAR (What was the goal? What actually happened? What went well? What needs to be changed?) are not the only components needed to make it successful.
There are other aspects you should pay attention to when conducting an AAR to ensure that you not only receive honest and valuable feedback but that you have the right information needed to make changes in the future.
It is helpful to assign someone as the facilitator of an AAR. This can even be yourself if you are conducting them across other departments. You can also ask for some help from your scrum master or project manager to facilitate AARs with the engineering team.
Considering that scrum masters have the experience of running successful retrospectives, I have found that they make for great AAR facilitators as well! They are highly skilled at keeping people on track and focused on the topic at hand, which can lead to better feedback and cooperation.
You also need a sense of psychological safety during an AAR. The good news about AARs is that they help enhance psychological safety by providing room for open and honest collaboration and a promised effort to make changes based on the feedback given.
So even if your first few AARs are a little rough, keep at it. As the team reviews decisions and makes improvements together, you will grow trust. And the more trust you have in your AARs, the better quality of feedback you will get, leading towards more meaningful improvements.
For an AAR to be successful, you also need the appropriate people in the meeting. If you are reviewing a marketing campaign, it probably doesn’t make sense to include engineering, but it matters greatly that you include product marketing and maybe even sales. Including the appropriate stakeholders in your meeting is necessary to collect meaningful feedback.
On the opposite side, including the wrong stakeholders may slow you down, make other teammates feel threatened and judged, and create an environment of confusion. This could lead to misunderstandings and incorrect conclusions.
AARs are valuable to your org. when done often, not only because they help build trust, but because they help you evolve quickly. As technology, the market, your customers, and your company change, conducting AARs after important decisions and actions help you stay agile and adjust at every step of the way. This way, you can move with the changes instead of missing them entirely.
So you want to conduct an AAR but don’t know where to start? Sometimes, to conduct an AAR, you have to do some introspection and research to really understand what you are trying to review and, further, what you are trying to learn.
Gathering data and information around the action or decision will be helpful context for your group when you conduct your AAR. If your AAR is about a recent feature launch, it is helpful to gather all the data related to the release: user engagement, sales numbers, bug reports, customer feedback, etc.
All of this information will help provide context for your colleagues so there can be more meaningful discussions. Without a full picture of the action you are trying to review, you run the risk of reaching ill-informed conclusions.
Once you have prepared your AAR, identified your key stakeholders, and assigned someone as the facilitator, congratulations! You are ready to conduct your first AAR!
Depending on the topic of your AAR, the time you need for your meeting may vary. Regardless, when first starting out, you should give yourself extra time on the books. It takes practice to wrangle a group of deep-thinkers into focusing on a specific topic and not continuously diving into the weeds. Lean on your facilitator here to ensure that the group stays on course. And if the facilitator is you, well what better time to hone your leadership skills than now?!
Pro tip: if you are the facilitator and are bad at multitasking, you may want to record the meeting or ask someone to take notes. Keeping track of what was discussed and what proposed changes the team needs to make is vital in making AARs valuable.
I have heard companies say that they conduct AARs anonymously to achieve more honest feedback. To me, this is a sign of a lack of psychological safety in the workplace. You could go about it this way, although I would argue that it would do absolutely nothing to increase trust and transparency on your team and would hurt you and your quality of feedback in the long run.
Instead, if you approach AARs with patience and the team commits to doing them frequently, you will see an increase in psychological safety across the board.
Begin the AAR meeting by introducing the goal. Provide context around why the goal was made to begin with. This reminder can provide clarity around the original desired outcomes and inspire better discussions.
I know companies like Amazon that provide a multi-page writeup on a meeting topic and allow 10–15 minutes at the beginning of the meeting for everyone to read up on it themselves. However, I find that a conversational style works better to keep people engaged and participating.
What actions were taken to achieve the goal discussed in question one and what were the outcomes? Present the information gathered in your preparation step. Setting the stage and arming your colleagues with information will enable everyone to participate in the discussion. This also helps the team better draw conclusions as to what went right and what went wrong.
As the group collaborates on the wins, make sure to identify which things happened on purpose and which things happened by accident. Since we want to make a shift towards being able to repeat product success on purpose, it is necessary to fully understand when things happen by accident. This way, we can attempt to implement processes and actions in the future that help us better predict outcomes.
This question is often the hardest to discuss and I have experienced times when the team exchanges blank stares and shrugs. If you are too vague or general in your discussion on what things went well and why, you could find yourself in a position where the next steps are not clear.
When stuck, think about what information or actions would be helpful when making a similar decision in the future. When discussing the second question, was there anything missing from the process? Were there roadblocks or one-off issues? Identifying failures will help your team define what needs to be changed in the future.
Sometimes it’s easier to decide what you WON’T change to reduce distractions and get to the root cause of a problem. Every AAR will be different and the important thing here is to work together to figure out how to improve.
And if there were no failures and you executed perfectly, then identify those steps you took and find ways to include and repeat them in your processes so you can replicate that success in the future.
Based on the outcomes of question four, the team will likely walk away from the AAR meeting with a list of action items. As you would in a retrospective, it is important that these action items are clear and that the team has ownership of them.
Whether the action item is a process change for the whole team or specific feedback for one person, everyone needs to be on the same page and understand how they are going to incorporate these changes in the future. Do not rush this step. Everyone should be copacetic about the decisions made and confident that they can execute them.
Sometimes, large process changes can take a while to flesh out and discuss. If you need to rope in other people or take more time discussing them, don’t be afraid to schedule breakout sessions. The purpose of the AAR is not to have a one-and-done meeting for the sake of having one, it is to improve. Take all the time you need and include the right people to plan and execute the improved changes.
Now, we’ll talk about things I’ve learned along the way and my tips for facilitating successful AARs.
Are there people not participating? While this could be a problem in any meeting, it is vital for everyone to participate in AARs considering how vital they are to the success of the business. Therefore, the facilitator should do their best to get everyone to collaborate and share their opinions. Sometimes the softest-spoken people have the best ideas!
Depending on how much psychological safety or camaraderie you have on your team, you may be able to just jump right into it. However, sometimes you gotta warm ‘em up.
I worked with a scrum master who would do icebreaker activities before each retrospective. They were a little goofy at times, but it made everyone loosen up and bond together before diving into uncomfortable discussions. Trust-building exercises are always welcome, especially if you work in an environment that lacks psychological safety and trust.
It is beneficial to share the notes and action items with the team after the meeting is adjourned. Any follow-up meetings should also be scheduled as soon as possible while the topics are at the forefront of everyone’s mind.
This may just be my Type A personality talking, but organizing the notes in an easy-to-access folder for your teammates really helps empower everyone to return to the discussions on their own time and not lose track of the learnings. Especially when they are coming up on a big decision, this is great to make sure that the team doesn’t repeat mistakes made in the past.
There are plenty of AAR templates online that you can steal from, but you will see that most are pretty basic. You can make your own or simply make a copy of my AAR template on Google Sheets to help you get going!
For action items, task management tools like ClickUp or Trello can help keep track of progress, set reminders for your team, and ensure that action items get done.
Reviewing your actions and making improvements is the most vital part of successfully planning, building, marketing, selling, and supporting products. Unfortunately, it is the most neglected aspect of software development, leading to unpredictable wins and repeated failures.
To achieve product success on purpose so that you can then repeat and scale that product success ad infinitum, you must incorporate AARs often to reflect on your team’s processes and decisions and understand how failures occur. It is only when you understand which decisions and actions lead to success and failure that you can make the necessary improvements to more reliably achieve success and grow in ever-evolving markets and technologies.
Constant improvement requires introspection, collaboration, and change at least weekly, if not more often, depending on how fast your team moves. AARs are the perfect solution to provide a structured way of reviewing actions and processes to guide teams in identifying areas for improvement.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
See how to define AI features that deliver user value. Validate needs, assess costs, and set reliability requirements before the team builds.
Learn how to read a P&L statement, assess product costs, build stronger business cases and align product roadmaps with financial priorities.
Learn how product managers can design products for both humans and AI agents with reliable APIs, permissions, errors, and workflows.
See how a cloud storage PM uses LogRocket’s MCP to power Otto, an internal tool that flags bugs and tracks feature adoption automatically.
Learn more →
