agile

Relationships of a good Product Owner – part #2

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

In my first blog post on this topic I explained how important it is for a Product Owner to maintain five key relationships within and outside of his product organisation. In this second blog posts I want to present archetypal Product Owners with their good and bad character traits.

Tom – the techie

Tom is, by experience, a very good software architect. He stood out in the teams he worked for in the past. Naturally his ambitions are higher. He wants to start his own software company soon. For that he feels that a good next step is to become a Product Owner.

As you can see in his profile above, Tom believes that his technical experience will help him leading his Teams far better than any business Product Owner would do, simply because he understands the technical language of his developers.

Where Tom lacks experience is clearly the business aspect of the Product Owner. Tom needs to improve on this part of his new role quickly! And he should be prevented from still making technical decisions, for the Teams.

Expression of his relationships
Tom’s five relationships

Carl – the control freak

Carl used to be a good project manager. Well, times change, and so he must adopt to new roles. He believes that the Product Owner role is the next step in his career. He managed projects in the past, now he manages a product!

What Carl did not understand yet is that responsibilities are divided differently in Scrum compared to waterfall projects he managed in the past.

Carl must learn to measure “success” with real quality features delivered each sprint that are of high customer value – and not that he delivered something in time and budget.

Expression of his relationships
Carl’s five relationships

Peter – the patriarch

Peter is a self-made man. He founded the company and created the product from scratch. Because of that he feels he knows everything about the market and his product.

Peter’s strength is his experience on the business level. Nobody in the company will have this knowledge on that level. But, Peter does not spend time with his Teams. He travels from one customer to the next, making phone calls with his organisation while in the car. Peter must attend prioritization and refinement meetings with the Teams in order to get his business knowledge across to the Teams.

Expression of his relationships
Peter’s five relationships

Wendy – the waiter

Wendy is new to the job of a Product Owner, both from her domain knowledge about the product and from her agile experience. She does not want any disputes between all parties, she sees herself as the intermediary between customer requests and the Teams – without making decisions herself.

Clearly, Wendy misses the leadership skills required for the job of a Product Owner. Furthermore, Wendy needs to understand the business quickly in order to be “ready” for making decisions as a Product Owner. Passing through requests directly to the Teams is not enough, her decisions need to be validated and prioritized from a business point of view.

Expressions of her relationships
Wendy’s five relationships
Conclusions

Having a good relationship with your “partners” as a Product Owner is worth working for. But, it takes two to have a good relationship, the Product Owner and his counterparts.

Therefore the Product Owner must constantly reflect on these, based on the responsibility and accountability he must live. A good practice is probably to review these relationships from time to time, maybe together with the Scrum Master, and identify activities to work on from tomorrow on.

Upcoming

In my third and final blog post of this series I will guide you through a system model exercise. The results of this exercise will give you as an Agile Coach hints what to look for in order to improve your Product Owner’s relationship.

2 thoughts on “Relationships of a good Product Owner – part #2”

Leave a Reply

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