#306 The Next Generation of Business Intelligence with Colin Zima, CEO at Omni

Generative AI is transforming industries at an unprecedented pace. But as AI changes how you or your team work, one thing is clear. Your skills also need to evolve. At datacamp, we offer everything you or your team need to adapt and thrive with AI. Whether it's business users looking to get the Most out of ChatGPT and Copilot, or developers and data scientists looking to fine tune models, you can learn the entire AI skills spectrum on Datacamp. Power your AI transformation today. Start learning@datacamp.com.

Youm have to understand how the business works. Like you obviously need the foundational understanding of sort of data movement and all of those sorts of things. The the way I would explain it is build the sales dashboard like you're responsible for sales. Don't build it like someone asked you to build a sales dashboard. I think ultimately what a data product is is just a highly curated, very well planned data asset in comparison to more of these ad hoc things things. And so the types of things that you care about are how does the user interact with it, is there, read, write on it, what is the visual quality of that object? But I really think about these things as mostly products, not data products in any special sense.

Welcome to Data Framed. This is Ritchie analytics tooling has diverged. On the one hand you've got a lot of sophisticated tools for data scientists and on the other hand you've got spreadsheets still remain ubiquitous for quick and dirty analyses. BI tools fit somewhere in between and there are a lot of great options. However, today's guest thinks that there are no great BI solutions that work for both audiences. That's why he set out to build his own. Colin Zima was an early executive at Looker, where he was Chief analytics officer and VP of product. In 2022 he went his own way and founded Omni in order to build a next generation BI platform. As CEO, he's now taking on Power, BI Tableau, Looker and a host of other players with big tech backing. It's that kind of ambition that makes you want to know more. Of course, I'm always keen for tips on how to create a better dashboard too. Let's find out what the next generation of BI will involve. Hi Colin, welcome to the show.

Thanks for having me.

Now I'm going to make you justify your existence a bit. So there are a lot of very mature BI tools at the moment. Why do we need another one?

It's a tough one because I think it's interesting because BI is one of these spaces where every company is also trying to Build their own thing and sort of everyone thinks they can do a little bit better. I mean, I think the funny story for me is I actually started a previous company. I really hated it the first time. I hated doing the startup thing because it's extremely difficult to sort of wake up and motivate yourself every day if you don't strongly believe in what you are doing. And almost the only reason that Omni exists is because I sort of experienced this frustration as a data person over, like the last 20 years where I had touched a bunch of different tools and sort of felt the good and the bad of them and I wanted them all to exist in one place. So the very simple story is I started in finance, grew up in Excel, sort of learned everything. Data from an Excel context ended up later in bi, got exposed to Looker data modeling, like very heavy SQL Concepts. And I was always frustrated that tools couldn't do both of those things at the same time. Like, there's a time and a place to cut corners and go really fast and be a little messy. And there's also a time and a place to operate like a software engineer and have governance and centralization. We just kind of never felt like it was getting executed. And after Looker went through an acquisition and sort of started slowing down, we said, let's go, let's go try to build it. And that's kind of what Omni has been.

Okay, that's very interesting, this, this sort of divergence of tools. I mean, certainly, yeah, a ton of very technical tools around. Like if you're a hardcore data scientist or hardcore sort of data modeler, lots of great tools that. And then spreadsheets are sort of ubiquitous as well for more casual analyses. And yeah, you're right, the two things haven't really come together in some way, maybe to be. Just talk me through. Like, when do you want to do these sort of past casual analyses and when do you want something that's a bit more rigorous?

So I think, I think that is actually sort of the core of the problem for a lot of this stuff, which is you don't always know. I mean, obviously there's foundational concepts that you want modeled at sort of the baseline so that everyone can do better. The example that I always cite is Salesforce's API puts out deleted records. Maybe someone needs those at some very obscure moment, but effectively no one needs the deleted records. And so that is stuff that you want controlled in the ETL cycle, cleaned up for everyone, for all intents. Like you never want an end User to see those things. There's other stuff where you're starting an analysis and you realize you're at the corner of what you are doing. And to make a structural change would take you two hours and sort of sidetrack you and you just want to sort of cut a corner and do a thing and sort of share the question or share the answer to the question that the person asked you or that you have really quickly. And I think the, the, the challenge is often finding the place where you want to be governed and you want to create a sandbox is actually really difficult because the lines blur all over the place. Like even for stuff that I would consider sort of messier for analytics. So product analytics is sort of a canonical example. Doesn't matter how many people were on the website or how many people did a thing. Not really like you're looking for directional analysis even there. You probably want to template things that you come back to all the time. But if you're, if your data collection is JSON, you want to be able to like reach into the JSON blob, grab out a field and go do a thing. And so I think the really hard part is that when, when the paradigm shift is a completely different set of tools or infrastructure, it gets really hard to actually have that subtlety. You get locked into the structure of a looker and really hardcore data modeling analytics or you kind of throw your hands up and you say give me like a CSV and I'll go make it happen in Excel and like same with a data science use case. I think my strong view is all of these things tend to blur together in different ways at different times and you don't always know. And thus you need tooling that can actually be flexible and adapt. Even when you start in one area, you might end up in the other area. So that like the example I always sort of thought was sometimes I'm writing one off SQL because I have a one off question. And then you realize that thing you did was important and needs to be sort of extended or shared by everyone. And as soon as you have to kick it out of your ad hoc tool into your govern tool, you've sort of lost the thread. And so I think it's very hard to sort of say like this data is good, this data is messy and it tends to be sort of like everyone and everything, but sort of blurry lines between all of them.

That's fascinating. Yeah, I think you're right that a lot of data projects, you're not quite sure where it's going to end up, and what can start as like, oh, this is just going to take me half an hour, turns out to be a big project that involves lots of different teams. Just it was a lot more complicated than you think or imagine. You go the opposite, opposite direction. And something I thought was going to be very complex is actually going to be a lot simpler and you end up with the wrong tools. Let me talk through, what's your approach then? Like how do you have tooling that suits both casual analyses and something more rigorous?

