Leveraging Software Platforms

Software platforms can be powerful tools to grow a product portfolio and create new revenue streams. But successfully using them can be tricky. This article shares my tips to help you take advantage of your platform.

Listen to this article:

Be Clear on What a Software Platform Is

In the picture above, product A, B, and C are built on the platform and use its assets. To put it differently, the platform serves three different products.

Let’s look at two examples of successful software platforms, syngo and Amazon Web Services (AWS). The former is a platform that standardises how medical images are read, stored, and shared across MRI and CT scanners and other Siemens Healthcare products; the latter offers cloud-based services on which other products can be built, for instance, Netflix’s video streaming. In both cases, a range of products take advantage of the services the platform offers.

Understand the Benefits and Drawbacks of a Software Platform

Platforms offer several benefits: They can help grow a product portfolio faster and cheaper and they can help increase revenue. Take a portfolio like Microsoft Office, for example. If the teams developing the different apps all created their own user-interface layers, there would be considerable code duplication, added development costs, and increased development time.

A software platform that standardises the user interaction and offers additional shared services, like saving and opening files, avoids these issues and allows the app development teams to focus on creating the app-specific functionality, rather than having to develop infrastructure code.

What’s more, opening up a platform to other companies, as, for instance, Amazon did with Amazon Marketplace, can create a new revenue source and help diversify the business. In Amazon’s case, the platform enables other vendors to sell products alongside Amazon’s offerings and Amazon collects a fee for each third-party sale.

But platforms also have potential drawbacks. I have seen software platforms grow so big over time that they became bottlenecks and slowed down the rate at which the end-user-facing products could offer new and enhanced features. I have also witnessed a brand-new platform being retired, as it did not meet the needs of the users—the development teams who should have used it to build their products.

As these examples show, it is worthwhile to carefully consider if a platform can benefit your business and to choose the right approach to build and manage it and to choose the right approach in order to build and manage it.

Treat the Platform as a Product

While a software platform is a piece of technology, it creates value for the product development teams by making it easier and faster to build their products and it generates value for the business by reducing cost, accelerating development, and possibly increasing revenue. Consequently, a platform should be managed as a While a software platform is a piece of technology, it is still beneficial in my experience to treat it as a product. Consequently, a platform should have its own product strategy and roadmap, KPIs, product backlog, and well-designed software architecture that leverages the right technologies.

Make sure, though, that the platform decisions are guided by the needs of the products it serves. After all, a platform exists to help teams build better products faster and cheaper. In other words, the platform strategy and roadmap should be derived from the strategies and roadmaps of the products that are built on it, and its architecture should be designed to make it as easy as possible to use its services.

A software platform, therefore, is more than a set of APIs. It typically requires documentation that shows how the platform assets can be used. It may also require tools that allow teams to code against its APIs. AWS, for instance, comes with a cloud development kit that supports .NET and Java, integrates with different IDEs, and hence supports developers to develop AWS-based applications at the time of writing.

Assign a Platform Owner

If we regard the platform as a product in its own right, then there should be clear ownership and an individual who manages the platform and ensures that it creates the desired value, as the following picture illustrates.

As a software platform is a technical, supporting product, I recommend looking for a senior developer or software architect with a strong technical background who can talk to the members of the product development teams and understand their needs as well as empathise with the end users, depending on the nature of the software platform. (This is certainly true for platforms that offer end-user-facing services.)

At the same time, the person should have the necessary product management skills to professionally manage the platform and ensure that it does a great job for the users—the product development teams who use its APIs—and the business. One of my clients, a games development company, successfully applied this approach to manage one of its key platform products.

Last but not least, a platform owner also has to work with the individuals who manage the products built on top of the platform—the person in charge of products A, B, and C in the picture above—to understand their strategies and roadmaps and discuss whose needs take priority in case of conflict.

Start Small

Creating a software platform is a new product development (NPD) effort and should be managed accordingly. This is also true if you take existing code and encapsulate it in the platform, as this typically requires changing or rewriting the software and finding an effective platform architecture.

I therefore recommend building a Minimum Viable Platform, ideally for a small number of products. This allows you to get a first version out comparatively quickly and adapt it to the feedback of the users—the product development teams. Like other NPD initiatives, you should, of course, validate the platform as you develop it, for example, by exposing early versions of new or changed APIs to the product development teams and asking them to code against them. But like other new products, you’re likely to find out how well the platform works only once it is being used in earnest and the products have started to employ its assets.

Once you have shown that the platform does a great job for a small number of products, you can expand its services and serve additional products. This avoids one of the potential drawbacks mentioned earlier: launching an ambitious software platform that is too difficult to use, something I have sadly seen happening more than once.

Ensure that the Platform is User-Led, Not Technology-Driven

Technical products, like software platforms, have a dark side: As they are developed by specialised teams, they can end up being over-engineered and over-complicated. In the worst case, a platform works beautifully on its own, but coding against it is painful and the overall performance of the product and platform is poor.

There are two techniques that can help you mitigate these risks:

1. Start developing a new platform by staffing the platform development team with members from the product development teams.
2. Use the solution validation techniques you would employ for an end-user-facing product, for example, sprint review meetings in which members of the product development teams participate and early releases of new or enhanced platform services which the dev team members test.

I have successfully employed the two techniques to develop a new telco software platform, where we assembled the initial platform development team from the various product dev teams who were destined to use the platform. This ensured that the platform did a great job for the products it served, and it increased its acceptance amongst the product dev teams.

Don’t Let the Platform Become a Bottleneck

I once worked with an organisation that employed a software platform that became so successful that it grew bigger and bigger: It served more and more products over time and it offered more and more services. What initially looked like an amazing success story, developed into a difficult experience: The platform started to slow down the rate at which the revenue-generating products could release new and enhanced features, as an increasing number of products were competing for the platform resources. The platform had become a bottleneck.

I hence recommend that you carefully manage the growth of your platform. In some cases, it might be better to accept some code duplication if this helps a product development team get a new feature out faster and create the desired value for the users and business. Alternatively, consider breaking up the software platform and offering platform variants that each serve a set of clients, for example, a storage platform and a media services platform.

Like with other products, regularly review the performance of the platform and make the necessary changes to its strategy and roadmap.