Running product retrospectives
Iterate on your processes as often as you do on your product; they will help you improve it faster.
Published on September 22, 2016
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 agendaHere’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.