Cost management lived only in the Hybrid Cloud Console, built around sysadmins. Cloud costs were rising, and developers, FinOps and platform admins all needed the same data — just not in the place where they actually worked. Same data, four different jobs.
One capability, shipped into three Red Hat products with four audience framings. Cost Management in Hybrid Cloud Console for FinOps, Resource Optimization in ACM for platform admins and engineers, and both surfaced inside Developer Hub for developers — each in the vocabulary they already use.
Research and discovery
Same underlying data, four different jobs:
The trick was to keep the data layer as one thing and let the experience become four. FinOps needs a money framing, platform admins need a policy framing, developers need a workload framing. The same recommendation has to translate cleanly across all of them, without asking anyone to pick up another team's vocabulary first.
Sysadmins think in clusters and namespaces. Developers think in services. Same word, different mental model.
Insight from the developer-journey research
That single finding — which came out of the developer-journey research — ended up reshaping the entire Developer Hub surface. A recommendation phrased in cluster-admin language just landed as noise. Reframed in service-and-workload language, the same recommendation got acted on.
Key UX moves
1Three design systems, one capability
The three surfaces — Insights for RHEL on the Hybrid Cloud Console, OpenShift on-prem and Developer Hub — each use a different pattern library and design system. The capability needed to feel genuinely native in each product without losing its underlying shape. Less a translation problem and more a question of system coherence.
2Meeting users where they already work
Rather than ask developers to leave their tooling to go look at cost, we surfaced the capability inside Developer Hub, where they already lived. Same recommendation, different surface, different defaults. The integration that shipped in Developer Hub 1.5 is the direct result.
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 on the surface. "Namespace" versus "service" is a vocabulary mismatch that can quietly nuke 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:
- $4.08M net present value
- 150% improved operational efficiency
- 20% recouped developer time
- 70% shortened development cycle
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)