Product Definition in Large Scale Scrum (LeSS) – Part 1

This is a cross-post from AgiliX blog post.

This blog is part of a series of peek previews from my upcoming book Coaching Agile Organisations.

This is the first part of a blog series about product definition in LeSS.

In large product development, teams tend to work on just a part of the real product. The part – a narrow product definition – is often a component or a specific activity in the development process; it is not a product.

A narrow product definition creates all kinds of problems for a product group. It locally optimizes the performance of the teams at the cost of the performance of the group. The causal loop diagram (CLD) below explains this dynamic. (See this blog for a quick overview of CLD notation.)

Narrow product definitions make it more likely to have specialized teams that only work in their silo, which in turn decreases adaptability and speed of learning at the overall product level. Broader product definitions lead to teams that cover multiple components and activities that together address the needs of end-users.

What is a Product Definition?

A commonly used definition of a product is “something that is made to be sold.” The product provides a way of making a profit.

• 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, or return on investment.
• A product is developed and sustained by a system of people, components, and processes.

The product definition determines what organizational elements (people, components, processes, and systems) are needed to develop and run the product. If your product is Mortgages, then your Product Owner is probably a business person who understands the market. The Product Backlog might have items like “Loan offers to small businesses,” and the users are likely to be paying customers. Mortgages is a broad product definition when it contains all the parts needed to produce an end-to-end solution to the end customer.

How To Define the Product?

The product definition includes multiple components, activities, and provides solutions to the needs and problems of end-users. You can define your product using the following two steps:

Step 1 – Identify the required organization elements to develop and sustain the product.

You start with the elements – your component teams – you currently call products, the activities, the people, and the processes you have presently in your group. You then study how the work works for your group so that you understand the types of dependencies that exist to develop, maintain, and sustain your product.

The typical steps to achieve this are:

• Identify some typical external end-users of your group.
• Identify some regular needs these end-users want to be addressed or tasks they need to complete.
• Identify some features for each of the users that they consume to address their needs or perform their jobs.
• 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)
• 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.

Step 2 – Clarify the revenue streams

A proper product definition identifies a group broad enough so that it includes revenue streams. Without it, the teams in the group will likely be disconnected from market concerns where the real value lies, and instead, the teams focus only 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 so? The way we prefer is to find answers to the following questions:

• How do the elements together generate cash? 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?
• Does the product definition have an independent profit & loss? If not, what organizational 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 cannot give a meaningful answer to all of the questions above, then your product definition is too narrow, and you would need to expand it.

Product definition completed?

At this point, you identified a set of organizational elements that together produce value for end-users and have an independent revenue stream. The result typically includes tens of components, skills, activities, and it can involve hundreds of people in total.

With such a large group, you may ask yourself, “How can I create effective cross-functional teams that include all these capabilities?” In the case of more than around ten teams, we recommend to organize the teams among Value Areas and contain dependencies per area.

This is the topic of my next blog, part 2.