Internal Platforms — Are They Products?

So … I had a bit of an identity shift in the middle of 2022.
After being an engineer for more than half my life, I decided to put on a different hat. I am still serving the same industry, but as a product manager. And one for internal platforms.

I am the first PM for this organization, and one of my main goals for 2023 is convincing both my engineers and my customers that we are building products!

That’s right. I am a product manager for a “thing” that already exists, and is actively in use but no one believes is a product. YET.

What IS platform engineering? And how is it different from building customer facing SaaS platforms?

Platform engineering is a relatively new stream, that became a necessity with the rise of cloud transformation. Moving from expensive and oversized bare-metal data centers to pay-as-you-go public cloud providers is definitely trending.

In the old world, application developers did not need to worry about where their applications were deployed, how the underlying hardware was provisioned, how the networking was configured, what security measures they needed to take, how all the traffic to their applications was managed. This was all taken care of by the teams that maintained the data center. The application developers only needed to focus on their own features and products.

In the new world, infrastructure is just another software service. Developers can make API calls to stand up a brand new server, configure it per their needs and deploy their apps. Sounds lovely, right? We save time by not waiting on tickets to be fulfilled, we save money by running only as much infra as needed and we are all oh so modern now.

But in reality, this is like moving to a whole other planet.

Working in the public cloud comes with its own set of challenges — all of which are new to our poor application developer.

They need to learn not just the cloud tech needed for their own work, but also need to start thinking about underlying non-functional requirements.

This is where platform engineering steps in.

Platform teams build tools that take care of standing up the necessary infrastructure — which is the servers that applications will be deployed on, the ci/cd pipelines that will deploy the applications, the security and networking needs, and a whole lot of other things. They standardize patterns across the company, add in goodness like logging and monitoring, cost optimization and what have you.

All good, right? Wrong! These tools are very hard to use if they are built with the urgent, and sometimes the only goal of moving into the cloud fast, and standardizing these operational needs!

The “user experience” typically goes like this — a developer needs to stand something up in the cloud, they ask for support and are told

• The infrastructure is all code now, you can just create a pull request in our repository to do what you need. Here are the instructions.

They read the instructions and do their best. But their attempt is fraught with mistakes, because infrastructure is NOT their domain. They put in their code for reviews and then starts the back and forth between the two sides.

This can be formidable for even a highly experienced application developer who has never peeked into the world of infrastructure. On the other hand, it is frustrating for the platform engineer who expects the developer to be able to read documentation and complete the task. They are engineers after all, right?

And thus we enter the ticket system black hole where the customer becomes a burden instead of the main focus.

I was recently at the lunch table with some engineering managers. They knew me, the person, but did not know what my role was. They knew the people in my org, but they did not know which team they belonged to. They regularly put in requests to engineers on my team, but they did not know what we actually did!! It felt like the people in this high performing org were the brand and not the product! You may think, well, good for the people, they are building their brand. That’s not true. These star performers are burning out, the products are not getting the right visibility and adoption! And the customer is mostly running around in circles trying to get their work done.

This is where my goal for 2023 comes in. There are teams building something valuable, and there are teams using it.

But none of them think of it with a product mindset!

The question now is — what do internal platforms look like as a product?

What do we mean by “product mindset”?

We start by defining the mission and vision of the product.

What are we “selling” and why are we selling it — what problem does our product solve — not for the company, but for our customers?

The mission for my platform org is — Enable developers to deliver value to customers “securely, reliably in a cheaper, faster and much easier way.

The application developers are central to this mission statement! We are moving focus away from finding the best technical solutions to solving our customers’ biggest pain points in the best possible way.

The vision, the experience of the developers once the right products have been built is — that most platform capabilities be available in a self-service, push of a button manner.

This sounds like a tall ask, and it is! But it is not impossible.

The core principles of customer empathy, customer delight, product discovery, iteration apply here as well.

We need to take advantage of the fact that our customers are right there, probably sitting on the desk right next to us. We are in a much better position of getting insights from them. Sit in on their own roadmapping sessions, train them to think about infrastructure constraints while designing their features.

We need to take advantage of the fact that we are privy to almost all the individual teams that generate revenue for the company, we can find common patterns and build products and features that will benefit the entire company’s bottomline.

We need to present our capabilities in the form of a product catalog.

We need to build a strong brand — such that if any developer needs a basic building block, they first search through the platform product catalog instead of googling for a solution!

I can talk about this until the cows come home, but I will leave you now with this — What do you think about internal platforms? Are they products?