I mean, I think the most important sort of takeaway that we had at Looker. So for people that weren't familiar with Looker or I mean, probably many are, there's a data model. And that data model creates little building blocks of SQL. So everything that you do on top of a data set when you're writing SQL, you can think about the little bricks that you fit together to write a query. Like everything in the select statement, the relationships, the where clause, these are all just little snippets of SQL that have use in different places. So if I ask for users by region, and I've divided regions into North America and Europe, it doesn't matter whether I'm grouping by IT or filtering by it. Region is a concept I want to use in many places. Those core concepts drive all of the centralized BI tools. There's a data model. You template out these things, you create this sort of rigid structure and effectively put pivot tables on top of them. The sort of insight that we had sort of leaving Looker was that all of the things that users are doing in UIs, in even spreadsheets or writing raw SQL can actually be templated into these pieces. If I write a giant blob of SQL, we might not be perfect at it, but we can break it into its component pieces and actually understand what it's made of. And in many use cases, you don't want to go do that. You don't want to take your 200 lines of SQL and, and break it into thoughtful building blocks that can compose together in a variety of different ways. But essentially what our tool does is as you are writing SQL or as you are doing Excel things, we understand the components that sit under them. So we are silently building data models. And thus when you decide that you want to take it from being sort of quick and messy to being more structured, we have pre prepared those pieces for you so that we can absorb them into a data model and sort of work with them like a mature BI tool. And that was sort of. The concept is, I think every major tool runs into these problems over time, like tableau, put prep underneath in Looker, you can write SQL. Like, ultimately every tool is trying to bend into all of these different use cases. But the challenge is, if you're not thinking about that as you build out the tool, moving between these layers can become very challenging because your post processing calculation layer that's like Excel doesn't talk the same way as your data modeling layer. But if you actually do the work upfront to sort of think about how these things weave together, that progression can become simpler. And that was sort of the really core insight that we had about building the tool that enables you to write a calculation that is Rho1 minus Rho2. And we understand that that's like a lag function in SQL and can kind of pull it back and do things with it if you want to use it in another context. That is essentially the building block of ami.

Okay, so I do like the idea of automatically doing the data modeling in the background. Now, I'm probably going to offend some analytics engineers here, but I would say in general, data modeling is not the fun part of working with data. So, yeah, having that automated does seem like some, or even if it's like partially automated, it does seem like it's going to be useful a lot of cases. I'd love to know a bit more about how or where Omni fits into a larger sort of data stack. Now, we had Tom Tungas, the venture capitalist, on the show last year, so he was talking about a postmodern data stack, included Omni and other as fairly modern tools like motherduck. So talk me through. Well, guess why do we need a postmodern data stack and how does it relate to the earlier modern data stack?

Yeah, I would say the postmodern data stack is not an official term by any means, but I think what's interesting is that. So I was actually one of the first Looker customers. That's actually how I landed at Looker when I spent eight years there. And in 2010, the idea of running analytics in a data warehouse that is disconnected from the BI tool was a very foreign concept. There were columnar warehouses, but it was essentially Vertica and Green Plum, like on premise stuff. And over the last 15 years, and really this was about 10 years ago, I would say that the world sort of coalesced around a way of doing data analytics. And again, there's, there's obviously a mix of all of this stuff, but you need to Collect your data together. And that is a combination of sort of sucking things out of SaaS tools and grabbing it from databases. So ETL has become a concept that is important to everyone, but it's really EL at this point. It's you take it from one place and you dump it into a cloud data warehouse. So fivetran is probably the most popular version, but there's a ton of players there. You've got the warehouse now and pretty much everyone has settled on some version of a cloud data warehouse. So redshift, snowflake, DataBricks, Mother Duck, BigQuery, things that process data quickly and cheaply. I would say that the kind of newest player in the space is the transformation layer and DVT is probably the most popular version of this. But you've also got SQL Mesh and Coalesce and a few other sort of transformation as a service products that effectively turn tables in your warehouse to other tables in your warehouse to kind of grossly oversimplify them. And then you have a BI tool sitting on top of them. I would say those four layers have sort of become the core of what a BI stack looks like right now. That is the modern data stack, the postmodern data stack, sort of whatever it is. Then you have a bunch of other tools on the side like catalogs and observability and what I call like the more niche tools that sit in the place. But those four are the core. The interesting thing about being the BI tool, and I see this sort of coming from a looker background, is what's interesting when you're the last mile, is you sort of have to take responsibility for all of the other tools in the stack because if the dashboard is wrong, you are the one that is wrong. And so it's always interesting to sort of think about our place in sort of how we interact with those other tools. Because again, going back 15 years, if, if Tableau is extracting and ingesting the data in memory and presenting it, it actually owns the stack end to end. But now in some ways that has sort of mutated into this four part best of breed stack where we need to understand how we interact with those layers better. So we have spent an enormous amount of time, for example, trying to be the best tool in the world alongside a DBT or SQL Mesh or Coalesce, for example, because data schemas have become much more fluid in 2025 than they were in 2010. The idea that that table would change its shape over time was, was sort of a problem for data people. You know, like that was called a migration. If you're, if you're like a database engineer now, it is just sort of like a day to day operation. And that was a, that was, for example, like a very large change for the BI tool that I would argue that even Looker, that is a relatively modern tool like 2012 was not fully prepared for. And I think when you look around the ecosystem, sort of data players now, especially in the BI layer, very few tools are built with sort of the expectation that schema is fluid, for example, and that is, I would argue, like, that is core now to the postmodern data stack because this stuff is so frequently changing.

