Product Thinking for Cloud Native & Platform Engineers by Stéphane Di Cesare & Cat Morris

Stéphane Di Cesare and Cat Morris’ talk at KubeCon EU 2025 in London tackles a challenge most platform teams recognise immediately: platform engineering creates enormous value, but it is often difficult to prove that value in a way the business understands. The reason is simple. Much of the work is invisible.

Demonstrating business value as a developer and an operator

Stéphane opens with a story from a previous role at a technology consulting company. During performance reviews, developers could clearly demonstrate impact through new features or new software. 

Operations engineers and platform engineers had a harder message to package: “It works. We have this big environment, and we keep it running.” Predictably, promotions and bonuses leaned towards the work people could see being built, rather than the work that kept everything stable, coordinated, and safe.

That imbalance became part of the motivation for the talk. Stéphane and Cat argue that platform teams need product thinking, not so that they all become product managers, but to deliver the right outcomes for internal users and to make platform value measurable and visible.

The platform trap: building impressive things that do not matter

Stéphane describes a pattern many engineering teams fall into. Engineers enjoy building, and it is easy to chase technically interesting solutions without stepping back to ask whether they solve a meaningful problem. He illustrates this with a memorable example: an Excel spreadsheet built to control a Kubernetes cluster. It is clever, but it also highlights the risk of focusing on what is possible rather than what is valuable.

This is where product thinking becomes useful. It forces teams to ask the questions that prevent wasted effort. Who is this for? What problem does it solve? What value will users experience? How will it be maintained?

What product thinking looks like for platform teams

Stéphane and Cat define product thinking through four practical shifts:

• Focus on user value: Not “what did we build?” but “what did we improve for the people using this platform?”

• Think problems before solutions: Start with what is hurting users today, not with tool migrations or architecture decisions.

• Outcomes over output: Output is tickets closed or pipelines migrated. Outcomes are reduced toil, faster onboarding, fewer incidents, and safer delivery.

• Products over projects: Platforms have a lifecycle. Shipping something and walking away creates technical debt and tribal knowledge.

They also broaden the idea of “users.” Platform engineers often default to developers, but in regulated organisations, users include compliance, finance, and data teams. They also reinforce that platform value is not only speed. A major portion of platform value is risk reduction, which is core to operations work but difficult to celebrate without metrics.

How teams get it wrong: solutions in search of problems

Cat shares a real example from her first platform product owner role. The team focused on an obvious fix: pipelines were old, they were using Jenkins, and the organisation had moved to Azure. So they migrated pipelines to Azure DevOps.

Three months later, the outcome was essentially zero. The team was less efficient because they were not well-versed in Azure DevOps. Maintenance became harder. Users saw little difference because the workflow remained broadly the same.

When they eventually stepped back and explored the problem space, they discovered much bigger issues: onboarding new teams was painfully slow, legacy systems were creating business risk, and peak-time scaling was manual and expensive. The pipeline migration was something they could do, but it was not the highest value thing they should have done.

Spend time in the problem space

Cat introduces the Double Diamond model: product work requires exploration and definition in the problem space before rushing into delivery in the solution space. Most engineering teams excel at building and iterating. The leverage comes from making better decisions earlier.

She highlights three practical techniques for understanding real platform pain:

• User and stakeholder interviews: Asking “what is hurting today?” often uncovers more than teams expect.

• Data and process analysis: Perceived pain does not always align with what happens most frequently.

• Shadowing: Sitting next to users reveals workarounds, unexpected behaviours, and friction users may not even articulate. Stéphane notes he learns something new every time he does it.

If you do not measure value, someone else will

Stéphane warns that platform teams must measure outcomes because if they do not define value, leadership will define it for them, and it may not match reality.

This is why product metrics matter. Not output metrics like tickets closed, but metrics tied to outcomes, satisfaction, and real platform impact. Stéphane points to the DevEx framework as a useful starting point, focusing on:

• Flow state (can developers focus?)

• Cognitive load (do they need to know too much?)

• Feedback loops (can they deploy and learn quickly?)

He also emphasises that perception metrics, such as confidence and satisfaction, are critical even if engineers find them uncomfortable. They reflect the real experience of using the platform and are harder to game than throughput measures.

What platform engineers can do right now

Cat closes with practical actions that engineers can take to see the benefits without having to train to become product managers:

• Shadow your users

• Ask “why” relentlessly

• Read business updates to align with organisational priorities

• Instrument and dashboard platform work so the impact is visible

The overall message is that platform engineering is high-leverage work, but value does not speak for itself. Product thinking connects platform work to outcomes, making that impact legible to the business.

Platform work creates real business value, but only if teams can articulate and measure it.

To dig deeper:

→ Watch the full talk 

→ Read Product thinking for platform engineers

→ Learn how teams can manage platforms as scalable, self-service systems that deliver measurable value