A good example of a platform is Amazon Web Services (AWS) which offers cloud-based services on which other products can be built, such as, Netflix.

For any platform to be successful and be adopted within an organisation, it will have to be defined in the business what it’s purpose is and how it can improve upon what the organisation currently has. One or the reasons usually given is that as it’s a shared service between products, the costs will be spread within the organisation, and thus reduce costs. However, this shouldn’t be the biggest reason for building the platform, because platform build and maintenance costs are usually high. Rather the best reason to sign off on a platform business case is the increase in quality of underlying infrastructure, in terms of cutting edge technology, features and security a dedicated team can provide.

Consider the Benefits and Drawbacks of the Technology Platform Within the Business Case

Platforms offer several benefits other than reduced costs, in fact, many platforms add to the IT budget, not lessen it, because of the human resources and expertise required for the value add needed to make the platform a competitive business advantage.

Take a portfolio like Microsoft Office online – Office 365, for example. If the teams developing the different apps all created their own backend layers for saving, storing, retrieving and searching for files, there would be considerable code duplication, added development costs, and increased development time.

However, the products within Office 365 is built on a shared platform that standardises and offers shared services, such as document storage and retrieval, and so avoids these issues, allowing 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, like Amazon did with AWS, can create a new revenue source and help diversify the business. In Amazon’s case, the platform enables third parties to use Amazon server, storage and networks infrastructure for which Amazon charges a fee.

Platforms come with potential drawbacks, the calling out of which in the business case are crucial for managing expectations about the platform and setting it up for success. Platforms can grow very big and complicated over time, as their use within an organisation and by customers starts to add many features and requirements to it.  This starts making upgrades to the platform take longer and longer and the platform becomes a bottleneck, slowing down the rate at which the end-user facing products can offer new and enhanced features. I have also seen a brand-new platform being retired, as it was overly complicated to use and did not meet the needs of the development teams that should have used it.

It is critical to consider if a platform can benefit the business, not solely IT, and then to thoughtfully design the service around the new value it adds to the products already being offered, iteratively build it, and carefully manage it.

Treat the Platform as a Product

The platform should be treated as a product in its own right, albeit a very technical one – it’s end users/customers are usually developers (technical users in their own right).

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 increasing revenue.

Consequently, a platform must have its own product strategy and roadmap, KPIs, product backlog, and well-designed software architecture that leverages the right technologies.

The platform strategy and roadmap of the platform should be derived from the strategies and roadmaps of the products that are built on it. Its architecture should be designed to make it as easy as possible to use its services. This means that the platform decisions should be guided by the needs of the products it serves. Because a platform exists to help teams build better product, faster and cheaper.

The platform, therefore, is more than just a set of APIs, it’s an entire ecosystem and will include documentation on how the it can used and if needed, bespoke tools to allow teams to code against the platform APIs.

For example, AWS comes with a cloud development kit that supports .NET and Java, integrates with different IDEs, and hence supports developers to develop AWS-based applications.

Assign a Platform Owner

Every product needs to have a vision, and as we consider the platform to be a core product that enables our other core products, our platform must have an owner who is responsible for engaging with the users, consumers and other product owners to design that vision – an individual who manages the platform and ensures that it creates the desired value.

Depending on the nature of the platform, it might be best to someone with a technical background (a senior developer or software architect perhaps) who is able to talk to the members of the product development teams and understand their needs as well as empathise with the end users. In my experience, this is particularly true for platforms that offer end-user facing services.

At the same time, that person should have the necessary product management skills to 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.

Last but not least, a platform owner also has to work with the individuals who manage the products built on top of the platform — product owner 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 and Iterate

Creating a platform is a new product development 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.

Based on current best practices of Scaled Agile, a Minimum Viable Platform, ideally for a small number of products should be released first, from which lessons should be learned, and subsequent, improved iterations with further features be released to a growing wider audience. This will allow you to get a first version out comparatively quickly and adapt it to the feedback of the users — the product development teams.

Like other development 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 use the platform.

Once you have shown that the platform does a great job for a small number of products, you can start expanding its services and serve additional products. This avoids one of the potentials drawbacks mentioned earlier: launching an ambitious software platform that is too difficult to use.

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

Technical products, like a software platform, have a difficult complexity to manage: As they are developed by highly technical 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 your own product against it is painful and the overall performance of the product and platform thus suffers.

There are three approaches that can mitigate this risk:

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
3. Provide early (beta) releases of new or enhanced platform services which the dev team members test and provide feedback on.

I have successfully used these approaches to develop a new retail platform, where we assembled the initial platform development team from the various group product development teams that were going to use the platform. This ensured that the platform did a great job for the products it served, there were synergies between the platform and product development teams and a high platform acceptance.

Avoid the Platform Becoming 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 as the platform started to slow down the rate at which the revenue-generating products could release new and enhanced features, because an increasing number of products were competing for the platform resources.

The platform had become a bottleneck. The growth of the platform has to be carefully managed. In some cases, it might even be better to accept some code or feature duplication if this helps a product development team get a new feature out faster and create the desired value for the users and business – that feature can always be added to the platform at a later date.

Alternatively, another way to better manage platform growth can be 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, regular reviews of the performance of the platform and making necessary adjustments to its strategy and roadmap is always required, too.