Timid BI
Traditional "BI products" are not aggressive in terms of vision, compromising their effectiveness. And this possibly reflects the cultural state of BI teams in most organisations
Building dashboards is painful and boring work.
I’m writing this as someone whose official job title once read “Head of BI”, and who has only tried building dashboards once.
My (failed) attempt at building a dashboard
This was about two years ago, when I had decided that I needed to institute a practice of “executive dashboards” in my company (we had tonnes of operational dashboards which worked rather well, but not much in terms of giving a quick view to the top management on what was happening in the business; moreover, it was nearly impossible to get two business leaders to agree on some basic numbers).
As a pilot I thought I should build a dashboard or two by myself. And quickly got bored by it. The repetitiveness of the process was mindboggling. Our tool of choice (what the org used) was QuickSight. And coming from a background where I’d done all my analytical work using code for 15 years, the whole drag-and-drop manual-adjustment-using-mouse experience was incredibly painful. The effort required was immense, and the outcomes uncertain.
Soon I realised that there are much better uses of my (and my team’s) time, and moved on to doing more interesting (and impactful) work than building dashboards (and nobody minded that we wouldn’t have “executive dashboards“).
How BI should add value
I was thinking about this when I was reading this blogpost by former CTO of Mode Benn Stancil. It’s a bit of a long blogpost, but makes a whole bunch of interesting points. Most importantly, it gives examples of how BI can add real value, and how traditional BI tools do everything but this.
Just as tools like Linear are unafraid to tell us how we should build software, BI tools could be bolder in telling us how to think about our business. Tell us how to interpret a time-series chart; force us to think about decomposing our business into its important components; give us a rigid summary table of our business that encourages us to debate what we do about the numbers on the page and now how we graph them; impose frameworks on us, and make us choose one.
(emphasis added)
Stancil, in his post, gives the example of XMR charts that, given a time series, tell you simply whether there is something for you to worry about or not. In other words, this tool helps managers make better decisions, and that is very different from most other BI tools that act in a more constrained manner.
He goes on to say:
If I had to guess, all of this is the real reason why BI tools are a tar pit: They solve the wrong problem. They’re focused on protecting us from bad inputs, and don’t do nearly enough to stop us from screwing up the outputs. And until one does that, we’ll keep feeling frustrated, keep churning through tools, and keep wondering why nothing seems to work.
Maybe it’s time to try another approach. Stop giving us more exploratory interfaces to get lost in. Stop waiting for us to become “data literate.” Assume we aren’t, and won’t be for a long time. If we were jaded about that, what would we build then?
Why BI tools are become this way
Now I’m getting into hypothesis territory. I say that BI tools are timid because BI teams are timid. And if you have someone who used to run a (timid) BI team and get them to build a BI tool, it is highly likely that you will get a timid tool.
BI tools are timid because BI teams are timid
If you think about it, traditionally the job of the BI team is to “provide intelligence to business”. And this they achieve through their familiarity with the company’s data, and correlation of such data with the business itself. This means that they continuously monitor the data, generate hypotheses, ask questions and provide insights (“intelligence”) to the business (this is how my team operated when I did the aforementioned “head of BI” role).
However, over a period of time, the role of the BI team has morphed. The familiarity and closeness to the data is still there, but teams have grown distant from the business. Now if you were to ask a random person on LinkedIn what BI does, you are most likely to hear that their job is to “build dashboards”. In fact, what are commonly called “BI tools” (Tableau, ThoughtSpot, PowerBI etc.) are actually tools that allow you to model and present the data in a nice manner - there isn’t much intelligence in there anyways.
In a way, it has become self-reinforcing. The scope of BI teams started narrowing, and they need to build stuff according to other people’s needs and specifications. That made the job of BI teams less sexy. That reduced the internal standing of the BI team within the org. And meant that BI became a sort of service provider to the rest of the org. This further reduced the scope of BI teams, and made the job even less sexy. And so on and so forth, and BI became downmarket, and timid.
And this timidity has reflected in BI products and their ambition as well.
You ship the org chart
I can’t find the original source of this but this is a common “truism” in the computer software industry - that you “ship your org chart”. That the way a product gets designed and implemented is a function of how the organisation is structured. One corollary of this is that when you get a traditionally timid team to design a product, they will necessarily come up with a fairly restrictive and unambitious scope.
BI teams are used to being service providers to the rest of their organisations. They take instructions (typically from business, and typically mediated by product managers) and build according to those. Apart from maybe some data modelling, they act with very little agency.
So when you build a tool for such a team, you need to make sure these constraints are getting “respected”. If the tool (used by the BI team) is too prescriptive to managers (or goes beyond what the BI team is expected to do), it becomes a tough sell. And so BI tools get defined and built “narrowly”. It also helps, like I’d mentioned earlier, that BI leaders (people likely to be building BI tools) also have the same mindset.
How we’re tackling this at Babbage
This tweet was doing the rounds recently - enough rounds that I even got screenshots of this forwarded to me on family WhatsApp groups!
Babbage works in the right direction according to this.
Making dashboards is shit boring and painful. We eliminate the need for dashboards as we know it.
Data analysts don’t like the pressure of “tell me in the next hour why our sales dropped in Timbuktu last week”. We anticipate such questions and deliver the answers to the people who might ask them even before they ask it.
Basically our AI takes the boring / painful, yet necessary, parts of a data analyst’s job and automates the hell out of it, leaving data analysts to work on what they were really hired for - to be able to deliver business-changing insight based on data. In other words, they can drive true business intelligence (rather than BI).
In other words, we do the “laundry and dishes” part of a data analyst’s job! What enables us to do this are our relatively outsider backgrounds - Manu is from a tech / product background, while I’ve done all possible data roles apart from building dashboards, and worked closely with CXOs.
It might also help that we’re NOT targeting this at BI teams, and CIOs are NOT going to be our buyers.
Tailpiece
My most favourite quote about BI comes from this post by Kaiser Fung:
The data science community is guilty of talking down on the business intelligence function. There is a misperception that BI is for less skilled people doing boring things. The reality is there is more science in BI than in so-called data science (defined here as software engineering). Science, after all, is about figuring out why things are as they are. Engineers, by contrast, use our understanding of science to change the way things are.
This, of course, talks about the traditional definition of BI.