TDSS Ep 94: Notebooks Aren’t Just for Data Scientists With Barry McCardel

We are talking to Barry, who, uh, co-founded a company called Hex. They're in the analytics space. And this is my burning question. So, you know, you have Looker acquired by Google, you have Tableau acquired by Salesforce. Periscope, someone bought Periscope, right?

No, they merged with, yeah, I mean acquired by Sisense, but yeah, you can.

Sure, Amplitude went public. Like, so there's, you know, in some ways it's like you can sort of see like industry movement like that and it can feel like, wow, okay, sort of the core analytics problems, you know, have been solved at a massive enterprise scale. Great, check, like let's sort of move on. Um, but my strong sense is that that is not how Barry feels, and I think that he is going to help us understand, like, what innovation is happening now and will happen in the future with analytics. So I want to get his take on that, like, what parts have actually been solved, um, and then where are we in early innings. So that's what I'm going to ask. How about you?

Yeah, I mean, I don't know. I think one of the things that's we should learn from, uh, when it comes like to, um, technology and this industry is that everything happens in cycles and whatever has been invented gets reinvented, right? Probably that's one of the mistakes that IBM did. Like, you know, they came up like with all these huge servers and they were like, okay, like we solved the problem, right? And now today you have AWS and like Azure and like, um, cloud computing, and suddenly even infrastructure got reinvented, right? And probably we are also like, even there we are entering another cycle of innovation. But anyway, uh, I think it's, um, it's a very interesting time because, uh, yeah, like as you said, uh, this market hasn't— like the BI market, the visualization market hasn't like produced any innovation for a while now. And when we say a while, we are mean talk about like 2 or 3 years, like more than that, right? But that's a long time when it comes to technology. So I'm very excited that we have Barry today because I think we are going to see what's next in this space. And we will learn more about the product that they're building, which is going to be— which is a very good example of what's next. In this space. So let's go and talk with him.

Let's do it. Barry, welcome to the Data Stack Show. We are super excited to chat with you.

Thanks for having me. Okay.

Uh, give us your background and, uh, tell us a little bit about Hex.

Yeah. So, uh, my background, um, I'm Barry, the co-founder and CEO of Hex. I have been working in and around data basically my whole career. In undergrad, I kind of stumbled into some really interesting research around social networks and was doing stuff both in spreadsheets and then like R. This was sort of like before data science was really a thing. I went into consulting and I was doing like dark, unholy things in spreadsheets. So I was building like whole data apps in Excel, like, you know, data tab by tab, data transformations. Dropdown interfaces, and I was writing like VBA to build UIs.

That is deep and dark.

Illicit access databases at PC towers I pilfered at clients to run a database. So a major US airline had a lot of their pricing and Wi-Fi maintenance infrastructure running off of a spreadsheet I made, which is horrifying. Every time I fly that airline, I wonder if they've migrated from it yet. And then I went to Palantir And I was there for about 5 years. And that was really an opportunity for me to sort of like do that type of stuff I was really enjoying around data analysis and data, you know, building different apps with data, sort of in the big leagues. And I was there through a really interesting time, like 2013 through 2018, around like the really emergence of a bunch of things that we, I think, almost take for granted around like, really working with large-scale data. You know, big data was the buzzword, data science as a discipline, and a lot of technologies that were emerging that are now quite widely adopted, like Spark, HDFS, even just AWS in general and the possibilities of the cloud. So it was a great time to be there, and I got to build a very— a lot of very interesting technologies. And I also met a bunch of folks that I'm working with now, including both my co-founders. Um, after that, I went to a healthcare startup in New York And that was really the acute moment for Hex where, you know, we had this problem. We had a really kind of quote unquote modern data stack. We had like Redshift. I think we were using Stitch. We were early adoptees of dbt. We had Looker for BI, but we were still doing a lot of our like exploratory analysis, modeling, storytelling work in like one-off Jupyter notebooks or SQL scratchpads. And we were sharing everything through like spreadsheets and screenshots and Slack. And I actually started this journey of Hex as a buyer. Like, I was looking for a piece of software that kind of fit my picture of like the type of platform that I wish we had. And it took a few months of looking and realizing that it wasn't out there to kind of come around to this. So in a way, I think Hex is like a culmination of all these experiences I've had. It's basically the tool that I wish I had at every phase in my career. I would have used it as a user at basically every time. Every job I had had. So, you know, that's sort of the backstory. So I started the company about 2.5 years ago with Caitlin and Glenn, who I both met and worked with at Palantir. Glenn was actually my intern in 2014. We've been working together ever since. So I'm very, very fortunate to get to work with some great folks on this.

Yeah. So I'd love to hear about maybe the moment or sort of the experience of realizing like, Am I going to start a company to solve this problem? You know, because sort of going from like a vendor search to embarking on an entrepreneurial journey is a, you know, is pretty dramatic. Maybe it's a small step, but tell us about that experience and like maybe some of the circumstances surrounding it.

Yeah, sure. I mean, I, I started this like looking for software. I was like Googling a bunch of terms that I figured someone has to have built this thing. And I couldn't find it. And I wound up asking a lot of friends who were at other companies doing stuff with, you know, on data teams or whatever, like, how do you guys solve this? And everyone kind of had the same answers, which is like, we don't, we're like, we've cobbled together like a JupyterHub thing and with a bunch of other open source stuff and it's all really brittle. And, but like, it kind of does the thing and none of this felt really satisfactory. And I had just come off of 5 years at Palantir where our whole get shtick was building really great software. And so I think I kind of felt this sense of dissonance of like, wait, someone should be building this. And I had just gotten off of 5 years of enjoying building those types of things. And so I came to this pretty reluctantly. I'm not someone who was like, I set out, I want to be a founder. I just need an idea and a co-founder. It's almost like I had to get dragged into it. The stars really had to align of a problem that felt glaring that I understood, There's a clear gap. Two co-founders who by circumstance were also getting bored in the thing, their things, and wanted to do a next thing. And so, yeah, I mean, it's funny, it was a pretty dramatic turn, but it was like, it kind of just dawned on me slowly. And when we decided to jump in and do it, it felt very natural. And it felt quite organic.

Yeah, okay. And then give us just the sort of one click deeper of detail and like, what does Hex do and like what problem does it solve?

