The Product Perspective

A Product+Owner

The Product Owner is most definitely the most misunderstood role in Scrum. There are good reasons why this happens, as a proper implementation of that role usually requires a change in how the organisation is structured.

We start by considering a small organisation using Scrum where just one team is working on a particular product this company is creating. The Developers have everything in their hands; they have all the competencies necessary to “get the job done”. Of course, this makes their work very flexible and adaptive: if there is anything they need to change in their development, they can meet shortly, decide what to change and implement it.

For their business priorities, they rely on their Product Owner. This person is “accountable for maximising the value of the product resulting from the work of the Scrum Team” or is “responsible for maximising return on investment (ROI) by identifying product features, translating these into a prioritised list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritising and refining the list.

The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. In the case of an internal application, the Product Owner is not responsible for ROI in the sense of a commercial product (that will generate revenue). However, they are still responsible for maximising ROI by choosing – each Sprint – the highest-value items”. (Principle: The Product Owner is accountable for sustained end value)

The Product Owner for this Scrum Team is probably either the owner of the company or somebody very close to that role. As such, this person understands the business and can drive the priorities in the Product Backlog to devise sensible business tactics and strategies depending on various constraints: financing, customer wishes, personnel-related issues and strengths, etc... The scope of these decisions is the Product as a whole. These “global” decisions impact the Product and the company betting on it.

This Product Owner knows every developer, stakeholder, and competitor one by one and interacts with them daily and is available for questions, clarifications, and discussions. It’s not just the decisions that characterise this Product Owner but also how this person can create a shared vision for the Product. Sure enough, the authority to decide lies in their hands and the responsibility for the Product's success: true accountability.

In this setting, decisions are swift: let’s talk to the Product Owner! In this way, we can have real adaptability at the Product level, which is the actual meaning of agility! (Related Principle: PO should inspect to see if outcomes have been achieved)

We could say that this Product Owner is a “Product” and “Owner” in the sense that their decisions span the entire scope of the Product, and the Product Owner is accountable for those, i.e. has authority and responsibility.

But... at Scale?

Let’s imagine now a company producing several “products” that result from the work of hundreds or even thousands of people, maybe overarching different companies, technologies and technical domains, and where there are several “components” that are common to several of those products. An excellent example to grasp the potential complexities is a car manufacturer. Several “platforms” are used to build different car models, yet the engines, and brakes, ... are built not only for those but for even more platforms. Even more: when the car is produced, it’s not the end of the “product”: your customers expect to get customer support to be able to find spare parts, ... and car manufacturers are moving more and more into the services market.

How do you define a “product” in this scenario? The problem is even more complex: how do you define a “product” in a way that helps you to adapt the product as fast as possible so that you can be as agile as possible?

Imagine for a second the scenario mentioned before. It would be great if it were possible to have your product developed by a small team of Developers under the direction given by a Product Owner. Still, the size of the development (number of people involved, amount of time, ...) is likely to make it very difficult, if at all possible, to keep this straightforward setup. So what parameters must we consider when defining a structure of Product Ownership at scale?

“Scale” is for Products, not for Organisations

First, a clarification on the usage of the word “Scale” in the context of Products: it has to do with the size of the Product, not with the size of the organisation! Imagine a big company developing dozens or hundreds of small products, each involving one team of Developers and each led by a Product Owner. While the organisation might be large, we can simply create many independent Scrum Teams and let them loose in pursuing value.

The Product Owners might work according to a company vision and might even align to avoid overlapping products and compete for the same customers. Yet, the model of the single autonomous Scrum Team still holds. No “scaling” is needed.

Now imagine a small company where there is a handful of teams working on the same Product: while the company might be small, the Developers are stumbling on the changes made by their peers in other Teams, hence the need to coordinate the work of the Team, hence the need to scale.

So whether we need some form of Scaling concept depends on the size of the Product, not on the size of the Teams!

Definition:

Scaling = a set of techniques used to enable two or more teams of Developers to cooperate when working on the same Product

A Product Owner can deal with more than one team

