Scaling Peaks
Published in

Scaling Peaks

How to Build a Platform

In the technology business, there is always a lot of talk about “platforms”. And for good reason. Platforms can bring companies leverage, whether as a platform builder who can leverage the combined capabilities of an ecosystem to drive more innovation and more value than they can on their own, or as a platform user who can leverage the services and distribution capabilities of an existing platform to short-cut a lot of work and time to get their offering to market faster, less expensively, more broadly and perhaps also to leverage synergies with other ecosystem members of that platform. Today, we see new variants of the platform theme emerging, such as PaaS, Platform-As-A-Service (frankly everything in today’s world is becoming “-As-A-Service”) and “Bring Your Own Platform”.

If you’re a platform builder, what are key things to keep in mind? Let’s first start with a broad definition of what a platform does: a platform allows third parties (ecosystem members / platform users) to build functionality (such as ‘apps’) and businesses on top of that platform by leveraging valuable services from the platform but without requiring the platform itself to change to support that particular functionality / business. Those platform users can be groups within your company or organization, if the platform is an internal one, or can be separate companies or organizations, if your platform is an external one. Having a well-defined abstraction layer between the platform and the stuff that is built on top of the platform is key to the platform’s leverage, to being able to supply a set of standards and services that can be used by many third parties over and over again to accomplish different end goals.

A platform, in the sense that we are discussing here, should have both technology and business dimensions to it, meaning that a technology platform should have an accompanying business platform that facilitates those third party platform users in building their own businesses on the platform, just as the technology platform allows them to build their functionality on the platform. In both cases, a platform should be designed to enable innovation on the part of platform users. Technically a platform should supply a well-defined set of standards that lay out how the platform is to be used, a rich (and growing) set of services that those users can leverage to build their own functionality, ideally an SDK (Software Developers Kit) to leverage services or possibly to create new ones on their own, and possibly a shared infrastructure (likely in the cloud, today), depending on the nature of the platform. These services should be general purpose so that different platform users can do different things with them.

I think that the test of whether you have created a true platform is if you see platform users building things on your platform that you couldn’t even imagine as you set out to build the platform. As innovative as Apple is (everyone’s favorite platform company example), no doubt they could never imagine the full range of apps that are now available on the iPhone. That is leveraging the collective innovation of your ecosystem. Likewise your platform business model should be ‘general purpose’ enough to support innovative businesses — you don’t want to put yourself in a corner where you have to stop platform users from pursuing what seem like good and innovative ideas just because your commercial model can’t account for that business. Apple itself struggled with in-app purchases early, for example.

One of the most important things to consider when building a platform is how you structure your organization. My own experience has taught me to believe in Conway’s Law, the idea that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” In order to get that abstraction layer right, between the platform and the stuff that gets built on the platform, your organization needs to mirror that, especially if you have folks in your org who will be implementing stuff, or helping customers implement stuff, on the platform. The platform team and the implementation team need to be separate and the implementation team has to use only the standards, services, and SDK that are available to outside clients. They have to request platform enhancements formally of the platform team, exactly as if they were outside clients. If they have access to any kind of backdoor into the platform code itself, inevitably they will be tempted to just add a little something to the platform to help them with a specific client implementation. That’s how dangerous roots from the ‘apps’ on the platform start to grow into the platform itself and they can be exceedingly hard to get rid of later on. Better to be disciplined right from the start.

Platforms are a powerful concept and there are many good reasons to build platforms. Just make sure you are clear, up-front, about whether you are better off as a platform user or a platform builder. When you are out for leverage, it is sometimes not entirely obvious which way round makes most sense. If you do build a platform, make sure your technical design, your business design, and your organizational design are all set up to make it a success.

Originally published at https://www.linkedin.com.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Philip Brittan

Philip Brittan

Philip is an entrepreneur, technologist, business leader, writer, and innovator. https://www.linkedin.com/in/pbrittan/ Blog: https://medium.com/scaling-peaks