So Hex is a platform for collaborative data science and analytics. Um, I think a lot of folks can think of it as sort of an immediate replacement for workflows you might be doing in a notebook like Jupyter. Um, we bring these types of data science and exploratory analytics workflows into the cloud. We make them collaborative first. We make the outputs of these really easy to share as interactive data apps. And we make it easy to build a base of knowledge and contribute to an overall growing knowledge within a company of what's true and help influence decisions. Breaking that down a little bit, like— actually, sorry, can I retake that?

Yeah, yeah, totally. Yeah, just start from the top and they'll cut it.

Yep. Yeah, so Hex is a platform for collaborative data science and analytics. We kind of do 3 things really well. We have an online collaborative-first notebook experience where it's very easy to come in, connect to data, ask and answer questions, work together as a team. We make it very easy to share your work with anyone as an interactive data app, so it's literally just one click, or I guess it's two clicks, to go from an interesting analysis or a model you've built to something that anyone can use as sort of a published web app, whether that's a simple report or something much more complex. And then we allow the outputs of the data work to contribute to an overall base of knowledge within an organization. And we can get more into this, but we really think of the art and the science of analytics as contributing to knowledge. And that sounds a little abstract, but at the end of the day, what you're really trying to do is influence decisions and help an organization understand the world better. And we think there's some big gaps in how the great work that data people are doing every day sort of translates to knowledge. And so we've built a series of features that we think sort of contribute to that mission, and, um, we're really excited about that. Awesome.

Okay, I want to dig into that more, but before we get into some of those details, I want to zoom out a little bit And I'm going to sort of paint a picture of, I would say, two different sides of the same coin when it comes to analytics. And these are two perspectives that we've, that we've heard on the show at some point. Okay. And I'm going to intentionally sort of probably draw like make these a little bit overwrought just to make it good. But, you know, so forgive me and our listeners forgive me. But so the first side of the coin is that the analytics game is kind of, you know, it kind of reached like a zenith and like most of the hard problems have been solved, right? And whatever the reasons are for that, right? It's because of, you know, modern storage and separation of storage and compute and like flexible visualization layers and, you know, all the stuff where it's like, okay, I mean, you can do advanced analytics like way more easily than you could ever do them before, right? And so From that regard, you know, some people would say like, okay, that sort of wave is over, and like the next big wave in the data stack is things related to ML and, you know, ML workflows and all that sort of stuff, right? That's sort of the next, you know, phase of the, of the modern data, whatever you call it.

Yeah.

The other side of the coin is that is the opposite, right? It's like we're actually in early innings, right? Like the, the advances that have been made are actually just the foundation on which like the really cool stuff with analytics is now going to be possible. Um, and so we're like pretty early, right? And so one good example of that is things like the metrics layer, right? Where you're kind of now seeing this like, you know, agnostic stack-wide, you know, sort of accessible layer, right? That, that solves a lot of different problems. So anyways, I'm interested in your perspective because, you know, sort of as a, you know, longtime practitioner and now someone that is really thinking through like solving a problem with a product in the space. Like, what do you think? Is there truth in both of those?

I mean, there's some truth in there. I don't think, I think the narrative analytics sort of world is solved is very far from true. I think there are parts that have gotten way better. And for folks who have been in the world for a little while, which I've been very fortunate to be like, there's a very dramatic shift from like 10 years ago to today. In terms of organizations' ability to bring data in, even just to have their data, especially for SaaS tools or other places in their possession, have it stored at scale. Obviously, tools like a platform like Snowflake and cloud data warehouses generally have unlocked a lot there. Be able to transform and model it, and the revolution that DBT has propagated over the last few years has been very, very powerful, you know, very meaningful there. And so I think we're just at the actual beginning of the situation where a lot of organizations can claim to even have like a corpus of like clean, reliable data that people can actually go tap into at their fingertips. So, you know, from that perspective, I think we're just very clearly still in the early innings of, of that. And there's some solved problems in there, there's some problems that are still very, um, uh, far from being solved in there. When we think about a lot of the unsolved problems in the analytics world, you know, we see our customers and, and potential customers come to us, like, it is very clear that there is a lot of people who still have a lot of friction around being able to ask and answer questions of data, be able to work with data at cloud data scale. And then it's just a lot of the sort of downstream workflows of that, like, how do you collaborate on these workflows? How do you share this work with others in a way that's actually useful and usable. And so just having the data in the data warehouse is like, you know, it's a big part, but it's not like— it doesn't mean that all these downstream workflows are solved. And there's a lot of innovation happening here. I mean, you mentioned the metrics there. I think that's extremely interesting. And that sort of gets back to, you know, great, you have all the data in your warehouse, but like, is everyone looking at the same measures? Are we, are we looking at these things the same way? Are we asking and answering questions in the same way? Like, that's a very unsolved problem. And so I, I think it's a little naive to say that, like, well, you know, check the box in analytics and it's all about ML. That said, there's a lot of interesting stuff happening in ML too. And I've been part of some really interesting projects that have leaned very heavily on ML. I've also been part of projects where we tried to use a bunch of ML and found out that, like, a simple scatterplot was actually all we needed. And so I think we're in the very early innings of figuring out where ML can best be applied. I'm personally a big believer in the idea of sort of this human-computer symbiosis and this idea of, I think a lot of ML techniques can best be deployed in helping people better ask and answer questions themselves, helping them better understand. I think I have been around the block with the idea of, let's just feed all the data and the machine will tell us everything. Um, you know, if that's ever going to work, I don't think that's particularly, uh, imminent. Um, and so at Hex, I think the way we look at a lot of this is like, there's a lot of unsolved problems in analytics that we're focused on, and there are a lot of opportunities to bring, um, to make ML workflows easier and to make it easier to bring ML into analytics workflows. And that's what's exciting to us. Yeah.

Okay. I have another question on that, but I'm gonna, um, I will I will, uh, use self-control. I want to dig in on one more thing and then hand the mic over to Kostas. Could you dig in a little bit on collaboration? Because yeah, that's something that, um, it feels like a marketing term that's been used with analytics like since the beginning of analytics has, you know, where it's like finally collaborate, you know, whatever. And in reality, I think anyone who's even using like relatively modern like BI tools, it really still is like a data producer and then there's just someone downstream consuming it. Like it's still pretty hard to collaborate practically, at least in my experience. Yeah. So could you tell us what does collaboration actually mean in the, like for you at Hex? Like does that take on sort of a different form?

