Eugenia Bergman and Hagen Tonnies presented how they shifted from project- to product-thinking after their platform outgrew single-team use at KubeCon & CloudNativeCon Europe. The limitations that they felt with their platform were one-off deliveries, lack of product vision, and weak feedback loops. They have moved toward a self-service, API-driven, multi-tenant infrastructure with clearer ownership and better abstractions.
Bergman mentioned that their platform development cycle was organized around yearly project planning. Work typically started with upfront scoping, budget allocation, and defined delivery milestones. Each initiative was treated as a project with a clear start and end, and success was measured by whether they delivered on scope, time, and milestones:
This worked well when the platform supported a single service to the organisation that delivered the Game Streaming product. Over time, our platform evolved to support multiple internal teams with different needs. That fundamentally changed the nature of the system.
Bergman mentioned several limitations that they felt with their platform:
- Each improvement was treated as a one-off delivery
- This resulted in accumulated capabilities that were competing in priority with the next delivery item
- The platform had no clear product definition
They were continuously delivering, but not always improving the usability or coherence of the platform as a whole, Bergman said. Feedback loops were primarily internal, centered on sprint performance (velocity, completion, quality), with little to no validation from actual platform users. The system optimized for completion rather than for long-term value.
Inspired by a mix of external influence and internal reflection, they shifted from a project to a product approach, Tonnies explained:
We had early peers introducing systems thinking and product thinking—drawing from ecosystems like Prometheus and Grafana—and internally we started engaging with material like Project to Product and The Phoenix Project, where we recognized many of our own pain points.
This led to a small community of practice among architects and senior engineers, where they debated these ideas and explored alternatives to our current model, Tonnies said.
Over time, their developer platform has evolved significantly. It was never a single, unified platform but rather a set of capabilities that grew organically around Kubernetes and GitOps practices, Tonnies explained:
Early on, the platform centered around Helm-based deployments, namespace-scoped resources, and a GitLab-driven workflow, where teams onboarded through an internal IDP model and operated largely within shared clusters. This worked well for standardizing application delivery, but it was primarily optimized for single-service teams and did not fully address broader multi-tenancy or more complex infrastructure needs.
As their ecosystem expanded, especially with the introduction of public cloud services like AWS, they saw a natural shift in expectations, where teams became more accustomed to self-service infrastructure and clearer ownership models. This highlighted opportunities for them to improve the internal platform experience, particularly in abstraction, documentation, and in enabling a stronger separation of concerns between platform and consumer responsibilities, Tonnies explained:
We’ve been evolving toward a more product-oriented platform model, with clearer tenancy boundaries, improved self-service capabilities, and better-defined interfaces for provisioning and managing infrastructure.
Today, they are investing in higher-level abstractions, such as environment and project constructs, and API-driven workflows that align more closely with cloud service provider paradigms. This is an ongoing journey, but the direction is clear: moving toward a more scalable, user-centric, and decoupled platform that empowers teams while maintaining consistency and governance across the organization, Tonnies concluded.
InfoQ interviewed Eugenia Bergman and Hagen Tonnies about changing to a product approach for their platform.
InfoQ: What inspired you to change from a project to a product approach?
Eugenia Bergman: The shift was not driven by a single decision, but by a set of signals we could no longer ignore. We observed that:
- Backlogs kept growing despite continuous delivery
- Teams were working around the platform instead of using it
- We couldn’t clearly answer whether what we built was actually being used
- We couldn’t always answer whether we supported certain capabilities or whether they were even part of our platform offering
At the same time, we realized that we were no longer just delivering infrastructure, but instead we were providing capabilities to internal customers. That required a different approach:
- From delivering features → to solving user problems
- From fixed scope → to hypothesis-driven roadmaps
- From output metrics → to adoption and usability signals
In that sense, the move to a product approach was less a transformation initiative and more a necessary adaptation to scale.
Hagen Tonnies: The shift also came from long-standing skepticism toward Scrum. While I valued its structure, it often failed to capture real outcomes or create the right environment for teams. Product thinking felt like a path toward better alignment between engineering work, user value, and team experience.
InfoQ: How does your developer platform look?
Bergman: At a high level, our developer platform behaves like an internal cloud provider.
It exposes infrastructure capabilities such as Kubernetes clusters, storage, networking, and supporting platform services. These capabilities are made available through self-service interfaces, primarily using Kubernetes-native patterns such as APIs and custom resources.
From a developer’s perspective, the goal is to:
- provision infrastructure as code
- integrate platform capabilities directly into workflows
- and avoid manual coordination or ticket-based processes
Internally, the platform is structured around a separation of concerns between service, control, and management planes, with composable building blocks that abstract underlying infrastructure, and contracts that define stable interfaces between layers.