Why platform engineering fails to scale: Product and adoption design in practice

Platform engineering can improve developer experience, provide reusable platform services across an organization, and help teams deliver software more quickly without compromising trust and security. In practice, however, many platform teams struggle to achieve the level of adoption they expect. Some teams find themselves pulled into project-specific support work. Others build tools and standards that are technically sound, but rarely used, and as a result, the platform does not deliver the reusability or scale it was intended to provide.

As a Red Hat consultant, I have worked on platform engineering initiatives directly and have also engaged with customer platform teams while working on modernization projects. Across these engagements, I have noticed recurring differences between platform teams that scale and those that remain stuck. These differences are not simply about technical maturity—they’re not only about whether the infrastructure is modern, or which internal developer portal (IDP) technology the team uses. What I’ve seen is that organizations that successfully scale platform engineering intentionally design the platform as a product: defining what value it provides, who it serves, how it is adopted, and where the platform team’s responsibility begins and ends.

What happens when platform engineering does not scale

What does it mean for platform engineering to scale?

A commonly referenced platform engineering maturity model from the Cloud Native Computing Foundation (CNCF) captures this well. It defines several areas of maturity and describes the progression from early, provisional practices toward more scalable and optimizing operating models.

The platform teams I see struggling most often are unable to move beyond the first level of maturity. They are pulled in many directions by users and stakeholders. Some spend much of their time building one-off tools or providing project-specific support. Others push standards too aggressively and are eventually ignored.

Why does this happen?

One reason is that platform engineering does not always have clear boundaries with adjacent practices such as DevOps or site reliability engineering (SRE). Because those boundaries are poorly defined, stream-aligned team members do not always find it obvious which of those teams to ask for what.

The same ambiguity also attracts a wide range of business expectations. Over time, every problem can start to flow toward the platform team, which becomes what I call a “bucket for every problem.” The team must spend its own cognitive capacity deciding how to respond to all these requests, which reduces the capacity available for designing, building, and operating reusable platform services.

To avoid this, platform teams need to move away from handling expectations one by one. They need to clearly define what value they provide, how far their responsibilities extend, and how that definition will be accepted across the organization. Expectations management is a crucial part of platform strategy.

Product strategy: Platform as a product

A common approach to this challenge is to treat the platform as a product. That’s the right attitude in theory, but it is often easier to say than to execute.

A practical product strategy for platform engineering needs to answer several specific questions:

• What problem is this platform initiative trying to solve?
• Who is the platform user?
• What journey is that user on, and what problem do they face in that journey?
• Where are the boundaries of the platform team’s responsibility?
• How will the platform be discovered by potential users, evaluated, and adopted?
• How will customer (developer) satisfaction be measured and taken into account in future product iterations?

Let’s take a closer look at the steps needed to ensure success as you turn your platform into a product.

Start with the problem statement

Product strategy always starts with a clear definition of the problem. Platform engineering is often pitched as a way to reduce cognitive load, but cognitive load by itself is not the primary problem an organization needs to address—it's usually a cause or symptom. The real question is: What business or organizational problem is important enough to justify investment?

Different problem statements lead to different platform services. For example, consider 3 organizations:

• One organization’s top priority is reducing developer turnover.
• Another wants to reduce cost through more effective use of modern platforms.
• A third wants to reduce security and compliance variation across application teams and better safeguard the software supply chain.

All 3 might say they are doing platform engineering. But the platform services they should design to meet their goals will be different.

In the first case, the platform may need to focus on developer experience, onboarding, and reducing friction. For the second organization, standardization, reusable migration patterns, and operational efficiency may matter more. And the third organization’s platform may need to provide secure-by-default delivery paths, trusted templates, approved base images, automated checks, and policy-driven deployment workflows. Accurately defining the problem statement early in the process is paramount for successful implementation.

Identify the real platform user

The next question is: Who actually chooses the platform?

In some organizations, developers research and select the platform directly. In others, the developer is not the primary decision maker.

In one organization I observed, most software development was outsourced to external development partners. The platform team improved the developer experience of its platform services, but adoption still did not increase.

When Red Hat Consulting investigated the situation, we found that internal teams were primarily organized around project managers. The external development partner often recommended which platform would be appropriate for a given project. However, the project manager was responsible for communicating internal constraints, rules, and standards to the partner.

The problem was that project managers were not providing information about the organization’s development platform. In many cases, they did not even realize that they were expected to do so, or that the relevant resources existed. In that context, developers were not the only platform users. The platform service needed to be designed taking into consideration the project manager as a key persona, because the project manager controlled the information flow that enabled adoption.

In another organization, the need was a platform service for citizen developers—that is, developers within the organization who work in departments outside of IT, like sales or finance—using an AI development environment. In that case, the users were citizen developers, but the organization’s AI Center of Excellence also needed to be considered as a user group because it was responsible for enabling AI adoption across the organization.

