The Highlander Principle

Posted on Wednesday 8th February 2012

Summary

This blog post discusses why it is important to put a single product owner in charge of a product and how this enables fast decision-making, learning, and delivery.

37 Flares Filament.io 37 Flares ×


If you grew up as a teenager in the 1980ies 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.

There can 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.

“We are brothers”

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.

Immortals Only?

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 or in the movie business to apply the role effectively. On complex products or large projects, you have two options: You can either employ a product owner hierarchy with a chief product owner in charge of the entire product and product owners responsible for features.

The alternative I prefer is to break up complex, feature-rich products into several lean, vertically aligned 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.

Summary

Learning from user feedback quickly requires effective decision-making. By putting one person in charge of the product, rapid experimentation, learning, and delivery are facilitated. Combining strong product leadership with collaboration and teamwork increases the chances of creating a great product.

No immortal warriors required. Promise.

8 comments on “The Highlander Principle

  1. […] the product owner role Two common ways to apply the product owner role The Highlander Principle Avoiding common product owner mistakes Scaling the product owner Desirable characteristics of a […]

  2. 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.

  3. Patrick Masi says:

    Hi,

    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.

  4. […] Don’t be afraid, however, to facilitate the discussions and to make a decision if no consensus can be reached. You don’t want to get stuck in analysis-paralysis but move on […]

  5. […] it conflicts with the Highlander Principle, which states that there should only be one product owner. […]

  6. […] A single product owner is beneficial to enable effective decision-making. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>