One of my clients had a platform called the “Internet channel” that was intended to increase user conversion and usability. The idea was great – the platform was supposed to make it easier for users to convert and use their products. But there was an unintended side effect: many product groups relied on the platform to do the integration and make their functionality accessible to customers. And just like a busy kitchen, the Internet channel group got many many requests, slowing down the development process. It was like a traffic jam, with too many requests trying to get through at once. And as a result, the Internet channel group became overloaded and caused a bottleneck, making it difficult for product groups to deliver their features to customers in a timely manner.
That’s what happens when there are too many reciprocal dependencies between product groups and a platform group. But don’t worry, there are ways to fix it!
Candy Bars and Commodity Platforms
Imagine a candy bar. What makes it delicious? Is it sugar? Well, yes, but sugar is just a commodity, the same in every candy bar. You wouldn’t advertise your candy bar as having sugar, because every candy bar has sugar. The real value is in the unique ingredients that make your candy bar stand out from the rest.
That’s the same idea behind a Commodity Platform. It doesn’t have any product-specific functionality, just like sugar doesn’t make your candy bar unique. A commodity platform provides a foundation for all product groups to build upon, but it’s not what sets them apart.
By creating a commodity platform, product groups can focus on what makes their products unique and differentiate themselves from the competition. The platform provides the necessary commodity functionality without getting in the way of their creativity. And just like every candy bar needs sugar, every product group needs a reliable self-service commodity platform to build upon.
How to create a Commodity Platform?
The key is t to eliminate reciprocal interdependencies between the platform and product groups. A way to do that is by moving all the product-specific functionality out of the platform and into the product group’s control; The platform becomes a commodity platform that only offers commodity functionality. No longer burdened by the unique needs of each product group, platform developers work mostly decoupled from the product groups. But also, the requested changes from product developers to the platform group will be greatly reduced. As a result, developers can build their applications without being frequently impeded by the dependencies on the platform group.
There are many ways to transfer control to the product groups. These techniques may include changing access policies, isolating and transferring functionality and creating platform self-service capabilities. To achieve optimal results, a combination of these techniques may be necessary.
I understand this is super hard! But hopefully it helps you consider options you haven’t before.
So, what happens once all the product-specific functionality has been transferred from the platform group and it becomes a commodity platform?
Well, product groups still have a dependency upon the platform, but now it’s a more manageable sequential dependency, rather than a messy reciprocal one.
In summary,
At scale, many teams can use the shared platform functionality. When that can be done on a self-service basis, it supports autonomy and improves product delivery flow. But when the platform group holds all the power and the teams need to request the product group to develop product-specific functionality themselves, it can create a bottleneck in the development process.
By eliminating reciprocal interdependencies and creating a commodity platform, product groups can focus on their unique features and the platform can provide the necessary functionality without getting in the way. It’s a win-win situation for everyone involved, and collaboration and smart processes can keep everything running smoothly.