Okay, so the idea of fluidity is very interesting because I think what maybe one of the most common complaints of business intelligence is, oh, the dashboard's broken and something upstream changed. So talk me through, like, what's the new workflow for making sure all your dashboards continually work? Like, how does maintenance work now?

Yeah, I mean, some of those niche players I think are attempting to play a part in it. So I'm sure all the observability tools would talk about, you know, data quality and making sure that the tracking is correct and things like that. Honestly, I think the biggest part here is actually philosophically how all these tools fit together. So now you need to make sure that fivetran got the data there, you need to make sure that your snowflake is up and running, you need to make sure that DBT did what it expected. And then the BI tool has to attach to all those things. From like the BI tools perspective, really what it is is just understanding the lineage of where things come from. We need to know that if we're dependent on column A and column A changed its name or moved its schema or something like that, that we can actually sort of touch and feel those things. So, like going back to kind of what I was saying, the sort of ability for the data tool to adapt to change, I would argue has become more important than almost sort of anything in the tool. Like very frequently we'll just have someone whose data moves from one schema to another. And it might have been planned in some sense, but I think historically that might have been like one week to go fix everything. And in a kind of very mature embedded analytics deployment, you need to do those things in lockstep because your data is in production to your customers. And so I would say, like, there's now these ideas of sort of software engineering or software life cycle for data in a lot of places. So My dashboard and the data model and the data warehouse or DBT or something like that. You actually plan a change across all of those layers together and you can go into a branch like we have literally git branching, where I can go make a change across all three of those layers at the same time and push them to production almost. That is the way that those types of things need to get handled. On the flip side, there's also the really easy version of this answer, which is just like we have great tools that can do alerting across all these layers now, and some of it is just doing the legwork to actually understand who is using what and pay attention to it. So a lot of it is really just the basics of setting up some monitoring on the content that people use and watching it.

Okay, so actually that idea of like git branching does seem very interesting. So I presume that means you've got access to like a whole suite of like standard software development sort of testing tools. Then how do you go about testing like the point and clicking part of things, or is that the easy bit?

That's a good question. I mean, I generally think that the developer, like the data team, sort of gets the punt on that responsibility. Because the sort of weird thing about a data team is in lots of contexts now, data analysts have sort of become product managers. We're producing things that look and feel like production assets. We have reporting in our product, our PM lead and VP of product built it all, deploys it all, and sort of manages it all. And it's literally a product that's in production, but at the same time they're partnered with someone like us to essentially build out the software that powers all of the reporting. And so in some ways you sort of yield the actual software development piece of it of, you know, building charts, interaction and things like that. And you can focus on the reliability of actually getting data into those objects and making sure that it looks nice and feels good. So I would say, like, our customer is certainly more focused on making sure the data is right and good. And the UI development is sort of left to us as the partner to make sure that the buttons work and the sort of the application stays up.

Okay, so really it's like it's kind of separate things, like make sure the data is in a suitable form for the database. You can test it all programmatically and then, yeah, you probably want someone on the BI team side to just check that the interface works. Just going back to the start of our conversation, you talked about how there are some Sort of very casual analyses where it's like, you know, you basically, it's like sort of spreadsheets plus and then there are some much more sort of rigorous analyses from a dashboard level. I'm curious, are there different requirements on the BI software for casual analyses versus for more rigorous things like I imagine like a dashboard that's sort of powering like company cash flow. Very different to just like, oh, I'm analyzing podcast listens.

Yeah, no, I think that's exactly right. And I think it's sort of obvious, but the builder is different and the consumer is different. So like the, I'd say the canonical internal example that most data teams are starting with is they're building a dashboard for their CEO. And the dashboard that you build for your CEO is very different than the dashboard that the data person has for themselves to go monitor, you know, data quality. And so I think the challenge is that, and this is, I would say a broad challenge across BI in general. The dashboard just being sort of like the main entry point. There are many different types of builders and many different types of consumers. Those different builders and different consumers have very different expectations for the product. So to like put it very tangibly, we need end users to be able to build dashboards quickly and simply. I need someone on the finance team or the support team to be able to build a four tile dashboard for themselves to monitor their job. That doesn't need to be the prettiest thing in the whole world, but that they can do in 10 minutes. And I also need to be able to build a dashboard for the CEO that can combine data from all over the business that looks exactly the way that they expect and that maybe could even get delivered out in external use cases that might be pixel perfect that the design team intervened on and sort of label layouts are particular or color palettes are particular. And I think you can sort of see that there's these trade offs now because I need the simplest tool in the whole world and I also need all of the complexity that you could possibly imagine. And that visual side I would say is even just one note of it. There's also sort of like data complexity which is like I might want to do it through a spreadsheet or really casual sort of querying interface, or I might want to do really complex SQL and you know, even data science use cases, which frankly we don't support right now. And I think the challenge is that we need to keep all of these in balance. So I'll give you an example of sort of like A way that we have tried to tackle this. We have the most common type of query on a dashboard is what we call a KPI. It's a number, maybe with a change, maybe with a Sparkline. Again, no rocket science to it. There's a lot of numbers on the dashboard and we've got a little configurator UI so that you can, you know, select a number and put a sparkline on it. And those are just like click two buttons and I get a sparkline and a number. So no config, very little control or less control, but like very easy to build at the same time. We will let you lock, unlock the HTML and CSS of that object and literally write web front end code to design it completely differently. And that's where a designer can come in and say, like, I need this 3 pixels to the left and you know, I want to bring my own font pack and I don't know, like, I want it to be mobile, responsive in a different way. I think that's the type of example that is really difficult to build in software because you're trying to make the simple, simple and the complex sort of like unbelievably open. And the dashboard is like the centerpiece of that for the organization because you have these users that want to configure everything and you know, build a web page, you know, actually act like a web developer. And then you have people that are just trying to pin four charts and get the tool out of the way. I think that is, I would almost call that singular problem. Like the core challenge of building BI is like, how do you reduce the number of buttons while also increasing the number of buttons. But that is sort of the, the torture of building a tool for everyone.