The point is simple: the platform may provide development tools, but the platform user is not always the person writing code.

Understand the journey and the problem

Once the user is clear, the next question is: What journey is that user on?

Figure 1. Journey pattern analysis

A platform team can classify user journeys and assess where platform services are likely to create value, as illustrated in Figure 1. For example, a journey to migrate existing systems from an on-premise environment to the cloud is very different from a journey to build a new system. The steps, risks, decision points, and problems are different.

The platform team then needs to estimate where it can contribute most effectively. A simple way to start is to look at 2 inputs:

• The expected number of projects in that journey
• The effect of common support or services the platform team can provide

By combining these 2 factors, the platform team can decide which journey deserves priority investment.

For example, a bug-fix journey for existing systems may occur frequently, but the platform team may have limited ability to improve it directly. On the other hand, if an on-premise platform is scheduled for retirement, cloud migration journeys may have both a large number of target systems and a high potential for platform support.

This analysis makes it easier to define:

• Whose journey the platform supports
• Which problem in that journey the platform is solving
• What support is needed
• Where the platform team should start

This may strike you as an excessive amount of analysis. But the platform service you provide will change depending on the answers to these questions: who is struggling, what journey they’re on, and what problem they’re facing.

In some scenarios, the right answer may be advanced automation or an integrated developer experience. In others, a concise 5-minute document or a downloadable, self-contained information package may be far more effective.

The important question is not which support is more sophisticated. Rather, it’s whether that support is actually usable on the user journey, and whether it contributes to platform adoption.

Define responsibility boundaries

Platform teams have limited capacity. They cannot accept every request and solve every problem. That means they need to define what is out of scope.

I think of this as designing a firewall of responsibility. It clarifies what the platform team owns, what it does not own, and how users should proceed when their needs fall outside the platform team’s responsibility.

This definition should come from the original problem statement. What activities must be deprioritized because they do not contribute directly to the problem the platform initiative is solving? What activities are better handled by another specialized team?

It takes discipline to say no. But platform engineers should not need to spend excessive time explaining, negotiating, or redirecting each request every time they do say no. The team should decide in advance how out-of-scope requests are handled and who owns the next step.

At the same time, simply saying “This is out of scope, so the stream-aligned team must solve it” does not help adoption. The goal is to help users find a path to self-resolution, even when the platform team is not the team doing the work.

For example, the platform team can collaborate with adjacent teams and create a navigation experience in an IDP like Red Hat Developer Hub. Along the developer journey, users can see which teams they should contact in different situations, which documents they should read, and which services are available.

In this way, the IDP is not just a front door to the platform team. It becomes a one-stop hub for the information and services developers need, while also protecting the platform team from becoming the default owner of every problem.

Design strategic marketing and enablement

The value of a platform does not depend only on the value of each individual service. It also depends on how many times that service is adopted and reused.

It is a mistake to assume that people will use a platform service simply because it is good. Target users need to know that the service exists. They need to understand whether it applies to their situation. They need to evaluate it, try it and eventually adopt it.

This requires marketing and enablement. But that does not mean doing every possible promotional activity. Adoption does not happen after a single announcement or training session. It progresses through stages: awareness, interest, trial, and application. Platform teams need to design those stages intentionally.

Where are the target users today? Are they aware of the platform? Do they understand how it applies to their journey? Are they able to evaluate whether they should use it? What needs to happen to move them to the next stage? How can they and adjacent teams influence adoption?

In one large platform team I observed, roughly one-third of the team’s capacity was dedicated to marketing and enablement activities. That may sound high, but it reflects an important reality: platform adoption is not automatic. It happens by design. This organization saw widespread adoption of the platform.

Conclusion

Platform as a product is not a radically new idea—much of it comes from basic product design practices. But in practice, applying those basics to platform engineering is not easy.

For many platform teams, designing services from the perspective of users and journeys is not yet a natural habit. At the same time, people who are familiar with agile or product design practices may struggle to apply those practices when the conversation shifts into infrastructure, IDPs, and platform technology. Application teams may also find it difficult to understand what platform engineering is supposed to change when the discussion is framed primarily in infrastructure terms.

That is where platform engineering becomes difficult. To scale platform engineering, organizations need a team that can connect infrastructure technology, application development, product design, and enablement. Platform as a product becomes practical only when the team can discuss the problem statement, users, journeys, responsibility boundaries, and adoption steps in the same context.

Platform engineering does not scale automatically. Its success depends not on technology alone, but also on whether the organization can build a team capable of designing the first step toward adoption.

If your organization is struggling to turn platform engineering into a scalable practice, the first step is often to clarify the problem statement, the user journeys, and the adoption path. Red Hat Consulting has helped organizations work through these questions in real-world modernization and platform engineering initiatives. Reach out to learn how we can help your team move forward.