A commonly used definition of a product is "something that is made to be sold."

“A product is anything that can be offered to a market that might satisfy a want or need”—McGreal, Don; Jocham, Ralph. The Professional Product Owner

The product provides a way of making a profit—or another value, for instance, social impact in the case of not-for-profit organizations. We use this definition and augment that with the following product properties:

• A product has users who are people.
• A product provides features to those users that address their needs and problems.
• A product has a business model; revenue stream, independent profit & loss (P&L), or return on investment (ROI).
• A product is developed and sustained by a system of people, components, and processes.

Most customers we work with organize teams around smaller areas of functionality with no straightforward end-user, customer or value proposition. In these cases, you find that the teams are working on just a part of the real product. The part they are working on is often a component or a specific activity in the business process; they use a narrow product definition. When many teams work on a product-part (that they call a 'product') then that group likely experiences unnecessarily reduced agility and long end-user feedback loops.

A broad product definition usually implies that the product spans lots of components and activities and provides solutions to the needs and problems of end-users. We prefer a broad product definition because that gives adaptability and short feedback loops. Why? There are several reasons:

• Wide product definition encourages all teams to focus on one Product Backlog that consists of end-user product increments Therefore, teams get a whole product focus and can learn about many product areas.
• Wide product definition encourages teams to increase work across product parts which reduces inter-team dependencies and thus shortens the feedback loop.

In Figure 1 the CLD explains how the broadness of a product may affect the speed of delivery.

Some product examples at our customers:

• Small Medium Enterprises Banking
• Media platform
• Energy Trading System
• Mortgage

Examples of product-parts:

• Internal CRM system
• Credit conveyor process
• Opening accounts process
• Website of a bank

The product definition that marketing uses might not be the same as the product definition used by the development group, which is perfectly okay. From a development perspective, the product definition is for optimizing adaptability to deliver value. From a marketing perspective, it might be beneficial to have a different product definition to address marketing goals like product identity and connecting with certain types of customers. For example, one of our banking customers has different kinds of loans with associated benefits and plans. These loans are presented as different products by marketing, but internally they are defined as a single broad product by the development group because if you look internally, the majority of functionality is similar for both products and they share the same architectural components and systems.

A systems approach considers the whole first and then improves the parts only if it also improves the whole. The whole, in our case, is the product, and the parts are the teams, users and systems. Furthermore, Russel Ackoff points out that the performance of a system is not the sum of its parts, but the product of their interactions. Therefore, we first define the whole product with all its parts, and then we redesign to improve their interactions.

The product definition determines what organizational elements (people, components, processes, and systems) will be part of the first step in your transformation. Your product definition determines:

• Who will be the Product Owner.
• What work items are on the Product Backlog.
• Who are the users of the product.
• And also, which organizational parts like teams and departments you need to develop and run the product.

You can define your product using the following two steps:
Step 1. Identify the required organization elements to develop and sustain the product.
Step 2. Clarify the revenue streams.
Let us give a brief overview of these two steps

You start with the elements—your component teams—you currently call products, activities, people, and processes in your group. You then study how the work works for your group to understand the types of dependencies that exist to develop, maintain, and sustain your product.
The typical steps to achieve this are as follows:

1. Identify typical external end-users of your group.
2. Identify the needs these end-users want to be addressed or tasks they need to complete.
3. Identify features for each of the users that they consume to address their needs or perform their jobs.
4. Identify the boundaries through which the users consume the features to satisfy their needs/problems etc. (for example, a Browser, App, API, Connector or Helpdesk)
5. Next, you want to identify the organizational elements that are needed to produce the feature and satisfy the customer. You do that by studying how each feature flows through your organization into the hands of the customer. You start at the boundaries and work through the components, systems, people, and processes until completion.

In our book, we show a few examples of facilitating product definition workshops.

A broad product definition should include revenue streams. Without it, the teams in the group will likely be disconnected from market concerns where the real value lies. Further, it probably divides decision making among various parties. Typically, one party—the business— is responsible for financials and requirements, while the other party—research & development— is accountable for delivering the product requirements on time and within the given budget. Each party will locally optimize for local concerns instead of adaptability
In this step we ask the question: Do the identified organizational elements generate revenue for the organization? Or are there missing parts to do so? The way we prefer is to find answers to the following questions:

• How do the elements together generate organization impact? For example, is the product definition able to have usage fees? Asset sales? Subscription fees? Licensing? If not, what would need to be added to the product definition?
• What business KPIs can you assign to the product definition? For example, can you assign it an increase in gross income? An increase in new customers? Customer satisfaction?

If you cannot give a meaningful answer to all of the questions above, then consider expanding your product definition.

At this point, you identified a set of organizational elements that together produce value for end-users and have a revenue stream.
The result typically includes many components, skills, and activities, and it can involve tens to hundreds of people in total. With such a large group, you may want to ask, "How can I create effective cross-functional teams that include all these capabilities?" In the case of more than around ten teams, we recommend organizing the teams among Value Areas that could be dynamic in size depending on how the Product Owner oversees the market changes. In the book A Scrum Book we defined a value area as: “A Value Area is a valuable product part that addresses the needs of a customer segment, but which has no useful value or identity apart from its inclusion in the product”.