7 Skills You Need to Be a Good Product Owner

As you become more familiar with Scrum, you will find that it is great for defining roles. A Product Owner For example, is responsible for the product backlog, creates user stories and forms the interface to the stakeholders and the Scrum-Team . That's all true, but what does it take to be a truly effective product owner?

To explore this, we turned to Lowell Lindstrom, one Certified Scrum Trainer® and one of the first pioneers of agile Software development . Over the last 30 years he has worked with and coached many product owners. He has found that the people best suited for this role benefit from accountability, visibility and the art of negotiation.

But there are nuances to these particular qualities. According to Lindstrom, the best have seven skills that go beyond the general requirements of "be a good communicator" or "be available" that could apply to just about any job. Spoiler alert: If you hate conflict, this role is not for you.

Customer enthusiast

If Product Owner Aren't you just an administrator who puts everything stakeholders say into the product backlog? Sure, you need to listen to what your stakeholders want, but you need to do more than just process information - you need to discover the latent needs that your customer or user hasn't even imagined yet.

For example, Lindstrom just launched a new email client and was thrilled to discover that it included a feature that allowed him to easily convert an email message into a PDF document. He no longer had to convert them to Word or change the destination option in the print function. It's clear that the team that developed this feature thought beyond the usual requirements of email.

storyteller

Those : managedagile.com

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 job is to think about how to turn this story into a product feature that - you guessed it - delights the user.

Let's take another email example. Let's say a backlog item for a rideshare company is to email users a receipt. What is the background? Maybe the user is a busy person on the way to the airport who needs to create an Excel expense report based on this receipt. In this case, you can think of additional information that would be helpful, such as the payment method (PayPal or credit card), document options (e.g. PDF), pickup and drop-off location, distance traveled, etc.

representative

Let's be honest. Even if only one person is supposed to be the product owner in Scrum, it is almost impossible for a single person to handle everything alone. As things start to slip through the cracks, teams will create additional parallel roles. For example, a team may establish a technical product owner role to compensate product owners who do not see themselves as team leaders.

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

developer

Those : agilemeridian.com

There is no mistake in saying that you are also a developer. In Scrum we attach importance to carefully delineating roles. This is helpful for teaching Scrum, but not always so helpful in practice. Roles can become overvalued to the point where the focus is no longer on the value delivered but on who does what. As a product owner, you may be thinking, "I own the product backlog. I own the user stories. I pass them on to the development team and they develop them. That's true, but you know what? You're part of a team. You're not just a team leader.

It is the entire team that delivers the value. If you see yourself as part of the development team, where your responsibility is to determine what to develop, you will achieve better collaboration.

Knowledge broker

Just as you are a developer, you are also a knowledge broker. Yes, you represent the product backlog and are the interface between the development team and the stakeholders. But you're not necessarily the final expert on the product. The developers who Code write, so they won't get very far if they contact you for user story details.

Instead, they should speak directly to the experts, the users' stakeholders. Your job should be to enable collaboration and empower developers by finding the right people to talk to. If these discussions result in changes to the requirements, you should definitely be informed. If not, you should let the developers take the wheel so they can get the information they need.

Conflict resolver

If you can't handle conflict, you're in the wrong industry. Especially in product development, we are dealing with a situation that is inherently full of conflict. This is especially true when those involved fight over resources and politicize what they will do. So the better you are at resolving conflicts, the less likely you will have to escalate (see below).

As a product manager, you must have the courage and ability to step in when things get difficult. And be aware that you usually have to go through conflict to reach a resolution. You must be cooperative to minimize the negative and you must mediate.

Effective escalator

Those : agileforall.com

No matter how good you are at resolving conflicts, it is inevitable that you will need to escalate something up the chain of command. This isn't about personal disputes, like little children complaining to dad: "He hit me." The escalation is a feedback to that Management that it pursues contradictory goals. For example, let's take two stakeholders who have tasked the same team with two different goals that don't fit together. This is a conflict, plain and simple.

The best product managers have a conflict escalation mechanism in place. Of course, you will try to sort things out as best you can with those involved, but you also need to cultivate the ability to move up and down the management chain. Don’t wait until you have a crisis before building and testing your escalation path. Look for opportunities to escalate small (but applicable) things very quickly so you become good at them. Then, when things get big and the stakes are high, you'll be ready to escalate with ease.

There are many other skills you can cultivate as a product owner to improve your appearance for your team, but working on these seven skills will give you a head start in your role. The training and certification to become a Certified Product Owner Scrum Alliance can also provide you with the support and empowerment you need to succeed.