Your Platform Is a Product. Start Managing It Like One.

Why platform engineering needs product management, enterprise governance, and accountability to the teams it serves.

Imagine your company has signed an exclusive contract with a technology vendor.

Every engineering team is required to use its services. There are no alternatives.

Unfortunately, the vendor has some troubling habits.

Its roadmap is disconnected from your business priorities. Simple enhancement requests languish for months. Breaking changes arrive with little warning, forcing your engineers to abandon planned work to maintain compatibility.

Each of the vendor’s products has its own documentation, communication channels, and change management procedures. There’s no centralized place to discover upcoming changes or understand how they might affect your applications.

And when the vendor announces a mandatory migration, your teams are expected to accommodate it on the vendor’s schedule, regardless of their own delivery commitments.

Would you tolerate this relationship?

If you could take your business elsewhere, wouldn’t you?

Yet this is remarkably similar to how some enterprises allow their internal platform and infrastructure teams to operate.

We’ve embraced platform engineering to accelerate software delivery. We’ve centralized common capabilities, standardized infrastructure, and created specialized teams to support the broader engineering organization.

But many organizations have adopted the technical structure of platform engineering without adopting the management disciplines that should accompany it.

A platform is a product. The engineering teams that depend on it are its customers. And we should manage it accordingly.

If Your Platform Is a Product, Where Is Its Product Manager?

The promise of platform engineering is compelling.

Rather than forcing every development team to become an expert in infrastructure, deployment pipelines, identity management, and observability, we provide shared capabilities that reduce complexity and allow stream-aligned teams to focus on delivering business value.

This is central to the Team Topologies model, which describes platform teams as providers of compelling internal products that accelerate delivery by stream-aligned teams.

But building a shared technical capability isn’t the same as managing a successful product.

Product organizations understand their customers. They research their needs, gather feedback, maintain roadmaps, prioritize competing requirements, and measure whether they’re delivering value.

So why do so many internal platforms lack a meaningful product management function?

When an engineering team needs a platform enhancement, whom do they contact? Often, the platform’s engineering manager.

When they want to discuss the roadmap or negotiate priorities? The engineering manager again.

Where is the product manager?

Some platform organizations do have product managers, particularly when their platforms also deliver customer-facing functionality. But those product managers may focus almost exclusively on external customers.

Having product managers doesn’t necessarily mean anyone is managing the platform as an internal product.

The engineers consuming that platform have their own needs: stable interfaces, clear documentation, predictable roadmaps, reliable services, and capabilities that make them more productive.

Who’s gathering those requirements? Who’s researching the developer experience? Who’s deciding which improvements will deliver the greatest value to those internal customers?

Engineering managers play an essential role, but engineering management and product management are different disciplines.

Every significant platform needs an explicit product management capability responsible for its internal customers. That doesn’t necessarily require a dedicated product manager for every infrastructure team, but it does require someone with the mandate, capacity, and authority to manage the platform as a product.

Engineers should still collaborate directly on technical matters. Product management should improve those relationships, not introduce another layer of bureaucracy.

Calling something a product doesn’t make it one. Managing it like a product does.

A Captive Customer Is Not Necessarily a Satisfied Customer

Internal platforms have an unusual advantage: their customers often have no choice but to use them.

Mandatory adoption can be entirely reasonable. Standardization improves security, reduces duplication, and creates economies of scale.

But it also removes an important source of accountability.

An unsatisfactory commercial vendor risks losing customers. An internal platform may continue enjoying universal adoption regardless of how poorly it serves the teams depending on it.

Here’s a question every platform leader should be willing to ask:

If your internal customers were free to choose a competing solution tomorrow, would they still use your platform?

Not because enterprise standards should be optional, but because mandatory adoption tells us nothing about customer satisfaction.

A platform used by every engineering team isn’t necessarily a successful product. It may simply be a compulsory one.

This is why platform teams should measure developer experience, customer satisfaction, and the value delivered to consuming teams — not just adoption rates or infrastructure performance.

More importantly, customer-centricity should influence how platforms are designed.

Good platforms provide well-designed APIs, automation, documentation, and sensible defaults. They establish golden paths that make common engineering tasks easy, predictable, and secure.

But golden paths cannot anticipate every legitimate business requirement.

What happens when a consuming team needs something the platform doesn’t support?

Too often, the answer is to submit a request and wait. Even when the consuming team has capable engineers willing to implement the enhancement themselves, they have no practical way to contribute.

This is where an InnerSource model can be especially valuable.

By applying open-source collaboration practices internally, platform teams can enable consuming engineers to propose enhancements and contribute code, subject to appropriate architectural, security, and quality standards.

