Retrospectives for Product Managers
As product managers, our job is to create as much value as possible; that is, our responsibilities aren’t limited just to shipping products. High-impact product managers invest in improving the processes and cultures that create their products. In other words, to maximize leverage, product managers need to help their teams and their organizations grow.
One of the best ways to improve on future performance is to reflect on the past. As we try to make improvements over time, we can use retrospectives to suss out what works, what doesn't, and how we can move towards better products and processes. (Note that in many working environments, “retrospective” is shortened to just “retro.”)
In this guide on retrospectives, we define what a retro is, we cover how to conduct a sprint retro, and we provide ideas for implementing impactful retros across a variety of contexts.
Defining retrospectives
The etymology of "retrospective" is derived from retro (backwards) and spect (looking). So, retrospectives are built on the action of looking backwards.
But, when you look back, you need to leverage critical thinking to drive improvement. Therefore, a retrospective only provides value when you can identify and commit to action items, based on learnings gained from reflecting.
Every productive retrospective contains the following components:
What went well, and celebrating those wins
What went poorly, and blamelessly diagnosing those gaps
Next steps to maximize upside and minimize downside
When we talk about “what went well” and “what went poorly”, keep in mind that this isn’t limited to metric-oriented outcomes. We also should keep people’s feelings and emotions in mind.
Why? The most innovative, productive, and collaborative teams perform best in environments that promote psychological safety. As PMs, we can’t create and maintain psychological safety unless we account for our teammates’ perceptions and psychological needs.
Therefore, when your teammates express negative emotions like frustration, conflict, jealousy, disappointment, etc., these are all valuable to discuss in retrospectives.
And, when people express happiness, excitement, and other positive emotions, retrospectives should also cover these wins too!
Furthermore, when we discuss “what went poorly”, the goal isn’t to assign blame or to punish people. Instead, the goal is to look for issues that we can improve together as a team.
While discussing “what went poorly” can feel awkward and uncomfortable, it’s necessary that we get specific to dive into the details. After all, if we only vaguely gesture at gaps, we won’t be able to come up with real action that will help us improve as a team.
Here’s an example: “I feel like we could have been more productive” isn’t going to bring us to action items. But “I found that my design reviews kept getting delayed by 2-3 days, and it seemed like my design reviewer was overloaded with too much work” is targeted and specific.
From here, we wouldn’t blame the design reviewer for failing to work hard enough. Instead, we would look for ways to reduce the upfront workload for the design reviewer, or to find alternate design reviewers to balance the workload.
Or, we could find ways for design reviewers to raise their hands and say “I need someone to help me out,” and simultaneously look for ways to streamline the design review workflow to take less time and effort while still ensuring we catch any issues with proposed designs.
We now understand the basics of retrospectives. Let’s dive into one of the most common retrospective rituals for product managers: the sprint retrospective.
Conducting sprint retrospectives
The first place that most PMs start using retros is within the context of a sprint. So, we’ll first break down what a sprint retrospective could look like for you.
Sprint retros are structured meetings that empower team members to review the current development process, brainstorm ideas to improve products, and make actionable recommendations to improve future initiatives.
Your first decision is to select who will participate in the retrospective. In general, you’ll want to invite the individuals who contributed directly to the sprint, e.g. developers, designers, data analysts, and QA testers. But, be careful not to invite too many people, as it may diminish the impact of each person's input and reduce the actionability of the feedback.
As an example, you usually won’t want to bring your manager to sprint retrospectives, nor will you want to bring customer-facing stakeholders (e.g. sales / marketing / support) or executive leaders. Their opinions are valuable outside of sprint retros, yes; but, within a sprint retro, they won’t be able to discuss the tactical details that led to specific wins or specific gaps.
You also need to set up the environment to have a productive retrospective. Critically, you’ll want to have a way for everyone to contribute to the conversation.
You can use a whiteboard with sticky notes, or you can use software like Google Sheets, Trello, Reetro, RetroTool, EasyRetro, etc.
And, don’t hesitate to ask for feedback from engineering managers and design managers - they’ll have a sense of which kinds of tools and processes have historically worked best for their teams.
When leading retrospectives for the first time with your team, you should explain the process to the team, clarify your expectations, and outline the overall goal. This helps team members understand why the retrospective is taking place and what they should gain from it.
Now it's time to begin the retrospective. Remind everyone which sprint you're discussing and show the sprint plan so that everyone involved can refresh their memory.
Start by asking the group for their take on what went well during the last sprint. People tend to be hesitant to take credit or praise themselves, so I tend to start off by sincerely complimenting someone and thanking them for a specific contribution they made. This usually opens up the conversation!
Some examples of wins that you can share:
One of our teammates came up with an excellent alternative to an approach that we had originally decided to take, and this alternative approach solves more pain in less time
One of our recent releases helped a customer succeed, and this customer shared a quote with our sales team about how much they love our products
One of our initiatives is ahead of schedule because we found another internal team to partner with, and they were tackling similar work
If people on the team are shy about praising themselves and claiming credit for their own work, then one way to get them in the habit of sharing is to nudge them to praise other people’s contributions. Over time, they’ll start to get more comfortable with identifying their own contributions, especially when they know that their teammates will back them up!
Now that we’ve gotten some momentum, and the team feels more comfortable with the achievements over the last sprint, it’s time to dig into what could have gone better. Ask the group what kinds of misses or gaps they found.
Since most folks don’t enjoy sharing bad news, the conversation might stall out again. That’s fine! That’s why PMs serve as facilitators, to help get the conversation moving again. If everyone's quiet, I'll offer to first contribute something I feel I could've done better.
Some examples:
One of the user stories that I spun up was missing critical detail, which caused us to miss the mark when tackling that set of work
One of our customers ran into severe bugs that we didn’t know about and weren’t able to prevent or monitor
One of my tasks had to get pushed back, due to unforeseen circumstances
I misinterpreted a teammate’s suggestion and proposed a new process that didn’t help to make the team more effective
From here, we now have a shared understanding of what went well and what could have been improved. We can now come up with ideas for what we’re going to do next sprint, both to increase the positives and decrease the negatives.
As ideas come up, note down each idea. Then, at the end, ask the team to commit to one idea to implement as a team. For this commit, make sure that when we kick off the next sprint, we remind people that this is the idea to implement. It can help to send a message in Slack and pin this message to the top so that folks keep this new action item in mind.
Of course, when brainstorming you’ll also see many smaller proposed action items that are targeted at specific roles (e.g. tasks for the PM, tasks for the tech lead, tasks for the data analyst, etc.). In cases like these, only note down these action items when the role proactively volunteers to tackle these tasks.
Why? Well, we don’t want to commit roles to involuntary work on the spot. Even if many of the proposed ideas might initially seem like good ones, we should give people the space to consider whether those ideas make sense to tackle at face value, or whether the intent behind each idea could be addressed in more effective ways.
End the session by reflecting back on the last retrospective. Did the team follow through on previous action items? If they did, were those outcomes positive or negative, and should we continue to keep those changes in place?
Well done for making it through your first sprint retrospective with the team! By regularly carrying out these assessments, you'll create a cycle of improvement. As each retrospective is based on the previous one, your team will be more successful in gaining value from each retrospective.
Applying retrospectives to teams
Retrospectives offer an incredible opportunity for growth, exploration, and reflection for teams. They’re not just restricted to the end of sprints; in fact, you can hold retros on almost anything.
In both my personal experience and in our coaching practice at Product Teacher, we’ve found that retrospectives can be incredibly beneficial in numerous scenarios, such as:
Crisis prevention
Project wrap-ups
Product launches
Quarterly planning
Lost deals
Won deals
Crisis prevention
When a crisis hits, you and your team can't afford to take the time to do everything perfectly. It's important to go back over the situation shortly after it's been dealt with, so that when another crisis arises, you'll be better equipped to handle it. This way, every crisis will become increasingly easier to tackle each time.
Once your team has completed crisis management, work through questions like these to reflect on the experience:
What was the root cause of the crisis, and how could we have prevented this issue from happening?
Which aspects went really well, and what should we celebrate? How can we strengthen or shore up processes, systems, and practices to help make future crises easier to navigate?
Who displayed acts of heroism, what acts of heroism were these, and how do we recognize their contributions? How do we encourage others to also step into the gap? Even more importantly, how do we reduce our dependency on “heroism” so that anyone can easily fix the issue?
Were there any hiccups in coordinating who owned which part of crisis management? How do we make future coordination and ownership clearer?
Project wrap-ups
When wrapping up a project and conducting a retro, you’ll need to do more of the homework where you bring in a full timeline of the project. That way, the team is on the same page on which events happened when, and where the misses and the successes were.
In the retrospective, make sure everyone is first aligned with the sequence of events and milestones that actually happened. And, make sure to give enough time for a project retro; you may need 1-2 hours here, whereas a sprint retro might only have needed 30 minutes.
For project retros, you’ll generally find that the biggest areas of improvement will be focused on how different teams are handing off to one another, rather than teams improving themselves.
Where you can, encourage people to discuss frictions that they saw when they passed work down to another team, and ask them for how they can make the process better on their end.
The hope is that people on the other side of the handoff will reciprocate and identify ways that they could have grabbed the baton better. If not, then spend some time asking this question explicitly!
Product launches
Product launches require the combined effort of many teams, from sales to finance to support to legal. Therefore, running post-launch retros can help us understand how to make future launches smoother and more successful.
During the retrospective, focus on questions like these:
Which launch processes worked, and why? Which processes didn’t work, and why?
Did anyone run into confusion or misalignment in terms of timelines, target segment, or the proposed value to the customer?
Were any of the handoffs between teams bumpy? Why were these bumpy, and what could we do to make it easier?
Quarterly planning
Product orgs need to run planning sessions to prioritize their initiatives, to spin up roadmaps, and to sync up internally and externally. However, planning is costly, requiring lots of precious time and lots of people.
To maximize the effectiveness of quarterly planning, it’s important to have retrospectives after each quarter’s planning, aiming at the following goals:
Are our plans helping us or are they hurting us? In which ways?
Were there gaps in our plans last time? How do we reduce the likelihood of these gaps next time?
Which planning processes served us well? Which ones didn’t serve us well?
How can we make planning more effective?
Lost deals or lost customers
Examining why a sales deal was unsuccessful, or why customers stopped using the product, can help you identify patterns and trends. As you look back on lost deals and lost customers, ask yourself:
What caused this prospect to pick a competitor instead of us? Or, why did our customer decide to stop using our product?
Were we aware that this miss was going to happen? Why or why not?
What can we do next time to prevent customers like these from leaving us?
What did we try to do to keep the customer? Where did our approach fail?
Won deals
Examining our successes in greater detail can enable us to replicate them more effectively and reliably. When we reflect on won deals, our team can discover:
Which kinds of value propositions work best, for which kinds of customers?
What did this particular customer care about the most?
Who were we competing against, and why did the customer choose us instead of them?
What kinds of things are we doing that didn’t really help with winning the deal? What are some ways that we can identify these low-value tasks and remove them?
Applying retrospectives to yourself
While retros are typically run with teams, we’ve found that running self-oriented retros can provide significant value as well.
These self-retros don’t have to be long, and you can typically wrap these up in 5-15 minutes. Don’t feel like you have to create any documentation for your self-retros, though you certainly could if you’d find it valuable to look back on.
For self-retros, you’ll still need the three core components we identified above: what went well, what could have gone better, and what you’ll do differently next time.
Here are the kinds of places where you can apply retros to yourself:
Ongoing productivity
Professional development
PM interview practice
“Oops” log
Ongoing productivity
Your productivity as a product manager is a key input into the productivity of your teammates. Therefore, taking the time to reflect on your work habits and your ability to get things done can pay strong dividends over time.
On a daily or a weekly basis, spend about 10 minutes reflecting on the way that you’re using your time at work. In which areas did you feel that you spent time well? In which areas did you feel that time could have been spent in better ways? What kinds of things can you do to improve your time management and your productivity?
I personally find it helpful to identify the kinds of things that stress me out as well as the kinds of work I find energizing and enjoyable. From here, I then dig into “why does this make me feel the way I do?”, which then helps me better understand myself and identify areas of improvement.
We teach more about productivity tactics in our monthly classes - be sure to check these out, and don’t forget that you can use your professional development budget at work to expense them!
Professional development
Being a product manager means taking charge of your own growth and development. By periodically reflecting on your progress and confirming that you're still pursuing the goals you've set for yourself, you can minimize the probability of career-related angst and ensure that you’re iterating towards PM fit. I suggest doing a check-in every few months.
Here are some questions to ask yourself during your check in:
Which kinds of outcomes did I get, and how did I get these outcomes? What am I proud of accomplishing, and where did I fall short?
What are the barriers that prevent me from doing more? Which resources can I use to help surpass these barriers (e.g. coaching, mentors, classes)?
Did I overestimate or underestimate the progress that I would make? How can I be more accurate in planning out my professional development?
Am I getting the mentorship I need? How can I gather more feedback about my performance, and gather more guidance in tough or ambiguous situations?
Interview practice
One of the most common issues I see when candidates prepare for PM interviews is that they rush through as many questions as they can, rather than taking the time to learn from their results. While they might feel productive in the moment, their actual skill hasn’t improved much over time.
When helping my clients through PM interview coaching, the very first thing I ask of them is to start taking the time to reflect on their interviews, as this exercise is a strong predictor of whether they’ll succeed or not.
When preparing for PM interviews, use retrospectives to quickly learn from your performance. Ask questions like these:
What did I do well in this practice round? How do I keep these good habits and good behaviors for next time?
What could I have done better in this practice round? What will I change for next time, and how will I make that change?
If I saw someone else doing what I did, how would I have evaluated them? Why?
Oops log
Everyone winds up making mistakes, no matter how much experience they have in product. That’s why it’s helpful to run retros on mistakes when you learn about them, so that you can identify patterns.
I keep a running log of small mistakes I make - the kind where you might say “oops!” or “darn it!” - and this oops log helps me remember that I can always improve.
When keeping an oops log:
Mistakes aren’t something to blame yourself about, because blame creates negative emotions and can lead to paralysis, denial, or self-destructive behavior
The goal of the oops log is to find ways to create systems, processes, or checks to help you reduce the frequency and severity of mistakes
That said, you can’t spend infinite time and energy preventing mistakes; “oops prevention” is an exercise in ROI, so it’s okay to let small mistakes go
Give yourself praise for mitigating mistakes and reacting quickly to them, and look at how you can keep mitigating them or reacting more quickly next time
Closing thoughts
Reflecting on your previous work is a solid way to strengthen your product management skills. Retrospectives can be utilized in any area of product, not just the ones we've outlined here. By being thoughtful of our activities, we and our colleagues can make amazing strides!
Thank you to Pauli Bielewicz, Mary Paschentis, Goutham Budati, Markus Seebauer, Juliet Chuang, and Kendra Ritterhern for making this guide possible.
