Part 2: Eradicating these bad habits from the role of product owner

Read Part 1 here.

Strong product owners can deliver incredible results. However, far too often, organizations don’t leverage the role of product owner to its fullest potential. This is a continuation of <part 1: eradicating these bad habits from the role of product owner.> We explored five anti-patterns previously, so let’s explore six additional patterns that your company should avoid.

Six pervasive habits adversely affecting the role of product owner:

Reverting to explore how and how long instead of focusing on the what

It’s human nature. When I ask a contractor to come to my home to estimate fixing a problem, I usually focus on how long it will take them and how they will approach the repair.

Even though I know little to nothing about the work, which is why I invited the expert over in the first place, I still try and orchestrate the work. And I think many product owners fall into the same trap.

The role of product owner is clearly focused on the what, not the how or how long. Even if you have the experience, you must resist getting into the implementation details. That’s for the team to sort out and you need to trust them to do a good job.

Interweaving technical work and design work within your backlog(s)

I have a name for it: feature-itis. It’s when a product backlog only contains feature-centric work and no other. It’s an unhealthy pattern, but an easy one to fall into, especially since it keeps your stakeholders happy.

But a product backlog needs to be balanced. It needs to contain:

  • Technical spikes so that the team can reduce technical risk
  • Design stories so that there is sufficient time for thoughtful design
  • Defect repair stories so that you’re continuously focusing on improving quality
  • Refactoring stories to maintain the vibrancy of the product
  • Other work items for team infrastructure, experimentation, and learning

I’ve often made the analogy that a good backlog is like a tapestry with many threads running through it; a solid backlog has sufficient amounts of all threads so that it has a balanced palate.

I know, an artsy view, but I’ve found it to be a helpful visualization.

Looking ahead because it takes time, effort, persistence, and the team

The central artifact for any product owner is their backlog, and the central activity for conducting (think orchestra and the conductor’s role) is the backlog refinement meeting.

This is the meeting where you and the team take user story ideas in order to:

  • Help improve the story description
  • Add nuance and breadth to the acceptance criteria
  • Decompose them into executable “chunks”
  • Estimate relatively based on complexity, risk, and effort level
  • Connect the dots to sprint themes and goals
  • Add related stories for research, reduce technical debt, and maintain valuable infrastructure

I’ve said it quite often that the product backlog (and the activity around it) is so much more than simply writing and creating requirements. The conversations around the backlog, in backlog refinement, are the key artifact that connects the team to the customer ask.

And you don’t just groom for a sprint a few days in advance of its beginning. A good goal is to have continuously refined 2-3 sprints in advance with your team.

Failing to trust your team

The lack of trust shows up most noticeably when the team is estimating the work and when the product owner has some experience in writing and developing similar software products.

You can see it in the backlog refinement meetings. The team weighs-in on the estimates (story points perhaps) for each story. And the product owner gives them a long, sad, and disbelieving look that implies they can’t understand why that particular story should take that long.

Or when the team suggests that, as part of implementing a particular story, they want to do a bit of refactoring to clean up that area of the product’s code base; again, the product owner is incredulous, implying that it’s good enough and that they’re “unwilling” to pay for the “extra 5 points” associated with the refactoring.

Or when the team gives the product owner feedback that they really don’t understand the business value of a particular story, especially as it fits into the persona for that specific user-type. The product owner usually ignores the feedback and simply moves on.

All of these are cases in which the product owner should have simply trusted the wisdom, common sense, and ideas from their team. It’s important that the team feels … trusted! Otherwise, they’ll shut down and simply stop engaging or owning their results, which is not what you want!

Refusing to say “no!” when appropriate
(Note: not “Yes, and” or “Yes, but” – give a clear, strong, and emphatic NO!)

There’s a wonderful video by Henrik Kniberg that I’ve shown more times than I can remember, in a wide variety of class contexts. My favorite quote involves saying no.

In the video, he says, “a product owner’s most important job is saying no. It’s easy to say yes, particularly if saying yes simply means adding something to an ever-growing backlog. A product owner needs to say yes and no, and then take the consequences for those decisions.”

I couldn’t agree more. And this point is amplified by the overwhelming habit I see most product owners have of saying yes … to everything.

Of course, there is business and executive/stakeholder pressure. There always is. But as Henrik says, “it’s your job to decide, to make the hard calls and prioritize your backlog.”

One of the five Scrum values is “courage.” Product owners need to have the courage to own their products and backlogs, which includes the courage to say no or to say choose one over the other.

Neglecting to realize that slack time is the “secret sauce” to agile innovation and creativity

One of the things I don’t hear discussed much by product owners is the role they can play in creating space (slack time) for their teams to innovate and create.

Of course, a big part of the resistance is the business pressure “for more” that most product owners are under. But at the same time, if they:

  • Have done a good job of sharing the why with their teams
  • Trust the thinking and capacity of their teams
  • Believe in the wisdom of the crowd

Then they’ll often be inspired to create some space for the team to innovate.

Take your team’s role of product owner to the next level

So, there you have them: the anti-patterns that keep product owners from truly being the strategic players they need to be. I suggest you familiarize yourself with these patterns, and when you see one of them emerging, stop and pivot away from this behavior. It’ll only make your product owners more effective – and your teams more successful.

And while you’re focusing on enhancing leadership roles across your organization, you might consider other areas of opportunity as well, like considering Scrum: the art of what not to do.