The product owner retrospective

The product owner is one of the most elusive roles known to the software creation process. It’s also the most influential role when it comes to a software development team’s output. I would go as far as saying that having this role implemented and performing properly has more effect on the value a team delivers than choosing a programming language, frontend framework, or whatever cloud to run on.

Differentiate between the role of the product owner and the person performing the role.

The most important thing when reviewing is that we differentiate between the role of the product owner and the person performing the role. In many teams, this role is performed by a single person. Sometimes it’s performed by a product manager, product owner, and business analysts. When reviewing we are not reviewing a person’s performance, we are reviewing the execution of the product owner role. Similarly, many development teams are able to review a developer’s code without ‘attacking’ the developer that wrote the code.

Where engineers have a broad spectrum of bachelor’s and master’s degrees backing their daily work, the product owner has to make do with fewer than a single page in the scrum guide. The backgrounds of the product owners I worked with are pretty diverse. Whether this is commercial, technical, philosophical, psychologists, I have worked with a broad range of product owners. Honestly, to this day, I cannot tell you which one is better or worse. In many occasions, it’s a role gained with experience. And this blog is written to offer a self-evaluation tool for evaluating and improving your product owning skills.

The software development community has a strong rhythm of evaluating process, output, and performance. Tools like value stream analysis and retrospectives provide recurrent feedback on our process. Many bigger organizations have organized roles that perform similarly into guilds. It’s common to find all kinds of teams, like agile coaches guilds, frontend guilds, cloud engineering guilds, and testing guilds. Less often you will find similar enthusiasm for product owners to establish themselves, but it certainly happens.

Time for a product owner retrospective

The tool described below can be used as a self-reflection tool. However, I would recommend performing this in a retrospective / intervision session with fellow product owners, or within your agile team.

The format presented above contains activities every product owner should perform. These activities are based on a graphic produced by William Gill which I found very helpful in the past five years. Based on the type of project/product different activities should get more attention than others. For example, the competitive landscape can be more important if you are a generic software vendor like Atlassian, compared to when you are leading an internal authorization platform team. Nevertheless, I found very few situations where I could leave one of them out.

Retrospective facilitation

This retro format is most effective when participants take a decent amount of time to take this seriously. Often it’s not about small tweaks. Anywhere between two to three hours gives enough focus time and allows for sharing ideas about participants.

Let’s go through the steps:

• Prep a whiteboard or create an online session with an empty board as depicted in the image above. Every product owner can have their own canvas.
• Participants are asked to contribute stickies on topics that they feel work out well on the left, and improvements on the right.
• First, validate participants have some idea about the different topics on the board.
• Alternatively, you could introduce them in a previous session if you feel it’s important that multiple product owners have a similar grasp on the same concept.
• Explain how much time is planned to spend on writing ideas. As the list is quite long, it also helps to process it in smaller chunks. You could split it in two times eight items, or four times ten minutes.
• After participants have mapped their work it’s time to analyze opportunities for growth. Take time and help each other to find more ways of improving these activities.

Embedding product owner retro’s

Assuming every team also performs process improvements in a sprint cadence I would advise a cadence close to a quarterly retro or at every six months. These retros can be time-consuming so try to balance the investment. Many organizations have created guilds or special interest groups where colleagues in the same role are sharing ideas. Often you will see front-end, scrum-master, or UX guilds. Following the same logic, it’s a great idea to pair up with your fellow product owners in a product owner guild. Especially when you consider the reasons mentioned in the third paragraph. A lot of our industry’s product owners do not have a ten-year career in doing it.

Originally published at https://www.linkedin.com.