Build better platform products

In 2018, I came across Evan Bottcher’s article What I Talk About When I Talk About Platform. I was coaching a company’s platform teams, which were looking to apply Agile principles and practices to their work. The business was undertaking an Agile transformation — scaling Agile and rolling out product management — in the same way that it had, years earlier, with the modification of its applications teams.

This seemed to me to be an inadequate tactic for an infrastructure and operations environment. Something was missing, and Bottcher’s article helped fill the gap. He introduced the idea of ‘platform as an internal product’; clarifying what an internal platform is, who it’s meant to enable, and how one might go about building a compelling one. These ideas were worryingly absent in our Agile transformation.

Two years later, I’m not sure the situation has improved much within the technology companies I work with. Platform as product articles and presentations are admittedly scarce. But I’m always surprised by how little platform product leaders know about it.

Why should this matter? It’s simple. How can you lead a team to build a successful platform product if you don’t understand the underlying principles of internal platforms?

So I’m writing this article to introduce platform product leaders to some of the “best of” platform-as-product ideas I’ve collated. I’m hoping it will help build better platform products and get you excited about this emergent practise — because pioneering work on internal platform products is incredibly exciting and rewarding.

Know your true customers

Platform teams can get quite muddled about who customers are. We commonly misperceive the company’s end customer, a key stakeholder or even another platform team as the customer. It’s easy to see why that might be the case:

• Our business wants us to feel empathy for the end customer.
• Key stakeholders apply pressure on us to solve problems.
• Other platform teams consume our products.

They’re often the loudest voices. But they are not the customer and thinking of them as such will hold us back from building a compelling product.

The actual customers of platform products are applications teams.

Few people express this better than Paula Kennedy in her talk Platform as Product: How to Delight Your Developers and Deliver Value to Your Customers. She summarises the problem like this:

• For the customer: “The platform didn’t meet our requirements.”
• For the business: “It takes forever to release new features and respond to market opportunities.”
• For ourselves: “Our customers aren’t adopting our platform.”

We can only solve these problems if we understand that our customers are applications teams.

Reduce your customers’ cognitive load

“Cognitive load” is an important concept. It describes how brains process information and the limited capacity they have to do it. There are three types of load: intrinsic (necessary), extraneous (irrelevant) and germane (relevant). The goal is to manage necessary load, reduce irrelevant load and increase relevant load.

Manuel Pais’s article, Kubernetes is Not Your Platform, It’s Just the Foundation, does a great job of explaining how cognitive load relates to platform product development.

• Intrinsic load is all the skills developers need to do their job.
• Extraneous load is all the things that need to happen to deliver that value.
• Germane load is understanding the business context for the problem they’re trying to solve.

I recently observed a customer-research interview in which a developer repeatedly used the word “exhausting” to describe how hard it was to navigate the steps needed to deploy an application into production. It’s a story we know too well, and my sense is that platform teams instinctively understand the unnecessary cognitive load applications teams shoulder. But what we perhaps don’t articulate so clearly is that our platform products should not only seek to reduce the existing cognitive load of applications teams; we shouldn’t be adding to it either. It should not be hard to use our new platform products — that’s the motivation behind self-service and low-friction solutions.

Eliminate your team’s toil

Many platform teams evolved from operations teams. (Watch Michael Coté’s talk, Platform as Product: Transforming from Service Delivery into Continuous Operations, for a fascinating short history of this evolution.)

When you have to prop up wobbly legacy systems and answer customer requests unceasingly, it’s unimaginably hard to find space to build a new platform. Some platform teams I’ve worked with had less than 20 per cent available time leftover for engineering once operational work was done. That’s why platform product leaders need to take a serious interest in toil.

Familiarise yourself with Google’s SRE definition of toil: “The kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” I’m betting there is a lot of toil hidden in your team’s workload.

The only way to reduce toil is to doggedly find and remove it by taking an analytical approach to where your team’s time is being spent. Review your incidents, customer requests, backlog items, team workflow and delivery metrics etc often. Measure toil, set a target threshold (interestingly, Google SRE’s goal is 50 per cent) and keep below it.

Understand you are not building a platform

Wait. What? Let me explain…

The move from operations team to platform team requires a shift in thinking; from supporting discrete tools (operations) to building interconnected capabilities (platform). But platform teams struggle with this holistic view and it’s commonplace to hear them say they’re creating “a container’s platform”, “a CI/CD platform”, or even “an AWS platform” — thus perpetuating functional silos and friction from the days of yore.

Your platform team is probably not building a platform. You’re more likely to be making a platform capability which, when connected with other capabilities, forms the platform. I love Ryan Murray’s description of “smaller building blocks that play well together” in the Thoughtworks article, Platform Strategy: Building an Engine to Enterprise Evolution. Creating these building blocks requires an overarching vision and strategy from platform leadership and meaningful collaboration among platform teams. This, in my view, is the greatest challenge in building a platform.

Why the struggle? It’s hard to build internal platforms when you haven’t seen one. I advise product leaders to collect examples from other technology companies and share them with their platform teams. My examples include MYOB’s Jupiter, Atlassian’s Micros, Uswitch, and of course, Spotify’s Backstage (open-sourced this year).

The underlying principles

The idea behind platform-as-product is simple: Apply the same product-management approach that product teams are using when they build their customer-facing applications.

But as I alluded to earlier, you are missing a beat if you just reorganise your platform teams to mirror product teams without understanding the underlying principles of internal platforms. So run as a product team but also:

• Understand who your actual customers are.
• Reduce your customers’ cognitive load.
• Eliminate your team’s toil.
• Understand you are not building a platform.

Thanks to Gabor Flamis, Gavin Coughlan and Scott Bell for peer reviewing this article. Thanks also to my editor Tracey Strange.