Seeing the system dynamic: narrow vs. broad product definition - part 1
What is the product? This is a critical question in organization design. You define the product narrowly or broadly, and the scope of the product is a continuum. We are going to see the factors and dynamics behind different choices in two parts. In part 1, we shall look at the case of platform as product; while in part 2, we shall look at the case of product area as product.
Platform is a popular concept in many product organization. It is often defined as product associated with organization - product backlog and teams. In most cases those are essentially components, as they are not facing external customers. They form one product together with the application. This is illustrated by the left part in the above picture. In some cases those are indeed products, as they have separate external customers than the application. There are two products with different customers. This is illustrated by the right part in the above picture. Let's look at them separately.
Platform is a component
Why does organization want to define platform as product, even though it is essentially a component? For reuse - multiple applications would reuse the same platform, so as to save the development cost. This is illustrated by balancing loop B1. The goal is the cost budget. The action is to create narrow product (i.e. platform) to promote the reuse. The rationale is that platform increases the extent of reuse, thus development cost is reduced, then cost pressure is relieved.
Why does organization NOT want to define platform as product? There is another balancing loop B2 involved. As smaller platforms are defined, more platforms are involved in delivering value to customer. The extent of synchronization gets lower, thus, cycle time gets longer. This creates time pressure, which drives against defining more platforms as products. It is a matter of which balancing loop dominates at certain period.
What's more interesting is that the asynchrony causes the waste of waiting, thus, increases the development cost. That forms a reinforcing loop R1. B1-loop and R1-loop together create "fixes that backfire". While B1 dominates, R1 is in vicious cycle, thus harms the goal of meeting cost budget. While B2 dominates, R1 is in virtuous cycle in helping meet the cost budget too. This dynamic is shown in the below diagram.
Back to reuse, what are alternatives that could still increase the extent of reuse while not defining platform as product? Internal open source is one alternative approach. The most challenge in adopting this approach is its organic nature, which can not be controlled but only be nurtured.
Platform is a product
There is a different tradeoff involved when the platform is indeed a product, facing external customers, besides internal applications.
In this case, the main drive is not the development cost, but the focus and support necessary to bring a product into the market. B3-loop illustrates this. The support on productization includes marketing, sales, budget, etc. Once there is gap, we define platform as separate product than the application product. This increases the product orientation, leading to better support on productization, thus closing the gap.
Meanwhile, this has an impact on application product. As platform goes on its own, the request from application may not be done in synchronous manner. Thus, the cycle time gets longer, which increases time pressure. This is the previous B2-loop, which creates a balancing force against defining more platforms as products.
In reality, platform product emerges much more than being correctly predefined. I have seen that many platforms never became real product. Those that did become real product were seldom predefined. Same as reuse, the platform product is better nurtured than controlled. When done prematurely, it sacrifices the application product, meanwhile does not gain in making successful platform product either.
In part 2, we shall look at the choice of defining as a narrow product vs. as a product area in the broader product.
