“My 5 predictions about the future of analytics” With Colin, co-founder at Omni

Today I'm welcoming Colin, co founder and CEO of Omni, the business intelligence platform recently valued at over $1.5 billion. Before launching Omni, Colin was VP of Products and Chief Analytics Officer at Looker, the business intelligence tool, which was acquired by Google for $2.6 billion. Hello, Colleen, how are you? I'm doing great. Thanks for having me. It's my pleasure. This episode is made possible by Omni Today. The objective is for you to share a few predict the future of analytics. So let's go. The first one you told me about was the dashboard is changing, not going away. Can you tell us more about that? Effectively, what's been happening is that AI has been eating a lot of the analytics sort of world. And so historically we were going into pivot tables, we were querying, we were writing SQL, and obviously dashboards were a huge component of all of that. They were sort of the end product. I think increasingly people have said, great, AI is going to just replace everything. We'll just use natural language for everything. And on the one hand, it does make things a lot easier for people. We've talked about self serve in business intelligence for 40 years, but now you can actually show up to a tool and in natural language you can ask for the thing that you want. And I think the logical conclusion there is great. These tools will just replace dashboards. There's no purpose to have a dashboard anymore. You just ask for what you want. I think what people are coming around to has been kind of interesting, which is as natural language has taken off the. We've actually realized that there are sort of costs associated with these things. And one of the costs is just the direct cost. Like we've got to start paying for inference now. And this is a new thing that we were not paying for before. Like someone has to go pay Nvidia money somewhere for these things. And so that's one side of it. They're also sort of slow. And you have to generate the idea that you actually want to express to go do these things. And so on the one hand, these things are amazing because you can just ask for what you want. On the other hand, the things that dashboards were doing before was they would pin a set of queries that would get you started and it would be the same thing that you could come back to forever and ever. In that sense, those problems have not gone away. Like, I have a bunch of financial metrics, I want the table to look the same way, I want it to load deterministically. Dashboards are great for Things like that. At the same time there's been this development where historically as a BI tool builder, we had to go build the canvas for you, we had to write all of the software for you to go build a dashboard. What's been interesting is that now while the LLMs can serve the query inside of it, like we can go write a query and get results back, they're also extraordinary at building front ends. And so we've seen this in things like lovable and you know, the base 44 and the sort of web builders claw design, things like that. What's been interesting is these tools are also incredible for building dashboards. In some way, AI has increased our ability to go answer questions, to do the natural language experience, but now it's also giving us this tool to build front ends. And I think this sort of prediction is associated with. It might be great to use AI to write lots of queries. I think we want deterministic queries. What is going to happen on top of those is I think that rather than having existing dashboards where I need to go pin five tiles and go build an API tool in the same way I can design in Claude, I can just say like, hey, build me a dashboard that looks like an airline cockpit. Build me a dashboard that I was sort of jokingly was like giving them e commerce brands like give me a dashboard that looks and feels like Nike or like Super Mario. And these are obviously like sort of joke use cases. But what has happened is now we can build dashboards that look and feel like web apps and that has sort of now closed the gap with the tangibility to touch and feel things as a user. So I think the net is we're going to use AI to do more stuff. But a lot of these use cases have keyed on the backend problems of AI, sort of this ability to write queries. It's going to be just as important on the front end to build dashboards that are now a lot more unconstrained in terms of user experience. This raises two questions. The first one is that I had on the podcast one data leader who is called Edouard Floriot from Sorare. I think I told you about that before, maybe. So he did something quite radical. He stopped using Looker. He switched to a more like a notebook style BI tool which is X. He told me that now his team no longer builds dashboards but at all. He was quite radical about it. And so he has like the whole team who ask questions to the AI for the daily needs. Let's say, and the analysts are focused on more like complex analysis. What do you think about that? Do you think that it's going to be really like a very niche type of companies, or is it something that you see as well in some, maybe like high tech companies? Yeah. So I think what it was was dashboards were the only way to serve a finished product before. And so too many use cases went into dashboards. I think now we're seeing people pick up an AI and too many things are going into AI. I think there's this noble idea that's just like, ask for what you want. I think the reality is there's times when you want an AI to go generate you a new thing on the fly, and there's a time when you want the exact thing that you look at every single week. Like, the most important dashboard in our whole company is a pacing chart that shows our current quarter relative to plan, relative to every other previous quarter, relative to the plan in that quarter. And could AI generate that on the fly? Possibly. Like, it is a ridiculously complex rebasing query and AI could probably figure it out. Do I want to either wait 10 minutes for AI to go figure that out over and over again and then validate that it's correct, plus pay the cost of inference to go do that? Like, no, I don't need to do that at query time every single time. And so I think what's happened is that we've gotten this new tool in AI that is shiny and interesting and magical and it does a lot of interesting things. And I think at some level it's made us forget the reasons that we did some other things in the past. And we see this in all sorts of bi. It's like we throw away data models and we do everything ad hoc. And then when we do everything ad hoc, we remember why data models are nice. We do too much data modeling, it gets too rigid and we flip to the other side. I think we're doing that in front ends right now. We're saying, like, dashboards are great. Everything's a dashboard. No, dashboards are terrible. Throw them away. Nothing's a dashboard. The reality is always somewhere in the middle. I want the comfort of the thing that I know and the lack of cost associated with that thing. Should everything be a dashboard? Probably not. If I want to go look up an opportunity now. So, like a deal for us, I generally am not going to a dashboard because it was a bad way of serving up a paragraph about that customer. I'm going to say, write me a Paragraph about that customer. So, like, I think that we need more nuance in the decision making that we have. Like, everything shouldn't be a dashboard. Nothing shouldn't be a dashboard. There's a middle ground that actually makes sense. This relates to a trend that has come up several times on the podcast that is that data analysts may increasingly evolve into builders. Do you think that the direction many analysts should take or will take and that this, what you said, will also be like an opportunity for a lot of data analysts? I think the big thing is now data analysts have way more leverage than they had in the past. And the example I would give is, let's, let's just say that we are building a dashboard. It used to be that that would take you a week and you'd have to go build data, model or manipulate data. Then you'd have to go lay it out and like, you'd have to do all these things by click. Like, I'm not going to go get a perfect dashboard if I do this, but I can now walk into a tool and say, build me a pipeline dashboard. I can go get a cup of coffee, I can come back in five minutes and I'll have the framing of a dashboard. And even if that only gets you 50% of the way there, it just means that the leverage that person has is enormously higher. What that means now is that that user is unlocked to go actually figure out things that need to get done. And I think the superpower that data analysts have that is somewhat interesting and I think a little bit underdeveloped is we are the people that are touching and sort of bridging every area of a business. And so the original, like I sort of jokingly always said it was called business intelligence for like 40 years. And we weren't doing business intelligence. We were doing data or we were doing analytics or something like that. I think because of these tools now, I don't need to go answer a person that comes to me and say, hey, can you show me the last 10 deals that we closed? I can go hand that to an AI, go ask it, what are the last 10 deals we closed? It means that I, or the data team, we're now unlocked to go create value for the company. And that value is not like, let's get the data pipeline in a clean place. That is still an input to actually creating the value. In many ways, what AI has done is let us become business intelligence and like, ultimately take action on top of things. So, like, the best use cases that I have seen in Our customer base are web apps or use cases that actually don't really look like bi even. And like my favorite one is we have a customer that's an E commerce brand. They had their support team, their management team can go through every single support rep on their team, have the AI read call logs and actually identify types of mistakes that those support reps make on the phone. So it'd be like didn't recognize churn was not nice, you know, like couldn't find the resolution for the customer. And it can actually go through ticket by ticket, identify those problems and then they can go hand them a paper that says here are the eight mistakes you made with examples, improve these behaviors and then they can actually measure or sort of count those mistakes. And I think very few people would say that sounds like data analytics. We think numbers, line charts, things like that. But that actually changes the way that that team operates. And because data teams have these incredible tools now we can sort of zoom out and say what are the problems that we're actually trying to solve? How do we increase the win rate on deals? How do we make the support Org more effective? How do we improve marketing spend? Rather than just saying like I provide the data to that problem. I think that teams actually do have the bandwidth like that person you were talking about to let people self serve and go turn to either advanced analytics, if that's actually the business problem, but like business problems. And I actually think that that data people are a very unique intersection of like understanding of AI and understanding of the inputs into AI which is effectively data to go solve those problems. Yeah, this is exactly the trend that has come up a lot on the podcast I was telling you about. There will be like many opportunities for data analysts to become builders and yeah, and we can easily see with your example like all the type of application that you could develop that leverage that are let's say like data intensive type of application where your knowledge of the database, your knowledge of the data combined with your ability to quickly develop custom tools for operations, for marketing, for sales, for anyone, that will become a superpower. I think that's great. And I think most of these problems are actually data pipelining problems. Like organizations have the ability to go analyze a deal and understand like why the SaaS company didn't win this business. The hard part was that it took too many man hours for someone to go through every single aspect of that deal and identify the way that you presented pricing wasn't good. Like we didn't understand the competitive set. Well, whatever reason, like that is what sales leaders are doing. All of those are implicitly like data pipeline problems, data understanding problems. I think that now that these pipelines can be so much faster, we have synthesis as a service is almost the way to think about AI is we can take a paragraph of text and say like, was this person nice? Did this person feel happy? And those sound like sort of silly things. But the synthesis of the text and like the sort of coming together of all of those things actually was the hard part. I'll give you an example. Internally I have been asking how consistently are we quoting pricing and taking that into the market. That was the type of problem that was really, really difficult to solve because I have to go analyze one hour calls, I need to look at every single one. And a human could go do that and say like we quoted this person this and this person this and this person this. Now I can have an AI loop through every single one of those calls, create structured data out of this unstructured data. And now the easy part is actually drawing a conclusion about what have we done, how consistent is our pricing. And it's data people that have this sort of nuanced understanding of what data is easy to find and what data is hard to find. And then what can I pull out of those things. But we now have the tools to essentially turn all these things into APIs. And I think that gives us now the power to, to go solve those problems. And so I think in some ways the rise of sort of analytics engineering had data people step back from the business a little bit towards the sort of the more objective side of data. I think now we're getting pushed again back towards the subjective side and interpretation and business away from the sort of trenches of data engineering a little bit. And I think that's a good thing. And so I just want to add something on what you've just said because it's interesting. I'm going to mention Edouard Floriot again because he always has some radical points of view. So I think it's funny to just to comment on them with you. He believes on his side that many of the best data analysts will eventually actually move completely into business roles like in product or in marketing or in ops, using what we've just said. So their analytics and AI skills, but also their business skills. Because what we've just talked about is becoming such a superpower that actually it's gone like, let's say, enable them to almost overcome a bit like the other competitors within the company, let's say. Do you see that happening or do you think there will still be plenty of room for very good, dedicated data analysts in most organization or. Yeah, so I think there will always be a place for data teams. I do think that they're going to get smaller and more efficient. Like I just generally think that people aren't that aren't in the line of revenue. Like teams will get smaller over time. That's a good thing. Like it means that we're more efficient, it means that you do more things on average. I think the challenge for data teams was always the glass ceiling of there are orgs that have C level titles and data is usually not one of them. It's a service center usually that sits inside of one of those orgs. And so the idea is like if you want to break into the C suite. I was the chief analytics officer, but ultimately I probably had more gravitas at looker by running product than I did by being the chief analytics officer. So I think for data it's always been this tension between liking the technicals of data, like again, the data engineering side, the back end and the sort of interface with the business like helping marketing do marketing better or helping sales do sales better or helping finance do finance better. I strongly agree with that point of view, which is data now becomes a superpower where if you can go use these things, you can be really effective in any of those roles. I think the challenge was always how much expertise a data person built up into any of those given areas. But I'll tell you, now that I'm running a company, being a data person is an enormously beneficial background because it gives me grounding to understand everything that's happening in the company. Ultimately, if you're going and managing 100,000 people who are not 100,000 people, you can't do that. Anecdotally, you can only look at broad numbers that are spread across things. And so I think as organizations get bigger and more leveraged, your chops as a data person need to be better. And again, like now we've got all of these tools which is I can go manage the data pipeline in a much more automated way. Now I'm leveraged to think about sort of what I'm doing with those things. So I think that's realistic. My advice to those people is you're still making a jump. Like it's tough to go from data person to marketer. There are a lot of other skills as a marketer or as a CFO or as a coo. And the way that you get those skills is by solving those business problems. So what I've always loved about being a data person is you can just dip into orgs sort of on an ad hoc basis. You want to be the marketing person for a week. Cool. Like go help optimize that org. There's still a lot to learn in those different places and ultimately a lot's a hiring problem too. So like you got to get great at recruiting. Moving on to the next prediction. It was natural language. Doesn't mean simple question and answer. Do you want to tell us more about that? I think this is another one of as sort of AI and NLP develop, we're sort of learning what all of these things mean. And it ties back even a little bit to the dashboard, which is the first sort of step here is you get a text box, you type in your query, you get an answer, and in between it's sort of a question mark, question mark. AI goes and figures things out. I think what we've seen is that there is actually more nuance required to sort of do things well. And I'll tell you what I mean by that. So on the one side we have things like dashboards. I don't really want any creativity. I want these exact four queries to come out every single time. And really the natural language box just direct you towards a query. On the other side, I don't really know what I want. I do want sort of a natural language box. Figure out what I'm trying to ask on that side in the middle. We've seen a lot of leverage in this concept that we call skills. And what I mean by that is rather than thinking about AI as sort of an agent that goes and figures out everything on its own, we have these repeated use cases that require judgment but also need to be agentic at some level. And I'll give you an example. Our FP and a team goes through and looks at month over month spend change across every category of our business. We have 100 accounting categories. Month over month, we look at the changes in those things. The ones that went up, the ones that went down, hopefully revenue up, cost down. But you're trying to dig in and understand sort of what is happening. You could go into a text box and in natural language say like, tell me what happened month over month to my business. That's probably not a great way to go run that query because embedded in that question is a rubric for how you want to do things. You know, like we look at commissions a certain way, we look at revenue a certain way. If travel goes up, I want you to go analyze these four categories of spend. You can encode the sort of logical train that you want an AI to go through and provide a much more detailed sort of description of what you want the AI to do. And it's agentic at some level. It is natural language, but it's natural language with heavy guardrails and a lot of guidance, much in the way that a human would have. We think that there will be a world where you will want to do tasks in a variety of different ways and very often you will not want to derive how to do the task on the fly. So I think that FP and a skill is a type of thing that we really want to create a lot of repeatability around and a lot more guidance. I wrote one last week for looking at week over week changes in our pipeline. And again, like I want to know the deals that advanced, when they advanced, I want to get a note on why they advanced. And it really is something that sits halfway in between a dashboard and an open ended agent. And why it is not a dashboard. I think a dashboard is just too constrained. The way I think about it is a dashboard is a flowchart that has one step. It just says return all these queries. An agent is a flowchart that has infinite steps. This is a flowchart that says sort of like if this, do these four things, if this, do these four things, do these four things always. It's really like the way that a human behaves. Yeah. When they're so the result will be different. That you don't want it to be static. It could go a lot of different ways. That's exactly right. And like maybe I could go build a dashboard that preemptively answers all 1,000 of those branches of the tree. But really I want an agent that's making decisions. So let's just say that we're trying to look at whether a customer is healthy. Maybe if they're healthy, I don't want it to do anything. Just tell me it's healthy. If they're unhealthy, I want to look at the four categories of unhealth and I want to dig into each of them. And if a user turned over, I want to know who replaced them. The whole idea is it's a set of logical sort of decisions that a human might make that I actually want to encode into the the sort of algorithm for how an AI decides things. Kind of in the same way that we had dashboards and really open ended things that required humans. I think now we have these scales of what an AI is doing. And I think that software engineers are already starting to do things like this. If I say, like, go write this code for me, I don't want it to just pick up style from zero and go write code a certain way. I don't want it to use any language. And those are sort of extreme examples, but I want it to understand the context of how we do business and how we make that decision and take that into account when it does a thing. And I think that these skills will actually become a predominant way that people do things, because a lot of the things that we do at work are on a weekly cadence or a monthly cadence. And we do sort of want to build the way that we do it and keep adding on to that sort of logical bucket so that we get to like a really consistent version of understanding. Yeah. So you think this will eat a lot of the dashboard use cases? I think it'll eat from both sides. Like, people built the customer lookup dashboard that does this. People are now going in and saying, like, how is this customer doing? I think the reality is there's something in the middle. You need it to be able to think like an agent. You want structure to it. And so I think that is a much better solution than dashboards to a lot of problems. We could create a dashboard that looks at week over week pipeline changes. I'm going to create a much better version of that by progressively improving the instructions for how I want it to look over week over week pipeline changes, or how I want it to look at month over month spend changes, or how I want it to look at customer health. How do you analyze this, for instance, in the company? Is this just like you say? So far it's like, okay, now we review each time we have a need, we decide, is it a dashboard? Is it this new kind of way, or is it just like full self service Q and A? I tend to think it's very organic. Like, I think what happened was we had dashboards for things, we threw them away, we replaced them with single queries. We've realized that we're asking the same query over and over again. And by adding more richness to the query, like more context, you can get a much better answer. And so I think that what we're trying to do, ironically with AI, is we look through all the sessions that we have internally and we say, what should be skills in here? What are the questions that people are asking where they're maybe not saying it in a nuanced enough way. And if we provided more guidelines with the question, sort of a better system prompt for that question, we'd get better results. So we've had kind of different orgs build these out. Like a great example is the support team gets tons of product roadmap questions. They started by coming in and saying like, you know, is Fedramp on the roadmap somewhere? And the AI would go try to figure out that question. It might check a couple different places. Maybe it checks Slack, maybe it doesn't. Maybe it checks our feature flags, maybe it doesn't. What we realized was like, no, we want you to go check these six places every single time. Make sure you check these six places, synthesize them. Then make sure you go pull up the roadmap presentation and see if there's a slide in there that has that in it. If there is, then provide some structure to the response. So it was something where AI made it easy to self serve, but trying to kind of hope that an agent could just figure out all of this context and do it in a rigorous way was not good enough. That is a perfect place for a skill. And so I think what we're going to see happen is people will go just go ask their own questions over and over again. If you see people asking the same question 10 different times and the response is good, but not as good as it could be, that is a great candidate for a skill that is like repeated work where more rigorous guidelines, essentially turning that eight word query into 200 words now can make that a much more effective query and it can constrain cost, it can improve the results. I think it's going to be an evolution that's interesting because this implies kind of a new role for the data team is to like maybe analyze what's going on so far. Basically the first step is to do like the full self service breaks and to make sure that it works as much as possible for the easy questions. And when this is deployed in the company, you have hopefully a lot of usage. And once you have usage, you can analyze usage like you've just said and basically find out where like you said there was some kind of frustration or you could feel like the answers were not perfect. And then you can start building and prioritizing the skills that you want to build. And this, at least in the beginning I think probably should be done by the analytics team that understand very well how to provide the best answer. No, you need to go find this specific database, do this, or take this documentation Etc So this could be like an interesting skill, but this time like a skill for people to develop in the coming months. 100%. Like, I think probably even more than the ability to just self serve itself, the ability to see what your users are actually trying to do is such an insane superpower. For people to have like data, people had to guess what people were trying to do. We could go look at the explorers and looker that people were trying to analyze or you know, the data sets that people got requests for. Now we can go literally see the questions that people are trying to answer. And if you can really force people to use this product and ask the questions that they have now, I can reverse engineer making sure that all of those responses are perfect. And that is such a superpower for data people. Most people cannot understand the exact intent that every single one of the end users had. Now we can literally see it, we can go see the responses and we can go reverse engineer perfecting the response. And that's how you create this sort of viral loop that makes the thing much better. All right, so moving on to the next prediction. You told me AI will start writing more data model than people. Do you want to tell us more about that? I think at the same time, people have not fully embraced quite how good AIs are at operating existing systems. You can literally just go hand it a pair of files from your IDE and say bring all the fields that aren't in this view into this other view. And it's the type of task where a human might have copy pasted that it would have taken them 15 minutes. Now it is a prompt and an AI can do it in five seconds. I think that we're getting to a point now where if we can discreetly enough identify the types of problems that come to exist, again sort of skills, we can provide guidance on how to go solve it. And AI can take a first cut at doing everything that we do. If a column disappears from your data warehouse, did your pipeline break? Was that column supposed to disappear? What do you do with all the content on top of it? There's a heuristic that a human has to go debug that problem. We can now go hand that to an AI that has access to these systems and it can go exercise the exact same sort of logic that I would have, except it can do it in an automated way, provide back a report and do maybe 90% of the things that I would do. I think that only very recently have people realized the level of automation that can exist here. And it's only going to get better as these tools sort of bend into supporting these things better. So to think of like a really tactical example, if code breaks in the ide in looker, we would put up a warning, say this code is broken. In Omni, we put an autocorrector in there that mostly just deleted the code, but it attempted to take an action and this was non agentic. Now we can go look at a line of code that is broken. We can say, hey agent, this line of code broke. What should I do? And if you can provide a rigorous enough heuristic, it can probably go solve maybe 50% of the problems. I think soon it will be 95% of the problems. And so we're just getting to a place now where people need to enumerate how they debug things. And in the same way that when a menu breaks, your engineering team is handing something to Claude code before they start touching the code, I think analytics teams will start triaging with AI and then they'll come in and intervene when they need to. Actually, this relates to another prediction that you told me about. So I think it's interesting to talk about them together. You told me semantics matter more than ever. Do you want to tell us more about that? Yeah, I think it's more that you need structure to how you're making decisions. And the things that are amazing about AI are also the things that are a little bit sort of scary or dangerous about them, which is they will answer your question no matter what. They will come to some conclusion in your data set. And so it is very important to that we understand that it's going to sort of figure out the shortest path to give you an answer. And if the shortest path is not the right path, then we need to heavily mark the path to go answer questions. I think what has happened is that we've sort of picked up many styles now of doing natural language for data analytics. We started with text to SQL and then people started bringing semantic layers to these things. And in the same way that there are sort of trade offs with everything, I think this sort of natural trade off appears, which is SQL is good at sort of understanding the 10,000 tables in your warehouse and figuring out a path to answer any question that you have. It's extremely expressive. With enough logic, it can think, it doesn't have the encoding of how we think about the world that a semantic layer has. And so semantic layers are more rigid, they're going to be cheaper, they're going to be faster to answer questions. But if that question that you wanted to answer wasn't encoded and your tool has to write semantics, you're going to get stuck. And I think what we're going to see is people are again going to land in the middle, which is having a grounding of a semantic layer, but let people create things on top of it that can sort of do creative things. And that's like how Omni writes queries is any of the views that we use have to be encoded in semantics, but then it can sort of write SQL with them. This is all just to say that I think that agents are going to be able to figure things out on the fly, but if they are not really well enumerated again in the same way that your data team understands the nuance of your data set, they're going to reach incorrect conclusions. And so it is now extremely important that we annotate how we think about things, how joins work caveats in data sets because it's gotten so easy to answer questions that if those questions are answered without the caveats attached to them, then people are going to draw the wrong conclusions. So if for example, I have web tracking and mobile tracking and I have a table called tracking and mobile tracking, an AI is going to very comfortably just tell you like we have this many users because I just looked at the tracking table inversely, if on the tracking table you say, whenever you use this table, make sure that you use the mobile tracking table. You can now sort of inject the nuance into your dataset that probably your data team had, but your end user doesn't have. And so this is all coming back to self service has gotten way easier. But if you don't properly gate the self service that you have with the caveats associated with things that you model it, you're going to enter now these problems that get much harder to solve because you don't have semantics. Yeah, it's interesting because this is really like the main complexity that we are experiencing I think as a sector on this topic. And so far the solution is a bit a mix of several elements we've talked about, I think. So you have the transversal basically semantics and context layer. And then you have also, like you said, a bit like the enumeration of how you do specifically each smaller process and you will encode in the skill directly what needs to be done for more like specific small analysis or use cases. Yep. And it's a bit like this mix of different elements that you need to build and to work on in order to have something that works. I think that's right. And I think that, I think this is going to develop over the next five years probably because the challenge is that agents can figure out a lot of things on their own. And if you leave an AI to go run for an hour and it can revalidate itself and you sort of inject skepticism into that AI, it will probably get to the right solution eventually. The challenge is that it's going to become a cost, performance trade off for these things. And the more that you can sort of narrow the search space and enumerate how to answer specific questions with skills or with semantics or things like that, the faster things will be, the more thorough things will be and frankly the better things will be. And it's going to take time for people to sort of come to these conclusions. If COMPUTE goes to zero, and again, if we all get genius level AI for free, I think then the assumptions that we have do change very significantly. Then maybe you throw COMPUTE at every single problem and you don't do any work. It's sort of like you have a bunch of humans on your team and they can go find your solution every single time. I think that we are way short of that. And in a space where there is constraint, you want to really provide structure to how you're asking these questions. And the more structure you provide, the more you can drive down cost, the more you can increase quality, the more you can increase performance. How you see things in terms of like combination of tools, One could say that you're a bit biased, but still I think it's interesting. I think you test a lot of the different tools. So today I see a lot of companies that will have for instance, one modern AIBI tool like Omni, for instance, that will be still combined with Claude for instance. And so both will like basically share the responsibility of what we've just said. And then this will be plugged in some way on a lot of data that is extracted from dbt because initially this is where we would document a lot of elements. And now you have also probably in addition some like in house context type of layer with a lot of different files that you want to have potential formats. Do you see this continuing like that with a lot of different tools? This will depend on the companies or your vision. Are you actually more like a head on against a cloud? Your objective is to do everything in Omni. I mean, how do you see things? I think that we've always been pragmatic about the world, which is, look, we would love to serve every single Query that needs to hit the database through AI and have Claude go through us to hit the data warehouse. I think the reality is that you're going to have shadow pipelines everywhere and there are going to be people that want to connect directly or that maybe just like the experience of doing it in SQL through Claude. I think that the question is sort of how and when do you optimize? Because there's a world where people want universal semantics. People have tried to do headless semantic layers and things like that and sort of we can be a headless semantic layer. The reality is even if you go try to build something headless, there are going to be people that connect to the warehouse below the headless semantic layer and go do things. So the challenge becomes how much do you encode in transformation in the warehouse via something like dbt or how much is done sort of down the pipeline at query time. Our goal is to just create as good a process for creating context as we possibly can and then have it live wherever you think it should live. So I think the warehouses should probably develop really clean standards for how context, AI context lives alongside data that doesn't exist right now. You can go shove descriptions in the warehouse, but it is sort of lowest common denominator. You're working with tables. I think that we can build much more nuanced tools and systems and skills and things like that that get closer to the business. It's always going to come down to where the users want to do work. And so our view is that we just need to fight to create as good a service as we possibly can that answers questions and then we need to go interface with other things that exist. So I hope that we could become the layer like, I don't know if you saw the Claude post. The Anthropic team wrote about how they're doing data analytics. They're using semantics, but if you read it in a nuanced way, they ask the AI to write using the semantic layer and if it feels like it can't, it bails out and writes SQL. And I think that these trade offs that look sort of small there are probably unacceptable in lots of different use cases. And people are going to need a system that has more nuance that they can't just throw tokens at to solve. So we're just trying to build something that can answer questions really, really, really well with a lot of precision and hopefully that solves the problem well enough that we can sort of expand into every type of use case. You have one last element that I wanted to talk about was maybe to have your vision on what the data team could look like in the future. You said that you're pretty sure that there will always be central data team. It will be smaller, but the team will still exist. What roles do you see in this team? So there is the analytics engineer. We said all the maintaining the model development is way easier, but it will still need to be done by someone. Will it be the same type of analytics engineer? And you said also that actually there will still be a data analyst. It's just that they are going to be closer to the business or maybe building more like a custom dashboards, but their role will change a bit as well. Like they're like elements you can share. So I mean, I think the things that seem obvious are dashboard building gets easier to do. So data analysts move from dashboard builders to business intelligence like actual analysts. So like I think in that sense like the report creators can level up pretty significantly. I think that analytics engineering just gets way more efficient. I think we need fewer people that have to go build tables and write SQL. We can have AI take a first cut and the person becomes a reviewer. So in the same way that sort of software engineers have become a lot more efficient, I think data engineers become a lot more efficient. I think the net of both of those is that people that can do a lot of different things at the same time become a lot more valuable. So a team that might have had two analytics engineers at a hundred maybe can have one now and that person can do even more things. And I think that is probably the biggest sort of leverage point that I see is just these people can get a lot more efficient. I think the other thing is the data teams that can take ownership over how AI is operationalized can create significant leverage inside an organization. They can just create a lot of value. So there is no such thing as a context Engineer or an AI advisor really right now. But at the same time OpenAI is hiring thousands of forward deployed engineers. Those people look a lot like data people and it's because they're really good at stemming together. Like where's data coming from? How does it get mapped into business use cases? And ultimately how does that turn into an application that solves a problem? I think those are things that data teams can take over. So the net is, I'm not even sure the team shrinks over time. It's just that it moves a lot more towards like AI shepherding and the sort of rote work that we need to do. So laying out pixels on a dashboard or writing SQL, we get a lot of efficiency. Thank you Colin for joining the podcast and sharing your predictions on the future of analytics. This was really insightful. Let us know in the comments what you thought about this episode and don't hesitate to comment on the LinkedIn post that Colin and I will share when the episode goes live. And yeah, that's it. Thanks again, Khalil. Yeah, thanks for having me. Thanks for listening. Before you go, I have a small favor to ask. Please leave a five star rating and a review on Apple Podcast. It really helps the show grow and attract amazing guests.