Shifting Platform Development from Projects to Products

Shifting Platform Development from Projects to Products

The industry loves a good maturation story. Team builds platform. Platform grows. Team realizes their operating model hasn't scaled. Team discovers product thinking. Cue the KubeCon talk. But the presentation from Eugenia Bergman and Hagen Tonnies at KubeCon Europe wasn't just another "we fixed our process" narrative — it was a case study in the fundamental mismatch between how we fund infrastructure and how infrastructure actually creates value.

The Project Trap Is a Funding Trap

Let's be honest about what Bergman described: yearly planning cycles, upfront scoping, budget allocation tied to delivery milestones. This isn't a platform engineering problem. This is a corporate finance problem masquerading as a technical one. When leadership treats platform work as a series of discrete projects — each with a beginning, middle, and end — they're implicitly declaring that infrastructure has a finish line. It doesn't. The platform is the product, and products don't ship version 1.0 and declare victory.

The "Game Streaming" origin story is telling. Single service, single team, clear success criteria. Of course project thinking worked there — the platform was the project. But the moment a second team onboards, the model collapses. You're no longer building for a known consumer with known needs. You're building for a market you don't control, with requirements you didn't anticipate, on a timeline you didn't set.

Optimizing for Completion Is Optimizing for the Wrong Thing

Bergman's line about "continuously delivering, but not always improving the usability or coherence of the platform as a whole" should be framed and hung in every engineering leadership office. Velocity is a trap metric. Sprint completion is a trap metric. They measure throughput, not outcomes. When your feedback loops are internal — velocity, quality gates, milestone adherence — you've built a factory, not a product. Factories optimize for output. Products optimize for adoption.

The absence of user validation is the smoking gun. Platform teams routinely treat developers as captive audiences. "We built it, they'll use it" is the internal-tools equivalent of "if you build it, they will come." Spoiler: they won't. They'll work around you. They'll script their own deployments. They'll complain in Slack. And your velocity metrics will look great while your actual utility trends toward zero.

The Turning Point Was Cultural, Not Technical

What's striking about Tonnies' account is how the shift started: not with a reorg, not with a new tool, but with a reading group. Project to Product. The Phoenix Project. Systems thinking from the Prometheus and Grafana ecosystems. A community of practice among architects and senior engineers debating alternatives. This is how real change happens — slowly, intellectually, bottom-up. The technical changes (self-service, API-driven, multi-tenant) were downstream consequences of a mental model shift.

And notice the lineage they cite. Prometheus and Grafana didn't become industry standards because they hit project milestones. They won because they solved real problems for real operators who had choices. That's the discipline platform teams need: pretend your users can say no. Because effectively, they can.

Organic Growth Is Not a Strategy

The description of their platform evolution — Helm, namespace-scoped resources, GitLab-driven workflows, shared clusters — reads like a history of the last decade of cloud-native adoption. It's also a textbook example of accidental architecture. Each layer solved an immediate problem. Together, they created a system "optimized for single-service teams" that "did not fully address broader multi-tenancy or more complex infrastructure needs."

This is the platform engineering paradox: the very practices that make you successful early (opinionated defaults, shared infrastructure, standardized workflows) become the constraints that limit you later. The move to public cloud (AWS, per the truncated source) didn't just add capacity — it added complexity dimensions that the original model couldn't express. Multi-tenancy isn't a feature you bolt on. It's a property you design for, or you pay for it in technical debt forever.

Product Thinking Means Saying No

Here's what the project-to-product shift actually demands: a product manager who can say no to stakeholders. A roadmap driven by user research, not ticket queues. Metrics that track developer success — time to first deploy, mean time to recovery, self-service adoption rates — not story points delivered. And funding models that treat the platform as a persistent capability with ongoing investment, not a project with a sunset clause.

Bergman and Tonnies' team hasn't finished this journey. No platform team ever does. But they've made the only pivot that matters: from delivering features to owning outcomes. The self-service, API-driven, multi-tenant infrastructure they're building isn't the goal. It's the evidence that they're finally asking the right questions.

The rest of the industry should be taking notes. Not on their tech stack — on their courage to kill the project mindset before it kills their platform.