Absolutely. So yeah, certainly there are so many just company dashboards where it is just, it's just numbers and then time series is like, how does this metric change? Like quarter on quarter. But then occasionally you want to do something really complicated. It's like, okay, yeah, I want a heat map. Can I do that? Not sure. Yeah. Since we're talking about user interface, there's been a lot of push for adding chat like interfaces. So generative AI to almost every product. Is that changing business intelligence interfaces as well?

I think it is because it's interesting again because I think this actually kind of oddly fell sort of into our vision accidentally in that what we are trying to build is sort of a product that can bend into many different use cases. So Excel and SQL and pivot tables. And it turns out that AI has just become sort of our natural language has become just another interface for how people want to do things. I. The examples I love to give are there's places where AI is a really friendly way of doing things. Like lookups are a great example. Like when you ask ChatGPT, like, make me a grid of tariffs by country, it can do that very quickly. And a tabular form is really, really nice. If you ask it to book a plane flight, it's not probably the best interface because, like you want a to and a from and you want filter dropdowns, you want to see the sort of neighborhood of controls that you have available. And so in some ways, yes, it is changing BI because people do want to be able to come ask natural language questions and sort of be on their way. But I think the idea that it could or should replace everything is also pretty tenuous because there's a lot of places where UI actually makes it easier to do what you want. And I think, like, if you think of the BI experience with 10,000 fields, all of which are named things that you don't understand, that's probably the example where AI can complement it really nicely. I think on the other side, again, like the plain flight example or like a really well curated document, it helps to see the five fields that you can choose from and the way they're structured and like to have a calendar picker on them and have UI attached. And so I think that the way that most folks will interact with these things is actually very complimentary in a lot of different ways. Like, I'll give you another example. We've got this Excel layer. One of our engineers, literally of his own accord, attached our Excel layer to an LLM and we copied Excel's dialect exactly. We reinvented nothing. We literally like copied their syntax. And it's actually magical what an LLM can do to write Excel functions, because I pride myself on my Excel skills and I can go in and write like really elegant functions that can do things, but you can, you can literally just say, like, write an if statement that, that says whether someone's over six feet tall and it'll just go write you like the, the 30 characters you need in. In one second. I, I think what is going to happen increasingly is just AI now becomes a component for the web in the way that dropdown filters or calendar pickers have been in the past. It's just UI that you can attach, but it needs to be thoughtfully attached. It's. It's not like no one is just looking for text Boxes everywhere to go do everything via natural language, it needs to be thoughtfully sort of dropped into use cases that it actually solves problems well with.

Okay, so I enjoy a disaster story. So do you have any examples of where you think AI has been forced into these things in a bad way?

I mean, I think the canonical example tends to be like the customer support phone call where you're talking to the rep and you're trying to get through the phone tree because you know that you have a special use case and it just keeps offering you documentation over and over again. I think those tend to actually be the hardest use cases. Like I think in BI there, there tend to be a lot of different use cases that require sort of train of thought. And over time AI might solve these. Like it might be able to sort of do number one and then do number two and then do number three. But if you try to do them all in one shot, like, you know, find me my best performing users and do X, Y, Z with them and then compare them to the population. I think one challenge of natural language, at least as it exists today, is it'll often just try to do it all in one shot and if it misses any of the component pieces, then you're sort of back from square one and you need to start from scratch. And so almost like decomposing, questioning and answering. And again, like, I think a lot of these problems will get solved better and better over time, but I think it tends to revolve around being able to introspect the responses that you're getting and also places where UI is just better to do things. So like, again, like, I think filtering is an example where AI can be amazing, like filter for users in the us I don't need to go find, you know, country and then go country equals us. I think that a calendar picker is probably a little bit easier, you know, in, in many circumstances than typing in AI. I don't know, I think we're going to see, but I think it's essentially provided sort of synonym based UI for kind of everything that anyone needs to do.

Okay, so yeah, that's interesting, the idea that if you need things to be right, then you want to have small problems. So like the equivalent of like a single formula or a single like calendar picker widget, rather than saying go build me this whole dashboard in one step. Because then things are not going to be quite as you want them.

Though, like, I think even as you say that that might accelerate you in a really significant way. I do think the key though, is if the end of the road is sort of the outcome of the AI and you're stuck if it's all or nothing. I think those tend to be the bad use cases. I think the ones where here's a dashboard, do you want to tune it up? I think those are the use cases that are most effective. Or you can sort of stay in the loop and adjust the result sets. So like, our CTO has been using Cursor for the last like two weeks and sort of slowly started evangelizing it. But one of the things that he's sort of been paying attention to is that often you need to say, like, no, you did this wrong, try again. Like, no, you did this wrong, try again. Or like, this is the style with which we do things like redo everything that you did, but do it in this style. And so it's like it's these building blocks and sort of human in the loop pieces that I think are most important for AI. And I think this is actually one of the interesting divergences that we're seeing in analytics is some people are trying to have AI go right SQL and some people are having AI work through a semantic layer. And I think what we're going to see is that the only way that it can be successful in data is through a semantic layer. Because SQL at its sort of core is not decomposed enough that the user can go back and forth with it. Where if we look at it from a semantic perspective and we can actually understand, you know, anyone can understand the pieces, it gives us a sort of release valve to go tune those things. So I'll give you an example. Today we've been working on sort of like multi pass querying. So one of our engineers was demoing this morning, it was like filter the last year for people that did something on Saturday. And then, you know, show me this other query, if that is 200 lines of SQL and it got Saturday wrong and you have to sort of inspect the three places in the SQL block, it says Saturday to go adjust it because like, I don't know, time zone was wrong or something like that, that's frankly going to be impossible for any user to do. Like it's going to be impossible for technical people to do. If it builds something in the UI and the Saturday Sunday dropdown says Sunday instead of Saturday and I can go click it and hit Saturday and the whole chain of thought works. That is sort of successful AI to me. And I think that sort of summarizes, I think the sort of push Pull that we're going to see for AI with data. Because in many ways writing SQL is easier. The Internet is full of SQL and you know, all of these LLMs are very good at writing SQL. The problem is that SQL is sort of monolithic. And if you're writing these monolithic objects, it gets very, very difficult to go back and forth with them without sort of rebuilding the whole thing from scratch. And so it's going to play out. But I think the biggest thing that I believe is that this stuff will have to go through semantics and sort of tie to UI for end users to be successful with them. But we're gonna have to see how it plays out.

