Pete Hodgson

Software Delivery Consultant

Your Platform is a Product

January 28, 2021

I once knew a team who built a beautiful platform that almost no-one used. In fact, the only real consumers of this elegant system were the platform engineers themselves.

This was partly intentional. The platform team considered themselves guinea pigs - they would be the first consumers of the platform, making sure that it was fit for purpose by eating their own dog food1. Sadly, while they succeeded in being the first consumers, they also ended up being pretty much the only consumers.

The platform team had crafted a set of elegant calligraphy brushes, but the other engineers in the org just wanted a box of reliable ball-point pens.

What caused this unfortunate outcome? The fundamental problem was that the platform they were building was only fit for their purposes. They crafted a set of elegant calligraphy brushes - because that was what they wanted to use - but the other engineers in the org just wanted a box of reliable ball-point pens. To put things in more concrete terms, the platform team built a collection of very well-designed pure functional Scala libraries, when everyone else really just wanted a less terrible way to build and operate their node.js apps.

I’ve seen this phenomenon a lot - platform teams frustrated by spotty adoption from the broader engineering org of the frameworks and services the platform team are creating. Usually, this is due to the platform team failing to accept one key fact: their platform is a product. Let’s explore what that means, and how product thinking can make your platform successful.

Hey! Your Platform is a Product!

Your platform is, in fact, an internal product. It has customers (the engineers in your organization)2, it exists in a marketplace, and that marketplace includes competition. Platform teams often miss that last part. It turns out that you generally can’t make other engineers use your platform if they don’t want to. They will find a way to continue using whatever existing solution they already have - or even build their own competing solution! Or they might decide to use an open-source tool. Or buy a third-party solution from a vendor. You might think that you can just tell other teams to not do those things, but trust me, unless your product is a compelling alternative to the competition they’ll find a way to go around it.

Products require product management

How does a platform team beat out the competition in the market? By building a compelling product. How do you build a compelling product? By employing product management practices.

As engineers, we tend to fall into the trap of assuming that the stuff we’re good at - designing and implementing elegant technical solutions - is the only stuff that’s important. That’s not true when it comes to platforms - product management and marketing are just as important if you want your platform to be successful - where success means delivering a lot of value to other engineering teams (your customers, remember).

To be successful, a platform team needs leaders who spend a fair amount of their time doing product management and marketing (and probably some program management as well). The best platform teams I’ve seen are led either by a very technical product manager or by a tech lead with a natural inclination towards product management. The platform teams which I’ve seen fail are invariably lacking in product management capabilities. They have fantastic, highly capable tech leads who just will not or cannot do the product management work their platform needs.

Platforms that provide value see adoption

Good products deliver value for their users by solving specific problems those users have. Good platform teams do the same thing. They identify particular pains that their customers (other engineering teams) are having and then build platform capabilities that address those pains.

A platform team should have a clear definition of what success for their platform looks like. If that definition isn’t centered around delivering value for engineering teams, or the broader business, there’s something wrong.

Things like OKRs and KPIs can make those success criteria more unambiguous. An objective goal - reduce average deploy time across the org by 10%, reduce code duplication by 5%, totally remove such-and-such legacy system - helps a team keep their attention fixed on delivering something valuable to their customers.

Harvest ideas from your customers

There’s a simple way to figure out what value your platform could provide to your users - go and talk to them. In product management this is often called customer development, and the good news is that internal products make for straight-forward customer development. You know who your customers are, and they’re very likely to happily talk with you about their wants and desires.

Even better, when your customers are engineers they’re often going to have already built some sort of solution themselves! 3 This means that part of a platform team’s work is to forage around the engineering org, looking for existing work from other teams that you can brush off, polish up, and turn into a shared capability that’s available for every engineer in the org.

Product thinking is your platform superpower

An internal platform’s success is derived from the total value that it provides to engineering teams. A successful platform must solve real problems, and must gain broad adoption. Taking on a product management mindset is the best way for a platform team to meet both those criteria.

  1. While I generally agree with the concept of “dogfooding” - using your own product in order to understand your customer’s experience - I’m not a fan of the phrase. I’d much prefer to drink my own champagne or eat my own icecream, personally. [return]
  2. I believe that this is a good working definition of a “platform”: an internal product whose customers are other engineering teams. [return]
  3. Product people tend to get quite excited when they find a customer who’s built their own solution - it validates both that there’s a real problem to be solved and that some sort of solution is feasible. [return]