This is a continuation of Bad Product Ownership anti-patterns that I’ve seen all too often. And that I would encourage you and your organizations to avoid.

Without more context setting, let’s get onto the patterns –

You might be a BAD Product Owner IF you…

Too often revert to explore how and how long, over focusing on the what

It’s probably human nature.

When I ask a contractor to come over 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 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.

Don’t interweave technical work and design work within your backlog(s)

I have a name for it. I call 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;
  • And 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 helpful to visualize.

Look-ahead, 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 (grooming) or refinement meeting.

This is the meeting where you and the team takes User Story ideas and –

  • Helping improve the story description
  • Helping add nuance and breadth to the acceptance criteria
  • Decomposing them into executable “chunks”
  • Estimating relatively based on complexity, risk, and level of effort
  • Helping connect the dots to sprint themes/goals
  • Adding related stories for research, reducing technical debt, and maintaining valuable infrastructure

I’ve said it quite often that the product backlog (and the activity around it) is so much more than simply writing/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.

Don’t 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/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 PO 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 products code base. And the PO again 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 PO 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 PO ignores the feedback and simply moves on.

All of these are cases where 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!

Don’t say NO when appropriate. Note, not “Yes, and” or “Yes, but”, but 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. He says –

A Product Owners 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. Then take the consequences of 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 say, 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.

Don’t 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.

I wrote about slack specifically in this 2013 blog post.

Of course, a big part of the resistance is the business pressure for MORE than most PO’s 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.

Wrapping Up

As I study and learn from the various scaling frameworks, many of them (Nexus, LeSS, and Scrum@Scale) put a distinct premium on the Product Owner role.

There’s a reason for that.

The role is central to the success of any agile team. The need to be focused on the customer and delivering value. While still fully engaging with their teams.

They have the vision and are able to articulate it in a healthy and balanced backlog.

And beyond all of that, they take the profession and craft of Product Ownership seriously and gave it fulltime

BTW: here are a couple of posts that also took an anti-patterns approach to the PO role -

Stay agile my friends!

Bob.

 

1 Comment