MegaBill Was Built for FinOps. Dimension Sets Made It Work for Everyone.

By Lior Blumenfeld, Product Manager at Finout

Most product stories kick off with a shiny spec doc. Ours? It started with a brutally honest confession from customers.

Picture this: We are at the annual Finout Advisory Board session with a small group of our most engaged customers - people who care enough to speak candidly because they want the product to shine. Mid-discussion, one of them says: "Look, you’ve given us unmatched visibility, but the filter component? It’s drowning non-FinOps users. They get lost in the sea of dimensions and end up coming back to us with basic questions - or worse, mistakes."

Ouch. True. And kind of hilarious if you’ve ever been the unpaid “filter help desk” for your coworkers.

We didn’t know it at that moment, but that was the spark. That was the exact second Dimension Sets started taking shape.

Act I: The Discovery Phase — The Swiss Army Knife Problem

Ah yes, the Advisory Board meeting - the place where compliments and complaints mingle over coffee. This time, the compliments came first (“Finout gives us unmatched depth and flexibility!”)… but those quickly followed by the punch: “…but your filter component is drowning non-FinOps users.”

In this case, the advisory board wasn’t wrong.

Imagine being handed a Swiss Army knife with 400 blades. Amazing, but… which one opens the wine? That’s what MegaBill’s hundreds of dimensions felt like to anyone who isn’t a part of the FinOps team - AWS services, GCP tags, Kubernetes labels, Virtual Tags, and more - this is a playground for FinOps teams, but a nightmare maze for everyone else.

The pain in practice? FinOps pros became full-time filter babysitters, fielding endless “how do I filter X?” questions. Non-FinOps users, meanwhile, wrestled with the platform instead of their actual work. Adoption slowed, and friction crept into daily routines.

What made it worse (and better) was that once one customer voiced this, the floodgates opened. Heads nodded, and suddenly we had a wave of “yep, same here.” Their words painted the picture better than any slide deck could:

• “You need to understand billing deeply to query the data. Once you do, it’s easier — but the learning curve is steep.”
  
  
• “We don’t want to learn the platform, we just want answers.”
  
  
• “Advanced mode should only be revealed when we’re ready.”

Image 1: Finout’s filtering component before Dimension Sets (a.k.a. the Swiss Army knife with too many blades).

So the gist wasn’t “the platform isn’t good.” Quite the opposite - the platform was powerful. But customers were begging us to make that power accessible. The message was clear: give non-FinOps users a confident, streamlined way to navigate costs, while freeing FinOps from being “babysitters”.

To allow that, instead of jumping straight into specs, I hit pause. Time to run workshops and tests, to really listen before building the solution for their pain.

Act II: The Great Filter Makeover

Once we’d defined the problem, it was time to get our hands dirty.
I teamed up with our UX designer, and we pulled in our platform’s power users - Sales Engineering and Customer Success for a workshop. Think of them as the Avengers of Finout: they know every corner of the product and aren’t afraid to tell you when something’s clunky.

​​

The workshop setup was part game, part therapy session. We started by making sure everyone spoke the same language: what exactly was a “Basic Filter” (that friendly dropdown for picking or excluding values) versus an “Advanced Filter” (the heavyweight tool for the brave)? Once aligned, we dropped the real challenge: Design your dream filter.

Cue FigJam. Each participant got a digital canvas with filter elements sliced into “puzzle pieces.” Their job? Rebuild the filtering component however they liked, as long as they kept its bones intact. We needed them to think out-of-the-box, but still be realistic inside our current framework.

Image 2: The FigJam board our Sales Engineering and CS superheroes assembled during the workshop.

And just like that, patterns emerged:

• Virtual Tags (vTags) always went first. Always.
• Dimensions dropped from hundreds to dozens, and were neatly organized.
• Search had to level up and play nice with the new, curated lists of dimensions.