One widespread way to organise several teams of Developers working on the same product is to have one Product Owner per Team. This is primarily due to a misunderstanding of Scrum. While it’s true that every Team sees exactly one Product Owner to get the priorities from one single source, the opposite is definitely not true. (Principle: Each team "sees" exactly one Product Owner)

We suggest that a Product Owner focusing on prioritisation and leaving all the analysis and design work to the Teams can drive the direction of many Teams (though there will be a limit...). (Practice: One Product Owner may have multiple Teams, Principle: Minimum Viable Product Owners)

Small and Big Product Owners

Another typical pattern is having product owners take care of a particular aspect of a large system. An example is an e-commerce system that considers the product catalogue as a Product, the payments as another Product, and the shipment logistics as another Product.

Each of these Product Owners is dealing with a small part of an entire system, so regardless of their formal role, they usually have limited ownership for what concerns their part of the system, and every change that goes beyond the boundaries of their area is problematic as it requires synchronisation among Product Owners.

This means that system-wide decisions are often escalated to some senior management forum, usually called “program management”, “portfolio management”, or “steering committee”, and while some decisions might very well belong to that forum, there will also be a significant amount of low-level synchronisation issues that will be passed up the chain.

“Small Product Owners” require a “portfolio management” to arbitrate priority conflicts

The configuration described is what we call “Small Product Owners”. While unavoidable in some cases, it reduces the overall adaptivity of the product given the usually large amount of escalations. A better alternative, where possible, is to opt for a “Big Product Owner”, i.e. a Product Owner with accountability over a wider part of the Product. This type of Product Owner encapsulates all the low-level decisions, escalating to senior management only the high-level strategic decisions determining which Product in the portfolio receives more funding.

A “Big Product Owner” encapsulates product decisions. Upper management is deciding how much to invest in each product

Some Definitions

Definition: A Value Stream for a business process is the series of steps to provide the product, service and/or experience the customer desires. Definition: Product is used in this context to mean an actual deliverable product and a service and/or an experience desired by the customer. So, the Value Stream is the process that results in the Product:

A Linear Value Stream

i.e. we would ideally expect to have a Product Owner being accountable for the whole Value Stream that leads to a Product:

The Product Owner Scope of Accountability

We call this simple situation "Linear Value Stream".

However, at scale, the scenario is usually much more complex as the input from different clients is used to create several end products, trying to reuse as much as possible of the internal deliverables and create internal synergies. This is a situation we call "Composite Value Stream":

A Composite Value Stream

So, how are we going to define what is the Scope of Accountability for a Product Owner? How many Product Owners do we need? And how can they coordinate? To understand the most adaptive way to arrange a situation like the one above, we need to understand what the “Products” make sense to define. To do this, we need to consider several different parameters... (Principles: Minimum Viable Product Owners, Collective accountability in case of Product Ownership Group)

There might be a very simple answer to the question above: For a Composite Value Stream, only one Product Owner should take care of the whole "ecosystem" and be accountable for defining the optimum value delivery proposition. Sometimes this is a viable answer; if so, it should be chosen.

At scale, however, the sheer size of many Composite Value Streams, as well as the interplay with other organisational variables (different departments and different sites involved, teams with specialised knowledge, ...), makes it often impossible for a simple Product Owner to take care of the whole system. However, it needs to be always kept in mind that ​​splitting the work into separate parts needs to be seen as an anti-pattern that causes

1. The need for synchronisation points, i.e. more upfront planning (and less experimentation options)
2. Localised knowledge and silo work
3. Integration is shifted to later stages of development, thus postponing risks to later stages of development

The problems of products being built as the sum of the work of organisational parts have been described by Conway's Law. While sometimes this is needed, it is nonetheless a significant source of dependencies, coordination effort and political games, not to mention that the inability of each part to develop a complete and customer-focused product minimises the possibility of learning what is important for the customers and reduces the options for testing, thus resulting in longer and longer engineering cycles needed to validate the product being developed.

Regardless of the current structure, adapting the organisation toward an End-to-End Product is essential. This requires a focused effort at all organisational levels, and the details are explained in The Change Perspective and how the definition of product changes over time is a significant driver for change in the direction of agility.