Okay, yeah, so certainly that's ties in quite closely with my experience of writing SQL is like writing it the first time is kind of fine, but then when you're trying to debug stuff, especially once you've got like a really long query that becomes incredibly difficult and then you're like, well, I should probably have written this as smaller common table expressions to begin with, but I didn't. And then, yeah, imagine when that's someone.

Else'S SQL though, you know, and now it's someone else's SQL every single time. But I, I think that's exactly the summary of it is like you can touch the one thing and understand how that decomposes, but as soon as that gets really big, it gets really, really challenging.

Okay, so you mentioned the idea of a semantic layer there. So just talk me through, like, just explain what's a semantic layer. Like, when should you build this, what should go into it, why do you need it?

At its most trivial, semantic layer is how tables join together and what columns mean and what sort of aggregations of said columns mean. So it is really just here's my raw data in a database and the semantic layer is when I ask a question about an aggregation or something about that raw data, how to explain it in business terms. I've got a user's table, it's full of users. Maybe some of them are employees, maybe some of them are customers, and maybe some of them are vendors. If I search for user count, when we talk about that internally, if it means customers, the semantic layer is saying, take that user's table, trim off the people that are not customers, and the count of them is users. That is really all that a semantic layer is. Obviously there's like nuance on how you write it and what, and sort of the workflow around all of those things. But it is just taking normal day to day Business conversation and translating it into database speak. I think that sort of obviates why it's so important for a natural language to be able to have that translation layer, because as you start applying creativity there, you might lose some of the nuance on, you know, what account of customers is. And you really need those building blocks to sort of effectively decompose business language into database language.

Okay, yeah, I like that particular one. Creativity involves. That seems like an important point because there's so many business metrics where there's a lot of creativity and how you define this or stuff like customer lifetime value, like how you attribute, like where a customer came from. It's like the definitions change a lot because, yeah, every team wants to calculate them differently. So having like a standard definition in your semantic layer seems great idea. So I'd like to talk a bit about getting the casual analysis crowd into business intelligence tools because it does scare me, like, how many businesses is powered entirely by spreadsheets. So there's always been this sort of like step up in difficulty or perceived difficulty from going from I'm doing something in the spreadsheet to I'm doing something in business intelligence tool. How can you make it easy for everyone, if they're not technical, to access bi?

It's a very good question. And honestly, I think we are going to struggle with this problem forever because in some sense there's a combination of problems. There's the semantics that we talked about, which is, you know, if you come and ask me for customer data, I can hand you a very, very clean version of that table that you understand really well and can go work with down the line. So in some sense, like, that's not an Excel thing, that's not a BI thing, that is a human made you a really small data set that represents a very curated piece of data. And so I think a lot of what tools can do to improve that is sort of help people with that first step to trim down the degrees of freedom that enable them to understand something and work with it. The challenge becomes that the universe of things that people want to do is very broad and a BI tool is highly generalized. And so the way I sort of think about that is again, like, there are divergences here where we could heavily curate the things that are available to people. At its most pure. We could get everyone one table with 10 columns and that is all that they can work with that is perfectly well understood. The good thing that we get there is a really simple piece of data that probably most people could work with. In a BI tool, the problem there is it can answer very few questions. And the challenge is as you sort of make these trade offs slowly to the other side of the universe, being like, here's the whole data warehouse, maybe with a semantic layer, but you can do whatever you want with it. Now suddenly every question is available, but each one requires more context. It gets very difficult to sort of make the trade offs between those I think sort of like, again, I'm a BI guy, but I think BI gets beat up for this concept. And Excel is sort of, you know, viewed as the solve for this. But it's not really sort of a BI versus Excel thing. It's a small data set versus all the data in the whole world thing. And so I think the first thing that you can do is just offer a lot of curation. I think the second thing is that BI tools have repeatedly sort of forced users to learn things that they don't want to learn. And I can give you an example which is like in Looker, we built a calculation language from scratch. It looked a lot like Excel. You know, the functions were similar, they did similar things, but ultimately it was a completely different language. And I think lots of companies sort of re approach these problems and try to solve them a little bit better instead of absorbing the knowledge that users have and bringing it into the tool. So paralleling to us, we literally copied Excel exactly. If you want to make a calculation, you type in equals, you click on B1, you click on B2 divided by B2 and you press Enter and there are trade offs there. It it we have to bend to the will of Excel and everything that we do. But the user can now bring a familiarity to sort of write that function and work with the tool the way that it works with. And so like, I do think natural language will open up more things for people, especially over like a well curated semantic layer. I do think though, at the same time there is nuance in the world that is very hard for any user in any context. The example that every BI tool always gives, that I always kind of chuckle at is sort of like, how many customers do we have? You know, the semantic layer solves how many customers do we have. Speaking to someone at Looker, you know, who has worked with semantic layers, that's a more nuanced question than the customer realized because the engineering team and the finance team and the sales team all have different definitions of what a customer is. And that's not a data problem, that is a human business problem, because finance only recognizes them when they have revenue and sales recognizes them once they're using the product, and product recognizes it once they spun up infrastructure for them. And maybe a semantic layer can get clean enough to explain all that nuance to people. But the reality is, like, if you and I are having a conversation about how many customers we have or something like that, I'm probably going to say customers over and over again and be completely casual about the nuance between those things. And those tend to be. The problem that business users get stuck on is not bi problems and they're not tool problems. Their life is hard and nuanced. And if you want to be perfectly right, you need to understand some of that nuance to do your job well. That is, you know, in some ways me throwing my hands up and saying I don't have to solve that problem. But like, I often don't think it's actually a tools problem. I think a sufficiently motivated user gets out what they need and we can always make our tools simpler. But a lot of stuff does require smart people to collaborate and, you know, nuance.

