A couple of years back, I worked as a data analyst and ran the implementation of a new business intelligence (BI) tool at a startup called Tictail. We were building an e-commerce platform serving more than 100,000 stores.

Working on a startup data team can be incredibly frustrating. You’re trying to find ways to contribute but are met with ad hoc decision-making and unrealistic expectations for insights to be delivered on demand. You’ll end up spending most of your time fixing broken data pipelines.

This time was different, we had a clear mandate from leadership to democratize data. We were excited at the prospect of finally being able to make a real impact. Our enthusiasm reached new heights when we came across the latest and greatest BI tool on the market. With its intuitive drag-and-drop interface, this tool promised to make data analytics easier than ever. The stakeholders seemed to love it.

We did everything right.

• We built a great foundation of transformed, clean, and well-documented tables.

• We designed and developed dashboards together with the teams, tracking their KPIs.

• We ran weekly training sessions with everyone in the organization.

Despite our best efforts, we only got a handful of users for our shiny new BI tool. We had failed.

Adding complexity

The non-technical stakeholders were overwhelmed by the number of dashboards and options. In an attempt to please everyone, our dashboards were so complex that we had to train people to understand them.

No matter how many dashboards or reports our data team built, the constant stream of questions in #team-data never slowed down. Every time we answered a question, we created a new report. We wanted to avoid answering the same question twice. The problem was that no one ever looked at them again. Reports were impossible to find, and questions had a short shelf life.

Product team members had even bigger issues with our tool. Even though they used data in their day-to-day work, they felt alienated by the lack of transparency and control of the new tool. The interfaces were supposed to make analytics easy but instead became a black box for those who already knew our data models.

Every time a dashboard metric was off, we investigated only to find more problems. We had implemented multiple layers of transformed tables and metric definitions on top of our production data. Engineers were experts in the underlying data, but they no longer knew what they were looking at. It made debugging a nightmare.

Back to the basics

One day, an engineer on the Growth team got fed up. He connected a SQL tool with basic viz capabilities to our data warehouse, and after that, things changed fast.

This SQL solution enabled Engineers and Product Managers to answer their own questions. They used SQL, an interface they already knew, and queried production data, a data model they already knew.

Data analysts and engineers started using the same language and working with the same tool. It closed the gap between the engineering’s and the data team’s understanding of the production system and its data.

The non-technical stakeholders we initially implemented the BI tool for were indifferent about what tool we used. The dynamic dashboards that took weeks to build were never adopted. The only features they did use, CSV export and Slack pulses, were more straightforward than before.

The three different types of data users

This experience taught me that a product organization has three types of data consumers.

1. The explorer: the non-technical stakeholder who wants lots of data and a no-code interface.

2. The lurker: they want to see basic metrics and export data to spreadsheets.

3. The builder: they know some SQL and want complete control and transparency.

Explorers are the loudest group, often managers, but in our organization, they were the smallest group by a long way. We had optimized for this minority at a very high cost.

When working at a fast-paced software company, we learned that you get significantly higher returns when you optimize for the Builders — the people in the product teams.

Here’s why:

1. Better decisions: Product teams make more decisions daily than any other part of the organization. The compounding effect of better decisions is huge.

2. Faster decisions: In a product-driven organization, the people building the product have the most context regarding data. Get them involved and answer questions faster than ever.

3. Improved data quality: When engineers and PMs use the data tool, they’ll understand the implications of shipping features that break reporting. They’ll also notice when something is off in a dashboard.

The truth is that most non-technical stakeholders won’t use your BI tool beyond looking at high-level static metrics — no matter the platform or system you choose. A drag-and-drop UI won’t change the fact that data analytics is complex and requires an understanding of the underlying data to get right

Teaching non-technical stakeholders SQL

So, how do you support the small group of non-technical stakeholders who still want to explore data themselves?

First, teach them SQL. SQL isn't difficult to learn, and the payoff is significant. If everyone knows SQL, they rely on the data team less because they can answer their own questions.

When you get a question, pair with the person asking and find a solution together - this is the best way to learn. They'll start by duplicating your work before eventually building the confidence to write their own queries. Soon you'll receive requests to review their new queries.

Use the strengths of a technical team and embrace that building product is all about shipping, learning, and iterating at lightning speed. Data is just one of several inputs to this process and needs to be flexible and fast.

Fast-paced product teams in organizations like Stripe, Shopify, and Uber keep data analytics simple and optimize for flexibility. They write SQL and visualize the data. If you don't trust us, trust them.

What's next?

Alright, let’s assume you manage to get this data challenge right. You taught some folks SQL and made data everyone’s responsibility instead of only the data team’s problem. Congrats, that’s awesome.

Solving this problem will offer new challenges — collaborating in tools that aren’t built for multiplayer and high barriers to entry unless you're a data expert. Luckily, this is what we solve at Mason.