Moving toward an End-to-End Product means having teams capable of working on larger and larger parts of the system. To do that, learning and creating teams with a broader solution and business domain accountability is paramount.

While on very large-scale developments, it might be impossible to reach a genuinely end-to-end-customer-focused Product, the path towards that goal results in fewer dependencies and more autonomous teams and, in the end, in a more adaptable organisation.

To do this, we must reduce Accidental Complexity! The path to reach a single Product Owner means working on progressively redefining what we consider a Product, simplifying the Product Development Organisation in successive steps.

Large organisations have several reasons why an End-to-End Product is not feasible. Some of these reasons are excuses that show a dysfunctional organisation. Here are a few examples:

• The product is too large/complex
• Our departments are organised in a different way
• There is no way our developers can work on such a large product at once
• We are organised in many different locations worldwide
• Our architecture does not permit a different way of working
• We need a system integration/test team to test everything in the end

The Teams and Craft principles describe in detail what are the problems caused by these assumptions and possible remedies.

To understand what that means in practice, we need to analyse what are the elements that influence a Composite Value Stream: the Product Dimensions.

The Product Dimensions

We can look at Products from different sides, different “Dimensions”. By assessing our product's essential and accidental complexity in each of these dimensions, we can evaluate how to organise the Product Ownership of our system to minimise the number of Product Owners, yet be able to drive the business properly. In general, the higher the accidental complexity in a particular dimension, the narrower the scope of accountability we will give to a Product Owner, hence going in the direction of Small Product Owners. At the same time, the more we can reduce the accidental complexity, the more global the accountability of a Product Owner and the fewer Product Owners will be needed.

Business Dimensions

The first two dimensions have to do with the complexity of the business we’re in:

Dimension	Reasons to opt for Narrower Scope of Accountability	Reasons to opt for a Broader Scope of Accountability	Comments
Product Strategy	If it is valuable to have parts of the Value Stream[s] visible as separate Products having their own strategy	When global optimisation is important (common experience, integration of Products, synergies among Products, ...), in particular when a broader Scope of Accountability would help creating a better experience for our customers and end users	The bigger the Product Owner, the more it becomes possible to drive global priorities in a complex system and deliver value to customers and end users: deliverables composed of several "components" to be assembled before the final delivery require additional organisational complexity. On the other hand, sometimes it makes sense to disconnect the strategy of several Products to allow them to be steered fast in their respective markets.
Multi-Product Strategy	Business Strategy of parts of the Value Stream[s] is more important than global decisions	Multi-Product synergies are more important	This is often an “Enabling Constraint” from the organisation, i.e. this is a deliberate choice to promote the integration of several products to be sold together.

Note that while it’s true that reducing accidental complexity will lead to a simpler structure of Product Ownership when it comes to the business dimensions, it is your decision on whether it makes sense to reduce complexity or whether the additional complexity seems reasonable and produces value for the company!

Constraints Dimensions

This second group of dimensions considers the aspects that might limit your decisions about what a Product is. Contrary to the Business Dimensions, accidental complexity in these dimensions is always problematic and worth removing. Trying to remove this complexity might, in fact, be the way to drive the company transformation over time!

