After reading the 745th blog post trying to define product management and product ownership ….

https://www.youtube.com/watch?v=uihgdgGBLKkYeah. I know. It depends. But …

To build a successful product you do need context, business savvy, domain knowledge, vision, customer empathy, technical prowess, communication skills, and [insert skill/hat here]. You need lots of hats:

But you don’t necessarily need Product Managers and/or Product Owners (people with those titles).

Businesses talk frequently about owning, single wringable necks and accountability. Someone needs to give the status update. Someone needs the visibility. Someone needs to be presentable enough to attend The Business (capitalized) meetings. The Business needs these things. Do they contribute to building a valuable product? That’s debateable. In addressing those needs, organizations often propagate anti-patterns that cause deep, lasting harm.

At conference after conference I hear about “bad product managers” and “incapable product owners”. I’ve heard product owner jokes in keynote talks. I’ve participated in multiple ad-hoc 5 Why exercises with strangers that identify product management as the root cause. Is it really that bad? I don’t think so. It’s safe to say that something else is going on. All of these well meaning people can’t suck so bad (although consultants would love for you to believe otherwise).

I think that the problem is 1) the pipe-dream, and 2) structuring the org around dysfunction. Time traveling to 2008, here’s a description of the product owner role:

Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.Wow. That sounds awesome. This superhero will figure it all out for us, and we’ll be off to the races. We’ll have someone to blame if there is no vision. They’ll know what to build, and we’ll build it. So we dutifully assign these people to 6–12 engineers, regardless of whether those 6–12 engineers build a singular product, and hope for the best.

A CTO (who prides himself on being “Agile”) recently told me:

Well John, you know that all engineers secretly want to be told what to build. We like to build. We don’t want to waste our time in meetingsIn addition to this being patently false — many engineers I know very much care about impact — we know this approach fails. We know we’re wrong often. At a minimum we know we’re rarely 100% right when we first ship something. And time is a cruel mistress. But the pipe-dream exists.

The reality is that most product managers are overworked, spread too thin, and under-empowered. They’re the go-between. What people recognize as “bad product management” can almost always be traced back to deeper organizational challenges. These challenges manifest in the connective tissue of the organization (the product team). Product makes for a convenient scapegoat.

Every PM can relate to that awkward moment when someone with “C” in their name is helicopter managing the product, while at the same time the team is beating them up for changing priorities. That’s not a recipe for attracting and retaining the best.

I often hear about the benefits of “creative tension” between the Product, Engineering, and Sales organizations. To which I respond with something like:

Why do you insist on silo-ing the product and engineering teams? Is engineering just a factory in your mind? How do you actually benefit from this tension? More importantly, what do your customers think about all of these coordination meetings? Why not a single product development organization?Some organizations have taken the bold step of a single product development organization, but this is pretty rare. Toyota had the famed chief engineer role, a staple of the value-stream oriented lean product development model. But the reality remains: most organizations are structured around their needs (and dysfunctions), and not the needs of the customer. They create product roles because “that’s what people do” instead of asking “what must we do for our customers”. The org becomes fatter, taller, less skilled, less resilient, less adaptable, and more complex to navigate.

You start optimizing around your company structure, and not what people actually need.

Probing Questions

Start by asking yourself some questions …

1. Do your PMs own outcomes or the delivery of features? If the delivery of features, why not just hire skilled project managers?
2. By hiring the single PM, are you failing to provide other much needed pieces of context to your teams? Are your PMs skilled at ________ ?
3. Why does every group of 6 or 12 engineers and UX need a product owner? Is that team exclusively responsible for an actual product? If they controlled the budget would they actually hire the PO full-time? Or would they put a rec out for other, more specific needs (e.g. “attend meeting X and let us know if there are changes”)
4. What do your teams need? What do your customers need? What % of your PM’s day is actually benefitting the customer vs. the internal needs of your organization? Why?
5. How do your product managers insulate your engineering teams? How could you eliminate the need to “protect the teams from __________” ?
6. Could you afford fewer, but more highly skilled product managers and product owners? Even if they had larger teams?
7. Are there more effective ways to deliver status checks?
8. Why do you need separate Product org and Engineering orgs? How does the customer benefit?
9. Could you rotate the PO role? Are there other folks in the organization who can supply the context, thereby cutting out the noise / signal loss? Do your needs remain constant? If not, can your PMs/POs remain that adaptable? Or do you expect them to just bail?
10. Are your most skilled product managers/owners working on the front lines?
11. Are your expectations for your product team reasonable? Is there enough time in the day to actually do the work adequately?
12. Can you bring the silos of your organization closer together? Such that the overhead of coordination would drop and benefit your customers? And what would that do to your product team? So yeah. Sometimes you’ll end up with the someone with the Product Manager or Product Owner title. But sometimes you wont. Before you write that job ad, consider what you need and/or what you need to do to make that person successful.