The platform team remains accountable for its product. Not every specialized requirement belongs in a shared platform, and some are better handled through supported extension points.

But the platform organization should provide a meaningful path for collaboration, including dedicating capacity to review, mentor, and integrate contributions.

A good platform organization doesn’t have to build every capability its customers need. It should make it possible for those customers to help build the capabilities they need.

The objective is developer autonomy.

A successful platform should eliminate unnecessary dependencies, not institutionalize them.

When Platform Teams Become a Source of Disruption

Imagine a product engineering team midway through an important development cycle.

An internal platform team announces a mandatory change. Consuming applications must be updated within a few days to remain compatible.

This isn’t an emergency security patch. It’s routine maintenance.

Engineers abandon their planned work, modify their application, perform regression testing, and coordinate an unscheduled deployment.

Then another platform team announces a different mandatory change.

Now imagine this happening across dozens of independently managed platform and infrastructure teams.

Each has its own roadmap, priorities, deadlines, and communication practices.

Each assumes its customers will accommodate the work.

Meanwhile, stream-aligned teams must somehow reconcile these unplanned demands with the business commitments they’re accountable for delivering.

The very teams established to accelerate software delivery have become a source of organizational disruption.

Consider a platform migration completed on time.

The platform team’s engineers implemented the change successfully. Their delivery objective was met.

But the migration forced twenty consuming teams to interrupt their commitments. Several applications experienced outages because of compatibility problems.

Was the migration successful?

Of course not.

Yet an organization that measures teams independently might still declare the platform initiative a success.

A platform change isn’t successful simply because the platform team delivered it. Its success must also be judged by what it cost the teams that depend on it.

This is more than a customer service problem. It’s a failure of organizational governance.

Enterprise Governance: The Missing Operating Discipline

Customer-centric product management is necessary, but it isn’t sufficient.

Even a conscientious platform product manager cannot independently coordinate dependencies across an entire enterprise.

Without common operating standards, every platform risks becoming its own little kingdom.

Different roadmaps. Different notification procedures. Different migration policies. Different definitions of adequate notice.

The cumulative burden falls on the consuming teams.

Enterprise governance should establish consistent rules of engagement without creating another bureaucratic approval process.

Platform teams should retain autonomy over their implementations and routine, nonbreaking changes. What must be governed is the impact of their decisions on the rest of the organization.

Three disciplines are essential.

1. Consistent Change Management

Shared platforms need enterprise-wide standards for assessing consumer impact, maintaining backward compatibility, communicating changes, planning migrations, and managing rollback.

Routine internal changes should generally be invisible to consumers.

When breaking changes are unavoidable, platform teams should provide reasonable notice, migration guidance, and transition periods. Versioned APIs, compatibility layers, automated migration tools, and progressive rollouts can reduce the disruption.

Get Carlos Devoto’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Exceptions are sometimes necessary. Critical security vulnerabilities and production incidents may require immediate action.

But routine maintenance isn’t an emergency simply because a platform team’s internal deadline is approaching.

One team’s lack of planning should not become another team’s emergency.

2. Transparent Roadmaps and Coordinated Planning

Every significant platform should have a customer-accessible roadmap.

But individual roadmaps aren’t enough. The enterprise needs a consolidated view of upcoming platform initiatives, breaking changes, deprecations, and mandatory migrations.

Consuming teams shouldn’t have to monitor a dozen communication channels to discover work that may be imposed on them.

Platform roadmaps must also be coordinated with the plans of stream-aligned teams.

A platform organization shouldn’t commit to a migration requiring substantial consumer effort without accounting for that effort in planning.

Likewise, product teams shouldn’t commit to delivering capabilities that depend on unplanned platform enhancements.

Dependencies must be negotiated before commitments are made — not discovered when deadlines are announced.

3. Enterprise-Wide Demand and Capacity Management

Engineering capacity is finite.

When platform teams independently impose mandatory changes, they’re consuming capacity already allocated to delivering business value.

Each change may appear modest. Collectively, they can consume weeks of engineering effort and derail carefully planned initiatives.

Someone must understand and manage that aggregate demand.

Enterprise governance should coordinate consequential platform changes, prevent unnecessary overlapping disruptions, and resolve competing priorities according to business value, risk, and available capacity.

The same discipline protects platform teams from being overwhelmed by requests from consuming organizations and competing executive mandates.

When demand exceeds capacity, leadership must make deliberate tradeoffs about scope, timing, priorities, or staffing.

You cannot create more engineering capacity by declaring more work urgent.

The goal isn’t centralized control over every engineering decision.

It’s predictable coordination of shared dependencies.

Standardize the rules. Coordinate the dependencies. Preserve autonomy over execution.

Stop Optimizing the Platform at the Expense of the Enterprise

