BY SCRUM ALLIANCE image of a product owner helping an agile Scrum team succeed

Scrum 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.

Related: In Search of the Perfect Product Owner

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.

Related: Diagnosing Dysfunction Using the Product Backlog

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.

Related: High-Performance Teams — Why the 'Who' Matters Less

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.

BY RICHARD K. CHENG Image of product owner coaching an agile Scrum team

\The product owner is a critical role in Scrum. They are the one that translates the needs of the users, customers, and stakeholders into a product vision, roadmap, and backlog that maximizes the value of their product.

However, how do we know if we have the perfect product owner, and what does it even mean to be a perfect product owner? Below are five key attributes to look for in an ideal product owner:

1. Bandwidth
2. Power
3. Knowledge
4. Interest
5. Vision

Bandwidth Bandwidth is best explained via a story. Years ago, I was a ScrumMaster at an organization where the Senior Vice President of Something Important, we’ll call her Jesse, wanted to be our product owner. The Scrum Development Team and I were initially quite excited because we had a great relationship with Jesse, and Jesse was very high up in the organization. With Jesse as our product owner, we felt that we could get a lot accomplished. However, we quickly realized that this was not working as well as we would have liked because Jesse was never around. For example, we were building out a new part of the website and the team needed to meet with Jesse to review some of the needs. Jesse said, “Absolutely. I’m about to get on a plane to New York but I’ll be back in three days. Let’s meet then.” At this point, we set a 45-minute meeting on the day of Jesse’s return, to which she showed up 20 minutes late. All of this is a bandwidth issue. Bandwidth: having enough time and capacity to work with the Scrum team, manage the product, and work with the users, customers, and stakeholders.

There are essentially two ways to resolve this issue:

Free up the product owner’s time so they have more time for product ownership Find a new product owner Related: Becoming a Scrum Alliance Certified Product Owner

Power Since Jesse was so high up in the organization, paring down other parts of her job wasn’t really feasible, so we went with option two: find a new product owner. Jesse had a direct report, David, who Jesse thought could do a great job. So, what if Jesse had approached David and said, “David, I want you to be my proxy product owner. You do all the day-to-day stuff, just make sure to run all decisions through me.” If we had gone down that route, not only would we not have addressed the original issue, but we would have made it worse by adding yet another layer into this product ownership. So, Jesse did not do that, but Jesse approached David and said:

“David, I’d like to talk to you about being the product owner. Your product, your team. As long as you’re aligned with the product vision and roadmap, you run with it. I’ll take a step back and be more of product champion or product sponsor and we’ll periodically synch up to make sure we’re aligned.”

This is power: the authority to manage the stakeholder needs, order and refine the product backlog and product needs, and the ability to accept the product increments. Whenever we hear terms like proxy product owner, delegate product owner, de-facto product owner, vendor product owner, stand-in product owner, analyst/product owner, or any variations such as those, we begin to wonder if they really have the power to be an effective product owner.

Knowledge What if David was a brand-new hire to the organization and had no idea about the product? That certainly would have been a big risk. Fortunately, David had been with the organization for more than six years on the business side and had a deep understanding of the product. That is knowledge: having a deep understanding of the product, who the users and stakeholders are, what they find valuable, and what the organization’s goals are for the product.

Interest Suppose David said, “I don’t want to do this job, I’m not interested!” Yet, he was forced to do the job - how well would that work? You would essentially have a disinterested absentee product owner. David would say things like, “I don’t have time to go to this meeting, you guys figure it out,” “It’s all high priority, get it all done,” and “I don’t have time to review it now, just show it to me at the end.” However, in this case, David was very excited about being the product owner and to work with the team rolling out this product. Interest: having a strong desire to be the product owner and being able to maximize the value of the product.

Vision What if the team approached David trying to understand the goals of our releases and David said, “I don’t know, where do you think the product should be going?” That is not product ownership. In this case, David had a strong vision for the product and was very excited about bringing this vision to the users. David was so excited and engaged with the vision that he was able to get the team excited and engaged with the vision, and an engaged team produces a better product. Vision: having a great understanding of what the product is, where it should be going, and the goals for the product.

The Perfect Product Owner Thus, the five key attributes to seek in a product owner are:

• Bandwidth: Having enough time to work with the Scrum team, manage the product, and work with the users, customers, and stakeholders.
• Power: Having the authority to manage the stakeholder needs, order and refine the product backlog and product needs, and the ability to accept the product increments.
• Knowledge: Having a deep understanding of the product, who the users and stakeholders are, what they find valuable, and what the organization’s goals are for the product.
• Interest: Having a strong desire to be the product owner and being able to maximize the value of the product.

Vision: Having a great understanding of what the product is, where it should be going, and the goals for the product.

Richard K Cheng is a Scrum Alliance Certified Scrum Trainer and the VP of Training and Chief Product Owner for NextUp Solutions, where he can be reached at richard.cheng@NextUpSolutions.com.