7 Skills You Need to Be a Great Product Owner

image of a product owner helping an agile Scrum team succeed

As you learn about Scrum, you'll find that it is great at defining roles. A product owner, for example, owns the product backlog, creates user stories, and interfaces with stakeholders as well as the Scrum team. That's all true, but what does it take to be a truly effective product owner?

To explore that, we turned to Lowell Lindstrom, a Certified Scrum Trainer® and one of the early pioneers in Agile software development. Over the past 30 years, he has worked with and coached many product owners. In his experience, the people who are best suited to the role thrive on accountability, visibility, and the art of negotiation.

But there are nuances to those particular qualities. According to Lindstrom, the great ones have seven abilities that surpass the generic "Be a good communicator" or "Be available" requirements that could apply to just about any job out there. Spoiler alert: If you hate conflict, this role is not for you.

Customer Delighter

As a product owner, you're not just an administrator, taking whatever the stakeholder says and adding it to the product backlog. Sure, you have to listen to what your stakeholders want, but you have to do more than process information — you have to discover those latent needs that your customer or user hasn't even imagined.

Lindstrom, for example, just started using a new email client and was delighted to discover it had a feature allowing him to easily convert an email message to a PDF. No more converting it to Word first or changing the "destination" option within the print function. Clearly, the team that created this feature had thought beyond the usual requirements of email.

Storyteller

Great product owners go beyond the mechanics of chopping up a user story into the product backlog and sending it to developers. As a product owner, your mission is to think about what will transform that story into a product feature that — you guessed it — delights the user.

Let's take another email example. Say a backlog item for a ridesharing company is to provide a receipt to users via email. What is the broader story? Maybe the user is a busy person on the way to the airport, and she needs to create an Excel expense report based on that receipt. If that's the case, you can think of additional information that will be helpful, such as payment method (PayPal or credit card), document options (e.g., PDF), pick-up and drop-off location, distance traveled, etc.

Delegator

Let's be honest. Even though only one person is supposed to be the product owner within the Scrum framework, it's almost impossible for a single person to manage everything alone. If things start slipping through the cracks, you start to see teams creating additional parallel roles. For instance, a team may create a technical product owner role to compensate for product owners who don't see themselves as the team leaders.

To survive and thrive, you need to delegate and ideally build an informal team that will help you. Wait, doesn't that sound like the Scrum team? Well, yes and no. The team could include the ScrumMaster and various members of the product development team if you want it to. But it's a separate, informal product owner team that can help you with various responsibilities, especially the ones where you may not be the expert.

Developer

It's no mistake to say you're a developer, too. In Scrum, we get hung up on carefully delineating roles. That's helpful for teaching Scrum, but not always as helpful in practice. Roles can become so overstated that the focus moves away from the value being delivered to who does what. As a product owner, you may think, "I own the product backlog. I own the user stories. I give them to the development team, and they develop them." True, but guess what? You're part of a team. You’re not just a team leader.

It's the entire team that delivers value. If you see yourself as part of the development team, where your responsibility is guiding what should be built, you'll end up with a healthier collaboration.

Knowledge Broker

Just as you are a developer, you are also a knowledge broker. Yes, you represent the product backlog and you are the interface between the development team and the stakeholders. But you're not necessarily the definitive expert on the product. So the developers writing the code may not get very far by talking to you to get user story details.

Instead, they should be talking directly to the experts, the stakeholders for the users. Your job should be to enable collaboration and empower the developers by finding the right people for them to talk to. Now, if those discussions bring about changes to the requirements, absolutely, you should be in the loop. If not, put the developers in the driver's seat so they can get the information they need.

Conflict Resolver

If you can't handle conflict, you're in the wrong game. In product development in particular, we're dealing with an inherently conflict-filled situation. This is especially true when people are fighting over resources and politicking, as they will do. So the better you are at resolving conflict, the less you will have to escalate (see below).

As a product owner, you have to have the courage and the capability to engage when things get difficult. And know this: you generally have to go through conflict to get to a solution. You'll need to be collaborative to minimize the negative, and you'll need to mediate.

Effective Escalator

Inevitably, no matter how good you are at resolving conflicts, you'll need to escalate something up the chain of command. This is not about personal squabbles, like little kids whining to Dad, "He hit me." Escalation is feedback to management that management has deployed conflicting goals. For example, take two stakeholders who have tasked the same team with two different goals that don't fit. That's conflict, plain and simple.

The best product owners have a conflict escalation mechanism ready to go. Of course, you'll try to sort things out as best you can with stakeholders, but you'll also have the cultivate the ability to go up the management chain and back down again. Don't wait until you have a crisis before you build and test your escalation path. Look for opportunities to escalate small (yet applicable) things very quickly so that you get good at this. Then, when the big things come in and the stakes are high, you'll be ready to escalate with ease.

There are many more skills that, as a product owner, you could cultivate to improve how you show up for your team, but working on these seven will give you a leg up on the role. Scrum Alliance Certified Product Owner training and certification may also provide the support and empowerment you need to succeed. Learn more here.

Lowell Lindstrom is the founder of the Oobeya Group, LLC. You can read more about him on his Scrum Alliance profile.

Level Up as a Product Owner

Become a Certified Scrum Product Owner and demonstrate your commitment to this important scrum accountability. Scrum Alliance-certified trainers and coaches provide an in-depth look at the role during a live online or in-person course.

RL_8_7-skills-need-great-product-owner