Flexera already had a way to catch cloud cost spikes. Almost nobody used it
Flexera's cloud cost optimization platform helps enterprises manage spend across AWS, Azure and GCP. I led discovery, research synthesis and design for a rebuilt AI-based anomaly detection experience, working across Product, Engineering and the Data Science team over a single quarter, from usage data to a shipped MVP.
“In plain terms: an anomaly is just a point where a number breaks its usual pattern, like a spike in a graph. Here, the number is cloud spend, and each spike is money someone didn't expect to pay. Catching it fast is the difference between a quick fix and a budget surprise a month later.”
FinOps practitioners, engineering leads and finance stakeholders needed a reliable way to detect, understand and act on unexpected cloud cost spikes before they compounded into budget overruns.
The existing experience required users to manually define dimensions and filters just to surface anomalies in the first place, and once something did get flagged, it came with no explanation, no way to filter further, and a disconnected workflow that redirected users away from their cost view. Customers didn't lack demand for anomaly detection. They lacked a trustworthy, explainable way to act on it.
“It'll flag a spike, but it won't tell me why. Was it a pricing change, a new workload, someone forgetting to tear down an environment? I still have to go dig for that myself.”
“Before I forward an anomaly to an engineering owner, I need to be able to explain why it fired. If I can't, they'll just close it out as noise and I've burned my credibility.”
— Head of FinOps, Flexera enterprise customer
Led with research over assumptions: audited usage data, interviewed FinOps practitioners on how they actually chase cost spikes, and aligned Product, Engineering and Data Science on a shared anomaly lifecycle before any design work began.
Shipped automatic AI-based anomaly detection with root cause analysis, giving practitioners a trustworthy “what changed and why” with no manual configuration.
One quarter: discovery to ship
Usage data review, stakeholder & FinOps interviews, current-state gap analysis, cross-functional lifecycle framework.
Data model definition, user journey mapping, wireframing, iteration with algorithm and engineering teams on what's feasible for MVP.
Shipped system-generated anomalies experience: navigation destination, filterable/groupable table, detail slide-out with root cause analysis concept.
What discovery and design needed to accomplish
Before any design work began, we set clear objectives for what research needed to answer.
Key design & research objectives
Understand why the existing Cost Anomalies feature had ~8% follow-through and near-zero adoption.
Learn how different FinOps personas, and different customer organizations, actually use cost and anomaly data day to day.
Define an anomaly data model and lifecycle that design, product, and the algorithm team could all build against.
Decide, with evidence rather than opinion, what belonged in the Weeks 9–12 MVP versus a later iteration.
The evidence base the MVP was built on
Before talking to a single user, usage data already made the case that something structural was broken, not just a rough edge. That reframed the research question from “how do we improve anomaly detection” to “why are practitioners choosing not to use it, and what would make them trust it.”
1. What the usage data already told us
37 of 5,155 eligible
12 of 355 accounts
Down 36.3%
Down 40.4%
19 of those 37 arrived from the tabular view, the intended path
18 arrived from the incidents page instead
Most of the 235 people who opened the tabular cost view never continued into the anomalies view. Of the 37 who did, only 19 came through that intended path; the rest arrived from the incidents page instead.
2. Auditing the current experience
A current-state gap analysis of the existing Cost Anomalies tool surfaced concrete, fixable reasons for the drop-off.
Minimal detection logic: anomalies were flagged using basic Bollinger Bands, with no explanation of why a point fell outside the band.
No root cause analysis: nothing surfaced likely factors like resource utilization, pricing changes or billing errors.
No deep filtering, suppression or annotation: no way to filter by resource type, cost impact or time period, mute recurring noise, or leave context for a teammate.
Disconnected workflow: users were redirected out of their tabular cost view into a separate page just to see anomalies.
The tool detected anomalies fine. It never explained them, filtered them, or kept users in their existing workflow, which is where the drop-off came from.
3. What FinOps practitioners told us
Stakeholder interviews kept circling back to the same moment: right after an anomaly fires, when someone has to figure out what actually happened. Practitioners weren't short on alerts. They were short on a trustworthy explanation and a next step they could hand off with confidence.
“It'll flag a spike, but it won't tell me why. Was it a pricing change, a new workload, someone forgetting to tear down an environment? I still have to go dig for that myself.”
— Head of FinOps, Flexera enterprise customer
“Before I forward an anomaly to an engineering owner, I need to be able to explain why it fired. If I can't, they'll just close it out as noise and I've burned my credibility.”
— Head of FinOps, Flexera enterprise customer
“When something gets flagged, I want to know how confident the system is and what's driving that, not just an arrow pointing up with no context behind it.”
— VP of Enterprise Architecture, Flexera enterprise customer
“Once we confirm what caused an anomaly, that should route straight to whoever owns the resource, with the fix attached, not sit in a list for me to chase down manually.”
— FinOps Analyst, Flexera enterprise customer
When the team scored friction points against UX impact and speed to fix, the absence of any root cause explanation ranked as the top priority. Practitioners could tolerate a noisy alert if they could explain it, but not an unexplained one. Missing alerting came next, with thin recommendations a step behind. Overwhelming graphs and broken in-page search moved to the backlog as lower-impact.
4. How usage actually varies by customer
Follow-up conversations with the product and research team surfaced behavioral nuance that a single FinOps persona glosses over.
Different customers, different jobs: one customer tracked cost-of-goods-sold per client, filtering by customer then grouping by service and region; another used the platform purely for internal infrastructure. No single default view could serve both without flexible grouping and filtering.
The tabular view as a pre-screening tool: some users check the percent-change table before ever setting up an alert, formalizing one only after spotting something concerning by eye.
Tables over graphs: once an anomaly is found, people need to drill into the resource level to investigate, and several sessions surfaced a clear preference for tables over charts for that.
Friction with scale: too many dimensions generated too many charts, burying real anomalies, and lazy-loaded content broke in-page search on large datasets.
Users brought the context themselves: scan the percent-change table to guess which dimension moved, then manually set up that exact combination of filters just to confirm it. The system never looked for the anomaly on its own.
5. Aligning Product, Engineering and Data Science on a shared lifecycle
We mapped the full lifecycle of a cloud cost anomaly, assigned a RACI owner to every step, and used a crawl/walk/run maturity model to set a shared target instead of five different mental models of “done.”
Detection: record created. Analysis: find the why / identify the root cause.
Notification: stakeholders alerted. Email and in-app alerts are not implemented; instead, important alerts surface within the anomaly record itself.
What FinOps advisors were actually hiring the anomalies page to do
FinOps practitioners are simply the people at a company whose job is watching the cloud bill, they're who gets asked “why did our AWS spend jump” and has to have an answer. The research surfaced a pile of pain points, but pain points alone don't tell you what to build. Jobs to be Done reframes the question: instead of “what's broken,” it asks “what is this person actually trying to accomplish when they open this page, and what would let them consider it done.” That framing mattered here because the old tool wasn't failing at one task, it was failing to support the underlying reasons people came to it in the first place.
We didn't run a separate JTBD study. We derived the jobs from our existing research, combining behavioral and analytical data. We grouped repeated needs into jobs, then validated them against the highest-impact friction points.
The three jobs map onto the three moments anyone dealing with an unexpected cost spike goes through: catching it early (detect that something's off), judging it in context (investigate whether it's a real problem), and explaining it confidently (decide what to do next and hand it off). Working sessions with internal FinOps advisors and engineering surfaced these jobs directly, captured on the research board below.
How each job traces back to research
Each job carries its own chain: a research finding exposed a pain point, the pain point implied a human need, and that need was restated as a job the MVP had to serve.
When cloud spend moves across dozens of services and accounts, advisors wanted to know what's unusual without combing through raw cost dashboards, so they could catch a problem while it's still small, not find it in a monthly review after the money is gone.
Evidence: “We don't need what we have right now. Without doing anything our users want to know what is unusual.” — internal Flexera FinOps advisor.
When an anomaly surfaces, advisors wanted to see it against the specific dimensions their team actually watches, service, region, usage type, billing center, so they could decide in seconds whether it's worth acting on instead of digging for context first.
Evidence: advisors converged on the same baseline dimensions repeatedly, and were explicit that one threshold can't fit a $50/month billing center and a $500,000/month one. “It would be great if the table had the feasibility to choose the dimensions.” — internal Flexera FinOps advisor.
When an anomaly needs to go to someone outside FinOps to get fixed, advisors wanted to explain why it fired before forwarding it, so it gets resolved instead of dismissed as noise, and their credibility with the receiving team stays intact.
Evidence: when friction points were scored against UX impact and speed to fix, the absence of any root cause explanation ranked as the top priority, ahead of missing alerts and thin recommendations.
Lined up together, the three jobs are really one experience in three steps: detect that a cost anomaly happened, investigate whether it's a real problem worth acting on, and decide what to do next, with enough of an explanation to hand it off. That's the shape the MVP took: a table to detect and investigate, a detail view to explain.
From jobs to a tested user journey
What we learned: three jobs kept surfacing in every working session, catch it early, judge it in context, explain it confidently, and each traced back to a specific finding in the research.
How we tested it: we walked each job back through the same internal FinOps advisors and engineering, and checked it against the friction-prioritization scoring, to make sure the proposed journey actually matched how they work, not just what they'd said in passing.
Two entry paths, one shipped, one sequenced for later
Path 1, the system proactively surfacing AI-detected anomalies in a new Anomalies navigation, is what the MVP shipped. Path 2, users defining their own alert rules and thresholds with email or in-app notification, was mapped in full but marked “not implemented in MVP.”
Why the journey is shaped this way
Strip away the domain and this is a familiar shape: someone gets a warning, and has to decide fast whether it's real and what to do about it. Three challenges in that shape drove the journey.
A warning with no explanation gets ignored. People don't act on alerts they can't justify to someone else.
The moment that decides whether the product gets used isn't when the alert fires, it's right after, when the person has to decide whether to trust it.
One click takes someone straight from a flagged item to its explanation, so the trust-deciding moment happens immediately, not several screens later.
Asking someone to set up rules and filters before they can see anything useful is asking for work up front, before they know it'll pay off. Most people won't do it.
Show value before asking for setup. Let configuration come later, once someone already has a reason to dig deeper.
The system surfaces likely problems on its own, with no setup required. Manual configuration exists, but it's a later option, not the entry point.
The experience we shipped
What we planned to validate after the MVP
User testing
Keep testing the shipped experience with users to catch usability issues the MVP timeline didn't leave room to chase down, and to find further opportunities for improvement.
Analytics
Watch how people actually use the key areas of the product:
Table data, and how people explore it
Date range picker usage
Setting up the funnel for slide-out interactions for root cause analysis
Together, testing and analytics were meant to confirm what we assumed rather than leave it assumed: whether the new journey actually behaves the way the research said it would, and where it still needs another look.