9 Ways Product Ownership Can Go Wrong—and What to Do About It

Product ownership not working within your organization? You might have a larger problem on your hands.

If there’s one role in agile frameworks that is the most misunderstood, it’s the role of product owner.

In some organizations, the title of “product owner” becomes synonymous with “product manager.” (Or worse, project manager). In others, the product owner becomes a part-time role tacked on to the duties of an already busy executive or leader.

Here’s the gritty truth: For an agile framework to be successful, the role of product owner has to work. And for the role of product owner to work, there are certain things that must be the case. When one or more of those elements is missing, it shows up as a certain kind of “problematic product ownership.” But really, it’s not so much the PO doing something wrong. The problem is more systemic than that. The organization itself is not yet set up for success with agile.

Not to give away the punchline, but… well, we’re giving away the punchline. These are the elements that need to be in place:

  1. The entire team has to be dedicated to the product
  2. It is truly is a product
  3. Nobody outside the team contributes to the product
  4. The team is diverse, with a complete cross-functional set of skills
  5. Management has bought into the idea of decentralized decision making
  6. Product-market fit has been achieved
  7. The composition of the team is determined by the funding of the product
  8. Hierarchy and politics are absent from the team
  9. Team success metrics are based on the product’s success

That’s it. But that’s a lot. If your team has all nine elements, your agile team is set up for success and your product owner should be able to get the product to market.

And if one is missing…again, one of the places where you will likely see the issue is with the PO role. Let’s take that first one as an example.

Approaching Product Ownership in an Imperfect Agile World...and how to make it  a little less imperfect.  Access our on-demand webinar recording here!

“The Entire Team Has to be Dedicated to the Product”

For an agile approach to work (and actually bring a product to market), there has to be a dedicated team. Else, work on the yet-to-be product will always play second-fiddle to other more pressing responsibilities.

You’ll know if you don’t have a dedicated team, because you’ll either have a Moonlighting PO or a Cat Herder. (FYI, if you want to see the full list of problematic PO types, it’s towards the end of this article. If you want to learn what these types are and what they mean for your organization, I highly recommend our webinar, “Approaching Product Ownership in an Imperfect Agile World”).

The Moonlighting PO

Moonlighting PO

A product owner has to have ownership of the development and go-to-market strategy for a product. That’s a dedicated role. But too often, someone who already has a demanding role is saddled with the title of “Product Owner” once agile is adopted. And who knows—they might actually be a great fit for the role! But you’d never know, as their day job is what they are being paid to do…and so that takes priority.

You can recognize the Moonlighting PO by these pain points: Stories are seldom ready when they need to be. In fact, the entire backlog looks like it’s been neglected. What is there looks like a jumble—there might be a lot of great ideas, but no real coherent product strategy, and no sense of what features are actually needed.

How does the organization fix this? The Product Owner needs to make this their primary responsibility. This might mean finding ways to delegate the POs “day job” responsibilities to someone else. Once their deck is cleared of the day-to-day, support them with the product management training they need. Finally, encourage the PO to “step into” the role. The PO is not someone executing on a list of tasks, but a role with some authority on the team. It should be treated as such.

The Cat Herder

Cat Herder POMaybe the PO is dedicated, but it is everyone else who has their attention divided across different roles and/or teams. In this scenario, the PO ends up having to track down team members and “champion” the work to be done on their product. It’s an uphill battle, however, because the Cat Herder does not have the authority needed to keep the team focused. So this PO can no longer respond to the market—now, they are just herding the team members and trying to get them to focus.

You can recognize the Cat Herder by these pain points: There are delays, which lead to a PO who has to find and cajole team members to deliver on time. Or, team members come to the PO asking for reminders and clarifications because it’s been a while since they even worked with the product. In response, many POs start to go crazy with structure—a cat herder who has been at it for a while might constantly request more documentation, or endlessly request more meetings. Productivity is unacceptably low, even though everyone seems as busy as a kitten on catnip.

How does the organization fix this? If it’s possible, the best thing to do is to reorganize all teams so that team members can be dedicated to a single product. Failing that (or, in addition to that), your teams need to find ways to make the best use of their limited time with each other. That might require, for example, scheduling more group working sessions (and fewer meetings). Or it could mean “lumping” time on a product together in schedules to reduce context switching.

The Other Problematic PO Types

Chances are good that you’ve seen at least one Moonlighting PO or Cat Herder in your career. Those are just two of the ways in which challenging organizational structures manifest in sub-optimal PO results. There are eight others, and they manifest when one of the above assumptions does not hold:

  • The Traffic Cop
  • The Jira Jockey
  • The  Beggar
  • The Technical Product Owner
  • BA-as-PO
  • The AWOL PO
  • PO as Project Manager
  • The Antagonist

Again, the PO is often the proverbial canary in the coal mine when it comes to identifying where agile transformations are going off the rails—though even veteran agile teams can suffer from these problems, too. If you learn to spot these problematic PO types in the wild (or, if you feel you are one of these types of PO!), you will have that much more insight into what needs to change to make the organization successful.

Want to learn about all ten types? Check out our webinar: 

New call-to-action

John Krewson

John started Sketch in service to the mission of improving the ways people and teams work together. His past experiences as an agilist and professional actor are the primary sources of inspiration in leading this mission.

Other posts you might be interested in