Yeah, we, we have two big collaborative sort of loops that we think about and focus on. So there's collaboration between two creators or two editors. And that might look like, I'm going and doing an exploratory analysis, or I'm taking a first draft of a model. I want to be able to work with you on it. And Hex is fully collaborative and multiplayer, which means it works just like a Google Doc or Figma or Notion or other types of tools like that, where you and I can both be in there at the same time. Now, the reality, the little secret about multiplayer is it's very rare that you and I are both working on the same thing at the same time. In fact, it can be quite annoying. It's nice when you need it. What we see really on the editor side is really it's about enabling review workflows. And what we'll see a lot of is doing code reviews, like, "Hey, I'll tag you in. Hey, can you go review this? You can go comment on something, give feedback on it. We can iterate on something together. Maybe you and I are passing a baton back and forth on working on something." There's also a lot of things in there around versioning, which is a sort of famously difficult problem around analytics of like, you know, how are we managing version control on this? And the joke is always, you know, most people are still doing version control for their analytics by passing around a spreadsheet that's just like incrementing, you know, V5 final in the, in the title. It's so true.

I mean, it literally is so true.

Or, or, you know, if you're very, if you're very modern and you're a data scientist, you're passing around a Jupyter Notebook with V5 final in the, in the file name. So, I mean, that was one of the first things we really wanted to tackle at Hex. So we have a great built-in version control system. It allows you to save versions. You can see a full edit history. It also supports full sync to GitHub. So we have a cleanly diffable file format that I can sync to GitHub, and we can manage the whole thing through pull requests. So again, on that sort of creator, creator, editor loop, we think we've really sort of we're well on our way to nailing it in terms of what that should really look like for individuals or teams to be able to work together on analytics and data science projects together. The other loop, and this is actually really the— was the initial focus of Hex, is the creator-consumer feedback loop. And this is not necessarily new to analytics. You mentioned like BI and the traditional BI world, you know, you can create a dashboard and send it out. What's really cool for us with Hex is we're enabling a much that sort of easy sharing for a much broader set of things. And going back a little bit, the acute pain point that brought us to Hex was we were doing a lot of work in Jupyter Notebooks and we were trying to share it. And it was incredibly frustrating. We were screenshotting charts and putting them in Google Docs, or we were rendering things as PDFs and sending them around via email. And it was like, what year is it? And So at Hex, we make it very easy to go from the notebook-type work you're doing. You can publish this as an interactive data app. It can be something simple and static, like just charts and a narrative around it. And then your consumers, your stakeholders, can comment on it directly. They can see live data, much, much better than throwing screenshots around. Or it can be something much more interactive. At Hex, it's very easy to go through and add parameters to your work. It's easy to sort of have a lot of customization on how something's going to be viewed. So we see people build dashboards. We also see people build very complex, like, workflow apps in Hacks because you got the full power of SQL and Python under the hood. And so it's very easy to sort of take that and publish that. So what you wind up seeing, and what's really exciting to us, is this, this change in how people communicate their work to their stakeholders and to the rest of the organization and the impact that work can have. And we fundamentally believe that by making it easier to share things, by making those things more useful and usable, by making them discoverable and easy to organize in a knowledge base, you can actually increase, meaningfully increase the impact that a data team can have. And that kind of is our maybe most fundamental mission. Yeah. Love it.

All right, Kostas, I've been holding the mic for too long, please.

Oh, that's fine. I mean, there were some amazing questions and answers there, so no worries. Uh, so Barry, I have like a couple of, um, questions about like the, the product itself, but before that I want to ask you something else. So you mentioned, uh, at the beginning that you've been working on Cake for like 2 and a half years now, and 2 and a half years like in the startup life is like a long time. So Yeah, can you take us through like your journey and tell us a little bit more about the people and like the things that happened, uh, from day one where you decided to, okay, now we commit to that until today, right? Uh, just to get an idea of what it takes, uh, to come to, to build something like, uh, what HEX is today, right?

Yeah. It was about 3 years ago exactly that I was in this, "Wow, gosh, why has no one solved this and what should we do?" It took a few months to go from that to actually quitting our jobs and deciding we were all in on this. I mentioned Glen. He and I were working together at the time, and for personal reasons, we were both actually going to have to move to California and find new jobs anyway. We were both following our amazing significant others who had dream jobs out here. It was easier for us, we were jumping off the ledge. Caitlin was gainfully employed, and it took a little more nudging to get her out the door, but the three of us were full-time on it in December 2019. The three of us were heads down working for the first few months, and then In March 2020, which was a very eventful month for everyone, both made our first hire, which was someone we had worked with at Palantir as a first engineer. And we had also raised the seed round. In those first few months, we had actually already built a functional prototype and actually already had a few users poking around and using it. And we're kind of well on our way to getting one of them to commit to paying. So that was enough evidence to the folks at Amplify to back us. Then the first year, I would say, really was a very small team, and we were just iterating and experimenting and throwing some things away. You mentioned it feels like a long time. That first year was very heads down, just building and trying to figure out exactly what this wanted to be. It's interesting when you're building in a space that's as crowded and with as much going on as in the data space, because you're constantly seeing other things pop up and other things happening. We felt through that whole time that we had a really clear thesis, the set of things that we were excited about that we just didn't see anyone else doing. With a product this complex, you need that, you need to stay focused, and you need to have some belief in, we are going to go build this and this will be viable. That first year was really about getting there. And then in 2021 is really when we started bringing it to market. So it was not more, much more than a year ago. It was like early 2021 that we launched the company, announced our seed, announced the product, and started taking signups for it. And so all of that to say that that 2.5-year span, it's really only the last year that we've really had the product to market and really only in the last, I don't I wouldn't even say 6 to 9 months that it's felt like a full mature sort of expression of what we had hoped it would be. And so maybe the message I would say to anyone else who's thinking of starting something is like, that beginning journey, it can feel like it's going slow and it can feel like it's taking a while, but if you're making the right investments, when they start to pay off, they will really start to pay off. And that's a really good feeling. Absolutely.

How many people, Uh, are in Hex right now?

We're about 40 people right now. Um, wow. Uh, and we're distributed all over the US and Canada.

Oh, nice. So how does it feel from your, uh, position, like from the 3 of you at the beginning being with like 40 folks today? Like, how does it feel as a founder?

It feels great. It's, it's humbling. It Daily, I'm mindful of the trust that all the stakeholders of our employees, our investors, our customers have put in our team and in me. So there's, you try not to feel that too acutely day to day, but it's a good reminder that there's some higher stakes now. But I'm extremely proud of this team. I'm kind of in disbelief every day that I get to work with such a bizarrely talented group of humans. The joy and pleasure as a founder is you get to spend your time hiring a bunch of people who are better at things than you. I can say objectively that for everything I do, there are people on the team that are better at those things than me. And now you get to have all these really smart, capable people working with you. You get to watch them go and do their best work. And I think of my job as really like, how do I set up and enable this fantastic group of people to do their best work? That's what I try to spend my time doing.

