When multiple teams are working on a single product?

The Scrum Guide describes the Product Owner as the sole person responsible for managing the Product Backlog. In other words, the Product Owner defines what the development team is supposed to build and in which order.

The “less is more” philosophy certainly applies to Product Owners, but there are many situations when having multiple product owners is unavoidable, and it’s paramount to know how to deal with them.

One Product Owner to rule them all

<blockquote><p>“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product,”</p><p>— the Scrum Guide</p></blockquote>

One Product Backlog means one Product Owner, which is why Scrum purists argue that you can’t have multiple Product Owners and Scrum at the same time.

According to the Scrum Guide:

<blockquote><p>“The Product Owner is one person, not a committee.”</p></blockquote>

The Scrum Guide is very clear about this because committees are known to reduce transparency and dramatically slow down inspection and adaptation.

<blockquote><p>“It’s very hard to listen to multiple voices,”</p><p>— Rebecca Jones, Boost Scrum Master for New Zealand’s National Library.</p></blockquote>

With multiple Product Owners, accountability becomes an issue. When nobody feels personally accountable for meeting deadlines and accomplishing critical milestones, the product backlog often grows larger and larger with no single neck to wring. What’s more, the presence of multiple Product Owners requires complex coordination and alignment, and even the slightest misalignment of priorities can prevent individual teams from doing work.

However, the real needs of real companies working on real products often take priority over best practices.

<blockquote><p>“If we had one Product Owner, they would spend all their time being a Product Owner, creating stories, sizing stories, doing refinement. Eventually, they’d become disconnected with the actual business that they were supposed to be the Product Owner for,”</p><p>— James Robertson, DigitalNZ Systems Manager.</p></blockquote>

The management of complex products is frequently the shared effort of multiple Product Owners, so it’s important to know how to split product ownership in a way that preserves transparency, aids inspection, improves adaptation, and doesn’t lead to inconsistencies.

When more is necessary, LeSS is the answer

<blockquote><p>“As long as a product is young and hasn’t reached product-market fit—or is close to achieving it—I recommend having a single person in charge of the product,”</p><p>“But once the product is becoming more successful and starts growing, once it attracts more features and becomes richer and requires more teams to develop it, a single person can usually no longer manage the product—without being overworked or neglecting some responsibilities.”</p><p>— product ownership expert Roman Pichler.</p></blockquote>

For example, a product may have several different streams that require a variety of skillsets, with a Product Owner assigned to each stream. A single team sometimes works on daily updates for multiple products, each of which has its own Product Owner. A web development agency may decide to outsource mobile app developers to work on the same product, creating the need for multiple Product Owners.

Large-scale Scrum frameworks for multiple Product Owners

With multiple development teams, the LeSS Huge framework provides a convenient solution that splits the Product Backlog into multiple Requirement Areas and assigns a different Area Product Owner to each. Requirement Areas are customer-centric categories of Product Backlog items, such as reliability, management, upgrades, continuous integration, protocols, and so on. Area Backlog Items are finer-grained than Product Backlog items, which are more coarse-grained and thus more manageable.

<blockquote><p>“An Area Product Owner specializes in a customer-centric area and acts as Product Owner in relation to the teams for that area,”</p><p>“An Area Product Owner does the same work as a Product Owner but with a more limited, yet still customer-centric, perspective.”</p><p>— LeSS Creators on the official website of the framework.</p></blockquote>

It’s recommended for one Area Product Owner to work with 2 to 8 Development Teams, which is what the standard version of the LeSS framework recommends. Likewise, it’s recommended for Development Teams to have the option to exchange some stories between them in order to promote the idea of a common Project Backlog.

In addition to the LeSS Huge framework, there’s also the Scaled Agile framework, which works with Product Owners and Team Backlogs instead of Area Product Owners and Area Backlogs, and the Product Manager and the Program Backlog instead of the Product Owner and the Product Backlog.

<blockquote><p>“Each Product Manager can usually support up to four Product Owners, each of whom can be responsible for the backlog for one or two Agile Teams,”</p><p>“Successful development is, in part, a game of numbers in the Enterprise. Without the right number of people in the right roles, bottlenecks will severely limit velocity.”</p><p>— the official website of the LeSS framework.</p></blockquote>

What the LeSS Huge and Scaled Agile frameworks have in common is that one Project Backlog is assigned to exactly one Product Owner, regardless of what terminology is used. This clear division of roles helps maintain priorities in the company and prevents the risk of conflict between different projects.

Conclusions

When the scope of development is huge, and the management has no other option apart from sustaining multiple development teams, it’s often best to split the Project Backlog into multiple areas and assign exactly one Product Owner to each area.

