Tag Archives: large projects

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.


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.

“Which project is best suited to pilot Scrum?” is a question I get regularly asked in my workshops and training courses. While it is always important to carefully consider the specific situation of an organisation, I have found the following six criteria helpful to select the right agile pilot project:

  1. Small: Your pilot project should be small and consist of no more than two to three teams. Large-scale agile development introduces additional challenges and requires further practices. If you must scale, start with one or two teams and slowly add more teams by splitting the existing teams and adding new members.
  2. Important: Make sure that your pilot is relevant to the organisation. Otherwise skeptics might dismiss it as a “pet project” and undermine the buy-in for the new approach. But avoid mission-critical projects – development efforts whose success severely impacts the organisation. Agile software development is a disruptive process innovation for most organisations. It requires the ability to experiment, to make mistakes, and to learn from them.
  3. Independent: Choose a project that has few dependencies on other teams. Having to coordinate with other projects or different groups adds a level of complexity and makes the disciplined application of agile practices difficult – particularly if the other projects follow a different process. If all you have to choose from is a large, complex project then look for a subproject with few dependencies to pilot your agile approach.
  4. Collocated: Start with a collocated agile project and avoid distributed development efforts, as these make effective collaboration more difficult and require additional practices and tools. Jointly writing user stories, pair programming, and having effective sprint review meetings become much more challenging, for instance.
  5. Software only: Limit your agile pilot to software development. This reduces the added complexity that arises when other disciplines such as hardware and mechanics are involved. Agile software development practices are also well understood. That’s true to a much lesser extent for hardware and mechanical engineering.
  6. New product development: Select a new product development project rather than updating an existing product if you want to try out Scrum. This allows you to explore how an idea is best transformed into a shippable product using agile practices. It frees you from worrying about a legacy code base that may be difficult to understand and lack the necessary tests. What’s more, Scrum is particularly well suited to cope with the flux, uncertainty, innovation, and risk that are characteristic of new product development.

Before you now select your pilot project or decide to delay experimenting with agile practices, consider the following advice:

  1. Know your goal: Understand why you want to try out a certain agile approach and what benefits you expect – even if it’s just to see what all the hype is about.
  2. Just do it: While it is helpful to look for the right pilot, nothing beats applying agile practices – even if you can only use selected techniques within your established process.

“What I hear, I forget.
What I see, I remember.
What I do, I understand.“
~ Confucius ~

The product owner is the person in charge of the product. For products of modest complexity and small projects, it may be feasible to have one individual playing the product owner role. But how do we deal with product ownership on large Scrum projects that develop complex products?

The Chief Product Owner

A large agile project consists of many small teams. Each team needs a product owner, but my experience suggests that one product owner usually cannot look after more than two teams in a sustainable manner. Consequently, when more than two teams are required, several product owners have to collaborate.

This puts us in a dilemma, as it conflicts with the Highlander Principle, which states that there should only be one product owner. The solution is to introduce a chief product owner. A chief product owner is responsible for the overall product, guides the other product owners, and facilitates product decisions.

There are two ways to apply the chief product owner role: working with one potentially large and complex product, or breaking up the product into multiple, independent sub products.

Option 1: One Product

If you develop one cohesive product with lots of functionality, you are likely to end up with a hierarchy of collaborating product owners with a chief product owner at the top, as the following image shows:

In the picture above, the chief product owner is responsible for the overall product whereas the other product owner manage feature sets or individual features.

Option 2: Product Suite

The second option is to break up the product into vertically-aligned, focused sub-products that can be managed by one product owner, as the following image illustrates:

The advantage of the product suite approach is to release the individual products separately and to package them to product variants. A flatter project organisation also means less overhead and faster decision making. The product backlogs are focussed and more concise reducing the grooming effort and increasing transparency.


If you work with more than one product owner, put one individual in charge of the overall product. As your product grows and becomes more feature rich, consider breaking it up into focused, vertically-aligned products that can be managed by one product owner and developed by no more than three teams. This allows the product owners to control their product, reduces decencies and overhead, and speeds up development.