Cloud bills were climbing, and the numbers lived in one tool, built for one kind of reader. But four kinds of people needed them, the money person, the policy person, the fleet person and the developer, and three of the four never opened that tool. Same data, four different jobs, one door.
One source of numbers, four framings, delivered into the three products where those people already spend their day, each speaking the vocabulary its reader already uses. The same city, drawn as four maps.
You're paying every month for memory nobody uses.
memory requested = 2× memory usedResearch and discovery
Same underlying data, four different jobs:
The trick was to keep the data as one thing and let the experience become four. Finance needs a money framing, admins need a policy framing, developers need an app framing. The same recommendation has to translate cleanly across all of them, without asking anyone to learn another team's vocabulary first.
The people who run the machines and the people who build the apps use different words for the same thing. A recommendation in the wrong dialect is just noise.
Insight from the developer-journey research
That single finding reshaped the entire developer-facing surface. A recommendation phrased in infrastructure language got ignored. Reframed around "your app," the same recommendation got acted on.
Key UX moves
1Three design systems, one capability
The three products each use a different design system, different components, different conventions, different houses with different rules. The capability had to feel genuinely native in each one without losing its underlying shape. Less a translation problem, more a question of keeping one identity across three wardrobes.
2Meeting users where they already work
Rather than ask developers to leave their own tools to go look at cost, we brought the numbers into the portal where they already spend their day. Same recommendation, different doorstep. The integration that shipped in 2025 is the direct result, the recommendations had been available all along, just nowhere a developer would think to look.
3Meaningful graphics as evidence
A common failure mode for cost recommendations is the "do this because we said so" tone. The boxplots, time-series and "why this recommendation" explanations all exist because users simply won't act on a recommendation they can't verify for themselves. Trust comes first, action second.
Challenges
1Three product teams, one capability owner
Coordinating across three product teams meant the capability seemed to have three different owners depending on who you asked. The breakthrough came when we started treating it as one capability with three rendering layers, and naming that out loud in every cross-team conversation.
High fidelity walkthrough
Shipped in Red Hat Developer Hub 1.5. The Resource Optimization integration is named directly in the release notes, which is Red Hat publicly endorsing the cross-product story.
Final takeaways
- Same data, four different jobs. FinOps needs the money framing, platform admins need policy and developers need workload. The capability stayed singular; the experience went plural, and that's why it worked.
- Mental-model gaps don't always look like UX problems. A vocabulary mismatch, infrastructure words shown to an app person, can quietly kill an otherwise good recommendation, no matter how solid the data behind it is.
- Meeting users where they already work beats asking them to come to you. The Developer Hub integration was the move, the recommendations had been technically available all along, just nowhere a developer would think to look.
- What I'd push harder for next time: a shared component contract, not a port of the UI, a contract, across all three surfaces. The cross-portfolio thinking landed cleanly at the data layer; the design system hasn't fully caught up yet.
Public proof and customer evidence
Forrester TEI study findings for the composite organization Forrester modeled:
Read the full Forrester TEI study →
"We can give our engineers a lot of autonomy thanks to the guardrails available in Red Hat OpenShift. We have automated a lot of the human handoffs required between teams which has saved weeks on lead-time delays."
Forrester customer interview
From Red Hat docs: "Efficiency scores put a monetary value on savings and waste. Metrics such as being 66% cost efficient or wasting $20,000 in a cluster are more tangible. These figures make it possible for financial departments to justify reallocating money." (Source)