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, where the project was generally for a particular business unit. You could get a representative of the business unit – a real product owner – to come and represent its needs in a reasonable way. That person’s idea of what was important was considered trustworthy, and so that person could effectively make the prioritization calls. In other words, it was one person, and they knew what the priorities should be, because they were experts in that actual application.
The Types of Projects
Contrast this with two other types of development projects that are out there in the world. 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.
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. (If we’re doing “agile,” of course, we focus on the most important ones initially.) It’s pretty 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, 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 little 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, because 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.
IMO, a lot of this revolves around a much narrower scrum definition of "product owner" than is covered in commercial software companies by "product manager". See my [now quite old] 2009 talk, http://www.slideshare.net/Enthiosys/agile-product… , that maps only 4 or 5 of Pragmatic's boxes to scrum-defined product owners. This is much more of a heads-down, drive-drive-drive development role than full-up product management at tech product companies. Critical, but not strategic and not deeply engaged in the market. A deeper/narrower subset of the old Tech Product Manager job.
Generalizing wildly and welcoming objections:
Product owners are fundamental to the scrum model. And I love them. In some sense, product owners represent the fraction of product management that development managers appreciate and understand.
Product owners are usually recruited for their ability to understanding the software process: to organize user requirements and translate those into stories; manage a backlog; carve big into small; review and accept a rapid stream of software bits; see what’s missing. They may be former project managers, business analysts, development leads, subject matter experts (SMEs) or test engineers. They typically report up through the development organization. Rarely are they software product managers as traditionally defined.
On average, they lack real-world experience converting software into products into revenue: the rough-and-tumble of capturing value in the marketplace. Of "show me the money."
As development-side folks, they believe in a rational world where the best software wins. Where customers objectively evaluate products on features and standard criteria. Where salespeople close deals by presenting facts to interested prospects, rather than co-opting customer purchasing processes. Where prospects can compute their likely ROI. Where marketers explain the full richness of complex algorithms instead of shrinking web copy to three bullet points. Where product reviews and industry analysts see our shining brilliance and ignore our low-pri warts. Where prospects understand what problem we intended to solve, and coincidentally have that problem. (Would that it were so.)
And honestly, having filled this role many times, there's not much time at the end of the day/week/month to get out and really meet prospects or new customers. To rub elbows with SEs or sales reps who hear new things. To try out competing products. To play "secret shopper" and find out what the other guys are saying about you. To taste the market first-hand.
Let's admit that we need BOTH product owners and product managers if our tech companies are going to be agile AND ship stuff that real-world customers trade for cash.
Rich – thanks for the thoughtful note. It's clear you've spent some time on this question (in fact, I think I remember you leading a P-Camp session on the topic of "product manager vs. product owner".) I think my key response to your characterization of the product owner role is that, in a product company, the prioritization of the backlog belongs more to the product management side, not the product owner. And this includes not only the ranking of the epics, but key design decisions, and the selection of even which bugs can be deferred for least impact on the customers/marketability of the product. Definitely the activities you describe of managing requirements into stories, and generally providing the impedance matching between product management and development, is pretty important – and a key skill for product managers in small companies when you don't have staffing for another person.
looking forward to the third post in Rich's great series of blog posts: 'A Product Management Skills Map For Product Owners' http://www.mironov.com/pm-skills4po/ http://www.mironov.com/pmskills2/
I think this is the one you mean – http://www.mironov.com/po-skills/. He didn't put "part 3" in the name.
Rich has it right here: “product owners represent the fraction of product management that development managers appreciate and understand.”
I think I disagree with you, Nils, when you say that prioritization of the backlog should not belong to the PO. That’s one of their fundamental jobs in Agile. What I would say is that they don’t own the product STRATEGY. Figuring out what target market, target buyer, and target user the product should be aimed at, and figuring out what high-level goals should be set and themes should be hit — those are definitely for the product manager (or perhaps the product marketing manager in some places), but grooming the list of features and functions that will deliver on those goals and themes must be in the PO’s job. Otherwise, they are really just a business analyst.
Bruce – I think we are kind of on the same page here. My point is that for a smaller company, in particular, the "product owner" role is part of the product manager's job. And, in addition, for a product company, the product owner – whatever it is – is distinctly different from what he or she would be for an IT organization. Rich has done a great job of parsing this distinction in his longer series of posts on product managers and product owners – http://www.mironov.com/po-skills/.
I agree with both of those points.
In smaller companies, people play any hats — most especially in product management. In a very small company, a PM may be responsible for all of the classic product management triad (strategy, product marketing and technical product management) as well as related items like business analysis, business development, etc.
Commercial software is where the need for more strategic thinking comes into play — you are totally right about that — but once a commercial software org gets big enough, I've see the PO reemerge as a separate role along with (not instead of) product management.