Placeholder

Running product retrospectives

Iterate on your processes as often as you do on your product; they will help you improve it faster.

Woman running product retrospectives in person

Matt Drozdzynski

Retrospectives are common practice of many agile teams. If you are an engineer and have ever been a member of a Scrum team, you probably took part in one. Sadly, they are not that common amongst non-engineering teams.2 years ago, my co-founder and I set ourselves a goal of improving the company every week. Not our services, not our products—the company itself; how we work.For a year nothing happened. We tried, but iterating on the company was a nebulous goal that always seemed out of reach. That’s until we introduced retrospectives. In one form or another, each team would meet every week to talk about what works and what doesn’t work about_—well—_the way they work.

The agenda

Here’s how Pilot’s product team runs their retrospectives:1. We meet every 2 weeks on Friday for 1 hour to do a team retrospective. The meeting more often doesn’t leave enough time for implementing changes; less frequently to see benefits of quick iterative improvements.2. Broadly speaking, there are three areas that we discuss: infrastructure, processes and tools.
  • Infrastructure is mostly improvements to how we write code and how to deploy it. Changes to our design system also fall under this category.
  • Processes are about how we work. How do we go from user research, feedback and ideas to fully deployed features in the shortest amount of time and with minimum friction.
  • Tools are things that we use to get our work done. Discussing whether to switch from Google Hangouts to Zoom, or whether to move from Trello to Asana fall into this category.
3. Everyone can add to our Product Retrospective project on Asana at any time. We often note down individual observations as we go along, and then discuss them as a team.4. Before the meeting, each of us nominates topics to discuss. There is no voting, no censoring. However small an issue, if you choose it as your topic, we will discuss it.5. We start each meeting by reviewing action items from previous retrospectives. Sometimes things need a little nudge to move along. And if they don’t for long enough, it usually means they weren’t important enough—so we put them on hold.6. Then, each of us takes turns to discuss the topic they nominated. It’s important to allocate roughly equal amount of team for each member to speak themselves out. Otherwise the meeting will be domainated by the most vocal team members.7. If you can, bring an external facilitator to help chair the discussion. We haven’t tried this yet, but I think it has the chance to make for a more balanced discussion if the facilitator keeps the team lead in check.8. After the problem is defined, we discuss potential solutions. We try to start with low-cost low-risk solutions first—more often than not they’re enough to solve the problem.9. Once we know what the potential solution looks like, we write down next actions, divvy up work, and move on to the next topic.It’s important you don’t take on too much in each session. Focus on incremental, achievable improvements.This is the only way to keep improving from retrospective to retrospective. Otherwise pending action items keep piling up, everyone gets demotivated and the progress stalls.---We never quite figured out what to do to meet our original goal. Only a week or so ago, in an casual chat with my co-founder, we realised that it just happened. And I think retrospectives are a big part of it.

Related articles

From startups to large corporations, US companies of all sizes use Pilot for international payroll, benefits and compliance.

All articles

Want industry news and product updates?Sign up for our newsletter.