Product managers aren’t just responsible for shipping a product. We’re also responsible for building the engine that builds great products. In other words, we build processes, best practices, and cultures around what makes a good product.

To strengthen this engine over time, one of our most valuable tools is the retrospective. It enables us to identify what’s good, what’s bad, and iterate towards better and better products and processes.

In this article, I’ll define what a retrospective is, how to conduct one, and how to apply it to various aspects of product management.

Let’s dive in!

Definition of Retrospective

The word “retrospective” is made up of two roots – retro and spect.

Retro means “backwards”, and spect means “looking”. Therefore, a retrospective quite literally means to look back on some period of time or some set of actions.

Of course, if all you’re doing when you look back is to relive the events without critical thinking, you won’t actually drive improvement.

A good retrospective should identify what was good, what was bad, and what can be improved.

In fact, there are 4 core elements to any retrospective, regardless of what context you use it in:

1. Identifying what was good, and therefore what should be kept for next time
2. Identifying what was bad, and therefore should be mitigated in the future
3. Coming up with next steps to maintain the good and to mitigate the bad
4. Confirming whether the next steps from the last retrospective were implemented

Now that we know the 4 core elements, let’s talk about how to conduct a retrospective.

How to Conduct a Retrospective

Traditionally, retrospectives are conducted on sprints. So, let’s walk through what a sprint retrospective looks like!

First, you need to identify the right participants. When conducting a retrospective, you need the people who were immediately involved to be part of the retrospective.

You don’t want to leave out critical attendees, since you need multiple perspectives in the room to accurately identify all of the good and all of the bad, and you also want people who can implement next steps.

But on the flip side, you also don’t want to involve too many people, since that dilutes the impact of each voice in the room.

It’s up to you to strike the right balance. Generally, for sprint retrospectives I’ll bring in engineering, design, and QA.

Second, you need to have a way for everyone to see what you’ll be writing down. I suggest using a whiteboard, or projecting with a computer. You’ll want to log all 4 elements of the retrospective in a way where the entire room can see it, so that everyone’s on the same page.

Now you can kick off your retrospective. Remind everyone which sprint you’re reviewing, and display the sprint plan so that attendees have something to refer to.

Acting as a facilitator, start the retrospective by asking the group what they thought went well over the last sprint.

I usually find that attendees are shy to start. Most people aren’t used to claiming credit or to praising themselves. To break the silence, I’ll compliment someone genuinely and thank them for a specific contribution they made.

Here are some concrete examples of “things that went well”:

• One of my teammates helped onboard another teammate, which meant she ramped up quickly
• One of the features we shipped last sprint made a large impact on a customer, and they’re so excited to use the product
• One of our projects is moving faster than planned due to innovative thinking from the entire team

Encourage the team to thank one another, and to claim praise for themselves when working on difficult initiatives.

Then, from there, ask the group what they thought went poorly.

Again, the room will usually be quiet – most people don’t like to share bad news.

Retrospectives are blameless. It’s critical to identify what was bad, without assigning owners or blame. Remind people that the goal isn’t to blame, but rather to diagnose and jointly improve.

If I’ve got a silent room, I’ll help nudge by sharing something that I thought I could have done better.

Here are some concrete examples of “things that went poorly”:

• One of the JIRA cards that I wrote didn’t have enough information, which meant that the assignee struggled to understand what was needed
• We as a team failed to meet a particular deadline
• A customer discovered multiple preventable high-impact bugs before we did

Now you should have two sets of information – what was good and what was bad.

The team can now brainstorm ideas for what we can implement for the next sprint. Note down each idea, and then ask the team to commit to one idea to implement.

Finally, close with a review of what your last retrospective looked like. Did the team implement the next steps that came from the previous retrospective?

If so, what were the results? Should the team keep doing what was newly implemented?

Once you’ve gathered all 4 elements of the retrospective, compile them into a centralized document such as Confluence or Google Docs, and publish it for the team to be able to refer back in the future.

Congrats on completing your first retrospective!

As you run more and more retrospectives, you’ll create a virtuous cycle. Since each retrospective builds on top of previous ones, your team will get better at creating new value from each retrospective.

Applying Retrospectives

Retrospectives are extraordinarily powerful because they enables you and your teams to continually grow, experiment, learn, and reflect.

But retrospectives aren’t just limited to sprints. You can hold a retrospective on just about anything. Here are a couple of areas where I’ve found retrospectives to be incredibly valuable.

