If you grew up as a teenager in the 1980s like me, you are probably familiar with the quote “There can only be one” from the first Highlander movie. Interestingly, this statement is also true for product owners: There should only be one product owner per product. But don’t worry: You don’t have to become an immortal warrior to understand the Highlander principle. Reading this blog post will do the trick.
Can there be many?
Traditionally, product ownership tends to be distributed across several individuals: A product marketer, for instance, writes a product concept or market requirements specification, and a product manager turns it into a product requirements specification. A project manger is then tasked with executing the project, and works with a business analyst, requirements engineer, or architect to analyse and refine the requirements.
While distributing product management responsibilities supports a linear, phase-and-gate-based process, it is not well suited for an agile environment characterised by rapid delivery and fast learning. Additionally, the handoffs between the different individuals can cause defects, delays, loss of information, and other waste; decision-making can be slow and may result in weak compromises; and if the product fails, a blaming game is likely to start.
“There can only be one”
The alternative is to put one person in charge of the product; the individual leads the product development and owns the product on behalf of the company. This integrates strategic and tactical product management aspects. It unites authority and responsibility, and speeds up decision-making. Meeting the user needs, creating a desirable user experience, and designing a sustainable business model receives the attention and leadership it requires. It increases the likelihood of realising the vision by delivering an attractive, well-rounded product.
But just like Connor, the main character in the Highlander movies, needs friends and allies, so does the product owner. To mitigate the risk of a single product owner being overworked or making suboptimal decisions, the Highlander principle must be complemented by collaboration: Leveraging the ideas of users and customers by gathering feedback on working software; and using the knowledge and creativity of the development team by jointly grooming the product backlog.
Working with a single product owner role can be particularly challenging on complex products or large projects. But you certainly don’t have to be an immortal to apply the role effectively. On complex products or large projects, you have two options: You can either employ a product owner hierarchy with an overall product owner in charge of the entire product and feature and component owners responsible for features and components.
The alternative I prefer is to break up complex, feature-rich products into several sub products, each owned by a single product owner.
A benefit of working with a product suite is that the sub products can be developed and released largely independently. Additionally, scaling issues can be avoided or at least reduced.
Post a Comment or Ask a Question
The problem with what you suggest is that there is just no way for a PO to spend enough time in the market to absorb the knowledge and skill set necessary to articulate strategy and effectively communicate it across the organization. As long as the POs primary focus is keeping the development team fed full of the information they need, all the other roles become secondary and insufficiently represented.
I tried to straddle this fence for over a year before we concluded that it just wasn’t enough to have one person doing both. After missing too many sprint kickoffs while onsite with customers or attending tradeshows, we concluded that collaboration between prod mgmt and dev’s team-focused PO was necessary. Prod mgmt owns roadmap, PO owns sprints, and we meet in the middle to coordinate and launch a release.
Hi Patrick, Thanks for your comment. I can very much relate to your experience. I have seen a number of product owners struggle with balancing the strategic, market-facing and the tactical, development-facing aspects, and I have noticed that there are two common causes.
Some companies wanted to become agile but did not change their innovation approach and still required extensive upfront market research and product planning including detailed business plans. This put considerable strain on the product owners and is not inline with an agile, experimental approach that uses working software to discover user needs. At other organisations, the development teams and internal stakeholders did not support the product owners enough. Developers expected perfectly crafted, crystal clear user stories; management expected status reports and detailed plans.
Introducing the product owner role without changing people’s mindset and without changing the development system is not going to be successful in the long run.
It’s certainly possible for teams to share their PO. But there’s also nothing to stop multiple products, and their clear owners, from being aggregated into a larger product which also has a clear owner. Each collaborating team could thereby have its own PO.
Thanks for your comment Hanna. You are absolutely right: You can divide a larger products into parts and assign an owner to each part, as I have described in my post Scaling the Product Owner.
Yes, having one person making all decisions can be efficient. But the decisions are often lower quality, and the team that needs to execute on them often operates less effectively when its members don’t feel shared ownership.
Furthermore, healthy teams can operate just as efficiently in decision-making and more effectively in execution.
Check my blog entry on who really should own the product.
Thanks for your comment, Roger. You are absolutely right: If one person makes all the product decisions, then some of the decisions are likely to be suboptimal or wrong. That’s why single product ownership must be complemented by collaboration, as I’ve mentioned in my post.
However, if nobody plays the product owner role and the development team collectively manages the product, there is a danger of not paying enough attention to the user needs, the user experience, and the business model, but too much attention to the technical solution.