5 Key Skills Great Product Owners Have

Being Product Owner is hard. Actually, that’s not quite true. Anybody can make a list of things to build, call it a backlog, and bring it to a few meetings every month. Being a great Product Owner is hard. Development skills are essential, but it doesn’t matter how fast your team delivers and how good your quality is unless you’re delivering the right thing every day. Identifying and expressing that “right thing” at every level of detail is a big job.

To improve our CSPO classes and our PO coaching, Bob and I made a tree of the skills that the best Product Owners use. While there are over two dozen skills on the tree—see, it’s not an easy job!—here are 5 you can work on to have an impact on your team right away.

Skill #1: Clearly express the connections between larger business goals and small backlog items

Many POs are good at making a business case for a project, but end up with a backlog of items that seem disconnected from that larger goal. By the time the team gets a few sprints into the project, half the team (and maybe the PO) have forgotten the business case and are just delivering on the details. They can no longer see the forest for the trees.

A great PO distills the business case into a short vision, makes it visible, and can point to it to explain every little thing on the backlog.

There are lots of ways to write a vision. One of my favorites is a variation on the elevator pitch template from Geoffrey Moore’s Crossing the Chasm. It goes like this:

FOR target customer
WHO need or dissatisfaction
product name IS A category
THAT key benefit (not key features, but what the features allow the customer to do).
UNLIKE alternative way of meeting the need
OUR PRODUCT how it’s better for the customer than the alternative.

Can you answer all the questions posed in this template? Could any member of your team? If not, you’d do well to fill in the template.

This doesn’t always make the most pithy, literate vision statement—it can sometimes be too formal or clumsy—but I love how it makes you answer some key questions about your product in a couple sentences. A slightly clumsy vision statement is better than none at all. And once you have a draft in this format, you can revise it read better.

Here’s an example for our Humanizing Work Conference:

FOR Agile For All alumni
WHO want to get better at their work
Humanizing Work IS AN Agile conference
THAT allows Agile For All alumni to learn advanced content from us and from other like-minded Agile practitioners.
UNLIKE a public Agile conference,
OUR CONFERENCE is built from the ground up on brain-friendly accelerated learning methods and has attendees who share a common language and understanding of the principles behind Agile (which lets every session go deeper).

This vision gives us a filter for every decision we make about the product. It prompts us to ask questions like:

• Is that session relevant to Agile For All alumni?
• Is it advanced content, or would they already have learned it in one of our classes?
• Is ______ brain-friendly or just how conferences always work? Could we make it more brain-friendly?

Sometimes you have more than one kind of target customer. For the Behavior-Driven Development with Cucumber book I’m writing with Paul Rayner, we’re targeting people in four different roles who have different needs. BDD is a practice for collaborating across roles, so we have to meet the needs of all these roles. So, we drafted four parallel visions, like this:

We had a client in education software who had to do this for students, teachers, and school administrators.

Once you have a vision statement, make it visible. If you’re on a colocated team, make a big poster and stick it on the wall. As a distributed team, we tend to use tools like Google Docs, Slack, and email. But when we’re together, we collaborate with paper.

Having a visible vision statement is great. But take it a step further: explicitly connect the vision to the details in your backlog. Say things like, “We’re doing this user story because it helps differentiate us from [alternative],” and, “Remember, we’re not building this story for everybody, it’s just for [your target customer], so we don’t have to do [some variation your target customer doesn’t need].”

You can practice this today:

1. Write a vision statement if you don’t have one already. Don’t worry about making it perfect, just fill in the blanks for a first draft.
2. Make it visible to your team. Incorporate their feedback to improve the vision.
3. Go through the top items on your backlog. For each one, write a sentence or two explaining how that backlog item moves your product towards the vision.

Skill #2: Write user stories in a way that allows the team to contribute to the “what”

I was once coaching a PO and a couple of developers as they groomed their backlog. I noticed that all their user stories looked like this:

As a user, I want some new feature for the team to build.

Yes, their stories actually said “as a user,” but that’s not what struck me. I noticed none of their stories said why the user wanted the thing. There was no “so that” or “in order to.” So, I asked them why.

“Because they don’t need to know,” responded the PO, “I tell them what to build, and they build it.”

I looked over at the developers, expecting to see shock and dismay at being treated like short order cooks, and was surprised to see them nodding.

“Yep,” one said, “she tells us what the user wants and we build it.”

Just to see if it might make a difference, I asked them to try adding a “why” statement to their top story. We quickly realized that the PO had a similar relationship to her stakeholders—they tell her what they want and she goes to the team to get it built. But we talked about it for a few minutes and came up with a plausible “why.”

The moment the PO finished typing the change into their backlog tool, one of the developers said, “Oh, that’s what you’re trying to do. We can do it this other way for a tenth of the cost of what you asked for.” So they changed the story to accommodate the new “what” and went on to deliver the value for a much lower cost.

By adding the “why” to their story, this team was able to collaborate with their PO to make a better “what” than either could come up with on their own. Writing stories in a way that enables this collaborate is a key PO skill.

Here are two simple ways to do this:

1. Make sure each story has a clear “why” somewhere that explains the larger value or goal for the user. Explicitly connect the story to the product or release vision if you can (as I described in the previous skill).
2. For the “what” in the story, try describing the task the user is trying to accomplish rather than the feature in the system. Ask yourself, “Am I telling the team what to build, or am I inviting them to empathize with and solve a problem for a user?” The more your language in the story trends towards the latter, the more opportunity you have for the team to solve the problem in a way you haven’t imagined.

