ºÚÁÏÃÅ

Platforms as products

Delivering value through customer focus

Ìý

As more organizations migrate to the cloud and seize the opportunity to build their own customized platforms on top of cloud infrastructure, different stages of platform performance or fluency are becoming clearer.Ìý

Ìý

As we noted last year, determining what kind of platform is fit for purpose and defining the value you expect it to deliver are critical initial steps. But then comes the drive to get the most out of your investments and maximize the value platforms provide — to do this, understanding the platform as a product is essential.Ìý

Ìý

Many of the disappointments that organizations experience with platforms stem from the failure to treat them as products. For example, many platforms intended for developer infrastructure lack the initial research into user needs and contextual analysis we’ve come to expect in other types of products. This leads to problems with user experience and adoption, and can ultimately even drive developers to take their sought-after skills elsewhere.Ìý

Ìý

The challenge can be addressed by seeing platforms as products that have customers who must be won over, with a value proposition, a clear roadmap and dedicated resources to help those customers create value for the organization. Like any good product, a platform needs ongoing attention, and to evolve and adapt in response to developer feedback and the changing business landscape.

Ìý

Signals include:

Ìý

The rise of Backstage and other platforms emphasizing developer experience, which can play a powerful role in engaging and retaining tech talent.

Ìý

and talking about engineering-focused platforms, which shows the view of developers as platform ‘customers’ is entering the mainstream.

Ìý

There is a move beyond data lakes towards federated data stores and data products, allowing a division of responsibility and smooth flow of value across an organization. The popularity of data mesh demonstrates the value of this approach.

Ìý

, an increasingly popular approach to structuring business and technology teams for peak efficiency, highlighting the need for platform teams to offer platforms as an internal product to enable and accelerate other teams.

Ìý

The opportunities

Empower developers, data scientists and others to deliver exceptional value. Platforms with a product mindset provide fundamental building blocks so that a ‘higher’ level team can spend less time on ‘lower’ level concerns, such as infrastructure, and instead focus on delivering what matters to their customers and the business.

Ìý

The value being delivered may differ depending on the type of platform (see table below for examples). It may be direct or indirect, and the latter may not always be apparent or appreciated by the business — such as a platform replacing an old system that performs the same functions in a more resilient, adaptable way. But even indirect value can ultimately be linked directly to positive business outcomes.Ìý

Ìý

Ìý

Good platforms can also offer value to consumers and , but with problem- or use-case specific acceleration. A bank might create one platform with strong compliance and security characteristics, and another amenable to fast experimentation.Ìý

In a highly competitive market for talent, effective platforms can be a key differentiator and a way to attract and retain skilled technologists. It’s no exaggeration to say that ML experts, in particular, can work just about wherever they like. They will inevitably gravitate towards organizations where they’re not wrestling with infrastructure problems, but using platforms that provide a foundation to apply their skills to meaningful projects.

Trends to watch

Ìý

Adopt

Ìý

Developer experience platforms. In our experience, what developers want —Ìýabove all else —Ìýfrom their employers is the ability, freedom and empowerment to do the best job, in the smoothest and most logical way. And at its heart, that’s what developer experience (DX) is concerned with. DX platforms provide tooling to make it as easy as possible for developers to create, test and deploy software, collaborate with their peers and build upon common services to quickly add value.

Ìý

Analyze

Ìý

Re-decentralization. The adoption of public cloud services such as Amazon Web Services, Google Cloud and Microsoft Azure represent a move to centralized systems. While they appear to be decentralized — disparate teams and organizations use and control their own portions of the cloud — the underlying infrastructure is often shared. As a response, companies are considering strategies that spread risk across multiple providers, availability zones or regions.

Anticipate

Ìý

Ubiquitous connectivity. Edge and on-device computing will bring experiences even closer to the end user, while 5G and satellite internet bring data to more places across the planet. This opens up opportunities to process massive quantities of data cheaply, improve privacy, reduce cloud costs and shorten response times to create unique experiences for customers.

Advice for adoptersÌý

Treat platforms as products and staff your teams with the right skill sets. Product management is a skill that is a culmination of experience and education, not something that anyone can just pick up. Do not expect this to come for free just because you have skilled infrastructure specialists.

Ìý

Be clear about the ‘core mission’ of people building platforms, and of their users. Platform builders should focus on making it faster for consumers of the platform to create business value. Ensure that business platform teams themselves are also using underlying cloud capabilities to create platforms quickly where possible.

Ìý

Invest in internal marketing of platforms and APIs. At one of our large energy clients, teams doggedly did 14 months of promotion on what they had built with little apparent traction, then suddenly found they had 25 teams building on their API. Those teams saved upwards of US$5 million by not building APIs from scratch.

Ìý

Embrace having multiple platforms. Especially given computing trends, this is to be expected, because each platform will have different characteristics and cater to different sets of customers. As long as it remains under control, a certain amount of duplication may be desirable as it can foster competition and force platform teams to be more attuned to their customers. Platforms should be a ‘paved road’ rather than mandatory. Make it so teams want to use a platform, not that they have to.

Ìý

Ensure platform product owners can articulate the value in terms of business outcomes. Platforms are not short-term cost savers, but they are accelerators; this means they need to provide demonstrable long-term ROI.

Ìý

Measure platform success. You can’t manage what you can’t measure, and measurement is the only real way to confirm value is being created and delivered. Success metrics will differ depending on the platform goal but are likely to include:Ìý

• adoption (number of customers, consumption by customer, consumption by product)

• service (issues raised, time to close issues)

• customer satisfaction (NPS, customer feedback)Ìý

• performance (uptime, throughput, response time)Ìý

• delivery efficiency (velocity, cycle time, roadmap delivery)

Ìý

Adopt . Associate cloud costs with the products and teams generating customer value, rather than burying them inside a platform or infrastructure organization. Focus on unit economics so that you can optimize your spend for impact.

Budget to run it, not just build it. For a successful platform, the first release is the first draft. You should anticipate needing new features, for instance, as adoption increases or as cloud platforms release new services. Increasing scale will demand feats of engineering that the platform’s users will never notice (hopefully). Active and thoughtful maintenance will be required to keep your platform functioning as a value multiplier.