Four Key Skills to Become a Better Product Owner

Great product owners don’t settle for being a backlog administrator. The product owner (PO) role, when done well, is the leverage role in scrum. A good PO can ensure a whole team does work that matters every day. 

Here are four skills that great product owners have and how you can develop them. 

#1 - Practicing Customer Empathy

The best product owners do the work to understand their customers and users. Not just what features they want, but rather, what they are trying to accomplish. What’s painful for them? What does success look like for them? 

The Jobs to be Done (JTBD) metaphor, popularized by Clayton Christensen and others, can help with this. The idea is simple: No one actually wants our products and services. They want what they want. They have their own goals — or jobs to be done — totally apart from our products. However, they might be willing to “hire” our products to help them do those jobs.

How do you develop this skill? Pay attention to this dynamic in your everyday life. 

When you see advertisements, ask yourself, “What jobs are they suggesting their product could help with?” Pay particular attention to psychological and social jobs. 

When you make your own choices to buy and to use products, notice the jobs you’re trying to get done. Notice how jobs and features are related but very much not the same thing. For example, I have no JTBD in my life related to building playlists in Spotify. In fact, I actively dislike making playlists. However, I value feeling a particular way when I sit down to write or when I go on a run, and I’m willing to hire Spotify’s “build a playlist” feature to help me accomplish that. 

Related webinar: Building Alignment and Empathy

#2 - Casting Vision

Great product owners cast a compelling vision for their products. They give their teams the larger context for their backlog items and help team members work toward a shared purpose rather than just taking orders. A good vision is a vivid picture of how the world is better once the team has completed its work. 

Unfortunately, most teams, if they have a vision at all, have a bland vision full of buzzwords and corporate speak. 

How do you develop this skill? Don’t try to write a great vision. Quickly write a crappy vision and then revise it over and over again until it’s good enough.

At Humanizing Work, we like starting with what we call the HOW-NOW-WOW template. Imagine you’re sending your team a note from the future, once their work is done and their product/release/whatever is in production and having an impact in the world. Now, set a timer for five minutes, and fill in these three blanks:

First, finish this question: “You know how…?” Fill in the blank with a concrete description of a painful situation your target customer currently experiences. For example, “You know how if you want more variety in your music listening, you either have to pay for more songs or get interrupted by ads?”

Next, finish this sentence: “Well now, …” Fill in the blank with a concrete description of the better situation the customer now experiences because of your product. For example, “Well now, you can instantly listen to pretty much any song you want, and you only have to pay a monthly subscription that’s about the price of a single album.”

Finally, it’s time for the wow. Add a sentence describing a delightful outcome that goes beyond just removing the pain. What about a better future will make the customer smile? What will make their eyes light up? For example, “... and if you don’t know exactly what song you want to hear, you can just hit ‘play’ on any of hundreds of curated playlists by music style, mood, or situation.”

With just those three sentences, you have the first draft of a vision. Now, iterate on it, replacing abstract concepts with vivid, concrete language. Paint a clear picture of how the world looks better because of your team’s work. Test it with your team, see what resonates and what doesn’t, and refine a bit more.

Once you have a “good enough” vision, refer to it in your sprint planning and backlog refinement meetings. Make it visible next to your backlog. And adjust it every few months as things change so you keep it relevant and engaging.

#3 - Illustrating Behavior with Examples

Great product owners don’t just create abstract specifications. They don’t just list comprehensive acceptance criteria and call the backlog item ready. 

Great product owners do the work to build a common understanding across their teams about what the user is actually trying to accomplish. One of the best ways to build that common understanding is with concrete examples. 

Imagine a user story in the backlog for a public library website: “As a library patron, I want to find a book by its exact title, so I see the specific book I want without noise in the search results.” 

The domain concepts of “exact title” and “noise in the search results” may be completely obvious to the PO. But their team may or may not have the same understanding. Moreover, the concepts are hard to define comprehensively in an abstract way, as with a set of acceptance criteria.

To ensure everyone is thinking about the story the same way, a good product owenrcan illustrate how they want it to work using concrete examples, and they can invite the team to suggest additional examples to make sure everyone is aligned. For instance…

Product Owner: “When I search ‘A Tale of Two Cities,’ I want to see the Dickens novel by that title, not books about, say, urban planning that happen to have ‘cities’ in the title.”

Team Member: “What about just ‘Tale of Two Cities’?”

PO: “That probably should still match.”

Team Member: “How about ‘Tale Two Cities’?”

PO: “That particular phrase never happens in the title, so that seems like a different kind of search, a keyword search. I don’t think that should match the Dickens novel for this story, but I’ll add the example to a future story about keyword searches.”

PO: “I think the pattern here is that leading articles aren’t required. So, ‘Tale of Two Cities’ matches the Dickens novel, and ‘Art of Focused Conversation’ would also match the book, ‘The Art of Focused Conversation’.”

How do you develop this skill? Before a backlog refinement session or sprint planning meeting, think about real examples of the behavior described in your backlog item. Come up with real (or realistic) data for your example. Consider how the example would need to change to end up with different behavior. Then, share examples when you’re discussing a backlog item and invite your team to propose examples you might not have considered. 

Related Article: Compassion is the Heart of Agility

#4 - Finding Vertical Slices

Finally, perhaps the most important skill great product owners display in their work: building their backlog from vertical slices of product, i.e., true product increments. 

The term “vertical slice” is a reference to software architecture diagrams, in which layers of a software architecture are typically represented horizontally. In order to deliver value to a user, a backlog item will typically require changes to multiple layers. So, if we drew the shape of the backlog item over the architecture, we’d see a vertical slice like this:

When a team completes a vertical slice, the system should be recognizably more valuable to a user.

Teams who work this way are more likely to experience the benefits of scrum. Planning and review meetings will be focused on real value. Team members can collaborate every day to create that value. It becomes possible to see incremental progress day-by-day and to use the daily scrum to inspect and adapt based on that progress so items don’t get stuck. Delivering real, meaningful value every sprint becomes not just possible, but routine.

Teams who work on tasks, components, or horizontal slices instead don’t experience these benefits. Scrum meetings become more about managing dependencies and ensuring everyone is busy. The cycle time from starting an increment of value to realizing that value can extend across multiple sprints. 

So, if you want to get good at finding vertical slices, how do you do it? 

First, develop the skill of recognizing the difference. Review a few sprints’ worth of your product backlog. For each backlog item, evaluate whether it represents a vertical slice. If it doesn’t, consider what other items it would need to be combined with to create a vertical slice (if a wide slice). 

Next, work on your slicing skills. Since 2007, I’ve written extensively about this, including a step-by-step flowchart. 

I consolidated dozens of articles into a single comprehensive guide to story splitting (i.e. finding vertical slices), which includes recommendations for how to practice this skill with your team. You can use this guide to identify how common splitting patterns show up in your own product.

What is good product ownership?

Good product ownership is far more than backlog administration. To have meaningful impact for your team and for your customers, invest time in developing the skills of practicing customer empathy, casting vision, illustrating behavior with examples, and finding vertical slices. Your team and your customers will notice the difference.

Looking for more product owner resources? Check out this collection of artilces and videos - Scrum In Review: Product Owners 

About the Author

Richard Lawrence is a Certified Scrum Trainer and Certified Enterprise Coach. He is the author of Behavior-Driven Development with Cucumber (Addison-Wesley 2019) and a frequent speaker at agile meetups and conferences. Learn more about Richard and his work at humanizingwork.com.