This is the first part of a blog series about product definition in Large Scale Scrum.
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 decrease 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.
Remove Local Optimization Of Narrow 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.
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. ‘Mortgage’ is a broad product definition when it contains all the parts needed to produce/sustain an end-to-end solution to the end customer.
How To Define 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.
Recommended For You Webcast, April 23rd: Like. Fav. Share: Social Apps Coming of Age During COVID?19
Register Now
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:
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:
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, I recommend to organize the teams among Value Areas[1] and contain reciprocal dependencies per area.
References
[1] – http://scrumbook.org
No Comments