Absolutely. I think you are making like a very important observation here, and it's one of the things that we don't talk about much, like the people that have been founders, uh, is like you— this privilege that you have as a founder, things, okay, go well, uh, to work with all these like amazing people. Um, that's, that's very, very important. Uh, all right, I usually don't ask that much about, uh, like these kind of things, but I, I just realized we don't do that much and we should ask more about like, you know, like how things are happening, put like more of the life around building the product, you know, and so like experiences and the journey that like people have. And because this is also important, it's not just the technology.

So I can do a couple-minute hit about something that might be interesting from like a product building perspective. I can tee you up with a question if you're interested in it. Oh, absolutely. Okay, we're gonna do this editing thing. So maybe if you want to ask something about how did you go from that initial idea to a product that people actually wanted to use or something like that. And then I can give you my spiel and if it's interesting we can use it, if not you can throw it away.

Okay, okay, yeah, yeah, sounds good, sounds good. Okay, so let's, let's do this. So, uh, all right, Barry, how did you get from like, uh, this initial like experience and the idea that you had, like what you described with the frustration that you were going through, right? Like, uh, as a buyer at that point trying to find a solution that didn't exist, yeah, uh, to actually end up with a product that you can sell, right? Because from the idea moment to building and selling, there's like a huge gap there, right? Like, and many things need to happen. So can you take us a little bit like through this journey and so we can understand like what it takes to do that?

Yeah, I think the core of it is a philosophy that I learned at a previous job that is called commitment engineering. Which is the sort of art and science of building, going from an idea to a product someone's actually willing to pay for. And the first step is really finding a problem that's acute and that resonates with people. And for me, I just felt this problem myself and started asking people like, hey, do you also have this problem? We started writing blog posts about this problem, and specifically the problem being around like being able to share and communicate work that we're doing as data science, data scientists and analysts. And you'll find people who are interested in that problem. And then the loop we went through and the loop that I think a lot of successful companies will go through is this commitment engineering loop of where you start by saying like, hey, talking to someone about their problem. And you basically offer, like if I came back in a few weeks with the first version, like a first prototype of this, would you take 30 minutes to run through it with me? And if someone says yes, then you are now in a commitment engineering loop with them. You have asked for a commitment of their time and you've in exchange going to go do some engineering for them. And you can kind of ride this loop all the way up to getting them to pay. Like the next step might be, you know, hey, great. Thanks for the feedback on the prototype. You know, if I came back in a few weeks with the next version that addressed all of that, would you take 45 minutes and click through it with me and actually use it for real? And you keep asking for commitments. The next one might be, would you invite your team to this thing? Would you show this to your boss? Would you demo it to your whole team, or whatever it is? And then the last one is, would you pay for this? And so for us, going through that with our early users and customers was extremely effective. It let us figure out where we were barking up the right tree, where people were excited to spend more time with us and spend more time in the product, or where we were not, which is where people were like, oh, I'm busy. This is kind of how you know that like you're not doing something that's actually that exciting to them. And so, you know, that first year especially was really about just trying to find users to be in that kind of engineering loop with and build for them instead of just building in a vacuum.

Okay, that's, that's something.

I don't know if that was that interesting, but you know.

No, no, no, it's, I mean, to me at least it's very interesting because I have been in the position of like starting something from scratch and I know how hard it is and how difficult it is to get advice on how to start doing these things, right? And I mean, it's even hard to find, let's say, you know, we have models and processes and playbooks for many different things, but these are not like the stuff that you can easily find like a playbook for. So any kind of like this—

Really hard.

—advice, I think it's like super valuable.

Well, I think it also applies internally at an organization, right? Like even if you're not going to found something, you know, like start a new company and try to raise money or whatever. If you think about like an initiative that you want to take on internally, like you have internal customers, right? And I'm just thinking about, you know, projects that I've thought about trying to start, you know, whatever, even in my job now. And I love that mindset of thinking about asking for those commitments as a way, like as a litmus test, right?

Because you're validating that you're that you're on the right track, that you're thinking about the right problem, that your product's solving it, that they're excited enough about it to pay for it. And this solves for the problem that you see a lot of people, maybe most people get into, which is, I'm gonna build this in a little vacuum. I'm gonna build this thing for me. And especially for a founder like me that had a lot of personal experience, that was the user, it's very tempting to just build the thing you want. And of course there's a degree of like judgment and intuition and taste that you need to put into something. There's some bets. That you need to make. But I think a lot of people, whether they're a founder or a product manager or an engineer, often can be too slow to get into that iteration loop. Or the other mistake you'll see people make is they'll start a relationship, especially very early when you're looking for more of early customers or design partners, they'll start a relationship saying, "Hey, would you pay for this?" Well, often if you ask that at first, they're going to say no. Because the product sucks because it's early and all early products suck. Like, it's not personal, it's just your product sucks because you've only been working on it for a couple months, man. So it's like, that's where, that's where I think like getting into that iteration loop that's based on you really understanding their problem and you're asking for those commitments of their time, that's how you're going to build up to actually having a customer in those early days. And I think your point, Eric, about that being applicable for internal stuff as well is I think really Great. A lot of data people are effectively building products. I mean, we see this within Hex. People build data apps, they're shipping, and whether it's for internal use or to clients or whatever, that type of iterative process I think can serve people really, really well.

So Barry, let's go, let's talk a little bit more about the product, how it is today. Okay. So let's say I'm just landing on your landing page and I go through like the signup process? Like, what do I need to start like working with Hex? What should I bring with me to do that?

Should bring data. So we— Hex, you know, is really useful if you can connect to your underlying data sources. So whether you're using a cloud data warehouse like Snowflake or BigQuery or Redshift or Databricks, we have connectors for dozens of these now, different data sources. And actually, really, from a, from like a getting started perspective, really, if you can connect to your data, it's very quick to get going. We will have people sort of be writing their first queries within a few, few minutes of first logging in. And yeah, it's really, really all you need to bring is your data and a great attitude.

Okay, that's, that's awesome. And you mentioned notebooks. Can you take us a little bit into this. And like, first of all, tell us a few things about notebooks in general, because, um, it's not like everyone— I mean, everyone has heard probably of like a Jupyter notebook, but it doesn't mean that everyone has used one, right? Um, so tell us a little bit about the history of notebooks, why they were created, and like, like what they are. And yeah, what Hex brings that is new and maybe fixes, like, compared to, like, what notebooks were doing so far?

