Considering we are talking about the Agile Product Operating Model and how Scrum is a product-oriented approach, you would think that how you define your product is simple. After all, you are reading this on a product, drinking your coffee from a product, and you consume products every day. But surprisingly, product definition is much more complex than it first appears.
I discussed these challenges in my blog after a webinar on product definition. Broadly speaking, anything can be a product as long as it has a clear set of users, stakeholders, and value. The organization can build a product roadmap and economic model for the product, and the product will exist for a period of time.
For software companies, the idea of a product is simple, as their unit of customer value is product-centric. However, even those companies find it hard to change their product definitions over time as the market and opportunities change. Once you define your boundary, it seems very hard to change it. For example, should Microsoft Excel be a collection of products? As companies grow, scaling becomes an issue. Product features multiply, configurations become more complex, and customer requests grow. Also, as the company grows, the bureaucracy becomes more complicated. Sales and marketing get bigger, creating more managers. Finance grows, adding additional stakeholders. New markets come with laws and regulations, which add to the number of stakeholders and their requests. What capabilities are in and out of the product (boundary) might not have conceptually changed, but the cognitive load for the teams working on the product has grown. For many large companies, it seems logical to break the product down into more focused products, shared service products, or platforms. These should be handled as individual products, even if the user base is internal and purchased as part of another product.
Many in the agile community argue that these “sub-products” are not products because they do not completely serve a customer value chain. By creating these sub-products, you are increasing the complexity of the environment without any real benefit. That complexity/dependencies will slow down the ability to deliver, get feedback, and ultimately provide more value. There is some truth to that. However, the distinction between whether something is a product or not is arbitrary. It is ultimately what makes sense to an organization. The question you have to ask is, where are we moving the complexity? Inside or outside the product boundary? And what are the implications of that?
Sub products or sub something else?
At the heart of good agile adoptions lies a simple truth. The most effective agile organizations have: Empowered teams with a clear sight of the problem they are solving and the ability to easily release an increment of value.
Using the concept of product gives you a collection of ideas that help your teams succeed. They include:
- Clarity of boundary - You know what is or is not part of the product
- Definition of user - You know who the product serves
- Clarity of stakeholders - You know who has a vested interest in developing and using this product
- Investor - Someone pays for this product to be built and supported
- Value - At the simplest level, the product provides more value than costs
- Roadmaps - Because a product exists outside of the work being done on it, you have to build roadmaps that describe its future
- Connection to business strategy - If people are working on the product, it must align with the business strategy
I am sure many of you are looking at this list and saying. I work on a product, and we do not have many of these things. In particular, value, roadmaps, and business strategy. I am not saying that if you are missing any of these things, it is not a product, but a product focus enables you to build or define these things. And if you can not find these things after lots of effort, then you may not be working on a product, or it is not a completely formed product.
The more I ponder the idea of product, the more I feel that it and its relationship with sub-somethings are perhaps a scale, not binary. For example, A well-defined product would have clarity and direct access to stakeholders. In contrast, a sub-something would only have proxy access to stakeholders via the primary product team. Everything “could” be a product, but some collections of capabilities have more product-like characteristics than others. Exploring the dimensions of “product-ness” would look something like this:
Other dimensions could be added in areas such as operations or investment, and there is another dimension around ownership. For example, Stakeholders could be clear, but the relationship is not owned by the product team, but again by the product's consumers.
The question is not whether is this a product, but..
Okay, so if there is not a universal definition of product but instead a series of dimensions or characteristics that make it easier or harder to work on this product, then the process of product definition needs to happen frequently with a view to the key question: Does this structure improve or reduce the ability of the product teams to deliver value often? Does this make sense from a funding and control perspective? And, is this a collection of competitive capabilities for our business and business strategy?
And the last question is the most important. Many capabilities are being developed and maintained that would make more sense to be outsourced or purchased. By defining the product model, an organization can review those choices. The best and most effective organizations focus on their core while managing context and not trying to do everything themselves!
Politics adds another dimension.
Yes, product models and associated organizational structures are affected by politics. As soon as groups of people are managed and budgets are spent, power, authority, and status become variables. Of course, it is the objective of any agile coach to make those things transparent, allowing the people working on the product model to explicitly decide on them, but the reality is that smart people can hide those needs with very well-defined needs and objectives. And agile coaches themselves are often swayed by strong personalities. To quote my Grandmother, “It is what it is, and that has to be ok, otherwise you will hurt your head pushing against a brick wall”.
The Product Definition Merry-go-around
After talking to hundreds of organizations and consultants about product definition, I sometimes feel that I am in the same position that I was at the start. Yes, products are great for grouping, aligning, and funding your organization's capabilities. They can help set a frame for the whole organization when thinking about “stuff”. But there is no perfect answer to your product definition puzzle. It is all about making some choices and measuring their impact. And then doing it again and again and again. And, yes, I know people hate change, but to be effective, you have to get used to it!