Quarterly Planning

Most product organizations have some sort of future-looking planning to help them identify their roadmap, and to align internally and externally on priorities.

Of course, planning is incredibly expensive – it takes lots of time from lots of people. Even more dangerously, if a plan isn’t sufficiently flexible, it can lock an entire team or an entire company into a bad set of actions for much longer than intended.

Therefore, it’s critical to conduct retrospectives on quarterly planning, with the following objectives:

• What are the processes that actually yield the most value?
• For processes that don’t yield value, how can we remove them from our next set of planning?
• Were there any key gaps that we missed? How do we avoid those next time?
• Did our plan actually help guide us, or did it slow us down instead?

Product Launches

Product launches are incredibly complex. After all, just about every department needs to be involved, ranging from sales to marketing to support to finance to legal.

With so many moving parts, I’ve found it valuable to conduct retrospectives on launches as well. That way, we can all identify how to launch products more successfully with less internal friction.

When conducting product launch retrospectives, I’m looking to understand the following questions:

• What kinds of launch tactics worked really well for us? What kinds of launch tactics fell flat, and why?
• Were we all on the same page on timing, audience, and value proposition?
• Could we have made handoffs smoother? For example, how do we ensure that design can provide marketing with enough lead time to create collateral, and how do we ensure that engineering can provide QA and support with enough lead time to prepare for the launch and ensure robustness?

Won Deals

By diving into our successes, we can learn how to replicate them with less effort and with more consistency.

By conducting retrospectives on won deals, your team can learn the following:

• What kinds of pitches worked the best?
• How did we stand out against the competition?
• What did the customer care about the most, and how did we address their pain successfully?
• What are the patterns across won deals? How can we double down on these patterns?
• What kinds of activities didn’t provide that much value? Can we eliminate them next time?

Lost Deals or Lost Customers

By reviewing why you lost out on a sales deal, or why customers decided to stop using the product, you’ll start to see patterns and trends as well.

When conducting retrospectives on lost deals or lost customers, you’ll want to know:

• Why did we lose the deal to a competitor? Or, why did the customer decide to stop using the product?
• Could we have seen this problem coming earlier?
• How could we have prevented this loss from happening, if possible?
• What did we try to do to retain the customer or prospect? Why didn’t our strategy succeed?

Crises

In the midst of a crisis, you and your team don’t have the time to do everything perfectly.

That’s why it’s important to revisit a crisis right after you resolve it, so that everyone can prepare for the next time. That way, each crisis becomes easier to tackle over time.

Try to get answers to the following questions through the retrospective:

• What caused the crisis? Could we have prevented it?
• What went really well? How can we maintain these processes so that future crises are easier to deal with?
• What were the acts of heroism displayed during the crisis? Were these heroes sufficiently recognized? How can we encourage others to also step up in times of crisis?
• Where were there breakdowns in ownership or handoff? Can we resolve these upfront now, so that future crises are less chaotic?

Daily Timesheets

When you track your output and time management on a daily basis, you can identify which areas of time you spent well, which areas of time you spent poorly, and how to improve.

I run a daily retrospective with myself. During that time, I’m looking to learn the following:

• Where was my time best spent?
• Where did I spend my time poorly?
• What can I do tomorrow to improve my output?
• What did I do yesterday that helped make my day today easier?
• What stressed me out today? How can I mitigate the stress?

The awesome thing is that because there are so many working days in a year, I get to run so many different experiments and potential optimizations!

Professional Development

One of the hardest parts of being a product manager is owning your own professional development.

By regularly looking back on your progress, and by checking to see whether you’re still on the path you set for yourself, you can prevent running face-first into quarter-life crises and mid-life crises.

I recommend conducting a retrospective on your professional development every quarter.

What you’ll want to answer for yourself:

• What did I achieve, and how did I achieve it? How can I strengthen my ability to achieve?
• What didn’t I achieve, and why did I miss the mark? Can I mitigate these in the future?
• 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?

By asking these honest questions, you’ll find that your growth will accelerate over time.

Summary

Retrospectives are a great way to build up engines that build better products over time.

The 4 core elements of any retrospective are: identify what’s good, identify what’s bad, plan next steps, and review previously planned steps.

You can apply retrospectives to just about every aspect of product management.

By being thoughtful about all of your actions, you and your team will grow immensely!

 

---

Have thoughts that you’d like to contribute around retrospectives? Chat with other product managers around the world in our PMHQ Community!