Yeah, of course. So notebooks, for the unfamiliar, are a format for, effectively, for coding, which is where the code is broken up into cells. So that's like chunks, and you can evaluate those cells of code independently of each other, and those cells will show you the output, the results of that. This is a form of what's called literate programming, which is a term that basically refers to a programming style where the code and the outputs and the narrative, like the explanation of it, are all sort of tied together. Notebooks really excel for workflows that are exploratory or iterative, where being able to run just that one little chunk of code instead of the whole script is really useful. You know, I'm gonna, I'm gonna try a different technique for this. I'm gonna try a different binning. I'm gonna cut this a different way. And you can sort of do that and immediately see that output. Which is really great for iterating through things you're working on. But notebooks also have a lot of problems. And there's this famous set of critiques about notebooks. There was a talk that Joel Groose gave at JupyterCon 2018 that was called I Don't Like Notebooks. It was a bold thing to go do at JupyterCon. But effectively, he was sort of calling out, rightly, a lot of the issues notebooks have, specifically around state. And because the cells are broken up into these different chunks of code, you can actually run these out of order. And they're running through an in-memory kernel, which stores state. So if I have a cell that says x 1, and my next cell says x 2, if I run them in order, x in memory will be assigned to 2. But if I run them out of order, then all of a sudden, maybe it's 1, maybe it's 2. Which cell did I run last? So without going too deep in that, you can wind up in these really weird spots where you have inconsistent state. And this causes 3 big problems. There's a problem around reproducibility, which is if I want to go rerun this, am I going to get the same results? Notebooks are notoriously difficult to make reproducible. It has problems for interpretability, which is notebooks can often, I think, be very hard to know what's going on. The code's broken up into a bunch of different places and maybe it was run out of order. So like, how does this thing even work? I've had this for going back and looking at notebooks I've made myself, you know, months later, like, what does this thing even do? But it's also true, you know, if you're trying to collaborate on a notebook, like being able to understand what's going on is really important. And then the last thing is performance. The way that a lot of people wind up solving this is just constantly restarting and running all, like just run all the code again, top to bottom, basically like a script. Which is very high overhead. There's also other— so that's all the problems around state with notebooks. There's also a couple other big problems with the way notebooks have traditionally worked, which is one is scale, which are traditionally run in in-memory kernels, which is great if your data fits in memory. It's very fast and snappy, but it's awful if your memory— if your data is bigger than that. And in this cloud data era, we are in a time when people are storing terabytes of data in cloud data warehouses, and that in-memory model does not always scale very elegantly. And then finally, I think there's a problem around accessibility. Um, Costas, you mentioned like there's a lot of people who have heard of notebooks but might not have used them. A lot of times that's because they're very hard to use. Like you have to like both understand these state and scale issues. You also traditionally had to be able to like install a Jupyter Python environment locally and then install Jupyter and you're doing package management, environment management, and you're trying to roll your own data connections using SQLAlchemy. And the whole thing was very messy and very difficult to to use. And you'll often see like a new data scientist start at a company and they've like a lost first 2 weeks just trying to get all this working. And so it's no wonder that there's millions of people working in data every day who haven't traditionally been able to access these workflows. So that's sort of the background that we walked into this with. We've been longtime notebook users and I've used them for, for years and years and sort of very familiar with all these problems. And I think at least part of what we came at Hex with was, what if we fix those things? I think a lot of people look at notebooks, they look at all these problems, they're like, well, we should get rid of notebooks and everyone should be writing things as like scripts or whatever. And we kind of came at it from a different angle. We were like, no, this is stable. We can build a really good version of this because this format actually rocks. And so I don't call Hex like a notebook company, but I think at the core is that we've built a really amazing experience around this, this notebook concept. And there's a few parts of that. So one, we've— I mentioned this earlier, but we made them fully collaborative, online hosted. So no more setups, one-click, create a new notebook. We've managed the environment for you. It's very, very easy to get started. It's very easy to connect to data. So we have built-in SQL cells. We're really kind of the first to do this where it's very easy to set up a data connection. You can write SQL right in your notebook, immediately visualize your outputs. In Hex, you can actually go back and forth between SQL and Python or just work in one or the other. So We actually sort of open it up to this universe of people who are SQL-first users or SQL literate and maybe haven't necessarily learned Python. And then around that state issue, we had a pretty big innovation here around what we call a fully reactive execution model. And that is where each cell in the notebook is treated as effectively as a node in a DAG. So folks will be familiar with DAGs from a lot of tools at the, um, uh, you know, ETL and orchestration layers like Dagster, Airflow, dbt, which are all sort of built around a DAG concept. We bring that concept to notebooks and we say each cell is really just a node, and variables that are referenced between cells— so like x 1, if I'm referencing x in another cell, that's a link, then it's an edge between those cells. By modeling a notebook this way and by turning it into something reactive, which means if you modify one node, only the downstream nodes update, you actually get a lot of advantages. And it solves those three problems I mentioned. It is much, much easier to reason about the state. And so your state is always in a consistent, clean place, and it's reproducible. So it solves that problem. If you run something, it's always going to run the same way. It's more interpretable. We have a nice DAG UI in Hex where you can actually see your full flow of your logic in your project, which makes it very easy to literally visually see what's going on. And it's way more performant. You don't have to restart and run all the kernel every time. You can just change one cell and only the things that need to be updated will be. So this was a lot of hard engineering work at the back end and the front end that went into this, but the net result is a product that really solves a lot of these problems around notebooks. It's also just much more interpretable and accessible to a big population of people. It's very, very interesting, very interesting that a lot of our customers, most of the users, were not using Jupyter before. These are people who were using SQL scratchpads, or, you know, they were trying to do their work in a BI tool or a spreadsheet. They don't even have a baseline of understanding how Hex is better than Jupyter. They just know Hex is great and I like it. And so, you know, we— that was really always part of the mission for us is like opening up access to these workflows to a bigger group of people. And it's very cool to see how we've been able to bring the great parts about notebooks to, um, like a 10x bigger audience than could have taken advantage of them before.

Yeah, absolutely. So if I understand correctly, and that's also like, okay, my, uh, like the perception that I had about notebooks, they used to be like a tool mainly for data scientists, or let's say not a tool for data analysts. Okay, like you had the data analyst who was mainly working in the BI tool And then you have more niche use cases with data scientists or like some other like people that were using like notebooks. Uh, and you mentioned that you see like a change there, like more and more people, uh, that didn't have access to that, they are using it now, uh, like through Hex. So who is like the typical user today? That's one question that I have. And the second question is How does Hex fit in an organization compared to more traditional, let's say, data visualization, let's say BI tools in general, like Tableau, like, and the rest, right? Yeah.