The outcome? A lightbulb moment. We realized we could deliver a quick win immediately by simply making vTags the first thing everyone saw in filtering and group-by. And more importantly, we uncovered the real requirement: FinOps teams wanted control, full control, over which dimensions appeared and in what order for their organization.

With these insights in hand, a new challenge uncovered: what on earth were we going to call this thing?

Act III: The Name That Kept Me Up at Night

Specs? Easy. Workshops? Fun. But naming? That nearly broke me.

Coming out of the workshop, we had clarity on what to build. But then came the deceptively hard part: what on earth do we call it?

Sounds trivial, right? Just slap a label on the thing. But anyone who’s ever named a feature knows the truth: the wrong name can shrink its scope, confuse its purpose, or make it sound like a sidekick when it’s actually the hero. And our scope was growing by the minute.

The “Basic Filters” phase: Our first instinct was… well, basic. Literally. “Basic Filters.” It made sense - we were trying to make filtering simpler for basic users, and not for the FinOps pros. But there was a catch. Basic Filters were only one component of the filtering experience and the pain we were discussing was much bigger.

The “Customizable Filters” attempt: Next, we shifted toward the bigger use case: “Customizable Filters.” That covered advanced filters, too. Progress? Sort of. But the more we mapped out use cases, the more obvious it became: this wasn’t just about filters. This was about grouping and putting into conext dimensions across the platform. “Filters” felt like stuffing an elephant into a shoebox.

For nearly two weeks, the debate ricocheted between three people: Asaf (our CPO), Chen (PMM), and me. Every day Asaf reminded me:

“Every letter / word / sentence has to be accurate and needed.”

Imagine how I felt, something like:

Out of options, we took the dilemma to the full product team. I showed a slide packed with crossed-out names. Silence.

Then Amit, who owns Data Explorer, among a lot of other features, leaned in: “Maybe it’s not keys. Maybe it’s actually dimensions.”

The “Dimensions” breakthrough: Another lightbulb moment: the real unit wasn’t the filter, it was the dimension. Until now, we’d called them “MegaBill Keys” (catchy, huh?). But this feature wasn’t just a MegaBill thing - it was about establishing Dimensions as a core platform concept that powered multiple components.

Me summing up the “dimensions, not keys” breakthrough—still unaware I’ll finally be able to sleep again.

The “Sets” evolution: Then came the twist. From dimensions, we got to “Sets” - groups of dimensions with a specific context that could travel anywhere in the system. That’s when the naming saga turned into weeks of back-and-forth. Me, the PMM, and our CPO in a relentless loop of brainstorms, hot takes, and “try again” moments. Eventually, out of the chaos, one name stuck: Dimension Sets.

Us through the naming process

Validation required. Sure, we’d fallen in love with the name internally, but we knew better than to trust our own bubble. Would customers get it? Would it click? That became the core question heading into prototyping.

In other words: naming gave us alignment on what the solution really was - but now we had to prove two things: that the design assumptions worked, and that the name Dimension Sets made sense in the wild.

Act IV: The Soundcheck — Do “Dimension Sets” Play Well Live?

Naming gave us clarity, but clarity alone doesn’t pay the bills. The real question was: would our design assumptions—and the shiny new name Dimension Sets—actually work for customers? Time to swap theory for prototypes.

With workshop insights in our back pocket, the “Dimension Sets” naming, and a fresh-ready prototype, we needed a simple way to sanity-check every moving part. So we treated the feature like an album in the making, we lined up each core assumption one by one:

• FinOps control: FinOps teams would curate the “primary” Dimension Set - the greatest hits album of dimensions—deciding what shows up and in what order.
  
  
• Configuration access: FinOps alone would hold the producer’s chair, mixing and mastering the tracklist for everyone else.
  
  
• User preference: Non-FinOps users would mostly stick to the hits, but could always flip to the full discography when they wanted deep cuts.
  
  
• Search behavior: By default, search would only scan the greatest hits. But once you switched to the full discography, search went wide—covering every track, and hidden gem.
  
  
• Usage patterns: Most listeners would be happy on the hits playlist, but when they craved more, moving to the full album library had to feel seamless—no skips, no broken tracks.
  
  
• Naming clarity: And of course, the album itself needed a name that clicked instantly. Dimension Sets had to feel like the right label on the cover.
  
  

