What is a Product?
Ilia Pavlichenko
Cesario Ramos
he product provides a way of making a profit—or another value,
T
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.
Figure 1: Broad product definition effect on end-user feedback loop. (copied from Creating Agile Organizations - A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)
Broad v.s. Narrow Product Definitions
for instance, social impact in the case of not-for-profit organizations
A product is anything that can be offered to a market that might satisfy a want or need
"
Figure 2: Organizational elements to produce the outcomes (copied from Creating Agile Organizations - A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)
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.
Product Definition from Different Perspectives
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.
You can define your product using the following two steps:
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.
A commonly used definition of a product is "something that is made to be sold."
McGreal, Don; Jocham, Ralph
The Professional Product Owner
The Professional Product Owner
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:
Why? There are several reasons:
In Figure 1 the CLD explains how the broadness of a product may affect the speed of delivery.
Who will be the Product Owner
What work items are on the Product Backlog
And also, which organizational parts like teams and departments you need to develop and run the product
Examples of product-parts:
- Internal CRM system
- Credit conveyor process
- Opening accounts process
- Website of a bank
Some product examples at our customers:
- Small Medium Enterprises Banking
- Media platform
- Energy Trading System
- Mortgage
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.
A Systems Approach To Your Product Definition
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:
How To Define the Product
Who are the users of the product
Let us give a brief overview of these two steps
Step 1: Identify the Required Organizational Elements
In our book, we show a few examples of facilitating product definition workshops.
Step 2: Clarify the Revenue Stream
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?
If you cannot give a meaningful answer to all of the questions above, then consider expanding your product definition.
Product Definition Completed?
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”.
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?
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?
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
The typical steps to achieve this are as follows:
Identify the needs these end-users want to be addressed or tasks they need to complete
Identify typical external end-users of your group
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)
Identify features for each of the users that they consume to address their needs or perform their jobs
THE BOOK
BLOG
MEMBER DIRECTORY
We use this definition and augment that with the following product properties:
A product provides features to those users that address their needs and problems
A product has users who are people
A product is developed and sustained by a system of people, components, and processes
A product has a business model; revenue stream, independent profit & loss (P&L), or return on investment (ROI)
Clarify the revenue streams
Step 2:
Identify the required organization elements to develop and sustain the product
Step 1:
Read more
Many problems at the workplace are not the fault of the individual managers or teams. They are often the result of working in an organizational design(OD) that impedes rather than supports Agility. The OD determines, to a large extent, how people cooperate, the prevailing mental models, and how work gets done. To change all of this takes time and requires people to unlearn old lessons and relearn new ones that support Agility.
The Critical Agile Organization Design Guideline
Resisting change during adoption is a normal human reaction. It is not a sign that a team or a particular department lacks courage or abilities. Also, it is not necessarily a sign that a particular framework or method is bad. Resisting change is not only inevitable; it is necessary for a change to become successful. A Scrum Master needs to be well prepared to work with resistance and have knowledge and skills in change management. In this article, we share a few critical guidelines that we use during change initiatives of any size.
The Critical Agile Organization Change Guidelines
According to Craig Larman, a renowned consultant, reducing switching costs by learning is resisted most by any organization. Speed of delivery can be quickly "sold" to management. But speed is by far insufficient to be Agile at the organizational level. Instead, the biggest issue in becoming Adaptable is narrowly specialized teams that stem from the lack of team and management investment in team learning.
What does it mean to be Agile on a large scale?
Creating agile organizations is hard work, requires patience, humour, and long-term commitment. It can take many years to simplify your organization and discover how to make agility work in your organization. But once you have been through all that, you ought to be able to react more effectively to changing market conditions
Certified Courses
What is a Product?
Ilya Pavlichenko
Cesario Ramos
he product provides a way of making a profit—or another value,
T
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.
Figure 1: Broad product definition effect on end-user feedback loop. (copied from Creating Agile Organizations - A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)
Broad v.s. Narrow Product Definitions
for instance, social impact in the case of not-for-profit organizations
A product is anything that can be offered to a market that might satisfy a want or need
"
Figure 2: Organizational elements to produce the outcomes (copied from Creating Agile Organizations - A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)
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.
Product Definition from Different Perspectives
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.
You can define your product using the following two steps:
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.
A commonly used definition of a product is "something that is made to be sold."
McGreal, Don; Jocham, Ralph
The Professional Product Owner
The Professional Product Owner
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:
Why? There are several reasons:
In Figure 1 the CLD explains how the broadness of a product may affect the speed of delivery.
Who will be the Product Owner
What work items are on the Product Backlog
And also, which organizational parts like teams and departments you need to develop and run the product
Examples of product-parts:
- Internal CRM system
- Credit conveyor process
- Opening accounts process
- Website of a bank
Some product examples at our customers:
- Small Medium Enterprises Banking
- Media platform
- Energy Trading System
- Mortgage
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.
A Systems Approach To Your Product Definition
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:
How To Define the Product
Who are the users of the product
Let us give a brief overview of these two steps
Step 1: Identify the Required Organizational Elements
In our book, we show a few examples of facilitating product definition workshops.
Step 2: Clarify the Revenue Stream
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?
If you cannot give a meaningful answer to all of the questions above, then consider expanding your product definition.
Product Definition Completed?
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”.
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?
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?
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
The typical steps to achieve this are as follows:
Identify the needs these end-users want to be addressed or tasks they need to complete
Identify typical external end-users of your group
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)
Identify features for each of the users that they consume to address their needs or perform their jobs
THE BOOK
BLOG
MEMBER DIRECTORY
RESOURCES
We use this definition and augment that with the following product properties:
A product provides features to those users that address their needs and problems
A product has users who are people
A product is developed and sustained by a system of people, components, and processes
A product has a business model; revenue stream, independent profit & loss (P&L), or return on investment (ROI)
Clarify the revenue streams
Step 2:
Identify the required organization elements to develop and sustain the product
Step 1:
Read more
Many problems at the workplace are not the fault of the individual managers or teams. They are often the result of working in an organizational design(OD) that impedes rather than supports Agility. The OD determines, to a large extent, how people cooperate, the prevailing mental models, and how work gets done. To change all of this takes time and requires people to unlearn old lessons and relearn new ones that support Agility.
The Critical Agile Organization Design Guideline
Resisting change during adoption is a normal human reaction. It is not a sign that a team or a particular department lacks courage or abilities. Also, it is not necessarily a sign that a particular framework or method is bad. Resisting change is not only inevitable; it is necessary for a change to become successful. A Scrum Master needs to be well prepared to work with resistance and have knowledge and skills in change management. In this article, we share a few critical guidelines that we use during change initiatives of any size.
The Critical Agile Organization Change Guidelines
According to Craig Larman, a renowned consultant, reducing switching costs by learning is resisted most by any organization. Speed of delivery can be quickly "sold" to management. But speed is by far insufficient to be Agile at the organizational level. Instead, the biggest issue in becoming Adaptable is narrowly specialized teams that stem from the lack of team and management investment in team learning.
What does it mean to be Agile on a large scale?
Creating agile organizations is hard work, requires patience, humour, and long-term commitment. It can take many years to simplify your organization and discover how to make agility work in your organization. But once you have been through all that, you ought to be able to react more effectively to changing market conditions
Certified Courses