So it's really interesting what you mentioned of like notebooks were traditionally just for data scientists. It's kind of worth asking why. And I think there's this sort of baseline problem that we see at a lot of places where like, there's these tools and it's like, depending on what you're doing and what language you're in, you're jumping between different tools. You've got people who are just working in spreadsheets. You've got people who are in no-code BI tools. You have people who are on like SQL scratchpads or SQL IDEs. And then you've got people over in notebooks and it's kind of these like artificial barriers just based on like, do you know a certain language or can you get like a Python environment working locally? I don't think there's anything about the notebook format that makes it like uniquely useful for only people who are doing modeling. In fact, I think notebooks are probably even more useful for a lot of like exploratory analytics workflows, they just weren't available to people because super high overhead, hard to get started, and really only worked if you were working primarily in Python, which, you know, is very widely known but not nearly as widely known as SQL in the analytics world. So I think just in the first instance, like, we came at this and looked at this as like, wow, notebooks should just be able to be used by a lot more people. And so when you ask about the core users that we see At Hex, we have a ton, maybe most, we don't have job titles for everyone, but like when we just empirically talk to users or customers, like SQL-first data analysts are a huge, huge part of our user base. They get a ton of utility out of Hex. In fact, it's awesome to be able to do SQL work in Hex. 'Cause one amazing thing is like you can do SQL on SQL. Like you can, we call it chained SQL or in Hex it's called DataFrame SQL. Really just means you can have one SQL query and another SQL query that queries the results of it. And for the SQL heads out there, this is effectively what you might do if you're using like CTEs, like a with as statement. In Hex, instead of writing like a 3-page long CTE, you can break this up into cells. You can actually see the results of each step. You can have them chained together. So it's much more elegant, much more powerful. And so there's all sorts of great things we've been able to bring to that sort of like analytics workflow that has nothing to do with like ML modeling or I think what traditionally got labeled as quote unquote data science. And so that's very, very cool for us to see. On the other hand, people who are Jupyter users, people who are Pythonistas who spend their day building models in Jupyter, Hex is familiar and powerful. It has all the best things about notebooks. We fixed a lot of the problems. So at Hex, we really think of the product as this low floor, high ceiling product that should be accessible to a much bigger population of people, but not artificially constrain you, which is what you've seen in the last generation of products and why you have that 5 different tools and you're jumping between them. It's either low floor, low ceiling, or high floor, high ceiling. With Hex, we really think that people should be able to collaborate between these personas and these workloads in a much more seamless way. So to the second part of your question about where it fits in, At most of our customers, we are deployed alongside or are very complementary to a traditional BI tool like Tableau or Looker. These are products that have, I think, a pretty specific and well-understood mission around like, I want to build some point-and-click dashboards that people can go and look at once a week, or I want to, you know, maybe there's a bigger population of non- quote-unquote non-technical people, non-data people who want to be able to go point-and-click and look at some metrics. Those workflows are important, they have their place, but if you go talk to most folks who are, you know, data analysts or data scientists, or even just much broader population of people who are just data literate, they're not actually spending their days in those BI tools. They're spending their days in notebooks or SQL IDEs, or in many cases winding up back in spreadsheets where they're dumping data out because these BI tools are really not built for deep exploratory workflows. They're not built for the type of flexible off-the-road, off-roading analysis that a lot of people are looking to do, and they're certainly not built for what you would traditionally think of as data science. And so, um, Hex really fits a big gap alongside these. Now what we see at most of our customers is we— alongside these, there's a lot of workflows that used to wind up in BI, they were kind of shoehorned into BI, that now can live much more natively in Hex. So I don't think of us as competing with traditional BI, but But we do wind up having a bunch of workflows move over and in some ways take some pressure off those tools to be like the everything to everybody. I mean, what you'll see a lot of people do is like, you know, Tableau or whatever. It's like the only way I can build a chart that I can like share and give to other people to visualize. So they'll have these really contrived workflows, like getting data into a chart in Tableau so they can just have a UI on it. Hex is a much better native way to do a lot of the things those people are trying to do. So at least today they're very complementary.

Okay, that's, that's super interesting. Uh, I'd love to hear from you also, what do you think about the future though? Because the BI market is— I mean, after like the acquisition of Looker, like we haven't seen like that much things happening there. There was like consolidation happening, we had like Yep. Sisense and Periscope Data, like getting together, which was interesting also because you had a tool, Periscope Data, primarily used by more, let's say, data science people merging with more of a BI and trying like to—

We have a lot of ex-Periscope customers and team members now at Hex. So yeah, I'm very familiar.

Yeah. Yeah. So how do you see the future and like, do you feel like Hex is part of a new wave of innovation?

Yeah, absolutely. Absolutely. We see ourselves as very, very much part of that. I think I wonder sometimes how useful the term BI even is. It's like, it's either extremely broad and it encompasses everything that's, you know, a chart, or, you know, you can also prescribe it a little more narrowly and be like, it's referring to a class of like reporting dashboard tools like Tableau and Looker. Either way, I think we're coming into a very dynamic new phase with a lot of upheaval. And there's a couple of really interesting trends here. One, I think you're just seeing a much, much broader set of people who are what I would call analytically technical or data literate, where they can think about data in more sophisticated ways. They can reason about tables and relationships between things. They, in most cases, can actually write SQL. And we see this not just with quote unquote data people, but We have a lot of Hex users who are PMs or marketers or salespeople. We see all sorts of different personas using Hex. So this population is really growing quite fast, and these are people for whom a lot of the work they want to do just does not fit well in that traditional BI paradigm. Second, there's these bigger secular trends we've seen, one being the advent of like the cloud data warehouses allowing data to be available at these bigger scales. I think there's a new set of assumptions around what analytics tools that fully embrace that look like. And then I think depending on who you're talking to, it's called the metrics layer or the semantic layer or something. But there's almost disaggregation of BI and unbundling of BI that seems to be happening, where BI that traditionally included both the visualization layer and the metrics and modeling layer sort of coming apart, and there's companies like Transform and dbt and others that are really looking to sort of have that metrics layer either be standalone or integrated into the bigger data transformation pipeline. I think that's going to actually have a lot of big downstream effects. And, you know, we partner very closely with the folks at dbt and the folks at Transform, and Hex has integrations with both of them. I think when, as you see this part of the stack come to fruition, I think we're going to see a lot of interesting things happen. And candidly, like, I think it has implications for our product where, um, you know, you can imagine being able to, in a Hex project, in a Hex notebook, effectively be able to have the first cell, instead of it needing to be a SQL query or pulling some data in via Python, it could be a metrics cell where you're able to pull in data from, um, one of these sources and start working with it downstream. At that point, what is the line between that and BI? What does this mean for BI and how these different layers of the stack are configured? I think there's a lot of interesting questions. And we have a lot of ideas on where this goes. And so we're very excited about the next chapter of this. And we're very focused on a bunch of the things we want to go build around that over the next few months.

