Catrine Björkegren: the “my product is the most important” anti-pattern in the Product Owner role

In this episode, we introduce a new set of questions. Two questions that help us understand some of the most common anti-patterns in the Product Owner role as well what great Product Owners look like.

In this episode, we talk about a Product Owner anti-pattern related to the PO’s relationship with other PO’s in the organization. We discuss the “my Product is the most important” anti-pattern!

The Great Product Owner: When a Product Owner is able to bring in the business perspective and trust the team to find out what’s the best possible technical solution.

Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.  

About Catrine Björkegren

Agile coach and scrum master, Catrine has worked with agile for a decade in various areas like education, nuclear waste, government agencies, pharmaceutical and at the Royal Swedish Opera.

She believes that co-location is the key to building teams and that leadership is the key to successful agile transformation.

You can link with Catrine Björkegren on LinkedIn and connect with Catrine Björkegren on Twitter.

2 thoughts on “Catrine Björkegren: the “my product is the most important” anti-pattern in the Product Owner role”

  1. Thank you Catrine!

    One challenge may be that delivery teams are tasked across multiple departments. How many people end up in these meetings? There could be dozens of people in a chain reinforcing some aspect of the priority making.

  2. Thank you for commenting!
    Yes, it can indeed be a problem that the team(s) have many stakeholders or other people involved in prioritizing.

    At these meetings at this client the participants were: around 6-10 stakeholders, the head of development and the scrum master that facilitated the meetings. This was an internal IT department so the stakeholders in these prioritization meetings were product owners for the products we developed and maintained, or project managers for bigger projects. Not all of them were present in every meeting because of the overall priority of the company.
    One important factor for making the priority meetings successful was that we always discussed priority for the company as a whole.
    Another factor is that the stakeholders learned that when the teams could focus on one project they would deliver. So if their product or project was not priority right now for the company as a whole, they would feel safe in knowing that when the time came for their product they would get the teams focus and would get things delivered fast.

Leave a Reply

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