Yeah, definitely. I can certainly see how one person in a, in a meeting is talking about like the total number of customers, whether they've registered on your site and someone else is talking about, well, these people have actually given us some money, so therefore they're a customer. Yeah, there's a scope for some comedy misunderstandings there.

And if I could, one thing that we've learned that's actually been very amusing about this is once you start attaching LLMs to your environment, the language becomes even more important. So I'll give you an example. We have a bunch of different versions of where a user came from. And one of them is called channel and one of them is called source. And as I speak to you, I actually can't tell you which one is which. I know one of them is like partnerships versus inbound, and one of them is like the type of campaign they came from. When you use an LLM and you use natural language, it is extremely pedantic about which one you wrote. If you write channel, it's going to bring you channel. If you write source, it's going to bring you source. And in some ways it actually requires the user to have even more nuance because it's just going to kind of one shot the answer for you. And you know, maybe in the future it'll say, like, did you mean source or channel? Like, the people confuse these things. But the reality is the LLMs are even more pedantic about language and almost Magnify the problem of sort of this nuance in some sense. And it's one of those things that we sort of just learned by trying to do this more and more that we're actually trying to sort of figure out how to solve.

Interesting. Like, I'm guessing the solution is just document your terms properly, like have some kind of glossary. But I don't know, is there, is there something better than that?

I think that, I think it probably is something like that. Maybe it's sort of like understanding when things are very similar or sort of used similarly and saying like, I did this. But this is also an option. It's sort of like the type of thing probably a user would do, which is like, if you were sitting next to me, I would pull up one and you'd be like, no, that's not right. I'm looking for the one with this. And then it would go find the other one. And I think that almost is how it is going to have to work. But it's going to be interesting to sort of see how you have to reverse engineer, you know, loose semantics, because human language is imprecise in some sense. And now these LLMs are sort of much more tuned to the specific differences in language that you use between different contexts.

Okay, So I think something for everyone in the audience to be careful of. Make sure you use just the precise language when you're, when you're prompting these things. So I guess let's talk about the even harder case then. So when you're in a heavily regulated environment or there are consequences to your analytics answers being wrong, how can BI tools help there?

I mean, I think the answer there, it actually comes back to the trade off, which is you need to reduce the degrees of freedom for your users. You know, in that example of like, we can go wild west and let people do their thing, or we can lock things up a little bit more. I think when you start talking about more regulated things, be that like HIPAA data and people's names or your financial metrics, you need to reduce the surface area of access and the degrees of freedom for your users. So I think the really simple answer is the tools need to be more rigid in those circumstances. And, you know, you need to apply row level access filters and column level masking and these much heavier weight BI concepts so that you can make sure that your revenue is stable over time. The other thing I will say in sort of the, the nod to there's always a human problem underneath, I will note that our revenue has changed several Times and that has been the result of hygiene in our sales ops process. And so there's also an aspect of the data is as good as the data that you have. Oftentimes that is actually source system problems. And so I think that I underappreciated as a data person how important the pipeline of data creation was to the quality of my data. Because as a data person I was just a pure consumer of that. And as a founder and leader of Omni, changing the way that our sales process work to make sure that, you know, salesforce entries were better was actually the main determinant of, of the quality of the data in our reporting. And so I think again, it's like the tools need to have the things that you need to be able to lock things up and make them curated and versioned and all of that kind of stuff. And then you need business process to be able to make sure that there aren't 12 transformations in DBT in your data warehouse that introduce complexity into that reporting and that your data collection is good.

Okay, that certainly seems to make sense that you want to data quality to be taken care of like right from the start of the process, like not just once it hits the BI layer. Do you have a sense of who needs to be responsible for all this? Is this like a head of data governance or who needs to care about making sure that the data quality is good and people have the right access?

I think, I think it depends on the size of the business. You know, like we're about a hundred people, there's, we don't even have a data team. I'm probably the most core version of the data team right now, which gets me in the product a lot. So I mean, I think at smaller companies it has to be the line of business that sort of owns the data set. You know, like sales needs to be responsible for sales as numbers and then it's going to flow through a pipeline. But ultimately, you know, that is theirs to own. I think as you get larger, you get specialization. I would argue that I don't think that you want specialists for governance or data management. Like, I think that the closer that you get to the practitioners and the tools owning their own things, the sort of more successful you are. Obviously like I have not managed data at JP Morgan and they probably have a different set of trade offs and like maybe standards that they want to drive through the organization. But I think ultimately you want to get it as close to the practitioner as possible because they're the one living day to day in these Objects and, you know, will drive the most quality naturally.

Okay, so that makes sense. It's like basically the bigger you go, probably the bigger the problems are with scaling data quality. And so, yeah, maybe you need a dedicated team for that, but at a small level in smaller companies, you probably want it to be closer to the practitioner. All right. Okay. So I guess a rated idea is that there's been a bit of a trend from just doing sort of individual analyses to creating data products. Do you want to talk me through like how you go from analysis to data product and where BI fits into this?