Awesome, and I'm looking forward to see what you are going to be releasing the next couple of months. Uh, all right, I have monopolized the conversation, so I think I need to give some time and space also to Eric because I see him, he, he, he has questions that he wants to ask.

So Eric, all yours. Well, I'm controlling the recording, so we can go long, which is, which is always super exciting, uh, when Brooks is away. Um, I like— I'd like to cover one last subject. So Barry, we've been talking about analytics and ML as, uh, sort of two distinct, you know, separate workflows, separate teams even in many ways. Like you were talking about Hex users, right, and saying, well, you know, a lot of our users like hadn't ever even used notebooks before, right? Um, maybe most of them at this point, which is super interesting. And so I agree, like if you think about the discipline of, you know, analytics, um, and like building ML models, like they are distinct, right? Um, like they're— there's overlap, right? But like even sort of the workflows and, you know, a number of other things like that, right? But how much crossover are you seeing, right? So if you think about building an ML model, like a huge part of that workflow is getting the data right in order to be able to actually build a model, right? I mean, that's, you, you sort of have to have that as a starting point, right? And so if you think about traditional BI, you're sort of prepping data to show up in a dashboard in Looker or Tableau, and great, right? People can click around and sort of learn with want to learn. But the way that you're talking about people building analytics workflows, you— it's like you're— there's like, it's bleeding over heavily into like, okay, well, you're basically, you know, halfway there to sort of doing the work, the workflow that's required for model building as well. So it was, it was really interesting for me to hear that like a lot of you just hadn't used notebooks. So two questions: do you think that that Venn diagram will have increasing overlap over time? And then two, do you think that's a good thing? Like, is that something that you want or even are building like into Hex?

Yeah, so, well, that's an awesome question. There's a lot there. I would say I've got a general philosophy of like, I do think there are two distinct parts. And when we talk about like the data world at large, of analytics and then ML engineering, like I think with analytics, your deliverable, your end result, your job to be done is like you want to influence a decision. Like you're, you're going to try to find, ask and answer some question, and you want the results, the answer to that question, to influence a decision. And at Hex, we kind of have a bigger picture of that. We say, you know, you're trying to contribute to knowledge. Like how does your organization know what's true and then be able to make decisions based on that. That is kind of fundamentally the story of analytics. And it's important and it's big. And there's a lot of people who do that every day. And I think that's just going to become more part of the firmament of how everyone does their job. On the other side, you see ML engineering and the deliverable there is like a trained model. It's like a prediction. It's like a, often it's like an endpoint. You know, you see a lot of ML models being developed to be able to run online where it's like a real-time fraud prediction score, or it's Sure. Something like that. That is a very different world. It's a very different tool chain. And you know, there's a lot of really interesting stuff over in that side of the camp around model training and hyperparameter tuning and ML ops and deployment and monitoring and understanding drift and scaling models up. And there's all sorts of really interesting stuff over there. Now, you know, clearly these two camps share some firmament, like you're You're, you know, in both cases you're using data in them. You're probably sharing data infrastructure, maybe the data in both cases coming out of a warehouse, maybe you're using something like a DBT to do the data prep and transformation for both of them. But I really do feel like these are separate workflows. And one interesting point here is like, you know, this title data scientist, I think has often been like conflated or maybe spans both of these. But I think if you talk to like 10 data scientists, I think like 7 of them are really doing analytics and they might be doing like very statistically rigorous analytics. They might be doing, bringing interesting predictive techniques in analytics, but fundamentally they're there to help influence a decision. And I think the people who are doing more of the ML engineering, I think are actually just starting to call themselves ML engineers actually. And their workflows wind up looking a lot more like the software engineers workflows. So this is sort of a macro theme of where I see this is going. Now, it is true that in analytics, I think there are really interesting opportunities to bring ML techniques into analytics, but that doesn't mean that it's converging with ML engineering. And I think, as you were alluding to, in ML engineering workflows, often the early parts of those workflows are doing some analytics to understand the data, whether it's understanding maybe a problem that exists that you want to solve with your model, or, uh, to do data prep and understand it. So we do see a lot of ML engineers use Hex in that phase of their work, but it has not been a focus of ours at Hex to like go into like a full-stack ML platform. Like there are a bunch of really great tools, whether it's MLflow and Weights and Biases or all sorts of other things that are really built around that. And so, um, these, these worlds have some connectivity, but I think it It is important to understand where you're focused and as a product where you want to succeed. Hex, we are all in on analytics. We think that's a huge market. We think it's, um, has a lot of unsolved problems. And, um, I'm very proud of having built a product that is just, I think, really accelerating and improving the analytics workflows of thousands of people every day now.

So yeah, I think that's a super helpful distinction. Between sort of statistically rigorous analytics. Um, yeah, and I would say maybe like another way to rephrase what you were saying is like actually delivering a model or like the results of the model as an experience, right? Because in order to actually take that and like deliver it as part of whatever's hap— like a recommendation on a website or whatever, like it is software engineering, right? Like you're, you're having to like deliver like a, literally there's like a development lifecycle and a lot of software infrastructure required to actually take that and like deliver. Yeah. These people are typically using IDEs.

They're deploying their code through the STLC. They're running CI/CD. There's a whole world in model, ML Ops now around deployment and monitoring. And like, it's got its own. Similar and parallel world as like DevOps. Yeah. Now, I do think there's some really interesting opportunities to bring software engineering best practices to analytics. And I think we've seen this in the sort of like a lot of things being defined as code movement. I think one of the best parts of GPT, in my estimation, is that, you know, you manage everything through pull requests, and it's all code. And like, there's a lot of great things there. But that, that's, that's separate to me than the story of how ML engineering is really sort of becoming much more of a software engineering discipline. Yeah, super helpful distinction.

