Whom do you serve? This is a paraphrase of Perceval upon arrival at the castle of the Fisher King.
‘Whom do you serve?’ might also be asked of product managers and product owners. As with many company titles, these are as unfortunate as those of business analysts and programme managers. They mean different things to different companies in different situations.
I’m going to spend this segment discussing the relationship between product managers and product owners. Compared to a product owner, the role of a product manager is old. Modern product management started in 1931 with a memo written by Neil McElroy at Procter and Gamble in an 800-word memo, where he delineated the notion of product from promotion and advertising. Product owners are an invention of Agile scrum teams, circa 2001 or thereabouts. But what’s the difference?
Simply put, a product manager is the person in charge of a product. S/he decides what features and functions a product needs, and works with others to price and place the product appropriately to gain customer acceptance.
In comparison, a product owner is the person in charge of a product. S/he decides what features and functions a product needs, and works with others to price and place the product appropriately to gain customer acceptance.
Déjà vu, right?
Product owners are most typically members of Agile teams—most notably scrum teams—, as they are an integral component along with the scrum master and the delivery team. They own digital products in the digital realm. Product managers have typically been assigned to physical products. But digital products can have product managers too. Unless it’s a relatively new company, the product managers were probably there first. One of the biggest problems arises when these two roles happen to coincide within the same domain.
In business, an owner would be assumed to be above a manager. People own businesses, and they hire managers. It’s very straightforward.
Let’s rewind for a few moments to the genesis of the product owner. Mike Cohn was one of the founders of scrum. Consider his definition.
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 marketplace, the competition, and of future trends for the domain or type of system being developed.
Mike Cohn
Notice the emphasis on holistic ownership. This is important. Note, as well, that a product owner is not a gopher or a glorified administrative assistant.
It might help to view this ontologically. In an old school company, where product managers already reside, perhaps the best arrangement would be for product managers of digital products to also be product owners. This may pose problems for older people who don’t fully grasp how ‘digital’ works. For this cohort, I suggest drafting a sort of digital Chief of staff or digital liaison—someone who can advise the product manager on the nuances of a product in the digital domain space. Perhaps this could be an opportunity to mentor this person into an eventual dual product owner-manager role.
Now consider this analogy. You own a car, but you decide to delegate sub-owners for your tires, your seats, your electrical system, and so on. It wouldn’t make a lot of sense. Of course, if something needed repair, you might not think twice about taking your vehicle to a tire specialist, an engine specialist, a transmission expert, or whatever, but you wouldn’t make these people owners. In fact, if upon inspection a mechanic notices additional issues, s/he would likely need to contact you for permission before taking any actions. This is because s/he has no ownership. These people are agents.
You may be thinking. Hey. Wait a minute. Not so fast. Many things have multiple owners. They’ve got legal partnerships. Corporations typically have many owners. And they delegate accountability to boards and executives. And you’d be correct. This is not the time and place to delve into principle agency challenges. But let’s just say that this construct is far from Agile. I could retort that in a political republic, the people are the owners of the government, and I think we can all agree that of whatever political stripe, this structure is anything but agile. I’m pretty sure this would not be a popular implementation. I’ll guess we also have our own thoughts on death by committee and analysis paralysis.
But what about condo and homeowner associations. Even if you are a tenant leasing commercial office space. You may have some control over superficial aspects of your office environment, but in the end, you need permission to make any but the most mundane alterations. Don’t these put restrictions on owners? Yes. Is anyone seriously considering one of these as a model for commercial digital product development? I hope not.
In a modern company for larger digital products, there should be a single product owner who should parcel out product management sub-functions. In some scalable Agile implementations, there are multiple product owners. Perhaps there is a data owner, an infrastructure owner, a customer experience owner and so on. Do these people make choices without conferring with the primary owner? Probably not. Because they don’t own anything. Employing normal language, these people are sub-product managers. Let’s just call them product managers. This is some of the reason I find SAFe and other so-called scalable solutions risible. This doesn’t make much sense. Semantically, it makes more sense to consider these to be product managers. I’d prefer something like product sub-system manager, but I don’t see the term catching on any time soon. And with good reason.
You may be wondering why I seem to be getting so hung up on nomenclature. Does it matter? In some sense, it doesn’t. Call your product owners cats, and product managers trees. The benefit is that given common understandings, the communication value increases. As I review job descriptions, it’s immediately apparent how mature an organisation is. This is not about some prescriptive orthodoxy. It’s about creating a common language. If every organisation defined product owners as cats, and their roles and responsibilities were about the same, I wouldn’t have even created this segment. I am not under any delusion that I’ll be the final arbiter in clarifying this. In the two decades I’ve been defending Agile itself, I haven’t gained any traction. Perhaps I’ve garnered a molecule of sympathy.
A reason I continue to insist on retaining the fundamentals of a product owner is that I recognise the opportunity costs. If your product owner is not an owner, you are probably throttling down your development throughput and delaying value recognition. Marry absent product owners with the assignment of scrum masters who are glorified managers, and you’ve got two strikes working against you.
I’ve already spent enough time in another segment discussing the nonsense of proxy product owners, so I’ll leave that topic. Again, once you remove the notion of ownership autonomy and accountability, you’ve diluted the benefit of product ownership and Agile by orders of magnitude.
We’ve arrived to the final topic of this segment. What if there is no single person who knows enough about the product? Perhaps it’s large or complex. Can this product have multiple owners? Again. There should be a single owner accountable for the entire product. Full stop. If additional people are needed to understand the complexities and gain a depth of knowledge on these components, that’s fine, but they still need to be in sync with the vision of the owner and there should be no disconnects between the owner and these sub-owners to slow the decision process. Even if they are the ones influencing or providing the vision. If they make too many bad calls, they should be replaced, and the product owner should feel pretty uncomfortable.
In enterprises that do not have modern infrastructure architecture, there are impediments to product owners, product managers, and of Agile itself. It is not modular enough. And it’s not set up for DevOps and continuous releases. It may not even be bi-modal. This is indeed a challenge, but it’s also a topic for a different segment.