Platform Engineering
Platform Teams Ditch Annual Projects for Continuous Product Thinking
Two infrastructure leaders explain how moving from project-based delivery to a product mindset helped their platform scale beyond single-team use.
InfoQ
When a developer platform grows beyond serving a single team, the traditional project-based approach—with upfront planning, fixed budgets, and delivery milestones—begins to break down. Eugenia Bergman and Hagen Tonnies, architects at a major cloud-native organization, recently shared how they shifted their thinking to treat their infrastructure platform as a product at KubeCon & CloudNativeCon Europe, moving away from isolated deliverables toward sustainable, user-focused capabilities.
The Cracks in Project-Driven Infrastructure#
For years, the team organized around annual planning cycles: scope work upfront, allocate budgets, hit delivery milestones, measure success by whether they shipped on time and on budget. That model worked fine while the platform existed to serve one product team. Once multiple internal teams with different needs began relying on it, the problems became obvious.
Bergman outlined the pain points: each feature landed as a one-off delivery, competing priorities buried earlier improvements, and the platform had no coherent vision. Even though the team shipped constantly, the platform itself was growing more fragmented rather than more usable. Worse, feedback came only from internal metrics—sprint velocity and completion rates—with almost no input from the people actually using the system.
Rethinking Infrastructure as a Service#
The turning point came from two sources. Externally, exposure to systems thinking through platforms like Prometheus and Grafana showed what a deliberately designed ecosystem looked like. Internally, books such as Project to Product and The Phoenix Project resonated with their pain points. This sparked a community of practice among senior architects and engineers to debate alternatives.
Tonnies noted skepticism toward Scrum had also built up: while the framework provided structure, it rarely captured real outcomes or fostered the right team environment. Product thinking offered a different path—one that could align engineering work, user value, and actual outcomes.
The Shape of a Product-Oriented Platform#
Today, the platform functions as an internal cloud provider. Teams provision infrastructure through self-service, Kubernetes-native APIs and custom resources rather than raising tickets. The architecture separates concerns into service, control, and management planes, with composable building blocks and stable contracts between layers.