The UX questions practically wrote themselves:

• Should users only see the greatest hits, or get “Primary + All”?
  
  
• Should the search stay scoped to the hits, or expand to the full discography?
  
  
• What should play first—the curated playlist or the full album?
  
  
• What happens when dashboards, anomalies, or saved views reference tracks not on the hits list—do we block them, or let users glide seamlessly to the full library?
  
  
• And of course: does “Dimension Sets” sound better than alternatives like “Primary Dimensions” or “Dimension Filters”?

The user test writing itself

Our approach was straightforward: we dropped these prototypes into Maze (basically an online playground where users click through mockups) and then ran live Zoom usability sessions. We watched, we listened, and we gathered both the click paths and the raw, unfiltered reactions.

And then came the twist: the assumption we thought was safe? Completely torched. We believed it would be fine to block easy transitions between the curated hits and the full discography—after all, who really needs every single track all the time? Turns out… everyone.

The feedback was across-the-board: users wanted freedom, not guardrails. They made it clear that no workflow should ever break, that restrictions were unacceptable, and that clarity without limitations was the real goal.

The key findings were impossible to ignore:

• Users rejected restrictions entirely — the All fallback was non-negotiable.
  
  
• Any Finout component using dimensions—whether Basic filter, Advanced filter, or Group By—had to auto-switch to All if the requested dimension wasn’t in the Primary Set. No broken filters, no broken groupings, no broken workflows.
  
  
• Dimension Sets beat every naming alternative because it resonated beyond just filters.
  
  
• 90% wanted the Primary Set as the default view.
  
  
• 80% wanted the Dimension Sets control pinned right at the top of the filtering and group-by components.
  
  

With those insights in hand, we could finally move from testing ideas to shaping an implementation plan.

Act V: The Release Plan — Dropping Singles Before the Album

With prototyping validated and Dimension Sets officially named, it was time to move from the studio to the stage. We had enough confidence in the design assumptions and the terminology to finally lay down an implementation strategy.

Our approach started with two clear audiences to serve:

• FinOps teams needed to reduce noise and finally retire from their side gig as unpaid filter babysitters. They wanted the power to curate the experience—deciding which “tracks” mattered most for their organization.
  
  
• Non-FinOps users needed simplicity. Less noise, more clarity, and a smoother way to explore costs without booking a tour every time they opened the platform.

Those needs translated into two technical components:

• Configuration Interface: the part where FinOps teams became DJs, selecting the playlist of favorite songs (the Primary Set) that everyone else would hear first.
  
  
• Default Filtering View: the main stage where that playlist actually played—so when users hit the filter, they saw the curated hits up front instead of being dumped into the messy back catalog.

The rollout plan? Think singles before the full album.

• Phase 1: Finout would configure Primary Sets internally, based on FinOps input, using a back-office tool. This setup applied only to selected users, with a kill switch in case things went sideways.

Image 3: Phase 1 — the “producer’s cut.” Finout configured the playlist (Primary Set) behind the scenes, pushing the favorite tracks to a few early listeners.

• Phase 2: FinOps teams themselves would take over, managing and updating Primary Sets directly in Finout. Permissions would control who could adjust the playlist, but the impact would ripple across the whole account.Image 4: Phase 2 — the “DIY remix.” FinOps teams became the DJs, curating and managing their own playlists (Primary vs. All) directly inside Finout.

Why the caution? Filtering is the most-used component in Finout. Any hiccup here could quickly escalate, confuse users, and chip away at trust. This two-phase strategy gave us guardrails:

• Test real-world behaviors without overcommitting.
  
  
• Stay flexible to tweak based on feedback.
  
  
• Avoid large-scale rollout risks while still tackling the FinOps pain head-on.

Of course, the worry never left - what if a filter tweak ruined someone’s dashboard mid-quarter? That’s why the fallback switch and user-level flags were non-negotiable.
Product principle: when you touch a live, heavily used feature, act like you’re defusing a bomb-steady hands, redundant safeties, and the rollback wire tagged before you even think of cutting anything.

And just when we thought our rollout plan was bullet-proof, fire-proof, and apocalypse-proof, the universe reminded us of that old saying: “Man makes plans and the universe laughs.” Our airtight timeline met an R&D surprise, and we found ourselves shipping the “temporary” solution to customer-proving that even the best bomb-disposal protocols can’t stop a well-timed plot twist.

Act VI: How R&D Jump-Started the Rollout

During Phase 1 development, the roadmap was crystal clear: Finout would configure Primary Sets behind the scenes with a humble back-office tool, gather feedback, and only then roll out a polished self-service UI. We had strict deadlines, wireframes in Figma, and usability tests queued up.

Image 5: The self-service tool initial vision

But then… surprise. Our R&D team, in a moment of self-preservation, whipped up a quick internal UI to configure and test Primary Sets. Not strategy, just survival. They were tired of constant interruptions, so they built Product and CS a tool to handle the customers requests on their own.

Image 6: The “rough cut” — the first Dimension Sets configuration page R&D handed to the product team.

And that’s when it hit us. R&D had accidentally built an internal interface that actually can work for customers. The design team was buried under other priorities, but this tool was already 80% aligned with our long-term vision. All it needed was a little polish. So we added search, cleaned up the buttons and text, layered in permissions, and suddenly, it looked customer-ready.

Image 7: The “remastered” alpha version of the Dimension Sets configuration page, released to testers.

What started as an internal hack had “PIVOT!!!” written all over it.

POV: When your two-phase roadmap suddenly collapses into one.

Instead of a slow, careful two-phase rollout, we suddenly had an alpha interface in customers’ hands. This saved serious development time, sped up delivery, and gave FinOps teams direct control of their Primary Dimensions right from the start.

With that unexpected acceleration, we found ourselves holding an alpha-ready product—and the next step was obvious: put it in front of real customers and see if it played as well live as it did in rehearsal.

Act VII: The Alpha Tour — Playing to Our Superfans

By this point, the focus wasn’t on how to build Dimension Sets—it was on whether the thing could hold up live. The hack-turned-hit-single was polished enough for the stage, so we lined up our first VIP audience: alpha customers.

With the alpha ready, FinOps teams could now configure the Primary Set using the new interface inside Finout. They could apply configurations to selected users in their account through the filtering component, with the safety net of turning it off if friction hit. This was the test drive before the big release.

The setup was careful and controlled. We embedded the alpha interface with permission controls so only FinOps teams could configure it. Feature flags acted like backstage passes—controlling not just who got to build the set, but also who in the organization would see the curated results in their filters and group-bys. That gave FinOps space to experiment first, then share their playlist only when they felt ready.

Here’s how the rollout worked:

• We demoed the feature to tester organizations live over Zoom.
  
  
• They sent us two lists: one for the FinOps users configuring the sets, and one for the users who would see those curated sets applied across Finout.
  
  
• We flipped the switches in real time, enabling each group accordingly.
  
  
• Feedback flowed instantly through live Zoom reactions and dedicated Slack threads.

And the results? Exactly what you want from a first tour: superfans going wild. Working with our most engaged customers was the perfect test bed— they confirmed the concept, handed us actionable feedback, and surfaced ideas we hadn’t considered. The energy was great, and one theme came through loud and clear: a single Dimension Set wasn’t going to be enough. Teams wanted separate views for Finance, Engineering, Execs - you name it. That demand for deeper customization steered the very next items on the roadmap (more on that later) and made the feature stronger well before GA.

Customer reactions spoke volumes:

• “I love that it doesn’t break links—you can just switch to ‘All’ if you need everything.”
  
  
• “Just want to say I love this.”
  
  
• “The experience of what that filter looks like now and the group-by looks now is a 1,000,000 times better than it used to be.”
  
  
• “This is a great step forward, can’t wait to use this.”
  
  
• “In the Primary set—you only see what you want, and it’s just incredibly responsive. I have no words…”
  
  
• “This feature is very useful. I get it completely, and it makes a lot of sense.”
  
  

The alpha tour gave us more than applause—it gave us a clear foundation for the next phase: turning the test run into a feature ready for general availability.

Act VIII: The World Tour — From Alpha to General Availability

The alpha validation gave us exactly what we needed to move forward—and even more than we expected. Not only did it confirm we were on the right track, but it also surfaced sharp feedback and fresh ideas that made Dimension Sets significantly stronger before GA. Our super users and most engaged customers proved to be the perfect testing ground. The excitement was real, but even better was the feedback that sharpened the feature into something GA-ready.

One example: alpha testers pushed us to add expand/collapse functionality in search results. It was simple but powerful—and we delivered it right away. With quick wins like that baked in, we were ready for the broader rollout.

Image 7: The filtering component after alpha-driven improvements.

The GA countdown began with an internal “What’s New” session - our bi-weekly show-and-tell where Customer Success, Sales Engineering, and Marketing get first dibs on anything fresh in the product. They loved it and immediately started lining up customer demos. One month later, Dimension Sets flipped to GA for every Finout account.

But launch day was just opening night. The usage data confirmed the feature’s impact: Users used the “All” dimension set in just ~11% of the filtering events in the past 3 months. In addition. We saw that when “All” is used, it’s almost exclusively admins (FinOps teams) performing the switches for deeper analysis.

In short: both Basic users and admins are adopting Dimension Sets — letting teams stay focused on what truly matters.

Customers stayed laser-focused on the roll-out, and the backlog filled up fast:

• Multiple Primary Sets – separate playlists for Finance, Engineering, Execs—already live in GA.
  
  

• Role-based Sets – auto-assign the right playlist the moment someone logs insitting in the backlog, waiting for its turn on stage.
  
  

GA closed one chapter but opened another. And for me, it set the stage for reflection—on what this journey had really taught me as a PM.

Epilogue: What Dimension Sets Taught Me

Looking back at this journey—from one customer complaint to a platform core capability—the biggest lesson I took as a PM is this: moving slow at the start makes you go incredibly fast later.

Discovery-first changed everything. Instead of rushing into specs, we spent weeks sitting with the pain. Internal workshops, customer conversations, even sticky-note debates—it all fed into the long naming journey from Basic Filters to Dimension Sets. Without that exploration, we’d have solved the wrong problem. With it, writing the PRD was almost trivial; by then the pain and solution were crystal clear.

Internal collaboration was gold. A short FigJam workshop with Sales Engineering and Customer Success surfaced insights I never would have gotten from surveys. And when R&D hacked together a tool just to ease their own pain, it killed Phase 1 of our plan overnight. Those moments taught me to watch for accidental gifts—the opportunistic pivots that leapfrog your roadmap.

Customer obsession was our secret weapon. We didn’t just build this feature for users; we built it with them. Live Zoom demos, Slack threads, continuous feedback loops. The alpha with our super users didn’t just validate Dimension Sets—it made it stronger, faster, and sharper before GA.

And then, there’s naming. What we call things matters. The shift from Basic Filters to Dimension Sets reframed the whole effort—from a tweak at the edge to a core platform capability. Terminology set the scope, aligned stakeholders, and gave the project its true weight.

The outcome: Dimension Sets is now live across all Finout accounts, giving FinOps teams clarity without restrictions and reducing their filter-babysitting overhead. From one candid complaint to platform transformation, the journey proved that structured discovery, rapid validation, and opportunistic execution can compress timelines—without cutting quality.

And just like that, Dimension Sets went from a hidden track to the headliner.