Okay, last question for you, and this will be a little bit unfair. I love doing this. Uh, so outside of like signing up for Hex and, you know, sort of making a lot of the analytics workflows easier for our listeners who work on analytics, you know, or work on sort of data engineering workflows or data teams, you know, that are part of, you know, analytics workflows, If you could give them sort of one piece of advice, maybe especially the ones who are earlier in their career, you know, as a practitioner who's now building a product and sort of serving people, you have a unique perspective on that. And so, and maybe you could, you could give a couple pieces of advice because just one is, is kind of tough.

But I do have, I have one big piece of advice I think is really important. You know, at Hex, we think a lot about helping data teams have more impact. And this kind of shows up a lot where you'll, if you know, if you're sort of in the data community, you'll often hear people ask like, how do I think about the ROI of my data team? You know, and like, as if it's some exercise that, you know, I need to go be able to plug a bunch of numbers in and calculate, you know, the profitability our data team produces. And, you know, companies are investing a lot in their data teams. They're buying tools like Hex and they're hiring really smart expensive people, data scientists and data analysts. And so that's sort of a natural question. And I think, actually, can I take this from the top? Sorry, my answer—

Absolutely. Yeah.

Got some more clarity as I went. Yeah, totally. Go for it. Yeah, well, I actually, I do have sort of one big piece of advice that I keep coming back to. And it's, at Hex, we think a lot about how data teams could be more impactful. Companies are investing a lot of money in their data teams. They want to be able to get some impact out of that. They want to make sure it's moving the needle. And you'll see this show up a lot where people ask, you know, like, what's the ROI of a data team? Or what's the ROI of a data scientist? As if that's something that can just go be like penciled out. And you know, you'll get into these weird exercises where you're like, well, we built this model or we built these 5 dashboards and they, We think they helped do this thing 10% better.

And that's— and it's like you need the data scientist to answer the question about the ROI of the data scientist. Self-quantifying. Yeah.

And like, really, I think this is kind of— I understand why it happens, but it's kind of silly. And so my big piece of advice to people who are on data teams or starting data teams or running data teams is the way that you're actually going to feel that impact is if your data team is embedded and aligned with the actual functional people. In the business. I think the last thing you want to do is set up an ivory tower. They just sit together, they only talk to themselves, they're off doing sort of like R&D, and, you know, the results and the things they're building aren't necessarily influencing decisions. And so we built this model and it has this prediction, and what was the impact of it? Well, you know, it would be this. And you get that a lot with, with folks, and I think I think personally, this is kind of an org chart thing. But I think like, folks on data teams should be really closely aligned. I think they should be planning their work. And they should be embedded with teams. And I just even gets down to like how you're setting like things like OKRs and goals. Like, I kind of don't believe that data teams should have big sets of their own OKRs. I think that individuals on data teams should be accountable for OKRs and sharing OKRs with folks on marketing or ops or product or or sales. And I think if you do that, when you're asked about the ROI of your data team, you as the data head of data or the data scientist or data practitioner don't have to go and try to pencil it out. You can redirect that person to those stakeholders. Because if you're doing a good— if you're doing your job well, the VP marketing or the product manager, the head of ops should be the one standing up and saying Oh no, there's— we couldn't have done this without the data. Yeah, we couldn't have done this without Amanda embedded with us. This was a huge part of our ability to go and solve this. That in fact, you should have those stakeholders advocating for you to have more headcount. Um, and so I think that's really important. I think it gets lost when people are doing a lot of data work is like, you know, how is this actually going to get used? Is this actually going to move the needle? And is the work that I'm doing closely aligned with the needs of the business? It's such an important thing, and I would encourage people to really just stay focused on that. And, you know, Hex, we have some small part of that. I think we, we help make that data work more useful and usable and easier to share. I think we can help influence that, but I think, um, it really needs to start with how you're thinking about the role of your data team and how it's organized within the company.

Love it. Amazing advice. All right, well, we are over time, uh, sorry Brooks, uh, but Barry, this has been an incredible conversation.

Yeah, I know, I really thank you enough. It was my pleasure. Well, sorry, I should say it was my pleasure. Thanks for having me on and really enjoy the show and hope folks enjoy the episode. Awesome. Cool. Yeah, I know I ran long on a few things. Sorry. It was great. I hope you guys will chop judiciously. Yeah, no, it'll be fine.

We actually had someone tell us recently, they were like, you should run the show even longer, like just, you know, an hour and a half, 2 hours. And we're like, woof. That's a big time investment. I don't know if we can do that.

Well, I hope it was interesting. Oh, it was so good. Good. I'm glad to hear that. Thank you. Cool. Well, thanks for having me on, guys. I'm excited to hear the episode and we'll talk more in a month or two when it's queued up. Yeah. Sounds good.

Thank you so much, Barry. It was great chatting about all that stuff, to be honest. Like very interesting perspective on things.

Well, thanks for the great questions. Okay, I'll see y'all. Bye. Cheers.

Costas, my big takeaway— well, there's so many actually. Um, I'm gonna actually show, because I've already broken so many rules with BrooksCon, I'm gonna actually have some self-control here and only have one takeaway. Um, so the commentary around the distinctions between work in analytics and work in ML was really helpful. And even though we didn't talk about that for a super long time, but I thought it was really helpful how he pointed out that, um, in many ways, you know, I think he said 7 out of 10 data scientists, if you talk to them about what they do, you could really roll a lot of that into actually like analytics work. You know, and it may even be predictive analytics, but it really sort of falls on the analytics side of the house. And that was just very helpful as you sort of look out at the landscape and job titles and all the gray areas and crossover. I just thought that was a really, really helpful perspective. How about you?

I think it's pretty hard for me to come up with just one thing that I'm going to keep from this conversation. Overall, it was like a great conversation. We talked about, like, first of all, the advice around building a product at an early stage. That was great. We talked a lot about notebooks, and like, when I— hopefully, like, people, more and more people out there will hear about them and give them a try. It is a very interesting, let's say, computation model. And companies like Hex really innovate on them and make them more accessible. And we should be able to consume data in a more exploratory and narrative way, right? And that's great. That's something that is missing from the BI tools out there. And yeah, that was great. And also, all the conversations that we had around BI, and the next wave of innovation there. So yeah, I'm really looking forward to have Barry again on another episode in a couple of months and get even deeper into these questions and chat more about visualization and data platform, notebooks, and BI.

Absolutely. All right, well, thanks for joining us again on the Data Stack Show, and we will catch you on the next one.