Meaning of “Product” in SCRUM Agile

If you work in a SCRUM team, you undoubtedly know that you have to have a product backlog and product owner. But what exactly is the meaning of a product in agile? For some teams, this can be a rather fundamental question. After all, an organization cannot identify suitable product owners, teams and roles without first knowing what the definition of its products are. And if there needs to be one product backlog per product, we need to know what our products are before we create a product backlog for each.

What is the meaning of a ‘product’?

To settle this topic, I start with my own, somewhat generic, definition of ‘product’:

A product is an item (physical or not) that is created through a process and that is offered to meet the needs and wishes of the target group.

An e-tail organization as an example

As an example, I take a company with a webshop. I myself have worked for several ‘traditional’ retail organizations that joined the world of online sales. After SCRUM was introduced, the question was usually always asked what we (agilers) actually consider the meaning of the word ‘product’ in our job names and backlogs. While most retail tigers see products purely as physical items that go over the counter, there are of course also services that are approached as a product. Think of additional warranty packages on goods or tailor-made advice.

Marketers and technicians like to go one step further. And that is exactly the reason for this blog. If I go back to an e-tail organization, we need a lot of software and hardware that can perhaps also be seen as a product. I take the webshop as an example. This means of transaction can be seen as a service for our customer, as it helps in the easy buying of products, viewing offers but also vacancies. Is the webshop itself also a product? I think so, since it contributes to the needs and wishes of our target group “the customer”.

Another good example is monitoring of click behavior of this particular webshop. But how exactly does it contribute to the needs and wishes of our target group? Well, that has more to do with the definition of your target groups. After all, colleagues (marketers in this case) are also a target group. By means of monitoring, they are able to understand how customers move around the webshop, where their interest lies and what they encounter. This gives the marketer the opportunity to present customers with more relevant offers and a more pleasant journey. In this case, both the webshop and its monitoring are a product.

How do you define a product within SCRUM agile?

With the above perspective in mind, I would like to zoom in on the way in which products can be determined with a SCRUM approach. I have often struggled with the question of how do I shape my products in a way that they:

1. Contributes to the company vision;
2. Results in scrum teams operating as well as possible, with as little overlap as possible;
3. Most important: bringing as much value as possible to my target group and organization;

I have to make a comment on point 2, since I have also experienced that the too many scopes of teams can lead to tunnel vision and therefore so-called ‘sub-optimization’. This focuses too much on one focus area (of the total) where control of the big picture is lost. While organizations want to define all of their products to best manage work, they don’t want to limit their focus so much that they don’t see the whole thing because they’re fixated on the individual areas of focus. As such, organizations want to define each product as broadly as possible. But then we’re back to it.

Roadmap

The product definition includes multiple components, activities and offers solutions to the needs and problems of your target group(s). You can define your product by following these two steps:

1) Identify the required organizational elements to develop and maintain the product.

You start with the SCRUM teams you currently call products, the activities, the people and the processes you currently have in your area of focus. Next, study what the work within this area of focus looks like so that you understand the types of dependencies that exist to develop, maintain, and maintain your product. The typical steps to achieve this are:

• Identify your target group(s) (the end users) within the focus area;
• Identify some regular needs that these end users have or tasks that they need to complete;
• Identify some features for each of the users that help them to meet their needs or perform their work;
• Identify the boundaries through which users use the features to meet their needs or challenges (e.g., a browser, app, or interface);
• Next, you identify the organizational elements needed to build the function and satisfy the customer. You do this by studying how each feature flows through your organization and ends up in the hands of your customer. You go through all components, systems, people and processes.

2) Expose the revenue streams

A correct product definition identifies an area of focus that is broad enough to include so-called ‘revenue streams’. Without it, the teams within a focus area are likely to be disconnected from the business interest (where the real value is) and instead, the teams will only focus on the part of the whole product.

In this step we ask the question: do the identified organizational elements produce a product that generates revenue for the organization? Or are there missing parts to do this? Our preference is to find answers to the following questions:

• How do the elements generate money together? For example, can the product definition charge an operating fee? Sale of assets? Subscription fees? Licensing? If not, what should be added to the product definition?
• Does the product definition have an independent profit and loss? If not, what organisational elements are missing?
• 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 can’t give a meaningful answer to all of the above questions, your product definition is too narrow and you need to expand it.

Have you determined your products?

Congratulations! At this point, you’ve identified a set of organizational elements that together create value for end users and have an independent revenue stream. The result typically involves dozens of components, skills, activities, and can involve a total of hundreds of people. You will discover that you have to refine in the future. It is a continuous game of analyzing, learning, adjusting and analyzing again.