Dimension	Reasons to opt for Narrower Scope of Accountability	Reasons to opt for a Broader Scope of Accountability	Comments
Technological: the number of different technologies that are needed to create the product	Many different technological domains	Fewer technological domains to cover or Developers learning more technologies	Developers have difficulties managing the overall scope of the development because of the sheer amount of technologies involved in building the product, hence the need to compartmentalise development and increase the coordination points. It is important to note that many companies opt for compartmentalisation of knowledge, hence creating artificially many apparently different technologies. For example, separating front- and back-end developers in different teams creates two “disciplines” that have no real reason to be different.
Technical: the technical practices used by the Developers	Development practices outdated	Technical excellence is the focus of the Developers	The application of modern technical practices - including widespread automated testing - simplifies experimentation and supports learning, hence reducing the need for information silos.
Product Size: how many people are involved in the development of the product	Larger products will make it more difficult to have a Broad Scope of Accountability for a Product owner	Reducing accidental complexity will help manage larger product developments while keeping a Broad Scope of Accountability for Product Owners	Size is seen as one of the prime reasons to split a value stream into smaller parts. Yet companies are developing similar products with very different organisation sizes, and often smaller organisations are more effective than bigger ones. We believe accidental complexity plays a very big role in this dimension, and opting for a Narrow Scope of Accountability is a significant component in creating accidental complexity.
Value Stream complexity: Composite Value Streams are inherently more complex to handle	Complex Value Streams might require to be split into parts	There is value in having a Product Owner responsible for the whole Value Stream	It is important to look at why the value stream is complex: often accidental complexity creeps in for various reasons: organisational history and structure, habits, no refactoring on the process, power structures, different locations, information silos, ...
Human Factors: We’re still humans, so things can go wrong even with a “perfect” process	Silos knowledge, lack of communication skills, multiple locations and remote communication, interpersonal problems, latent conflicts, ...	Individual and interactions, face-to-face communication, co-location, Developers interacting with the Stakeholders...	The way we interact is often an additional problem “on top” of the others: learning to interact and communicate at the product organisation level as well as keeping the energy and focus of working in small Teams. Here is where the support of professional facilitators can help and agile has a lot of suggestions for this dimension!
Politics: What should not happen in a company, but often plays an important role	Internal and inter-company politics play a role in how a value stream is organised: the more present and important they are in an organisation, usually the more the value stream will be split in parts in order to cater for the need of more roles with organisational power		Interestingly enough, lack of product focus (and customer centered approach) is an important reason why internal politics become a game people play. We have noticed many times that reorganising the company around customer value reduces the weight of politics and, more in general, of the other social networks of the company.
Organisational Structure: Often a product is being developed by a suboptimally structured product development organisation, either due to lack of understanding or, more often, due to historical reasons	The more organisational silos, the more information is isolated, resulting in more fractalised development. Loyalty to managers and organisational silos trumps loyalty towards the product vision and the customer	A properly organised product development organisation helps to organise teams around customer value	This often requires a radical management-led restructuring: a kaizen approach usually fails at the department boundaries, requiring a Kaikaku instead. This is why it is important for management not only to “support” an agile organisation but to be directly involved in creating it. Organisational Design principles help inform the change. Conway's Law is a popular way to describe the problem.

And, in your organisation, there might be additional dimensions to consider...

Using the dimensions

One of the most common problems in an agile transformation is to define “what is our product[s]”. This is especially true in companies with complex composite value streams: the discussion is not trivial. It becomes fundamental to drive the agilisation of the company properly. As we have previously seen, agility promotes using a product development organisation to deliver products. Hence, the process of re-organising around products is a central driving force of this work. (Principle: Minimum Viable Product Owners, Minimise unnecessary complexity)

In this re-organisation process, removing accidental complexity is paramount to getting to a “more agile” organisation than the original one. However, this process has many practical limitations due to the current organisation and what is realistically possible. Here is where the dimensions of a product become helpful. Consider a company with a composite value stream to deliver several products to the market. This is often done by taking various parts of the value stream and mapping them as “projects” under the lead of a project manager and coordinated by a PMO, portfolio management or a similar structure.

In practice, these are all silos that interact via pre-defined organisational interfaces, creating an interdependent system where every deviation becomes a project management nightmare. While this scenario is already challenging to set up in a production environment where the cycle repeats over and over, it is way more complex to handle in product development where the nature of the activities is less predictable and less repetitive. As such, improving how a company works could and should pass through repeating cycles of improving the product definition, each time looking at the product dimensions and understanding how to reduce accidental complexity in each constraint dimension.

It is important to notice there is no single strategy to implement these changes: sometimes, it is as easy as bringing the technicians together to "merge" some part of the organisation into a bigger Product definition. Sometimes the change is led by management changing the organisational structures to create a larger Product. Sometimes it might take years and a treacherous path to reach there, involving company politics, management egos, cultural differences, ...

And, sometimes, it cannot be done at all, but this is the crux of every organisational development initiative.