The first part of the transcription of the discussion between Kiran, Co-founder and COO of coMakeIT, Part of Xebia, and Sundar Sarangan, Executive Director, ISG Research, facilitated by Runki Goswami, Chief Marketing Officer, Xebia, talked about what is a platform, what is not, and the platform mindset.
The second part delves deeper into the platform mindset by defining its attributes- the roadmap, the infinite time horizon, and communities. The discussion traverses along the concepts of digital communities and why platform makers should realize the collaborative role of communities in making their innovations and hence their businesses successful. Further, it elaborates the timeless nature of platforms and the need for all the stakeholders to align with a shared vision.
This insightful discussion is a treasure trove of knowledge. Read on to accumulate all its wealth.
While working together we identified some attributes of the platform mindset. And firstly, let us start with the road map.
Products have roadmaps, while projects have plans. How does a roadmap distinguish a platform from a product? Would you please elaborate on this using some client examples?
That’s a good point.
A roadmap defines a product, especially its functions, features, and timeline indicating when it is available for the customer and how it grows. A product company builds a roadmap inside the company. Whereas a platform one should build a roadmap not entirely inside the company but integrate roadmaps of the ecosystem players too. We can call it a federated roadmap. It is not just the platform maker’s thinking that is evolving the platform, but the coexistence and participation of others too on the platform. This is the fundamental difference while defining a roadmap for a platform.
Truly, that really makes a platform stand out.
The other attribute we identified is the time horizon. How is the ‘time horizon’ of platforms different from that of projects and products?
In product development, we talk about ‘sunset’. Whereas in a platform it is a persistent sunrise. A platform constantly evolves, and accumulates new features, products, and partners. It grows on its own, independent of the time horizon. Whereas for products, we need to check if they are relevant to a specific time, and to a technological evolution. So, there’s a specific time horizon for a product, whereas a platform doesn’t have one and evolves. It is continuous, long-term, and always exists. It makes it easy for the customer to retain the knowledge of the platform and not shift from one to another.
So, can we say that when we come up with a platform strategy, we must think of a platform that is going to live forever?
Yes, that should be the idea. However, the form of the platform changes despite the fundamental principles of ecosystem support – allowing other partners to come in and allowing innovation on top of the platform – remaining the same.
So, combining the road map and time horizon attributes we discussed now, can we say that platform companies should take up more of a discovery-oriented approach to requirements? They have to discover from within, and from external influencers and stakeholders too. So, Building the community should be the next phase in the platform development initiative. Whereas a product company is much more specified from the inside out. Is that a fair interpretation of the client examples and our observation of what platform companies do differently?
Yes, the approach is fundamentally different.
While talking about a product roadmap, the first person we think of would be a product manager or an owner. For a platform, that is not the case. The requirements and the road map are determined largely by the players in the ecosystem. Capturing requirements moves from product management to the business model level. While we need to leverage one level of wisdom while building products, for a platform we kind of federate wisdom from all perspectives and brings the requirements to fruition. That is how requirements for platforms are captured differently from that of products.
You’ve also described the differences earlier in a simple sentence – “Products have users, and platforms have communities”.
Another important difference is – A platform company aligns the different moving parts differently from a product company. Product management or mindset is much more aligned around a common vision or a shared vision and less about being specific and being directive to teams. Because you must support greater autonomy in individual stakeholders. The community is not taking orders from you anymore.
The maker’s vision aligns with that of all stakeholders and participants in the community. This shared vision brings together the attributes of the road map, the time horizon, the way requirements are approached, and the focus on the community.
Now, how do you see the role of technology and client leaders changing in a platform world?
We’ve talked about mindset, so next, we need to talk about a mindset shift.
Business leaders should believe that innovation is also possible outside their company. The innovation is distributed. It is triggered by the platform the technology company delivers, but then everyone participating can also contribute.
Hence, firstly for the mindset shift, one should believe that innovation needn’t be confined to the four walls and should exist beyond. Secondly, an architect should evolve, think broadly, and transform themselves into platform architects from product one. They should leverage not just the proprietary components that the company develops but also the open-source components to build a superior product. The thinking should be broader, which means, everything need not be controlled by a single person or a company. All the partners will address a domain where a set of technologies are going to help, and everyone involved will be able to contribute and innovate. I think these are going to be the critical aspects of the mindset shift.
The operating model of a platform business is fundamentally different from that of a project or product-based ones.
This is a clear outcome from our research, how a different mindset translates into a different operating model for a platform business.
So, to understand the importance of the new operating model, let’s discuss a little about the limitations of the other two models, product, and project-centric ones.
Projects are natural, they have a start and an endpoint, and we use them a lot in our day-to-day activities. But they have significant limitations when applied to a technology business. And to address them, product thinking evolved.
What according to you are the limitations of project-centric thinking?
You summarized it quite well.
The natural tendency is to think of a task as a project. There’s nothing right or wrong about it.
But, when you’re building intellectual property and you want your thing to stay in the hands of your customers and in the market for a long time, knowledge is a very critical component. When working on projects, the knowledge of it goes missing once it ends. Everyone who worked on it moves out. So, continuing knowledge and processes will be a challenge. I don’t mean to say that project thinking is a wrong choice, but in the context of product or platform development, thinking in projects is not the wisest thing.
When you have an important critical activity when developing a product, considering it to be a separate project and finishing it is probably the most appropriate way as everyone has a clear goal, deadline, and objective that they can align to. So, are you saying not to use it as a primary mode of building products and platforms?
This probably is the reason why product thinking came up, has evolved over the years, and became an important discipline.
Does product thinking or product mindset address everything? If not, what are the biggest gaps in product thinking that created platform-centric thinking?
While broadening the scope of a product, one always thinks about its functions and features. More functions and features indicate more functional requirements added, and the product gets bigger. However, the product is still only addressing a specific problem of the market, probably a few customers without and a few others with customizations. So, there is a limitation of the product – It exists only within the boundaries of the business and the technology domain. It is a big departure from project thinking where we’re packaging best practices, making a standard product out of it, developing it once and selling it many times, and part of the business is repeatable. All these salient features of the product, however good, also limit it from becoming kind of timeless.
If you want the product to stay relevant for a fairly long period, not sunset but continue to evolve, then it requires a different kind of thinking. And I would call it platform thinking.
- There are several attributes of platform mindset – a roadmap, an infinite time-horizon, and a community strategy.
- Products have users, and platforms have communities
- A platform’s requirements should be gathered from all the products, platforms, and businesses or people participating in the community.
- Platforms should be designed such that they allow other partners to come in and reinforce it with their innovations.
- Platforms trigger innovation and make innovations possible outside the owner’s business or their contributions.
- The strategies of projects and even product thinking are not suitable for platform development. Building evolving platforms need a platform mindset and a different operating model based on it.
The next and final part of this discussion transcript talks more about platform mindset, info mediation, and how platforms can be ideas too. To know more details, please talk to us.