Two products or one?
Contents
• Guide: What Is Your Product?
• Guide: Expanding Product Definition
• Guide: Product over Project or Program
Two products or one?
Any product that needs a manual to work is broken.
—Elon Musk
Early Scrum was confused.
Most early Scrum descriptions refer to Scrum as a framework for managing complex projects. Ken Schwaber, one of the creators of Scrum, wrote Agile Project Management with Scrum, which opened with “I offer you Scrum, a most perplexing and paradoxical process for managing complex projects.” This feels strange as Scrum has always been about products, not projects. There is a Product Backlog and a Product Owner, not a project plan and neither a project manager.
Luckily, this confusion is resolved. The Scrum Guide now states, “Scrum is a framework for developing and sustaining complex products” and eliminated projects.1 Does that matter? Hugely! As we’ll touch upon in this chapter:
What is your product? The Scrum Guide is silent on what product means and what the scope of that product is. Perhaps because it’s obvious? In large-scale development the definition of product is rarely obvious and one of the most important decisions you’ll make.
Why is the definition of product important? It will define the level and size of the Product Backlog, determine who are your end-customers, and who is a suitable Product Owner.
It also makes LeSS Huge more common than people would expect. A broader product definition often has more teams working on that product which leads to LeSS adoptions becoming LeSS Huge.
When scaling, principles related to product definition include:
Whole-product focus—Obviously, different product definitions lead to different focus. What product definition can lead to a broad perspective while still be meaningful enough to deserve focus?
Systems thinking & Continuous improvement towards perfection—Different product definitions lead to a broader or narrower perspective. Assuming broader product definitions are advantageous, what system dynamics does it cause? If the product definition is flexible, can it aid in continuous improvement?
Customer-centric—Whatever product definition is chosen, it must stay customer-centric. Will broadening the product definition be more or less customer-centric? From this perspective, are there different directions of expanding the product definition that are better or worse?
More with LeSS—Broader product definitions lead to LeSS Huge being more common than initially expected. Does this just add complexity or will it lead to more with LeSS?
The Product Owner prioritizes the Product Backlog, and the Teams incrementally build the product while keeping a whole-product focus. But what is the product? Is the product the output of the teams? Or whatever your current department happens to build? Or is it a component? A framework? A platform? Does it matter?
It matters. The product definition determines the scope of your Product Backlog and who makes a good Product Owner. When adopting LeSS, it determines the amount of organizational change you can expect and who needs to be involved. The question “What is your product?” might sound simple, but it isn’t. It is an essential choice.
You can choose to define your product narrowly. Suppose that a component developed by twenty teams is the “product.” That leads to a non-customer-centric technical Product Owner and technical items on the Product Backlog. Is that bad? Yes. It can’t be sold, it is not customer-centric, it doesn’t deliver customer value, and it often leads to building technical cool stuff that isn’t used or usable.
Alternatively, you can choose to define your product broadly. Broader definitions tend to be more customer-centric. Yet, when your product definition is too broad, it becomes impractical, as it may cover less friendly departments or even different companies. Also, it becomes increasingly hard to express a clear and compelling product vision.
So, what product definition to choose?
In LeSS, broader product definitions are preferred because they lead to:
enabling more customer-centric and finer-grained prioritization—all in all, a better overview of the development and the product
resolving dependencies using feature teams
thinking together with the customer—more focusing on the real problem and impact than on the requested “requirements”
avoiding duplicate functionality
creating simpler organizations
Enabling customer-centric and better prioritization—Narrow product definitions lead to many separate small Product Backlogs. How can you prioritize across them? How do you know there is a mismatch in priority, as there is no overview? The result? At best, big-batch coarse-grained prioritization between backlogs rather than item level. But more commonly, political games to promote one’s favorite team that is hyper-productively continuously delivering low-value items. In contrast, with a broad product definition all items are in the same backlog, thereby enabling fine-grained prioritization and increasing the overview in development and product.
Resolving dependencies—Narrow product definitions cause dependencies between separate products. Consider a platform product with a few “application products” built on top of it. The dependencies between them are managed by creating coordination roles who do lots of additional planning. These so-called products are, in fact, just components of a larger product, and the techniques to deal with dependencies are the same as used in component-team organizations. But we can resolve these dependencies differently. With a broader product definition those “dependencies” are within the same product. They can be resolved by giving a feature team the end-customer-centric feature that spans platform and application. This avoids additional roles and complexity.
Thinking with customers—A narrow product definition limits the possible solutions to real customer problems to the current product scope. For example, a customer requests the ability to export data in XML so that another “application product” can import that data. If the product definition were one of those applications—narrow—then it would be implemented as requested since the requirements (solutions) are limited to the product scope. But if the product definition were broader, it would increase the creative scope of the teams, who could explore better solutions to what the user is trying to achieve. In the case of data export, the teams might figure out a way to link the applications, thus eliminating the manual exporting and importing by the user.
Avoiding duplicate product functionality—A narrow product definition can lead to some similar products or product variants. These end up as separate departments who have or will have separate code repositories. When similar or the same product functionality is needed in multiple products, they end up with either (1) porting the functionality from the first product to the others, which tends to involve additional coordination and code clarification and rarely works well (2) re-implementing the same functionality for the different products, or (3) creating a new internal “component product” and moving the functionality there, with all the associated organizational complexity.
With a broader product definition, though, the product variants are managed as one, through one Product Backlog. This leads to one shared code repository and avoids the need to re-implement the same functionality multiple times. It also leads to simpler organizations.
Creating simpler organizations—A narrow product definition leads to additional organizational structures for the work and decisions between “products.” For example, the resolving dependencies section mentioned coordinator roles. Another example of this additional structure is project (or program) portfolio management, which boils down to big-batch requirements prioritization. The work from the narrowly defined products must be somehow prioritized and funded. Traditionally, the solution is project portfolio management whereby big batches of requirements—projects or programs—are periodically prioritized and funded together. Notice that the apparent need for this portfolio management is a consequence of complexity created by the narrow product definitions!
In contrast, a broad product definition would cause all work to be in the same Product Backlog: leading to all prioritization going through the one Product Backlog. This eliminates the need for the now obsolete project portfolio management, leading to a simpler organization.2
So broader product definitions are preferred. However, taking this to the extreme would lead to one Product Backlog for The World. What restrains the product definition? In short, commonality and structures.
Commonality—The items in the backlog must have some common reason for belonging to the same product. Three key commonalities restrain the product definition:
Vision
A common product vision motivates people and facilitates bounded creativity. A too-broad product definition would generalize the vision to “Do Stuff” and people would stop caring. So prefer all items to be towards a common meaningful vision.
Customers or markets
Multiple related smallish products might serve the same customers or markets. Having the product definition include all these smallish products eases prioritization and encourages teams to explore unserved customer problems. But a too-broad product definition containing all possible customers makes it impossible to figure out whose problems to focus on. So prefer all items to be for a clear and usually related set of customers.
Domain
Multiple products in the same domain often share a significant amount of similar functionality (or implementation) and require the same domain knowledge. Thus, broadening the product definition avoids duplicating functionality and allows for finer-grained prioritization. But, when the product definition was expanded to multiple domains—too broad—then no domain specialization would be allowed, causing the teams to forever learn new things without ever building anything. So all items should be in one or a few clear customer domains.
The questions about commonalities lead to both narrowing and broadening the product definition.
Existing structures—These also restrain how broad the product definition can be. The teams working from the backlog work within the same Sprint, coordinate and integrate their work together, and deliver one integrated product increment.3 Organizational structures need to change when adopting LeSS, but sometimes existing structures prevent a broad product definition... for now. Two existing structures that might prevent a broad product definition are companies and departments:
Companies
A part of the product might be built by another company. That can limit the product definition. Below are three common types of limiting multi-company structures:
Hired teams or outsourced development—The teams in the other company work only on this product. Thus they should work from the same Product Backlog and in the same Sprint. Avoid letting this constrain your product definition for long. Also avoid giving the other company one component, as that leads to component-team structures with all its associated problems.
Customized components—The other company customizes their generic product, which is a component in yours. They probably can’t work from the same Product Backlog as they have multiple customers. At least try to have them continuously integrate their product and customizations to our codebase.
Generic components—Either your company is creating a generic component that is part of a larger product, or your company is using a generic component made by another company. Either way, the teams building the component will never work from the same Product Backlog and in the same Sprint.
Departments
LeSS adoption usually involves structural change. However, the existing departmental structures can influence the amount of change and restrain the product definition. For example, application A runs on platform X. Platform X is also built internally and has only a few applications built on top of it. If product A and platform X are organizationally close, they should merge when adopting LeSS. Neither A nor X is an individual product but both are part of a broader product definition. However, if the only common manager is the CEO five levels up the hierarchy, then merging them would require a CEO-level decision. That would be impractical and would prevent the LeSS adoption from starting. So, temporarily create or continue with narrow product definitions for A and X but try to expand those over time.
The previous section mentions a key point: Product definitions can change over time. This is explored later in a separate guide.
Deciding on your current product definition and the potential future expansion is an important adoption step. It is usually done with early continuous discussions or sometimes in a more focused workshop.
We approach it by first exploring the expanding forces and then the restraining ones. We take the following steps:
Take whatever you consider your current product and ask the following product definition-expanding questions:
What would the end customers answer if we ask them, “What is our product?”
This question eliminates technical internal products and increases the customer focus.
Do we have components that are shared or functionality that is the same across our current products?
This question looks for product families that might be treated as one.
Our product is part of? What problem does the product solve for end-customers?
These questions explore larger products or systems that your product belongs to.
Explore the restraining forces by asking these questions:
What is the product vision? Who are the customers? What is the product’s customer domain?
These questions explore the commonality that must exist within the product.
What development is within our company? How much structural change is practical?
These questions explore the structural boundaries of the product definition.
Compare the broad product definition (outcome of step #1) with the practical product definition (outcome of step #2) and explore what is a good future product definition. What changes are needed to achieve that?
The output of these steps is the initial product definition and ideas for how to expand it in the future.
Following are three examples of product definitions. NB! They are simplified as each could be a book in themselves.
A financial trading group is often organized by financial product type (e.g. securities, derivatives) and further subdivided into a front office (deal making) and back office (processing). Each has its own business plus support development department.
A simplified trade-life cycle: pricing, capture, validation and enrichment, and settlement. For each step there is a component (or “application”) such as the Derivatives Pricing component or the Securities Settlement component. There is arguably 50% or higher duplication of functionality between components across the product types.
The traditional structure is component teams, with the view that the Securities Settlement component is a product, and so forth. Is it? Let’s apply the expanding and restraining questions:
What would end-customers say if we ask, “What is our product?”
Probably “complete trading solution” or “complete securities trading solution”.
Do we have shared components or functionality that is the same across our current products?
Yes, such as Reference Data and Market Data, and some are potentially shared but currently separated with high (but hidden) levels of duplication, such as Settlement, Trade Capture, etc.
Our product is part of?
If it’s claimed that Securities Settlement is the product, it’s part of Securities Back Office, which is part of Securities Trading, which may be part of a larger Financial Trading. Taking that further, the Financial Trading product is part of the Financial Trading system that includes several such products and exchanges.
These expanding answers point to defining the product as one that allows customers to trade. It would span securities and derivatives, front to back, and potentially even more. What restrains this?—only focusing on the key questions:
What development is within our company?
Our trading system development is all within our company, but the systems of the securities exchanges are outside. This definitively restrains the definition.
How much structural change is practical?
Securities and Derivatives are in different profit and loss centers, and the front-end traders specialize in one financial product. The managing directors of these groups aren’t very concerned about company-wide technology efficiency—unless pushed by the CEO. Thus, it isn’t yet practical to broaden across the financial product types.
The front/back office technology subdivision encompasses components that no doubt should be within one broader product such as a broader front-to-back Securities Trading product. But the separate directors will fight hard to keep their fiefdoms, and no one higher in the organization is yet focused on or especially concerned about merging them. Merging the front and back office is currently politically impractical.
In conclusion, most of the restraining answers support one overall Trading product that does not include the external securities exchanges. But the last question—How much structural change is practical?—points to political restraints that narrow the products further. Therefore the realistic starting point of defining products might be four products: (1) Securities Trading front office, (2) Securities Trading back office, (3) Derivatives Trading front office, and (4) Derivatives Trading back office.
In the future, the likely next step is to merge Securities front and back office products into one Securities Trading product, and likewise for one Derivatives Trading product.
A base station is the part of a telecom network that talks to your phone and connects it to the Internet. Usually, thousands of people are involved in developing a base station. Each generation of telecom network (2G-GSM, 3G-WCDMA, 4G-LTE, 5G) has a different variant of base station. These variants have different functionality running on different hardware. And within each generation, there might be sub-variants with different technology for different markets. For example, for LTE there are a TDD-LTE and a FDD-LTE sub-variant. A telecom group is often organized around these sub-variants.
One base station variant consists of some major components: Platform, Application, and several others. The Platform is shared across several variants and is traditionally a separate department from the Application.
At first, the definition of product seems trivial. But when it is explored with the expanding and restraining questions, it turns out to be far from trivial. We explore only some of the most important questions.
What would end-customers say if we ask “What is our product?”
In that case, if we decide an end-customer is a telecom operator, such as AT&T, then they would say: one specific base-station variant such as a TD-LTE base station.
Do we have components shared or functionality that is the same across our current products?
Yes. The functionality of the variants are similar and they share a common Platform component, suggesting that they are just one product.
What problem does the product solve for end-customers?
A single base station by itself does not deliver any value or useful functionality without the support of the phone and other components in a telecom network. In fact, a base station is just a component in a larger network, which suggests the expanded product ought to be the entire telecom network.
The expanding questions lead to the entire telecom network as the product. That would be pretty funny to everyone in telecom, so let’s use the restraining questions to explore why:
What development is within our company?
A telecom network potentially involves elements from many vendors and thus would be impossible to treat as one product. But all variants of base stations are within one company, so it would make sense to define the product as base station (covering all variants).
How much structural change is practical?
Different base station variants have their own departments and separate code repositories... that have a common origin but got split off along the way. Merging the departments would be, in the short run, politically hard to achieve, and merging the code repositories would be an enormous amount of work.
The Platform component that is shared between variants also has its own department and thus the organization will initially resist the inclusion of Platform within one variant. All this seriously restrains the product definition.
Conclusion? Unfortunately, the initial product definition must be one variant of the base station, albeit with an annoying external dependency on the Platform component, leading to internal component team dynamics. Over time, the product definition should include Platform and expand to cover more variants.
We keep this example short, but include it because of its important conclusion.
A banking group initially viewed online banking as their product. However, when exploring the expanding questions, they quickly realized that online banking by itself was not a product at all. Instead, it was one channel towards their real product—core banking services. After they exposed online banking for the component it really was, they realized it was the root cause of a lot of unnecessary complexity, such as synchronization between “products,” program management, and project portfolio management.
Unfortunately, the restraining forces exposed the political difficulty of merging their group within the real product, and hence their initial product definition is still just online banking. In this case, however, it wasn’t their product definition that should expand. Instead the core banking services product needs to extend to include online banking.
The previous guides determined that the product definition is a choice and explored how the restraining forces can cause the initial product definition to be less than perfect. This opens the door for using the product definition as a tool for continuous improvement.
During the life of the product, the organization must constantly ask themselves, “What prevents us from expanding the product definition?” The answers provide actions for future organizational improvement. In this sense, the product definition plays a role similar to that of the Definition of Done, except that the product definition tends to be harder to expand, as the organizational impact tends to be bigger, involving, as it does, different departments with their own goals, P&L, and politics.
With the popularity of project management, most companies seem to assume that all work must be organized around projects or programs. But what defines projects? A project has a clear start-date, a clear end-date that will be missed, and sort-of a fixed scope. Decisions, status tracking, and budgeting are based on the short-term project goal. The project ends with a release, and when a project is done, it’s done.
Products are not like that!
Instead, products have a clear-ish start-date, an unclear end-date, and a clear purpose with an unclear and evolving scope. They will be around longer than you expect! One product has multiple releases that are just points in time in which the product is shipped to the customer. Examples of products include nearly all software development. Not only obvious products such as mass-market software or online service products, but also less obvious internal products such as trading systems. Products outlive projects.
People are so accustomed to projects that they forget to notice that the usage of many projects in companies is to build and extend products. But that’s a mistake! Managing products as projects has severe disadvantages. These include: (1) decisions of long-term versus short-term trade-offs will be made based on the short-term, (2) frequent fantastical budget processes, (3) overhead of starting and stopping projects, and (4) temporary teams or even temporary employees.
LeSS prefers managing products as products. That means one Product Owner with one Product Backlog for the lifetime of the product. Advantages include (1) proper perspective on short-/long-term trade-offs, (2) financing based on the future value of the product rather than on specific features, (3) elimination of project and program structures and the associated overhead, and (4) stable long-term teams.
Much more can be said about the project/product distinction and its organizational impact. It probably deserves a book by itself.
The preference for broader product definitions leads to more LeSS Huge cases than most people would expect. In the cases where the earlier narrower product definitions were at least customer-centric, these smaller products might become Requirement Areas of a single larger product definition. For example, in the Financial Trading product mentioned earlier, the Requirements Areas would probably be Securities and Derivatives.
1. Except noting that each Sprint is like a mini-project.
2. Company-level product portfolio management makes decisions about which markets the company wants to be in. That will probably remain in very large companies.
3. The one integrated product increment can consist of multiple deliverables or even multiple sellable products. That’s a big idea we don’t expand on in this introduction.