Skill #3: Modify the backlog in response to change (without having to throw out lots of work)

Whether it’s from customer feedback, your competitor’s latest release, a new technology, or a new regulation, the world changes in a way that affects your backlog.

Great POs respond to change by changing their backlog so it always reflects the current reality and your current knowledge. Merely competent POs add new backlog items and reprioritize in response to change, but they tend to leave out-of-date cruft in their backlogs. (Bad POs ignore change and treat the backlog as a big up front project plan, but you wouldn’t do that.)

The key to being able to respond to change without having to throw lots of work away is avoiding detail in your backlog until it’s unlikely to change. I know, that almost sounds too easy to be a real thing, but we have several clients doing it well.

Here’s how you do it:

1. The top of your backlog should be user stories, sized small enough that 6–10 could fit into a sprint and with enough detail that the team feels comfortable committing to them in sprint planning. Most backlogs should have about 2 sprints worth of stuff like this on the top of the backlog and no more. When you get down to this level of detail beyond a few weeks in the future, you’re very likely to have to throw something away when the world changes. Small details are fragile to small changes.
2. Beyond 2 sprints, don’t use user stories. Instead, use minimum marketable features, or MMFs. An MMF is a small (minimal) change in system behavior (feature) that’s valuable enough actually get in somebody’s hands (marketable). You can prioritize these in your backlog. You can size them against each other just like you do with stories. And you can measure the relationship between feature size and story size as you split these MMFs into stories. MMFs are usually stable enough to use in your backlog out to about 6 months.
3. Beyond 6 months, even MMFs are too volatile, so just keep a cloud of themes you want to address over the next year or two, with the most likely ones at the top. This will let you keep your product strategy in mind without wasting time on detail that’s likely to change.
4. Finally, keep a list of things you’re intentionally leaving out of your backlog. You can revisit this list quarterly to see if they need to get promoted to the backlog, but you won’t need to waste energy on these items every time you look at the backlog. In his Getting Things Done personal productivity method, David Allen calls this the “Someday/Maybe List.” I have one that includes things like, “Learn German.” It’s something I might like to do someday, but don’t want to think about today.

Your backlog ends up looking like this, with small items on top, larger items further down, and eventually a cloud of options to draw from:

(I teach more about how to structure your backlog in this way, how to visualize it on a kanban board, and how to forecast releases over it in my 80/20 Product Ownership online course.)

Skill #4: Say “no” appropriately when necessary to maximize the value of your product

We give out a lot of NO buttons at conferences and in our classes. They say “no” 10 different ways, and Product Owners love them. They’re a joke, but they highlight a real issue.

If you don’t say “no” intentionally, you can’t say “yes” intentionally. You still don’t get everything done, but instead of choosing what to say “no” to, you let it happen by accident or let others choose.

Great POs have the skill of saying “no” without being a jerk. Here are a few ways to say “no” when someone wants to add something to your backlog:

1. “I’d like to add that item to the backlog, too. What should we pull out to make room for it?”
2. “That’s not a priority for us at this time. We’re choosing to focus on [current focus] right now. Let’s consider it again [next month/quarter/year/whatever].”
3. “Sorry, that doesn’t fit our current vision.”
4. “Help me understand why you want this. Maybe there’s another way to solve this problem.”
5. “No, because [reason why you’re choosing not to put this item in your backlog at this time].”
6. “Here’s another thing you can do in the product that might help…”
7. “Here’s another similar item in the backlog…”
8. “Maybe we can include part of that in [another closely-related backlog item].”

You’re the Product Owner because your business leaders trust you to make the best decisions about the direction of your product. Accept that responsibility and be deliberate about what you say “yes” to and what you say “no” to.

You can practice this right away by looking at your backlog for things you’d like to say “no” to now. Either remove them if you the authority to or plan how you’re going to talk to the stakeholder if you don’t.

(If you’re not actually trusted to make decisions about what goes in your backlog, by the way, that’s an issue to address directly. No amount of skill in saying “no” fixes that one.)

Skill #5: Split big slices of value into small slices of value

Of all the skills a PO can have, this is the one that makes the great POs stand out. Great POs can take a big idea for a project and find early high-value, high-learning MMFs. They can take an MMF and find the essential user stories that make it marketable. They can take a big user story and split it into several small stories. And they can take even a small story and help the team build it in small, valuable slices.

Getting good at splitting has several benefits:

• It helps you identify the low-value parts of every project, feature, and story so you can avoid ever building them.
• It helps you find the high-value parts so you can build them first.
• It helps you avoid building components, infrastructure, and technical tasks that don’t directly deliver value.
• It reduces the risk in each sprint because you’re not betting the whole sprint on one or two stories. Getting 9 of 10 stories done is better than getting 1 story 90% done.
• It gets you to done much faster, which enables earlier feedback and more frequent releases.

I’ve written a lot about how to split a big user story into smaller stories. My articles and posters on story splitting account for almost half the traffic on our website.

If you have stories near the top of your backlog that are larger than ⅙ of your team’s velocity, try using my story splitting patterns to find some small, valuable slices inside those stories.

Update, October 2020: Richard’s latest story splitting resources are available at Humanizing Work.