Platform Engineering Is Product Management for Infrastructure

The views expressed here are my own and do not represent those of any current or former employer.

I’ve watched this play out at every company I’ve worked at.

An infrastructure team builds something powerful. Really powerful. The architecture is clean, the code is solid, the documentation exists (sometimes). They ship it, announce it in Slack, maybe do a lunch-and-learn. And then… crickets. Developers find workarounds. They roll their own solutions. They keep doing things the old way.

Six months later, the infra team is frustrated. “We built them a great tool and nobody uses it.” They blame engineering culture. They blame documentation. They schedule mandatory migration deadlines.

Sound familiar? Because the problem isn’t the developers. It’s that we built the wrong thing, or built the right thing the wrong way, because we were thinking like an infrastructure team instead of thinking like a product team.

Your Developers Are Your Customers

This isn’t a metaphor. It’s an operating model.

A product team would never ship a feature without talking to their users first. They wouldn’t build something and then measure success by whether it exists. They wouldn’t ignore feedback loops. They wouldn’t blame their customers for not adopting.

But infrastructure teams do this all the time. I’ve done it. I built an internal tool once that I was genuinely proud of. Clean API, great performance, thorough documentation. Nobody used it. I was annoyed for about two days before I realized: I’d built what I thought was correct instead of what teams actually needed. I’d solved my problem, not theirs.

That failure changed how I think about platform work. Now, every platform capability starts with a question: what problem does this solve for the developer? Not for the infrastructure team. For the developer.

Then: what’s the cost of not using it? If there’s no real cost to ignoring the platform, adoption will be optional, and optional tools lose to inertia every time.

And finally: how do we measure whether it’s working? Not whether it’s deployed. Whether it’s working. Lead time, onboarding friction, infrastructure costs. Those are the metrics that tell you if your platform is actually making developers more productive. Uptime and latency matter, but they don’t answer the product question.

Golden Paths, Not Golden Cages

The concept of golden-path solutions has shaped a lot of how I think about platform engineering. The idea is simple: provide a well-lit, well-paved path that handles the common cases, while leaving room for teams to step off the path when they have genuinely unique requirements.

A golden path for deploying a new service might include a pre-configured CI/CD pipeline, a Terraform module that provisions the right infrastructure, monitoring dashboards wired up out of the box, and cost visibility from day one. A developer who just wants to ship a service shouldn’t need to understand VPC peering or transit gateway routing. But the senior engineer who needs custom networking? They should still be able to get under the hood.

This is harder than it sounds. The temptation is to pick one extreme: give everyone maximum flexibility (nobody gets a fast path, everyone reinvents the wheel) or lock everything down (the platform becomes a bottleneck, tickets pile up, teams route around you).

The art is finding the right layer of abstraction. I haven’t always gotten it right. One version of a deployment platform I built gave teams so much flexibility that nobody used the same patterns twice — the platform was technically optional and it showed. Another time, I locked things down so tightly that developers started writing their own Terraform outside the system just to move faster. Both mistakes looked like success at first: the first had high adoption numbers, the second had high consistency numbers. Neither was actually working. The times I’ve gotten it wrong usually involved optimizing for the metric I could measure instead of the outcome I actually wanted.

Self-Service Changes the Game

The goal of self-service infrastructure isn’t eliminating the platform team. It’s freeing up the platform team’s time for the work that actually requires their expertise.

When an engineer can provision a new environment, set up monitoring, and deploy to production without filing a ticket, the platform team stops being a bottleneck and starts being a force multiplier. Instead of processing requests, you’re building the next generation of capabilities.

In practice, this means building Terraform CI/CD pipelines that give teams guardrails (operational safety, consistency, fewer deployment failures) without requiring them to become Terraform experts. The pipeline enforces the standards. The developer just pushes code. Everyone’s happy.

This connects directly to FinOps, and it’s one of my favorite examples of platform thinking. When cost visibility is baked into the platform, teams make better decisions automatically. They can see the impact of their infrastructure choices in near-real-time. That feedback loop is vastly more effective than quarterly cost reports that arrive six weeks after the spending decisions were made.

Scaling Through Platforms, Not Through Heroics

The platform-as-product mindset becomes critical at the senior IC level because of a simple math problem: you can’t scale yourself by writing more code. At the principal or staff level, your impact is measured by organizational outcomes. You scale by building systems and platforms that make hundreds of other engineers more effective.

This is where the player-coach approach intersects with platform thinking. Staying hands-on keeps your understanding of developer pain points current. Roadmap decisions, standards, cross-team alignment: all of that strategic work is better when it’s informed by firsthand experience with the tools.

Infrastructure decisions also don’t happen in a vacuum. A networking change affects product timelines. A cost optimization initiative hits data engineering budgets. A reliability improvement changes how SRE allocates on-call. Translating infrastructure strategy into language that product, security, and data teams can act on? That’s half the job. And you can’t translate something you don’t deeply understand.

The Metrics That Actually Matter

Most infrastructure teams measure the wrong things. Here’s what I track instead:

Lead time. How long from “I need a new service” to “it’s running in production”? If the answer involves multiple tickets, manual approvals, and a two-week wait, your platform isn’t working. It’s just a slower version of the problem it was supposed to solve.

Onboarding friction. How quickly can a new engineer start shipping? If they spend their first two weeks fighting their development environment, that’s a platform problem wearing an onboarding costume.

Infrastructure costs per unit of value. Not just the total bill. Are teams making cost-aware decisions? Can they see the impact of their choices? Are you spending more to do the same thing you did last quarter?

Adoption rate. This is the big one. Are teams actually using your golden paths? If not, why not? Low adoption means you have either a usability problem or a trust problem. Both are fixable, but you have to correctly diagnose which one you’re dealing with. Guessing wrong means building more features that nobody asked for.

What I’ve Learned

Platform engineering isn’t a rebrand of DevOps. It’s a fundamentally different way of thinking about infrastructure work. When you treat your platform like a product, you ask different questions, measure different things, and build solutions that developers actually want to use.

The teams I’ve seen succeed with this approach share a few traits: they listen to their users, they ship incrementally, they measure adoption relentlessly, and they’re willing to kill features that aren’t working. That sounds exactly like product management.

The best platform teams aren’t the ones with the most impressive internal tooling. They’re the ones whose developers forget the platform exists — because it just works.