Yeah, I would say. The first thing I would say is like, I think in some ways data products are like an over marketed term. You know, it's. I think it was probably created by vendors trying to do something new or sort of carve out a new niche in the market. I think going back to sort of our previous conversation, there are more polished objects where the recipient of them, and I'm talking data objects at this point where the recipients of them are much sort of stricter in their needs and their consumption, like data data team as product manager. And there are other types of analyses that are very ad hoc and very small. And I think ultimately what a data product is, is just a highly curated, very well planned data asset in comparison to more of these ad hoc things. And so the types of things that you care about are how does the user interact with it, you know, is there, read, write on it, what is the visual quality of that object? But I really think about these things as mostly products, not data products in any special sense. Like you're either delivering a product out to your end user or you're sort of doing data analysis. And so the kind of data product sort of term is even a little bit strange to me. The example I love to cite here is if you've ever used Zillow or any sort of home buying website, those are essentially data products. You know, it is a map with a bunch of listings on it that has drill through control and effectively presents data. Now it's doing it in a way that no one would consider it a BI tool. The experience is highly defined for the use case that the user has. I am navigating a map. Maybe I need to lasso, maybe I want to search by a bunch of different facets. And then when I click on things, I get a very specific experience that is built around what I'm doing on that page. So I've got a giant picture section, I've got a little table of data. I'VE got another little table of like previous sales. And each of those objects is delivered in a visual way that is more aligned to what the user is doing with them than the constraint of the tool. And I think that is essentially the description of a data product is an experience for the end user that is bent more to the end user's needs than a dashboard. I think there's always blurry lines here because, like, what is the difference between Zillow and a dashboard? I think like an engineer might say nothing and like a BI person might say everything. But I really think that it's, it is much more of a gradient of experience of just how do you make your BI tool feel a little bit less like a dashboard and a little bit more like something that was built to solve a problem for the user. And I think we'll see more of that over time as tools get better, but also just more, more business tools have become consumerized and consumers have higher expectations than business users. And so kind of everyone is pulled towards things that feel better. And so I think it doesn't sound good to say like dashboards that actually feel good, but I think that's most of the definition of what a data product is.

Okay, so I like that. I'm not sure whether people at Zillow like that, especially if your entire business is a fancy dashboard. But, but, but. So it was interesting that you said that consumers have higher expectations than business users. That's kind of a sad statement for business users. So how do you create these data experiences that are great in business?

So I, I think this is actually the funny thing because as speaking as like a builder of business products, I think the interesting problem is that often the consumer product is much more finely directed. So again, going back to the Zillow example, Zillow doesn't need to do open ended data analysis on any type of data set across any database and any dialect across many different types of users. It needs to deliver a very curated, very specific experience for a single use case that is highly well defined. So there's no corner cases. The null handling doesn't matter. It doesn't have to deal with time zones. Like it owns the dataset and it owns the presentation layer. And so I think when you look at a consumer app, like a Netflix, for example, is doing one specific thing, it needs to help you pick movies and it means that the UI can be highly tuned to a specific experience. If I look at Omni or a BI tool, I need to deliver that. Maybe I, maybe I need to deliver A movie picking dashboard. But I also need to deliver something that looks at the database logs for exceptions and I need to get salesforce data. And I need to tell you about your marketing pipeline. Because our tool is so flexible, we have to make all sorts of different trade offs where we have to generalize well, but maybe sacrifice specific use cases. And I think again, this comes back to. This is the hard thing about building data products is we need to build simple things for end users that are really fast to build, where the trade off is time to value. And we also need to be able to build Zillow in the product and have something that is pixel perfect and lays out in a very consumerized way. And I think this is ultimately the trade off between B2B products and B2C products. There are very few B2C products that have the same surface area as an ERP or a CRM or a BI tool. And I think this is often why it's so challenging, because the trade offs are really different. I, I do think at the same time that doesn't mean we have to deliver crappy, you know, dashboards. And so I think what we're trying to figure out is like how do we reduce the surface area so that you can build something really polished and control the CSS of a dashboard and lay it out like a web app. But we also need to do that for when you show up with, you know, your, your database, you know, nulled out a column and we don't want to blow up the whole BI tool or something like that. So it's difficult to find the trade offs. But I think ultimately that is how we get better. Like we are able to care about these problems down. I think, I do think these things are improving over time, but there are trade offs that you have to make.

Okay, so it sounds like the way sort of around these trade offs, at least for people who are building dashboards, the creators, they should try and aim for something that's very targeted towards solving specific problems for their users. Is that your advice then or what's the best way to create a great.

No, no, I think that is exactly it. I think sometimes people build dashboards and that just means I'm going to throw eight queries on this web page that do a thing. And I think if you think about that from a product builder's point of view, they're thinking, what is my user trying to do and how do I get them to that outcome? As we start building dashboards better, they will feel more like products. And again, Like, I think if you reframe it from I'm building a dashboard about our business and to I'm making everyone in the business aware of what's going on. Very small reframing, but I think probably significantly changes how you build that object for your end user. Like, what is the drill through path? How do they understand the objects that exist there as people use it? Are you evaluating whether this tile matters and whether it should get deleted and another thing should get added? And again, like, it's not rocket science, it's just thinking about it from the user's perspective and what they actually need.

Okay. Yeah. So it seems very similar to the idea of things like data storytelling where you've really focused on what do people want, what they care about, what do they want to hear. And I want to target my language.

Though I would say, like, I think storytelling the challenge there is often again, like this trade off thing. I think you can tell a really effective story on a static piece of data. It's really hard to be a good dynamic storyteller. It's easy to make a PowerPoint presentation with four slides that are static and say like, this happened here, this happened here, this happened here, this happened here. As soon as those charts are live, making that a great story becomes a little bit trickier. And I think this is where you need to think about, like, if you're trying to tell a story, maybe you should take static pictures and tell the story. And that's a snapshot in time that is a little bit different than, you know, a dashboard that is how to the business do today and the types of things that it needs to be successful. So again, like, I think it all comes down to like, what are you actually trying to do? Make sure that you're doing that.

