How I run remote product retros

Retros are a staple of the product management arsenal.

Whether you run the standard sprints or funkier product frameworks like Shape Up, at some point you need to look back on your performance and see if you could have done anything better.

This is when retrospectives (aka retros) come in.

I've tried countless retros formats. While there isn't a 'right' retro format, if you're struggling this one will give you a huge head start.

You can make a copy of my retro format here: https://docs.google.com/document/d/1ZEG4UnFcXwEoiDq6dduyQzKhKrPbiORTyYwnitfT4Hw/edit?usp=sharing

---

Remote, in-person, or hybrid?

I currently run a hybrid product team (5 in office, 3 remote). My previous team was fully in-house.

The format below worked for both.

Template

I like to start with the obvious: what day is it and who's present?

This keeps me organised, simple as that.

The attendee list is also a reminder to ensure everyone on the call contributes. If I notice someone's attending but not participating much, that's a red flag.

Previous actions

In this section, I list the actions we agreed to take in our previous retro(s). In Confluence, I'll list them as to-dos.

At the beginning of the retro, I go through each item and tick those we achieved.

This is an important section; arguably the most important.

Retros are only worthwhile if you learn from them. You only learn from them by listening to the team's feedback and actioning it.

If you don't action feedback, the usefulness of your retros goes down to zero. Good luck getting your busy team to attend a useless meeting. They've got enough on their plate.

Conversely, if you show you've listened to and actioned feedback, the team will continue to see the value in contributing.

Retrospective

This is the meaty part of the call. I create a table with three columns:

1. Contributor. Each attendee gets one row.

2. What went well. Each attendee talks through positive things that happened in the last cycle.

3. What didn't go well. Each attendee talks through negative things that happened in the last cycle.

Each attendee contributes, one by one. It's a chance for everyone to speak up. It can be awkward to 'force' feedback, but you must push through it.

Not getting feedback from your team is worse than the pain and awkwardness of asking for it. Trust me.

If you listen and action the negative feedback, you will see it recycled in the 'what went well' section. This is a good sign. You're on the right track.

The 'didn't go well' category is, of course, where most of the learning happens. Take copious notes. Drill down to understand the core of the issue instead of the surface-level complaint.

For example, a developer may raise the following negative: "I struggled to review this PR and was blocked for 2 days trying". This doesn't sound good. But in itself, this doesn't provide any actionable feedback.

It's your job to drill deeper. Why was it a struggle? Who did you ask for help? Why couldn't you get any help? Continue to follow up until you uncover the true inefficiencies. You can then turn these into actions in the next section.

Actions

In this section, list the actions you've extracted from everyone's feedback. In Confluence, I list them as to-dos and tag the person responsible for each to-do.

These should be clear actions. The actionable kind of actions. Stuff people can, you know, action.

For example:

• “Alex to update the documentation on PR review process.” Great!

• “Steve to remember to write tests.” Not great.

• “Sarah to invite new team members to Confluence so they can read PRDs.” Great!

• “Hannah to communicate better.” Not great.

You get the gist. Someone must be able to pick up the action and do it. You (the PM) will also be responsible for tracking its completion. If you can't tell whether someone has 'done it' or not, it's not a good action.

Beware of managerial or behavioural 'actions'. Things like "John should communicate better" or "Peter to make sure he is on time at stand up" are traps:

1. As the PM, you are running this meeting but you are (likely) not the attendees' manager. It's not your role to fix behaviours.

2. Most of those cannot be tracked or achieved.

Once the meeting is over, start actioning the tasks. At your next retro, copy these actions up into the first section on your next retro; and the cycle continues.

Cadence

Your retro cadence depends on your product cadence. I've tried a bunch of different variations and they all have their pros and cons.

My basic recommendation is to schedule your retros:

1. After each development cycle (e.g. in standard SCRUM that would be every 2 weeks, in Shape Up that would be 6 weeks, etc.).

2. After deployment. The entire cycle must be over. Deployments may uncover issues, delays, or grievances.

3. At a time when everyone's available. This can be tough with remote teams but everyone must be on the call.

4. For about 60min. You may not need the whole hour.

Miscellaneous tips on running retros

Having run retrospectives for many years, here are a few things to look out for.

1. While you will spend most of your time discussing negative stuff, take time to celebrate the wins. Positives are important, too. Congratulate the team and proactively point out positive things you have seen.

2. The devil is in the details. Ask everyone to be specific with their feedback. "This sprint was tough" isn't feedback. Drill, drill, drill until you understand why.

3. Include everyone. This is surprisingly hard. Some team members are naturally more shy, don't want to share in public, or are content letting others talk. Be on the lookout for this. Everyone should contribute.

4. Get involved. As a PM, you are also part of the feedback loop.

5. Be prepared. The first 10 minutes of the call will be on you. You should know where you got to with the previous actions and have your own feedback prepared.

6. Action the feedback. I can't stress this enough. The moment you treat retros passively, you'll lose your team's interest. Everyone's very busy. Make their feedback count.