The Eternal Agile Question: Product Owner or Product Manager?
I’ve been thinking agile lately, and that whole question about the “product owner” versus the “product manager.” Which should you have (or should you have both?) and what do they do?
As I’ve mentioned before, the key analytical point to remember is that agile – and the “product owner” concept – came from internal IT development projects. In an IT development project, the work is done for a particular business unit. The product owner is a representative of the business unit – a real use of the application – who sits with the team and can represent the users’ needs in a reasonable way.
The point is that the product owner’s idea of what is important is considered trustworthy due to their role as a user. Therefore, the product owner can effectively make the prioritization calls. In other words, it’s one person, and they knew what the priorities are because they are experts in that actual application.
It turns out IT applications are a very different beast from commercial software products. So different that the product owner role no longer makes sense.
The Types of Projects
Contrast this with two other types of development projects that are out there in the world.
“F-22 Strike Fighter” projects
There’s the “F-22 Strike Fighter” type of project. In this project, the customer (the U.S. Defense Department, for example) develops a set of requirements that is then farmed out to contractors to implement. The goal of this project is to end up with a product that precisely delivers on the requirements as spelled out in the requirements document, no more, no less, and to do so at high quality and in a reasonable amount of time. And if there is a change to the requirements, it requires renegotiating the contract as a whole. Prioritization in this case is pretty easy, at least in the base case – the contractor has to implement everything in the requirements. That’s it.
Commercial software for sale
Then there’s the type of project that I work on, which is a commercial software product. In this case, the company producing the software, and in particular, the product manager, creates the requirements. The customer provides input on what they want, but their requests are not “requirements.”
(If we’re doing “agile,” of course, we focus on the most important ones initially.)
It’s easy to define a whole universe of features that could go into the product, only a fraction of which we are capable of implementing in a timely manner. So the fundamental activity of the product manager for a commercial software product, after coming up with this huge list of features, is to prioritize the list with the goal of having the most successful product when it gets into the market. There are lots of tools for this – lean startup is one great approach – but at bottom it involves developing a deep understanding, or at least a deep set of analytical tools, as to what the market really wants, what it is ready to actually buy, and so on.
Product Owner Is The Wrong Abstraction for A Commercial Product
The key point, when it comes to talking about a “product owner,” is that in the third case, commercial products, there is no product owner. There is no one person who knows what the product needs, whose decision is always assumed correct, and who can truly represent the universe of users. The product manager, rather, becomes a channel to the market, the set of users, and has to use techniques and skills to translate what the market wants to what the product should do.
In the spirit of agile, these are admittedly somewhat rough distinctions, but they are qualitatively on the mark.
- An F-22 type project has relatively low prioritization needs, but it has a lot of need for traceability, especially to testing and quality issues.
- An internal IT project has more need for prioritization, but there’s assumed to be one person who is capable of doing that prioritization and whose answers to prioritization questions are directly inspired by the usage of the product.
- Then there are commercial products, where prioritization is a fundamental, deep, and very difficult issue. There are typically lots of unknowns, there is competitive pressure, and so on. No one person can play a “product owner” role out of his or her head or based on his or her experience, but instead needs to actively engage the market and channel its needs and desires.
Agile Is Powerful, But “Product Owner” – Meh!
I don’t mean to imply that agile is meaningless in the context of a commercial product. I’m only addressing the product owner concept. As I’ve written about several times, an agile process is an intrinsically better approach to developing something of value than a waterfall process, even large features, because its nature is to ensure that delivery of value is front-loaded.
I’m curious whether others have struggled with this product owner vs product manager question, and what you’ve concluded. Please share your thoughts and let’s have a conversation about it.