Okay, now you've enticed me. Like, is there a way to do this? Like, have you got a tip for how you can tell stories that are dynamic?

I hate to just be like, AI might solve this, but I, I think there are some interesting things that it's like if I get a few slices of data, I can actually pass that into an LLM that can say like, here's what's been happening. I think the risk there is like, if you've ever done one of these for fantasy football or something like that, it often just sort of reads the values on the page and says the most trivial things in the whole world. So I think it's tricky. But again, I would really go back to, you need to think about what you're Doing like, are you trying to have something that every single day has a new insight for the business or is that even realistic? Like, great example, internally, we used to meet every single Monday to do corporate metrics. We realized that, you know, every, every three week period sounded pretty much the same because our business doesn't change that quickly. And so now we do a monthly meeting and the numbers actually move. If you're trying to build a data story on a dashboard that needs to that that someone's going to open every single day, you probably need a very different set of values and sort of actions that a user can take versus a sort of monthly review. And so like, I think the time matters, I think the intent matters. I'm not sure that you can sort of have a genius insight on a dashboard dynamically, but I don't know, like, maybe LLMs will figure this out over time too. Okay.

Yeah. So I like the idea that in theory at least, LLM's very good at explaining things. So you can probably get analytics LLM to explain the output from a dashboard, have that update as often as you like. But also, yeah, certainly if your business metrics are changing wildly from week to week, then you have a problem. Yeah. So I like the idea of maybe monthly is fine in most cases, or at least you hope it is. All right, so just related to this, are there any skills that you think are important for business intelligence analysts to learn?

I mean, it's going to sound pretty obvious from the rest of my stuff, but I, I mean, you have to understand how the business works. Like, you obviously need the foundational understanding of sort of data movement and all of those sorts of things. I think those are well trained and pretty obvious to people. I think the really big thing is you, you want to understand what is driving the business and how and why. And that's going to help all of your analysis be better. Like the, the way I would explain it is build the sales dashboard like you're responsible for sales. Don't build it like someone asked you to build a sales dashboard. Because when you're responsible for sales and you build that dashboard, you're going to ask the next question about every single thing that you have there and you're going to find the thing that is missing there. And I think that is always the most important version of how people do things. Like, I always think of this example where I asked the data team at Looker, we were doing a big repricing and sort of the whole question was, what should pricing be? I got a dashboard and it had 25 tiles on it. And my first question was like, great, what do you think pricing should be? And the person was like, I'm not really sure. In some sense then that means that you haven't actually sort of taken the last step to figure out why we're doing the things. And so it's like, it sounds really, really basic, but sort of just like be the kid that asks why over and over again of their parents as you do everything that you're doing. And all of your stuff will get like a hundred percent better. So I really think that that is the most important thing for data analysts.

That actually sounds very cool because you get to role play as like head of sales, which is cool. I get to pretend to be an executive, little power trip. But also you get to pretend to be a petulant child who's asking stupid questions, which is also quite fun. So it sounds great both ways.

I. That's why it was my dream job. Like this are the things that I like doing, pretending I'm in charge and asking why. Nice.

Cool. All right, so what are you most excited about in the world of bi?

I mean, like, I don't know, it's hard to not just say us and like everything that we're doing. I mean, I think I'm most excited to just sort of see how AI impacts. All of the existing tools like LLMs are just moving so quickly and have created so much uncertainty. I think it's interesting because even 10 years ago, like, the ability to parse and use natural language was the hard part. Now the natural language parsing is the easy part and the hard part is back to being data. It's, it's kind of amazing to just see the new things that become available to us as builders because of the advancement of just intelligence and all of this kind of stuff. It just changes every single week. So it's going to be really interesting to see how that keeps going.

Nice. Yeah, I mean, certainly a lot of exciting stuff just continuing so brilliant. I always need follow recommendations. Whose work are you most excited about at the moment?

I don't like. I feel like I'm a nerd. I like reading other competitors docs to understand what they're building. So that's, that's, that's my light reading. I really like the Logan Bartlett podcast. It's, it's a business podcast, so he pretty much talks to business leaders, but I think he does a really, really nice job of sort of drawing out just interesting insights from. It's mostly CEO guests. So I would say that's probably the main, that's the main kind of business thing that I look at. I mean the DBT roundup is pretty good. The analytics engineering roundup is a good one to follow. Ben Stancil on stuff. Sack writes good stuff as well. I need to think a little bit harder about how to answer that one next time. All right.

Okay. So Logan Bartlett and Ben Stunsall, certainly Ben Stunsall's sort of data camp regular, sort of webinar guest. So yeah, he's got a lot of great content. All right, that was going to be my last question, but I need to follow up on something. So you said that you spent a lot of time reading competitors documents. Now are you actually reading documentation or are you just getting an LLM to summarize it for you?

I actually read the documentation. I still feel like I'm trying to get better at thinking about ways to use LLMs, but I think I've just been in BI for so long. I like to really try to understand the nuance of how people are building stuff and the trade offs that they're making. You know, whenever anyone announces something new, instead of reading their announcement, I just go straight to the docs and try to understand what the feature is actually doing so I can sort of back out what they were trying to do, why they were trying to do it, what kind of trade offs they made. So I guess like, I don't know, if you're building SaaS, go read your competitors docs. It's like a, it's a gold mine for understanding how the thing works.

I think you might be the first person who's been enthusiastic about reading documentation, but yeah, that is a great tip. It's like, yeah, read your competitors docs, see what they're doing, see how they're building stuff. Probably going to have some useful insight there. All right, wonderful. Thank you so much for your time, Colin.

Of course. Thanks for having me.