Why Platform Engineers Need to Think Like Product Managers

Platform engineering as a discipline is maturing. As organisations shift from viewing platforms as just technical enablers to strategic investments, expectations are rising. Teams must now demonstrate measurable business impact, rather than merely building tools or checking boxes.

Despite this shift, many platform teams still operate with a project mindset, measuring success by deployments or ticket velocity. This results in solutions that go unused, investments that underperform, and platforms that fail to evolve.

In 2024, Colin Humphreys (one of the founders of Syntasso and co-creator of Kratix) shared five lessons he learned from a lifetime of Platform-as-a-Product. This article will emphasise two core aspects of Colin's experience:

• Adopting a “product mindset”.

• Finding the right abstractions for your organisation.

This serves as the firm foundation for platform engineers building and maintaining a Platform as a Product. 

Why platform engineering needs a mindset shift

You know the saying, “If we build it, they will come”? Well, it doesn’t hold up when building software today, and it definitely doesn’t work for internal platforms.

You see, internal platforms are products. And like any product, they (should) have users. In this case, your users are your developers. That makes platform engineering a form of consumer software development, even if the consumer is inside your organisation.

For example, a Reddit user shared that they built their platform with just Backstage, but their team refused to use it because it was too complicated. This is the reality of countless teams. It might even be your reality reading this now. 

Platform engineering needs a mindset shift because platforms are not just internal tooling; they’re strategic enablers. Else, why build or improve the platform? 

There is a fine line between what’s technically interesting and what’s valuable, which is why embracing a product mindset is critical.

Before we go into how platform engineers can think like product managers, the first step is to understand how product managers think.

The core principles of product thinking

How do product managers think? In summary:

• They think like their users. 

• They think of their users.

• They think for their users.

Product managers obsess over users. Because the success of a product is not just about its output (cool features) but also about its outcomes, instead of “we shipped a new deployment pipeline,” you’ll say “deployment times dropped by 40%”.

Additionally, as they listen to users, they iterate relentlessly.  It’s essential to remember that listening to users doesn’t mean simply taking orders. It involves digging deeper to identify and understand the root problems affecting the user experience (developer experience), thereby anticipating their needs through the right abstractions. 

With data obtained from obsessing over their users, product managers define a product strategy, prioritise features, evaluate feedback, define releases, create roadmaps and report to relevant stakeholders.

The role of product managers

Practising product thinking as a platform engineering leader

Going from theory, how can you put product thinking into practice as a platform engineering leader?  Below are three core ways you can.

From MVP to TVP: Start small, stay lean

The acronym MVP may have crossed your mind as you read this article. Product management is often synonymous with building an MVP, and this is true, as it is the best way to learn about user preferences.

It is no different for platform engineering. When designing your platform, it’s tempting to go big. However, a Minimum Viable Platform (MVP) approach is more effective. Begin with the minimum set of features your developer needs to start developing and iterate from there. By starting small, you can get fast feedback, improve upon what works, and avoid bloated, unnecessary features.

To do this in practice, you have to suppress the idea of “golden paths” or “paved roads”. Not necessarily avoiding golden paths, but ensuring developers have flexibility. A promised “golden path” without flexibility reduces productivity and creates friction.

To offer flexibility, build your platform around an “X-as-a-service” mentality. Not a cloud service provider “Postgres-as-a-service”, but your unique organisation's institutional knowledge “Postgres-as-a-service”, that’s compliant, secure, and flexible for developers to consume. 

Open-source platform engineering frameworks, such as Kratix, enable multiple stakeholders to contribute to building and configuring a platform's components, giving developers the flexibility to move beyond the predefined “paved paths” when they encounter an edge case or a new use case. 

While an MVP helps avoid early complexity, it is equally essential to avoid platform bloat over time. As your platform grows, it's critical to remove unused features, push towards higher abstractions or remove custom solutions. Thereby creating the TVP (Thinnest Viable Platform). 