Resources

We've all come across this adage "Too many cooks spoil the broth.", and it surprisingly turns out to be true for all walks of life, including the intricate world of product management.

With many IT companies embracing a hybrid or fully remote working model now (one of the impacts of Covid-19), it has become increasingly challenging to keep everyone in the team in sync with the ongoing developments of a product. The same is true for products where there are more than one product managers (or product owners), who when not synchronized with the product's goals and visions, can prove detrimental and greatly reduce the chances of the product's success.

As product managers act as the North Star of a product, it's very important that all product managers sync themselves with one another, as well and keep every product activity aligned with the product goals. As easy as it sounds, this is the most difficult one, and the remote work model has just exacerbated the problem.

In addition to that, with products becoming more complex and end users preferring 'one stop for all' solution, it's just humanly impossible for one product manager to work with multiple teams. Going by the current trend, future products would not only be about providing solutions to problems but would also be about how smart they are, or how 'human' they are in solving our problems. And, solving the problems with so many teams can't be done by a single individual.

So, does that mean that such products will eventually fail? Not really! Here's a list of some of the practices that I recommend every Product Manager, working with multiple other product owners and development teams, follow, to increase the odds of a product's success:

Be the guardian of the product's vision and goal: It's very easy to digress from the product vision and goal when multiple product managers or product owners work for the same product. As I have mentioned above, teams structures are evolving into distributed, larger and more diverse forms, and therefore, having multiple product managers or product owners is becoming a necessity.

As many product managers working together can lead to tussles and clashes, I advocate the model where there's a chief product manager or chief product owner and multiple product managers/ product owners working with him/her. Many would disagree to the proposal but I have not come across a better solution to solve this problem, and it may not be perfect but it works!

So, elaborating further, it would be the primary responsibility of the Chief Product Manager to repeat and remind the product vision and goal to all product owners so that everyone in the team is aligned. This is possible with regular and frequent meets between the Chief Product Manager and other product managers or product owners and synchronize all with the over aching product goal.

Attend end user interviews & usability test sessions: It can be very challenging for any individual to play so many roles all by him/herself, and can therefore, be tempting to delegate the job to other product owners, but I'd strongly advise and recommend all such Product Managers to attend such sessions at all costs. The reason is very simple: these meetings are very effective ways to validate your hypotheses and ideas with very little effort. The number of test subjects may not be very significant, but these sessions can pave the way for all future researches.

Don't try to do all by yourself: Being the 'decision maker' and making product decisions everyday can take a heavy toll on you, so it's very important to focus and prioritize your work. There's only so much you can do considering the number of meetings and interaction that you have day in and day out. Therefore, invest your energy and focus on tasks that are strategic in nature, and delegate the rest to the other product managers or product owners.

Don't be an autocrat but make firm decisions: No one likes to work with an individual who doesn't listen to ideas of others. Having more than one product managers can actually help you in better problem solving, and encouraging others to share their ideas has helped me time and again to making better product decisions.

However, it doesn't mean that you have to agree to all proposals from other product managers, and it's important that you learn to say "no" to others as and when you deem fit. Practice being data driven, and logic oriented while making decisions and manage your personal opinions and biases to make better decisions.

A single Product Backlog for one product: It may sound cliche when I say that there shouldn't and can't be more than one Product backlog for one product, even if multiple teams are involved in the development of that product. It may sound logical to have separate product backlogs for separate teams, but, if your team decides to do so, it'll severely impact transparency, reduce visibility, and most of all, hide the overall picture of the product.

On the other hand, when you have a single product backlog, it makes it easier for the Product Manager to order features based on business priority, as well as keep everyone informed of the future plans for the product, and for every other product owners and team members to align themselves according to the updated product backlog.

Encourage teams to practice Scrum: Although Scrum will not solve any of the problems described above, it will help teams practicing the framework to do things better and evolve as a more effective and productive team with the passage of time. With guidelines on team structure and team interactions in the form of mandatory events, Scrum makes it easier to find, analyze and resolve issues and problems faster.

As a Product Manager, Scrum helps me manage 'risks' better, as scrum teams develop features in fixed iterations, called 'Sprints', which are of a duration of four weeks or less. By the end of the sprint, I can validate the developed features with the target end users and take further decisions based on the feedback.

In addition to that, I can choose to release any or all of the developed features as per market needs, and this, at times is a game changer in today's times, when there are many competitors trying to solve the same problem as we do.

The above points are in no way a complete set of all the good practices that you can and should follow as a product manager. They have helped me build better products and will hopefully help you focus more on your product, thereby, improving its chances of success!