The paradox of easy to use BI tools

Most data teams operate as a service-oriented function. It's just the natural consequence of the role. Business users need data, data analysts are hired to retrieve that data, eventually reports and dashboards abound.

As the tools improve, it gets easier and faster to create them. But every user wants something different. Now that they are cheap to make, the data team is expected to meet the demand, and reports and dashboards proliferate. This leads us to Jevon's Paradox. Easy to make, but too many to maintain. Environments become clogged with low-value, low-quality reports and then users can't find what they need (so they ask for yet another one!)

To bring real change, one option is for data teams to stop thinking in a service mindset and instead think in a product mindset. Instead of turning over requests for new dashboards, they are given a problem and tasked to create and maintain a product that solves that problem. It could be a real-time dashboard or a package of static reports or a machine learning model. Ultimately, it is up to the data team to decide the best solution.

Realistically for this to work, the data team needs to be as accountable for the outcomes as the business counterparts they work alongside. This incentivizes them to focus on actual business improvement instead of fulfilling every business user's whim for data. (Isn't that what these self-service BI tools promised?).

Adopting the product mindset, they will get feedback and feature requests from business users. This feedback is just that, feedback, not a new task to complete. Feedback is collected over time and tested for feasibility and cost/benefit. The decision of what to implement is up to the data team. They may often say no to many requests because they don't align with the overall solution, or they don't provide incremental value. The ideas they do implement are the ones with the highest value to the company. The result is a set of data products that are of much higher quality and value because the data team can spend adequate time to design, test, and refine the solution instead of jumping from one request to the next.

Of course, what happens if most data requests are getting shot down by the data team? The business users either have to learn to self-serve, work within the available options, or they end up hiring more analysts to service their data requests and the whole cycle starts over again. The data team would need to consider this outcome to build prevention measures into their strategy. For example, a concerted focus on training up business users on the self-service options and how best to use the data solutions they maintain. They may also need to dedicate some resources to regularly culling low-value self-service reports to prevent regressing back.