In this blog I talk about how you could deal with the challenges of defining your product in a LeSS adoption.
Why do you need to define your Product?
In a LeSS adoption you need to have a product definition, because your product definition determines what organisational elements (people; components; processes and systems) will be part of the adoption. Your product definition determines:
- Who will be the Product Owner;
- What items are on the Product Backlog;
- Who are the users of the Product;
- and also which people you need to develop and run the Product.
For example. Let's say you define your product as "the backend", then your "product owner" is probably a technical person who understands the backend, and the items on the Product Backlog are likely very technical like for example "extend domain model with ...", and the "users" are other development teams.
On the other hand, if you define your product as "Business Loans", then your Product Owner is probably a business person who understands the market of business loans, the Product Backlog will have features like "Express loan offers to small businesses", and the users are paying customers.
What is a Product?
Most customers I work have been scaling Scrum using what I call Copy Paste Scaling and introduced narrow product definitions and lots of other problems because of that. I then have to make the teams aware, that what they are actually working on is just a part of the real product. The part the teams are working on is known in LeSS as a component.
In LeSS, we prefer that the Product is defined as broad as practical because that will give you adaptability and speed. In LeSS adoptions, this usually means that the Product spans lots of components. Also, we want the Product to provide solutions to the needs and problems of end users. And, in case of commercial companies, the Product must provide a way of making a profit.
When working with my customers I define a product as having the following properties:
- It has users who are people;
- It provides Features to those users that addresses their needs and problems;
- It has a business model; (independent P&L)
- It is developed and run by a system of people, components and processes.
So, if you are working as a team or Product Owner on something that does not have 1 or more of the above properties, then you are probably not working on a product. Of course there will be exceptions to the rule, it is just that I have not seen any commercial product until today that does not have these properties.
Internal and External Product Definition
The product definition that marketing uses might not be the same as the internal product definition used by the LeSS product group; and that is perfectly okay!
Marketing might differentiate their product definition to create product identity and connect with certain types of customers. For example, in one of my banking customers, they have difference kinds of credit cards with associated benefits, plans etc. These credit cards are presented as different products by marketing, but internally they are defined as a single broad product by the LeSS group. Another example could be the different smartphone models (product family) , as they are defined as separate products for the end consumers. Internally the smartphones probably share a lot of their (software) development components and might be defined as a single Product.
So, from the LeSS development perspective the product definition is for optimizing adaptability, speed and learning. From a marketing perspective, it might be beneficial to have a different product definition.
Where does Product Definition Fit In Your LeSS Adoption?
LeSS adoptions are mostly about moving a product group from teams that focus on a small part of the whole product, to teams that have a whole product focus. At the start, the teams usually already work in an agile approach like Scrum, but the group wants to take the next step and fix their problems. ( See Scale Your Product Not Your Scrum ).
LeSS has some approaches for moving teams to a whole product focus. One approach is a all-at-once approach that if often used for a smaller LeSS adoption. The other approach one is an incremental approach, using a Feature Team Adoption Map which is typically used in LeSS Huge adoptions. (See Feature Team Adoption Map Explained for more details)
In both adoption approaches you basically follow the steps below:
- Define your Product
- Define the activities needed to have a perfect Definition of Done. ( Once you know the Product components and Definition of Done activities, you also identified the people needed to ship the product. )
- Let the people self-organise into Feature Teams that can cover most Product components and Done activities.
- Determine how to deal with the Product parts and Done items that are not taken on immediately after the flip, if any. (For example, use Feature Team Adoption Map)
Below you can find a detailed explanation of step: Define your Product.
Defining Your Product
Step 1: Study how the work works
You want to study how the work works for your group, so that you understand what organisational elements you need to develop, maintain and run your product. The steps I take are:
- Start with the things you currently call "products" (components), the people and processes you have currently in your group;
- Identify some typical end-users of your system (could be people from antoher company integrating your product into their product);
- Identify some typical needs these users want addressed;
- Identify some features for each of the users that they consume to address their needs;
- 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)
Follow each of these features from boundaries through the components, people and processes that are needed to provide the feature and satisfy the customer. Some components or other organisational elements get touched a lot of times by different features or by different users' needs. When this happens, it is highly likely that there is a reason for that, and the reason is that these organisational elements are probably part of the same Product and not a "product" on their own.
You will notice that your Product will be defined broader and broader, which is good if you want to optimise for adaptability, speed and learning. It is also very useful to use the expanding questions / restraining questions as described in the guide Define Your Product of the LeSS book.
The end result will be the set of components, people and processes that define the product.
Once you understand what organisational elements are needed to develop, maintain and run your product, you need to define what organisational elements you want to start with. Also, the identified organisational elements could involve 100s of people and that means you probably want to use an incremental approach and divide the Product into Value Areas. But where to start?
A helpful tool to figure this out is to use a Component Heat Map.
Step 2: Component Heat Map
Now that you have your Product defined you can study your work even further. Have a look at the features you want to develop the coming months and plot them against the components that are touched when you develop the Features. When you track the number of times a component is touched by the features, you get a sense of which components are used the most. You can say that, the more a component is used the more it lights up, hence you create a Component Heat Map.
The components that heat up the most indicate the work you have most of, and this information is very useful in LeSS (Huge) adoptions. The information helps the Feature Teams to select the order in which components are adopted. You want to optimize for that work you have most of, so the components that you need most should go first!
Also, the Component Heat Map will have various Hot Spots as you can see in the graphic above. In LeSS Huge, these Hot Spots could point to Value Areas in your Product that you can use to identify your LeSS Huge Requirement Areas.
There are more ways to identify your Requirements Areas. In LeSS a Requirement Area is defined from the customer's perspective. Another approach to find your areas, is to ask your customers to group PBIs from their perspective.
Please remember that smaller Products are preferred, but they have to be real products. An exception is when you have many small independent products, because then the negative dynamics of local optimisation can severaly reduce adaptability at the compant level. See Value Stream Fork for more details.
So far for now, I have to go to watch a football game.
In future blogs I will write about steps 2, 3 and four of your LeSS adoption.