Sales pitches are the only place where "self-serve dashboards" work. In the real world, it's a different story. That story usually starts with an engineer or data scientist who's frustrated because they spend too much time writing queries and preparing dashboards for business people. They think that if they make BI easy enough, everyone will be able to "self-serve," but that rarely ever happens. What actually happens is that engineers and data scientists end up being the only people using the "self-serve" BI tool, which, ironically, makes it not self-serve at all.
Why Self-Serve BI Doesn't Work
SQL is the only self-serve BI tool. Still, most "self-serve" BI vendors don't want to admit it, so they find ways to reinvent the wheel and disguise SQL as something else. Maybe that's what customers want to hear, or maybe they genuinely believe it—I'm not sure. Either way, the problem with most approaches to "self-serve" BI is that they consider SQL to be the only barrier to business stakeholders querying data. That's not true. Let’s say you could wave a magic wand and make writing SQL queries as easy as writing an email. Do you think business stakeholders would suddenly start querying data? The answer is no. Even if these people knew how to write SQL queries, they wouldn't understand the semantics of the data they're querying. They wouldn't know what the data means, where it comes from, or how it's calculated. They wouldn't know how to interpret the results or how to validate them. In other words, writing the SQL query is actually the easy part.
Attempt 1: The Conventional "Dropdowns and Checkboxes" Approach
First, let’s consider an example of a conventional "self-serve" BI interface which uses dropdowns and checkboxes to make queries more accessible. This interface is essentially "SQL by mouse". While it might appear user-friendly, it’s slower, less reliable, more limited, and not generalizable to other tools. For some non-technical people who are scared of any monospaced writing with syntax highlight, this interface might be a good first step. However, even if it's 100x easier to use than SQL, stakeholders like your CFO would not use it. They lack the context to understand the data being queried, and they probably feel insecure about the results, which they don’t know how to validate. Ultimately, the task will fall back on you, and you'll end up typing SQL.
For more insights on improving productivity tools for technical teams, check out this quick creative team management guide.
Attempt 2: The Text-to-SQL Approach
Remember that magic wand that makes writing SQL queries as easy as writing an email? That’s what text-to-SQL tools aim to achieve. But they're not enough. LLMs can be too effective at translating natural language into SQL, generating a query for any question, even those that don’t make sense. This is problematic because it lacks context and semantics. A technical person would recognize these discrepancies, asking for more details about the business hypothesis and available data. Here, SQL is not the problem.
Image description: A frustrated engineer or data scientist manually working on complex BI dashboards that business stakeholders fail to understand.
_Image: An engineer gets bogged down in queries, symbolizing the inefficiency of so-called "self-serve" dashboards._
What Actually Works
If the problem with self-serve BI is not SQL but the context and semantics of the data, the solution lies in training people to understand the data they’re querying. However, this takes time, and business stakeholders often need answers immediately. Moreover, keeping up with changes in the database's schema, data models, and ETL processes adds significant overhead for the technical team. The true solution is not to make BI self-serve for non-technical people but to make technical people support business stakeholders more efficiently using better tools.
For more on the importance of having the right tools, see this comprehensive guide to choosing the right remote working platform.
Recommendations
1. Give LLMs to Technical People: Instead of deploying text-to-SQL for non-technical users, provide these tools to technical people. They already understand the data context and semantics, allowing them to generate quicker and more accurate responses.
2. Flexible Tools for Technical Users: Allow technical users to utilize flexible tools like Python or R. This avoids the need for data transfer between different tools and overcomes the limitations of BI tools confined to dropdowns or SQL-only interfaces.
3. Better Sharing Mechanisms: Make it easier for technical people to share their work. Current tools such as notebooks or internal data applications come with overhead. Tools with the simplicity of Google Docs but containing all building blocks of a data application are required.
I'm obviously biased because I'm building a data tool for technical people that encompasses these principles. But it’s essential to build tools that work rather than tools that don’t. Most importantly, identifying the real problem is crucial.
Remember these 3 key ideas for your startup:
Context Over Simplification: Understand that simply making SQL easier won’t make BI tools self-serve for non-technical users. Address the context and semantics of the data.
Right Tools for Right People: Equip your technical team with tools like Python, R, and enhanced LLMs to enable them to support business stakeholders efficiently.
Simplified Sharing Solutions: Invest in tools that facilitate seamless sharing of technical data insights akin to Google Docs, allowing easy access without infrastructure overhead.
By applying these principles, startups and SMEs can significantly enhance their productivity and make better use of their human resources in data management and analytics.
For more details, see the original source.
For more on the benefits of structured remote work tools, consider exploring Edworking's features.
