agile

Relationships of a good Product Owner – part #1

Why good relations inside and outside of a product organisation are key to the success of a Product Owner.

Scrum failures are common

We all have seen failures in adopting Scrum in an organization. And hey, it’s part of the whole concept to fail fast, use inspect & adapt and correct it the way you think is best. Typically large organizations face challenges in adopting Scrum at a large scale. There are various reasons why agile adoptions do not create the effects you wished for — flexibility in the development, code quality, self-learning development teams and more.

In such cases we normally try to find out on a team level what we can improve. But seldom do we investigate in the Product Owner’s role and how it was lived during the agile adoption.

In this series of 3 blog posts I want to explore how Product Owners behave according to typical patterns and archetypal habits and how to overcome their flaws within the organisation.

The role of a Product Owner

The product owner’s responsibility is to maximize the value of the product resulting from work of the development team(s). Yet, Scrum does not tell how product owners should act to reach maximum value for their products. This is up to the agile organization to decide how to achieve this.

Also product owners “own” their product backlog. They ensure that all product items in the backlog are ordered according to the set goals and value created by each item. Product owners are accountable to make the product backlog visible and transparent and are there to help the development team understand the items they need to implement in the upcoming sprints.

An important principle to note is described in the Scrum Guide:

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

Five relations

In large-scale agile organisations a Product Owner must constantly work on five important relationships influencing the success of an agile adoption:

The backbone of the organisation

The Product Owner and his Teams own the product together. In a trust-worthy environment the Teams implementing it product will take on real ownership of the product too.

That of course requires a close relationship between Product Owner and the Teams. Good Product Owners visit the Teams regularly but do not micro-manage the Teams. Instead, they work with them during Refinements, Sprint Reviews and Retrospectives.

The window to the outside

Without involving customers and users a Product Owner would not be able to create real customer value in his product. Even broad market knowledge would not be enough to succeed with a product because the customer gives feedback if the product is valuable or not.

Thus, Product Owners must closely work together with the customer base and need to be transparent about what they are planning to deliver but also listen to their customers in order to learn more about their goals and problems.

Customers also need to be aware that their product is developed according to Scrum. The Product Owner educates his client base about his agile way of working and why this is beneficial to them, shipping every sprint. A good Product Owner in a large-scale development organisation will invite customers to Sprint Reviews or Refinement Sessions with the Teams.

To own or not to own

Higher management must give their Product Owners the accountability and responsibility for their Product’s success. If this is not the case the Product Owner will not have full authority to make decisions critical to the Product, e.g. hard business decisions or decisions about resources.

Nevertheless, future Product Owners must do a self-assessment in order to find out if they are capable to do the job. Even if management lets them, will they take over full ownership of their product? How much do you want to bring about change? And finally, are you the one who makes the executive decision?

If you are confident about the above you will automatically be on eye level with your management and maintain a good relationship with them.

Be frank and listen

The relationship to the Scrum Master(s) is different. It is not about product domain knowledge, it is about how to act as a Product Owner and how to improve on that.

As the Product Owner you need to be frank with the Scrum Master in order to overcome concerns and impediments you might have in your role. The Scrum Master is a coach for the Product Owner, he needs to know what’s bothering him.

On the other side the Product Owner must be open to listen to the advices a good Scrum Master can give him. Reflecting on situations is also a good practice of a Product Owner. This way he is able to tell the Scrum Master about his concerns.

Introduce your Teams

It is a very good practice when Teams talk directly to their customers and users. This helps getting an unfiltered view of how customers see the world. Although this is still unusual for many companies it truly helps the Product Owner doing the job, especially in large-scale development organizations.

With many Teams to “feed” with feature requests for a big product a Product Owner is quickly overloaded with work. Time spent with Teams is rare to achieve. That’s why the relationship between Teams and their customers is so valuable and important. It helps reducing the Product Owner’s work in the product organization without loosing the main responsibility.

Product Owners must ensure, that this relationship is lived by actively connecting both sides, invite them to business meetings and, if required, educate the Teams how to approach/talk to the customers.

Upcoming

In the second blog post of this series I will focus on different archetypes of Product Owners pointing out their strengths and weaknesses doing their job.

1 thought on “Relationships of a good Product Owner – part #1”

Leave a Reply

Your email address will not be published. Required fields are marked *