PRODUCT OWNER

7 Skills You Need to Be a Great Product Owner

BY LOWELL LINDSTROM

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.

The 18 Characteristics of a Great Product Owner

Barry Overeem

Barry Overeem website

Product Owner Scrum

During a recent Product Owner training I gave the participants the assignment to complete the sentence "A great Product Owner..." The result was a nice overview of characteristics, skills and conditions necessary to fulfill this role in a great manner. In this blog post I'll share the result, completed with a short explanation and some more ideas of my own.

A Great Product Owner...

• Embraces the product vision. A great Product Owner represents the customers voice and creates a product vision together with the stakeholders. Every decision is taken with the product vision in mind. This ensures sustainable product development, provides clarity for the development team and increases the chances of product success drastically.
  

• Exceeds the customers expectations. A great Product Owner truly understands the customers intentions and goals with the product and is able to outstrip its expectations. Customer delight is the ultimate goal!
  

• Is empowered. A great Product Owner is empowered to take decisions related to the product. Sure, creating support for his decisions might take some time, but swiftly taking important decisions is a primary condition for a sustainable pace of the development team.
  

• Orders the product backlog. A great Product Owner understands that the product backlog should be ordered. Hereby priority, risk, value, learning opportunities and dependencies are balanced with each other.
  

• Prefers face-to-face communication. A great Product Owner understands that the best way to convey information is face-to-face communication. User stories are explained in a personal conversation. If a tool is used for backlog management, its function is to support the dialogue. It never replaces the good old-fashioned conversation.
  

• Knows business models. A great Product Owner has a backpack full of valuable business models. He knows when to apply a specific model. Examples are Business Model Generation, Lean Startup or Impact Mapping. Based on these models he knows how to drive product success.
  

• Shares experiences. A great Product Owner shares his experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down your lessons learned is also highly appreciated.
  

• Owns user story mapping. A great Product Owner should master the concept of user story mapping. It's a technique that allows you to add a second dimension to your backlog. The visualization enables you to see the big picture of the product backlog. Logically he should also know all the stuff Jeff Patton has created.
  

• Has a focus on functionality. A great Product Owner has a focus on functionality, hours or even story points are less important. The goal of the Product Owner is to maximize value for the customer. Its the functionality that has value, therefore this is the main focus for the Product Owner.
  

• Is knowledgeable. A great Product Owner has in depth functional product knowledge and understands the technical composition. For large products it might be difficult to understand all the details, but the Product Owner should always know the larger pieces of the puzzle and hereby make conscious, solid decisions.
  

• Understands the domain. A great Product Owner understands the domain and environment he's part of. A product should always be build with its context taken into account. This includes understanding the organization it concerns but also being aware of the latest the market conditions. Shipping an awesome product after the window of opportunity is quite useless.
  

• Acts on different levels. A great Product Owner knows how to act on different levels. The most common way to define these levels is strategic, tactical and operational. A Product Owner should know how to explain the product strategy at board level, create support at middle management and motivate the development team with their daily challenges.
  

• Is available. A great Product Owner is available for the stakeholders, the customers, the development team and the Scrum Master. Important questions are answered quickly and valuable information is provided on time. The Product Owner ensures his availability never blocks the progress of the development team.
  

• Is able to say 'no'. A great Product Owner knows how and when to say no. This is probably the most obvious one but nonetheless also the most difficult one to master. Saying yes to a new idea or feature is easy, it's just another item for the product backlog. However, good backlog management encompasses creating a manageable product backlog with items that probably will get realized. Adding items to the backlog knowing nothing will happen with them only creates 'waste' and false expectations.
  

• Acts as an entrepreneur. A great Product Owner basically is an entrepreneur for his product. He has a keen eye for opportunities, focuses on business value and the Return On Investment and acts proactive on possible risks and threats. Everything with the growth (size, quality, market share) of his product taken into account.
  

• Uses the Backlog Prioritisation Quadrant. A great Product Owner is familiar with the Backlog Prioritisation Quadrant and uses this as an instrument to discuss the Product Backlog. The Backlog Prioritisation Quadrant clarifies the fact that the backlog consists of more than only new features. Technical innovation, technical debt and providing support should also be taken into account.
  

• Takes Backlog Refinement seriously. A great Product Owner spends enough time at refining the Product Backlog. Backlog Refinement is the act of adding detail, estimates and order to items in the Product Backlog. The advise is to spend on average 10% of the capacity of the Development Team to refinement, the way it is done isn’t prescribed and is up to the team. The Product Owner can involve stakeholders and the Development Team with refining the backlog. The stakeholders because it gives them the opportunity to explain their wishes and desires. The Development Team because they can clarify functional and technical questions or implications. This will ensure common understanding and increases te quality of the Product Backlog considerably.
  

• Has studied all the stuff from Roman Pichler. A great Product Owner has read all the articles of Roman Pichler and uses his templates continuously. Creating a product vision, roadmap, persona, canvas or sprint goal, the website of Roman Pichler is the place to be!

CONFIDENTIALITY / COPYRIGHT NOTICE: This site and my information and any attachments contains the PRIVILEGED AND CONFIDENTIAL INFORMATION of Fred Finkelstein & Irondesigner DBA / LLC mutually, Inc., its affiliated corporations or legal entities, and is intended only for the use of the individual(s) named above. If you are not the intended recipient of this e-mail or invited to this site, or the employee or agent responsible for delivering this to the intended recipient, you are hereby notified that any unlawful interception, dissemination, disclosure, printing or copying of this e-mail or site or any attachments is strictly prohibited under the Electronics Communication Privacy Act (ECPA), 18 USCA 2510, 18 USCA 2511, and any applicable laws. If you have received this e-mail or viewing this site in error, please delete or destroy it & close down, including all attachments or copies, and immediately notify us by e-mail at mechanicalengrg@gmail.com