How to move beyond the product manager vs product owner discourse

A look at some of the common points in the product manager vs product owner debate and a conclusion that the better question is who should do what?

Next time you find yourself in a room of product people and agile coaches ask the question “should you have both product managers and product owners?”

You’ll be sure to start a discussion with a lot of sound and fury that resolves absolutely nothing.

The product purists in the room will insist that you should only have product managers and that product owners don’t add much value. They’ll go on to let you know that product ownership is only a portion of product management and it’s best to have one person handle both discovery and delivery (and that discovery is obviously more important).

They may even go so far to say the worst thing that ever happened to product management is the creation of the product owner role.

The agile coaches will insist that product managers usually fill the product owner role and remind you how important it is to have someone readily available to answer developer’s questions, manage the backlog and (along with waving hand motions) all that other “producty” stuff.

Meanwhile, all the practicing business analysts and product owners in the room shuffle nervously in their chair. They most likely all exhibit some form of discomfort, but the type of discomfort depends on the role they fill and type of company in which they work. All would agree that the nature of that conversation just isn’t helping.

There are some good points…

My interest is helping those practicing business analysts and product owners. To do so, it’s helpful to call out the points in those arguments that hit the mark, and some things they both forget to mention.

Minimize links in the communication chain

The product purists aren’t wrong.

Ideally, the people making a product (ie engineers, designers, analysts who we’ll collectively call “makers”) should interact directly with the people whose problem the product solves (customers and users).

The more people you insert in the middle of that interaction, the greater the chance for misunderstanding, miscommunication, and a disconnect between the problem to solve and the solution.

And you can get close to that ideal situation if your team works on something completely new, and only on that something.

However, most teams working in organizations that build software for its own use are working on something that’s already in use as well as trying to add new capabilities, or optimize the existing product.

They need to ensure they’re building solutions that fit properly in the broader environment, whether that’s working inside existing processes or existing technical infrastructure. And, they need to make sure that solving a particular customer/user problem makes sense for the broader business.

Balance outcome and output

The agile coaches aren’t wrong either.

You can scream about outcomes until you’re blue in the face, but eventually you’re going to need to build a solution to deliver those outcomes. And its best if you can build parts of that solution quickly so you can learn if you’re heading in the right direction.

So it’s usually a good idea to do things that slow the makers down, such as making them wait for answers, and asking them to work on the wrong things.

One way to solve that is tied in to the point above. If makers interact directly with users, they’re more likely to build the right thing and won’t have as many questions. But there’s a lot of work involved in designing, developing, and deploying solutions. The more complex the product and the organization, the more of that type of work there is.

Context often goes unmentioned

The arguments I repeated above are usually based on an assumed context. Unfortunately that context does not match what most practicing product owners and business analysts find themselves in.

Yes, if you work in a start up that’s trying to go from o → 1, you don’t need a product manager and product owner. Heck, you may not even need a product manager at that point.

And yes, if you’re working on one of 50 teams working on a huge 20 year old software product, each of those teams could benefit from having someone with a product perspective available every day to answer questions and provide clarity.

And there are a lot of contexts where something in between the extremes makes sense.

People build digital products

Despite what the techbros pitching AI try to convince you, people still build digital products. And the more varied activities people are responsible for, the more likely they are to gravitate toward the work they enjoy.

Back in the day when I wore the project manager/business analyst hats on the same project, I did both as needed, but I tended to focus more time and energy on understanding data, processes, and rules and did barely sufficient coordination and communication.

More recently when I was a delivery lead, I found myself focusing on the data, rules, and refining the backlog. I facilitated planning and retrospectives but also offered that responsibilities up to others on the team if they wanted it.

It’s going to happen, and no amount of arguing over titles or roles is going to change that natural human behavior.

So how do we resolve this?

I don’t have any grand unifying theory that will solve this dilemma across the industry. But writing up to this point makes me wonder if instead of debating product manager or product owner, the more helpful question is who should do what?

With that in mind, here’s a simple technique to guide that constructive conversation with your team.

I’ve found that many organizations have this perception of what different people should do based on some idea of common accepted roles and responsibilities (which often turn out to be neither common, nor accepted).

And then there’s what specific people in those roles have experience and expertise in. The things they’re likely to gravitate toward in the heat of the moment.

One thing I’ve had success with is pulling together the specific people working on your product and have a “how should we work together” discussion.

If your organization has some “standard” as to what each role is supposed to do, start with that. Then, have an open conversation about what makes sense for the specific set of people involved.

Because most activities have someone who actually does it and others who are involved in some way, some teams like to use RACI to guide that discussion.

I’m partial to DACI because it clears up confusion between “Accountable” and “Responsible” in RACI, and it acknowledges the fact that most activities need someone actively driving things to completion.

Then, once you’ve reached agreement on who is going to do what, be willing to revisit that agreement on a regular basis, see how it’s going and adjust.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent