The Unbearable Weight Of True Self-Service

Self-service is the only feature request that means less the more we say it. Buyers demand it, vendors promise it, and nobody agrees on what it is. That vacuum is why dashboards die on the vine and why “data-driven” companies still run their business in Excel.

In the early days, I thought self-service meant one thing. When I was at Looker, we’d tell customers we solved self-service: users could hop into an explore, grab the fields they needed, hit run, and boom—instant insight. And if they needed to go further, they could just export to Excel.

And that worked. That story helped build a $300M+ business.

But I also spent a lot of time with commercial customers—data engineers who loved the LookML layer and the centralized governance it offered, and business users who quietly pasted CSVs into spreadsheets because they didn’t want to wait for someone to update a dashboard. Both groups were “using” the platform, but for completely different reasons. That gap stuck with me.

Why self-service still feels broken

Today, at Sigma, I see the same tension play out again and again.

Analysts tell me they want to empower their stakeholders. They don’t want to spend their day tweaking filters or creating yet another fiscal-year-to-date column. These tasks are too granular for an analyst’s time—but too important for the business to ignore.

Self-service is the only feature request that means less the more we say it. Buyers demand it, vendors promise it, and nobody agrees on what it is.

So what happens? People work around the system. They pull the data out, adjust it manually, and move on. That workaround is self-service, just not the kind anyone wants to talk about.

For a while, I thought the job was to eliminate those requests. To give the business just enough flexibility so the analyst could focus on deeper problems. But I’ve come to realize that’s only part of the picture.

Self-service can’t be defined with a single answer

There’s no universal definition of self-service. It means something different to everyone:

• To a sales manager, it might mean clicking a filter and seeing refreshed results. 
• For a revenue operations director it’s any way that will let them forecast accurately. 
• As a stock manager, it’s entering numbers in a table. 
• For an analyst, it’s writing SQL. 
• If it's an executive, it’s asking a question in natural language. 
• And to a data scientist, it’s the full gambit of Python.

And all of these definitions are right. Each role is self-serving in the way that fits their work best. That’s the part we keep missing in BI. The people who rely on data don’t all want the same thing—and they shouldn’t have to.

The problem isn’t that self-service hasn’t been achieved. It’s that we keep trying to define it with a single answer, and then prescribe that answer to everyone. We create a rigid workflow and wrap it into a dashboard. And when adoption stalls, we blame the tools, fire the analysts, or give up altogether.

There’s no universal definition of self-service. It means something different to everyone.

When tools don’t flex, people work around them. And the more prescriptive the system, the faster it breaks down. That’s when spreadsheets multiply. Screenshots start floating around in Slack. Metrics drift. Trust evaporates.

The goal of BI isn’t dashboards, it’s better decisions

Ironically, the answer to all this complexity isn’t tighter control. It’s better infrastructure. And that’s where governance and composable architecture come in—not as barriers, but as enablers.

When governance is embedded into the semantic layer, teams can define core metrics once and use them everywhere. When architecture is composable, you can separate concerns: storage, modeling, and presentation all live where they do best. You don’t force everyone to use the same interface—you let them choose, while ensuring the foundation is solid and consistent underneath.

The answer to all this complexity isn’t tighter control. It’s better infrastructure.

Self-service isn’t about building a perfectly simple tool. It’s about building a system that respects complexity while keeping it manageable. One that supports multiple working styles, without compromising trust or slowing anyone down.

Because at the end of the day, the goal of BI isn’t dashboards. It isn’t governance. It isn’t even self-service. It’s decisions.

And if your stack isn’t helping more people make better decisions, faster, it doesn’t matter how clean your semantic layer is or how pretty your UI looks. Your users will simply choose the option that lets them get their work done.

True self-service means better decisions at scale

That’s why I joined Sigma. Because the future of BI isn’t about forcing everyone into the same workflow—it’s about giving them the power to work the way they need, without sacrificing trust, scale, or speed.

The future of BI isn’t about forcing everyone into the same workflow—it’s about giving them the power to work the way they need

We’re building a platform that respects the messiness of real business, while bringing structure where it counts.

Not to chase some clean idea of self-service. But to help more people make better decisions, faster.

‍