Any self respecting developer or product person will be doing team retrospectives on a regular basis. These retrospectives provide a great opportunity to reflect on past releases, build team dynamics and identify any areas which could be improved.
However, I’ve found product retrospectives to be a lot less common. Let me first explain what I mean by “product retrospectives”: a regular opportunity for a team to reflect on the product or service. This is explicitly not about the team or process improvements, it’s all about the product:
- How is our product performing (or not)? — I appreciate that many of us will monitor product performance on a daily or even hourly basis. However, there might people in your business who don’t keep track of recent product releases or performance. They might also not be au fait with the assumptions — business and user — which underpin a particular product feature or improvement.
- How are we doing against our roadmap and business objectives? — This is an opportunity to look at the bigger picture and review progress against key roadmap milestones and success factors. What have we been doing (and why)? What’s coming up and what’s the impact that we’re expecting?
- What are our users saying? — If you’re getting user feedback on a regular basis, I find product retrospectives a great time to share user learnings and insights. This can be as simple as sharing excerpts or quotes from user feedback sessions or a video of users testing your product remotely .
- What’s happening in the market? — To avoid looking at a product or proposition in isolation, I always try to look at competitors as part of a product retrospective. What are our competitors doing? Why? Similarly, I also like broadening perspectives by learning from businesses in different sectors or markets.
- What product ideas do you have? — Facilitating a product retrospective isn’t a one way street. It’s also an opportunity for the people in the session to provide their suggestions based on the data and learnings that you discuss with them.
As with regular retrospectives, this is how I typically structure my product retrospectives:
- Set the stage — I’ll outline the goal for the retrospective, identifying both the desired outcomes of the session as well as what I expect to cover. For example, I will explain how we will use the product retrospective to further shape the product roadmap and that some concrete product objectives are a desired retrospective outcome.
- Gather data — To create a shared picture of what’s happened or is happening, I’ll start of by presenting hard facts around releases, roadmap progress, business objectives and key results. I’ll use these facts as a starting point for discussion, facilitating a conversation around data, underlying assumptions and problems to address.
- Generate insights — This part of the product retrospective is about asking “why” and thinking about what could be done differently. At this stage, I’ll talk about qualitative user feedback and we’ll discuss the “why” behind some of our insights.
- Decide what to do — At this point in the product retrospective, the audience is likely to have some product ideas or suggestions worthy of further exploration. From experience I’ve learned that the format of a product retrospective doesn’t lend itself particularly well to a lengthy discussion about the merits of a product idea. However, it’s a great opportunity to gather thoughts and to prioritise ideas for further discovery.
- Close the retrospective — This is where I tend to do a quick recap of the main insights and actions discussed during the retrospective. I’ll also ask if there are any specific items that the audience would like to see covered in the next product retrospective.
Main learning point: Hopefully you can see how easy it is to to do a product retrospective and the benefits you’d get from doing this on a regular basis. I’ve done product retrospectives with single teams (e.g. development teams or marketing teams) but have also run them for ‘multi-disciplinary audiences’ (i.e. members from different teams in one room). In both cases, you’ll be able to create a shared understanding of product performance and get valuable feedback to help move your product forward.
