All the Ways Being a Product Owner Is Hard

I have been a Developer, I have been a Scrum Master, but I’ve never been a Product Owner. I’ve been fortunate enough to work with some amazing POs over my career, and watching every single one of them has assured me that I would make a terrible Product Owner.

Being a Product Owner is an incredibly hard role to perform well. Just like with being a Scrum Master, so much of one’s success relies on how well-supported one is and how much respect one receives from colleagues. There’s much that the individual Product Owner is responsible or accountable for that can be easily derailed by someone not playing the game.

I have great respect for you Product Owners, and here are all the ways that I think your role is hard.

The Visionary

The PO looks after the future of the product. Sure, you care about the current state of it, but you have a laser-sharp focus on what the product will look like in a sprint, a quarter, perhaps even a year. You have to continually Inspect and Adapt the product goal so the rest of the Scrum Team and the stakeholders understand what you’re trying to achieve.

Although you’re working with the Development Team, you’re concerned about the desired outcomes and not the features or implementation. You need to talk to the Developers with understanding and yet keep yourself separated from the work they’re doing so you can be the Scrum Team’s focus on the bigger picture.

Product Owner Backlog Guard

You hold the keys to the kingdom by owning the Product Backlog. You choose which items are added, removed, and worked on next. Your Backlog details how the Scrum Team currently thinks they’ll make your vision a reality. This means pressure from a multitude of angles, though.

Your stakeholders, the Development Team, your bosses: everyone thinks they have the right to tell you what the Product Backlog should look like. Just because you’ve created a Product Backlog Item for something one of these people wants to be included in the Product, don’t think that they’ll leave you alone. Now they want to know when it’s going to get to the top of your Backlog.

When something does make it onto your Product Backlog, you nail it down as much as possible. As time moves on to a point where the Development Team is likely to be able to work on a PBI, you ensure that it’s written with as little ambiguity as possible. No PBI is ever going to be perfect, but it’s your job to make sure it’s close.

Value Maximiser

You take that beautiful Product Backlog that you’ve guarded so well and make decisions about value. You have to remain Transparent so the Scrum Team and your stakeholders understand why you’ve ordered the Backlog the way you have. Everyone wants to know how you define value and how you calculate which Product Backlog Items have the highest value.

Customers

Everyone around you thinks they know the customer as though they are the customer. You want to release the work of the Development Team as quickly as possible so you can start generating insights into how users interact with the Product. Once you see some data, you alter the Product Backlog so it better reflects your new understanding of the Product.

Evidence-Based Management

Everyone in Scrum loves metrics, and the Product Owner is no different. You care about customer satisfaction and the cost of delay. You look for metrics that help you understand the value of your Product so you can better order your Backlog. Value is hard to quantify, and if anyone can do it, it’s you. My favourite metrics that I’ve seen a PO use are:

·?????? Feature Usage Index

How much functionality of the product is being utilised?

·?????? Installed Version Index

What percentage of your customer base is on your latest release?

·?????? Innovation Rate

How is your budget split between building new functionality, maintaining existing functionality, and expanding capabilities?

·?????? On-Product Index

How much team time is spent working on product and value?

Supporting the Development Team

So much is said about how the Scrum Master supports the Development Team, but I rarely see anything singing the praises of the Product Owner’s dedication to them. Unfortunately, I more frequently see Developers and Scrum Masters berating the Product Owner. I’m here to change that…

You support the Developers when they’re creating their Sprint Backlog to help them not over-commit. You look at the scope of their Backlog and lovingly question if they’ve got the right amount of PBIs on it.

Product Backlog Items aren’t just a set of requirements that you and the stakeholders have written to the Developers, dictating the work that needs to be done. You have sat with the Developers on numerous occasions to co-create the Acceptance Criteria for every single one. By working so closely with the Developers, you have created trusting relationships with them.

You also recognise that although you’re of great benefit to both the Developers and the stakeholders, you don’t want to be a bottleneck for communication between them. You have spent time helping to build relationships between the two groups so that when you’re not around, they don’t have to wait for you to ask each other questions or provide answers.

The Single Point of Accountability

You are accountable for so many things that I could write a whole article on your accountabilities alone. You ensure quick decision-making, you provide clarity and focus, and you eliminate wasteful delays. I’ve reduced everything that causes you stress and that you are a lightning rod to protect the rest of the Scrum Team into one sentence; apologies for such brevity.

Sprint Canceller

When the sprint goal is obsolete, you’re the only person who can cancel the sprint. We know you’re going to listen to the rest of the Scrum Team before you do so, but you alone bear the weight of being the person who says the sprint is over early. Here’s hoping you get to cancel more sprints because the Development Team has delivered earlier than expected than because you’ve realised you’re going in the wrong direction.

Organisational Respect Required

We all like to be respected by others in the organisation, but without it, you really can’t do your job. No one is allowed to give the Development Team direction based on a different set of requirements than those in the Product Backlog. The Development Team is not allowed to act upon what anyone other than you say. For this to stay true, both the Development Team and the wider organisation need to respect and uphold your authority.

Thanks, Product Owners. Keep doing a great job.