MVP and TVP overtime

The diagram above illustrates how an MVP often starts small but tends to expand over time as more features are added.

In contrast, a TVP also begins small but deliberately shrinks some aspects over time, either because they’re no longer essential or because they can be replaced with commodity solutions. This approach keeps the platform lean, even as its overall impact continues to grow. You should read this article by Abby Bangser on Scaling Platform Building: Balancing What is Unique to Your Org and Common Across Teams.

Prioritising work with product tools

With the holistic approach to building and maintaining your platform in mind, how can you prioritise work with product thinking?

Product managers love their frameworks, and now that you are thinking like them, you can too! 

Frameworks such as RICE (Reach, Impact, Confidence, and Effort), the Kano model, the MoSCoW method, Value vs. Effect, Opportunity Scoring, and Cost Delay can be valuable tools when prioritising. 

Let’s look at RICE, for example: 

• Reach: This asks questions like, How many developers use X (a platform feature)?, How often do they use it?

• Impact: This asks questions like, Does this help us meet our business goals faster? How many hours will it save developers? Does it contribute directly to the business bottom line?

• Confidence: How quickly can your platform team execute each feature? You can measure your team’s confidence level in executing ideas using a percentage scale, ranging from high (100%), medium (80%), to low (50%). Or whatever scale you see fit.

• Effort: Aside from the confidence of the platform team, how long will it take to implement a feature?

Answering these questions, backed by data, puts into perspective which feature to build first. You can learn more about these product prioritisation frameworks.

Sell the platform

While writing, I was thinking, should this come first, middle or last? Well, it should be everywhere. 

The platform might be easy to use, compliant, and secure, but you can still have developers doing things their way. It happens. That’s why you have to sell the platform constantly.  You are a platform engineer, but ultimately, you are doing sales. Selling to developers.

There is this saying: WIFFM (“whiff 'em”), meaning “what's in it for me?” Daniel Bryant says it to me regularly. I have started thinking that way. Not “what's in it for you”, but what's in it for the developer when they use the platform. Will it make their lives easier? If yes, how? Show them.

The fastest way to get started selling is to showcase the testimonials of your product (or the platform). 

If Team X has not yet adopted the platform, and Team A has been using it for a quarter with great feedback, demonstrate to Team X how Team A is performing and how they can achieve similar results. 

Now you have a platform. Developers are using it; they seem to love it. How do you measure its success?

Measuring success with product metrics

Measuring platform success is often seen as an opaque task. If we look at it on a spectrum of two sides, if developers are using the platform, it is considered successful; if they are not, it is considered a failure. 

We know there are lots of variables on each side of the spectrum, so it is essential to look at them critically.

There are many ways you can measure platform success:

• Engineering intelligence metrics

• Core 4 framework

• Adoption and onboarding percentages

• Developer productivity and DevEx

A notable highlight from the list above is the newly created Core 4 framework, a unified developer productivity framework developed by the creators of DORA, SPACE, and DevEx. 

The Core 4 framework by Laura Tacho

Core 4 isn’t a pick-one-and-run model. It’s a balanced system. The above four dimensions are meant to hold each other together, because speed means nothing if it tanks developer experience, and shipping more features is worthless if quality collapses.

The point isn’t to chase a single metric. It’s to track a set of signals together that reflect how the platform is performing across delivery, reliability, experience, and impact. Only by looking at the whole picture can platform teams make smart decisions, adjust trade-offs, and stay aligned with what actually matters to developers and the business.

Learn more about the Core 4 framework in this article by Laura Tacho. 

Platform engineering teams should be developer-obsessed

Product thinking isn’t just for product managers; it’s essential for modern platform teams. The most successful platforms are those that prioritise the correct problems, prove their value, and evolve continuously. 

Your platform is only as good as its foundation.

By shifting mindset, your platform engineering team can deliver more meaningful solutions, gain trust across the org, and scale with intention.