Having a platform is not enough; the real challenge is ensuring that it is understandable, usable, and actually adopted by its users. Eugenia Bergman and Hagen Tonnies presented how they shifted from project- to product-thinking for their platform at KubeCon & CloudNativeCon Europe.
Bergman mentioned that they introduced a producer–consumer model to simplify how teams reason about interactions. In this model, a team that provides a capability is a producer, and a team that uses that capability is a consumer.
This helped make dependencies explicit:
- Producers define clear interfaces and expectations
- Consumers interact through those interfaces rather than through ad-hoc coordination
One of the key shifts was moving from coordination through meetings and intermediaries to coordination through interfaces and contracts, Bergman said. A practical heuristic they found useful is:
If two teams require a recurring meeting to coordinate their work, the interface between them is likely not well defined.
By treating team interactions more like APIs, with clear boundaries and expectations, they reduced coordination overhead and enabled more localized decision-making.
Originally, "done" for us meant that a project or feature was delivered according to scope and timeline, Bergman mentioned. Once they realized that this definition was insufficient for a platform, they shifted toward a more product-oriented definition: a capability is done when it can be reliably used by others:
A capability is done when it’s integrated into the platform ecosystem, documented and understandable, supported and operable, and actually used by its intended consumers.
To evaluate progress, they ask themselves "Is this being used?" and "Does it reduce friction for users?" This helped align development work with actual user value rather than delivery, Bergman said.
Leadership support was critical, not as a top-down mandate, but as an enabling force that created alignment, trust, and space to evolve, Tonnies said. What mattered most was the willingness to support experimentation, accept iteration, and recognize that moving from projects to products fundamentally changes how teams plan, prioritize, and measure success.
From an architectural perspective, this also meant having an "organizational error budget"—the ability to explore new approaches, learn from missteps, and refine direction without immediate pressure to meet rigid expectations, Tonnies explained:
That safety allowed us to treat the transformation as a learning system, where progress comes from understanding the gap between expectation and outcome and continuously improving based on that signal.
The shift from project to product was not purely driven from the top; it emerged from real friction observed by teams and users, with leadership enabling us to act on those signals. Having trust and protected space to experiment made it possible to engage meaningfully with senior stakeholders, balance innovation with responsibility, and gradually build a more product-oriented platform model, Tonnies concluded.
InfoQ interviewed Eugenia Bergman and Hagen Tonnies after their talk.
InfoQ: How do teams collaborate as producers and consumers of the platform?
Hagen Tonnies: Our collaboration model between teams as producers and consumers is still evolving, but it is increasingly structured around clear ownership and intentional interaction points. We took inspiration from Team Topologies to learn about these concepts when we formed new collaboration efforts. Typically, each product area is represented by a product owner and a lead engineer, who work together to engage with their counterparts in other teams and align on shared capabilities. These interactions happen through regular check-ins, often within sprint cadences, where teams discuss and refine the contracts between what is being provided and what is expected in return. A key focus is making these relationships explicit—understanding the promises a producing API or capability makes, as well as the obligations on the consuming side, and ensuring both are grounded in real use cases.One of the main challenges has been building a shared mindset around these producer–consumer dynamics, especially in moving from implicit coordination to explicit, contract-driven collaboration. We emphasize focusing on common use cases—the "80% path"—to ensure we deliver consistent value without over-engineering for edge scenarios. To support this, we’ve introduced roles like Scrum masters and product operating managers to help facilitate these conversations and improve alignment across teams. At the same time, we are investing in coaching and enablement, helping product owners and engineers develop the skills needed to operate effectively in a product-oriented, API-driven ecosystem.
InfoQ: How do you track that your platform is actually being used?
Eugenia Bergman: Usage is something we deliberately measure rather than assume. We track adoption through a combination of operational and product-oriented signals, including API request volume, active consumers, provisioning activity, and the usage of specific capabilities over time.The timeframe varies depending on the capability. Some services, such as storage provisioning or quota management, generate adoption signals almost immediately after release. Others, such as networking or infrastructure topology capabilities, are naturally used less frequently and may take several weeks or planning cycles before teams integrate them into their workflows.
What matters most is that we can observe whether a capability is being used and creating value. One of the key lessons from our journey was that delivering a feature is not the same as delivering value. A capability is only truly "done" once it is adopted and relied upon by its intended users.
Tonnies: Done requires active enablement—clear storytelling, education, and even internal evangelism—so teams know when and why to use it.