Consider a hypothetical platform modernization initiative.

By retiring a legacy interface, the platform team expects to simplify its architecture and reduce maintenance costs.

Sounds reasonable.

But what if thirty consuming teams must modify, test, and redeploy their applications?

If each team spends two engineering days on the migration, that’s sixty engineering days of work imposed on the enterprise.

And that doesn’t include the opportunity cost of delayed business initiatives or the risks introduced by coordinating so many application changes.

The migration might still be worthwhile.

But shouldn’t the business case include those costs?

Otherwise, we may be celebrating an improvement in platform efficiency that actually reduces enterprise-wide productivity.

A platform team’s efficiency is not the same thing as the efficiency of the enterprise it serves.

This is why product management and enterprise governance belong together.

Platform product managers must understand the full impact of their decisions on their customers.

Enterprise governance must ensure those impacts are visible and accounted for when priorities and commitments are established.

The objective isn’t to optimize every team’s performance independently.

It’s to improve the performance of the organization as a whole.

We Need to Measure Platform Success Differently

Traditional engineering metrics matter.

Availability, reliability, security, deployment frequency, recovery time, and infrastructure costs are all important.

But they don’t tell us whether a platform is genuinely helping its customers.

A platform can have excellent uptime and still be a terrible product.

A platform team can deliver every roadmap commitment while making the broader engineering organization less productive.

We need a more complete definition of success.

I would evaluate platform organizations across three dimensions:

Product Value and Customer Experience

Are consuming teams satisfied? Does the platform address their needs? Can developers accomplish routine tasks through self-service? Does the platform reduce friction and cognitive load? Are customer requirements reflected in its roadmap?

Operational Excellence

Is the platform reliable, secure, maintainable, and economically sustainable? Are changes introduced safely? Can failures be detected and reversed quickly?

Consumer Impact

How much unplanned work does the platform impose on consuming teams? How frequently do platform changes cause outages or degradation in dependent applications? Are migration commitments honored? How much delivery time is lost waiting on platform dependencies?

These measures should be considered together, with appropriate attribution for shared failures. Customer satisfaction cannot excuse security or reliability problems, and not every consumer incident is automatically the platform team’s fault.

But consumer impact must be visible.

If a platform team’s metrics say it succeeded while its customers are paying the price, the metrics are wrong.

When success is measured this way, the incentives change.

Backward compatibility, self-service capabilities, proactive communication, InnerSource collaboration, and disciplined migration planning become essential aspects of product delivery — not optional gestures of goodwill.

This Is a Leadership Problem

None of this is an indictment of platform engineers.

Most platform teams are staffed by capable professionals managing critical infrastructure, responding to incidents, addressing security requirements, and supporting numerous consuming teams.

Many operate under severe capacity constraints.

Some engineering managers are effectively expected to serve as product managers without the mandate, resources, or support to do so.

And if leadership measures platform teams primarily through infrastructure reliability, cost reduction, and their own delivery commitments, why should we be surprised when those become their priorities?

Organizations tend to get the behaviors their management systems encourage.

The solution must begin with enterprise technology leadership.

We need platform product management that takes internal customers seriously.

We need governance that coordinates roadmaps, manages shared capacity, and establishes consistent rules for changes affecting consuming teams.

And we need performance measures that hold platform organizations accountable for the value they deliver — not merely the work they complete.

These aren’t separate initiatives.

They’re complementary elements of the same operating model.

Product management creates customer accountability.

Enterprise governance establishes the rules of engagement.

Outcome-based measurement aligns incentives with enterprise-wide success.

Without all three, we risk building highly specialized engineering organizations that optimize their own operations while making everyone else’s work more difficult.

The Real Measure of Platform Success

Let’s return to that hypothetical technology vendor.

Its services are reliable. Its engineers are talented. Its teams consistently deliver against their roadmaps.

But its customers struggle to get requirements prioritized. Breaking changes impose unnecessary work. Communication is unpredictable. Delivery commitments are disrupted by unplanned demands.

Would you renew the contract?

If not, why should we hold our internal platform organizations to a different standard?

The ultimate measure of a platform team’s success isn’t how much work it delivers.

It’s how much more effectively the rest of the organization can deliver because that platform exists.

References and Further Reading

• DORA — Platform Engineering. Product management, developer experience, self-service capabilities, and measuring platform outcomes.
• Team Topologies — Key Concepts. Stream-aligned teams, platform teams, and reducing cognitive load through internal platforms.
• InnerSource Commons — Introduction to InnerSource. Applying open-source collaboration practices within enterprise engineering organizations.
• Google SRE Workbook — Canarying Releases. Reducing the impact of production changes through controlled rollouts and validation.