The Data Stack Show - 143: Collaborative Data Analytics on the Data Warehouse, featuring Rob Woollen & Stipo Josipovic of Sigma

Episode Date: June 21, 2023

Highlights from this week’s conversation include:Stipo and Rob’s background in data (2:43)What is Sigma? (7:46)Takeaways from building analytics products in-house (9:16)Sigma’s approach to datastore interface (11:32)Why analytics and BI are still not a solved problem (15:50)Combining SQL and spreadsheets for useful interface (23:17)The evolution of BI to today (29:40)Overcoming the challenges of collaboration in working with data (33:17)Creating operational coding that humans can understand (46:50)The future of BI (54:00)Cloud’s impact on BI and analytics (1:00:04)The value of getting close to the data for analytics (1:02:21)Final thoughts and takeaways (1:08:45)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Welcome to the Data Stack Show. Each week, we explore the world of data by talking to the people shaping its future. You'll learn about new data technology and trends and how data teams and processes are run at top companies. The Data Stack Show is brought to you by Rudderstack, the CDP for developers. You can learn more at rudderstack.com. Costas, I, you know, we've talked with a lot of database companies on the show, but I love talking with analytics companies just because it seems like both databases and analytics tools are so pervasive and seem to actually be proliferating at a pretty high rate.

And so today we're going to talk with Sigma, and they have a fascinating approach to analytics, sort of a spreadsheet and SQL focus. So we're going to talk with Sipo and Rob. Sipo's from the product side, Rob is CTO and co-founder. And I have so many questions. I mean, number one, spreadsheet and SQL, you know, the two fundamental tools for analytics, like why build a tool that is a spreadsheet and SQL, you know, I mean, that's going to be fascinating to hear.

But they also have an interesting story. They sort of came of age right on the heels of Snowflake, sort of out of the same group. I think that'll be really interesting to ask about. So yeah, I think those are the things that I'm going to ask about. How about you? Yeah, I definitely have many questions about how to bridge the spreadsheets and the relational paradigms together. I think that's part of the success of Sigma, that they might not

somehow like to do that. So one thing is to understand how they did it. What is left out there, because I'm sure that there is still work to be done. These are two of the foundations of working with data that usually don't overlap. Each one has its own pros and cons. There's a reason that we have both and we don't have only one, right? Yeah. And I'd love to hear both the product and the technology story behind it,

because there's very different challenges there, right? And I think we have the right people to do that. It's one of these also rare occasions where we have both product and engineering representation at the same time, so we can ask the same question from a different angle and see the differences in perspective. So we're definitely going to spend a lot of time on that. All right. Well, let's dig in. Let's do it.

Steepo, Rob, welcome to the Data Stack Show. We have a million questions, so very excited to get to it. But thanks for giving us some of your time. Thank you. Happy to be here. All right, Steepo, let's start with you. Give us your background. Tell us how you got into data and then ended up at Sigma. Sure. So I guess my career has been a little bit of, you know, at the time felt a little bit like jumping through Goldilocks stepping stones of

random jobs. First, starting with working in public policy, doing data analysis, to which I had a pretty strong reaction, jumping where, you know, if you've ever worked in government, you'll know how much technology is involved. And for me, it was not enough. So I made a pretty hard pivot to the next Goldilocks bowl. And I jumped into full stack engineering where I worked on, somehow ended up inadvertently working and building a internal analytics app for the company I was working for. So inadvertently to ANBI without knowing what AN After that, you know, I think my next journey was in my next step and my realization was that where I really wanted to be is not just in the processing data. And it wasn't just really sort of building the tools, the infrastructure to work with data, but it was in

decision-making itself. And so that's when I made a cut over to, to actual BI management here in San Francisco with a company called PagerDuty. So as a practitioner, then a little bit into my journey, a tiny little startup decided to reach out to me to ask what I thought about their product. And this company was Sigma. And I was the second person outside of the company to see the product. And from that first time that I saw it, they might have oversold. And so clearly, I joined as a sales engineer and transitioned over to the first product manager. And I've been doing this for about five years now. Awesome.

Okay, Rob, I have to know, were you part of the group that got early feedback from SIPO and PagerDuty? No comment. We use the word oversold, so I had to ask about that. But Rob, give us your background. Absolutely. So let's see, I've spent now, gosh, more than 25 years in enterprise software. And I've always built things that in some ways they're not finished products. They're things that other people take and build on top of or do something to build their own products with.

So I actually started my career working in the Unix kernel. I thought that was like the coolest job. I was, you know, the technology nerd and loved Unix. It ends up it really wasn't actually that interesting because it was always a lot of just like people just expect kernels to work. There's not like a lot of interesting features they want. And so I remember in like the mid 90s, I was like looking at a bus signal and trying to debug this, you know, crash. And all my friends were working on like these cool new dot com startups. And I was like, I want to go do something that sounds a lot more fun like that. So I moved up to San Francisco and I joined this company, BEA, that was building a product WebLogic. And the whole idea was really try to build kind of an operating system for the web and really sort of give developers a platform and Java at the time to build out.

I ended up spending nine years there, building that out, taking it out to be a pretty successful business. We were a multi-billion dollar business. And in about 2007, I got really excited about this idea of cloud computing. I remember talking to some friends at Salesforce and even just the idea that, you know, I left a company where I think we had 40 versions of my on-prem, you know, stack that was maintaining. And they were like, we have only one version. And that was about enough. I was like, once I heard that, I was like, I'm moving a few blocks. I'm going to work there. So I spent seven years at Salesforce building out a cloud platform for them. I spent a lot of time

there trying to think about, again, what would you need to build out a product on top of a cloud stack? In Salesforce's case, it was both, you know, their internal products, like their CRM, as well as things that third parties would try to build. And I left Salesforce then in about beginning of 2014 and joined a venture capital firm, Sutter Hill. And I left Salesforce then in about the beginning of 2014 and joined a venture capital firm, Sutter Hill. And I joined there because of a few things. One is I was crazy enough to want to go start a company. But the second is I really liked that what makes Sutter Hill different was that instead

of just like a normal VC firm trying to invest in kind of, you know, interesting pitches they see, they actually tried to start companies from scratch. And so I watched them do that very successfully. And I went and made that leap. And as part of that, they helped us found Sigma. And so we founded the company in 2014. And I've been our CTO and obviously co-founder ever since. Very cool. And could you just give us the quick, what is Sigma? Tell us what Sigma is. Absolutely. So the way I think about it is we started from this idea that people were going to move to cloud data warehouses. So we were early on seeing this transition to things like Snowflake or Google's BigQuery or Amazon Redshift. And we thought about those environments and said, what is the interface that you'd want to build on top of one of these

things? And in particular, like if you wanted to say, hey, I want everyone in my company to leverage this like massively scalable repository of data, what is the interface you'd want? And so what we built is something that lets multiple people work together, collaborate, build out very complex analysis. And the interface we chose to sort of base our product on is the idea of a spreadsheet. And so what you do in Sigma is you can build these collaborative workbooks where, say, Steepo and I could build a bunch of analysis together. We could interact live and share things back and forth. And we can write formulas. We can, you know, just like you would in sort of any of these sort of traditional spreadsheets.

But the magic of it is that everything you do in the product actually gets translated to SQL, executed against that scalable data warehouse. So you're combining all the sort of benefits of a traditional kind of centralized, like technical data warehouse with something that's actually broadly accessible and very powerful. So that was the original kind of, you know, idea and pitch and what we built out. Love it. Well, I want to return to the founding. But before we do that, Stipa, I want to go back to part of your story. So you built sort of homegrown analytics products inside of a company as sort of one of your first forays into full stack engineering. And I've never done that personally, but knowing some people who've worked on that stuff and knowing that there are companies like Sigma who literally build big companies around this.

Did you have any takeaways from that? Was there ever a point at which you said, maybe we should have bought something instead of trying to build this homegrown? Maybe I have the use case wrong. That seems to be sort of a formative experience. And so I'd love to hear about the lessons that you have taken away from that and sort of influenced the way that you think about building analytics products? I love this question so much. I've never, I never regretted that decision. And even still, you know, knowing where the market is, I still, I, you know, if I could go back in time with the same market, I, barring Sigma, you know, I would make the same decision again.

The reality is that the way that people work with data right now and with traditional BI is so limited. And the behaviors and what we needed at the time at the company that I was at was just, there's no tool that could easily support it. And in reality, it wasn't just choosing a tool. It was choosing an entire sort of infrastructure for how I needed to prepare my data to be able to work with it. So there's these like layers and layers. It wasn't just the top level of how do users interact with this. And I, at the time, as an engineer was just trying to understand how do these layers interact? What are these models that I have to think through? And if I'm having a hard time understanding how to work with this data, and I'm supposed to be the technical person doing this work, how the heck is anyone

else supposed to work with this? And so, you know, I think it's influenced a lot in how I think about the end state of where we need to go. But I also feel that all of my time working with traditional BI tools just as much has influenced that too. Love it. Rob, let's go back to, you gave us a little bit of the founding story, but Snowfl know, sort of one of the founding stories out of Sutter Hill and was in pretty close timeline wise to Sigma, right? I mean, you're talking maybe a couple of years there. What I would love for you to dig into just a little bit relative to the founding story is an interface on top of a data store is a very, that's not a new concept, right? And even when you started Sigma, that was in the enterprise, at least sort of a prevailing paradigm of how you did, you know,

business intelligence, right? It's like, okay, we have a data store and we have some sort of layer on top of that, you know, whatever. What about the existing paradigm that, you know, from a basic architectural standpoint, data store interface, what about that wasn't working? And like, what made you, I mean, really, in many ways, it kind of sounds like you're saying like, the data store is completely different. And so we need to think about the interface completely differently. Is that a good summary of the way that you were thinking about it? I did there and then stole my answer. Yeah. But I will give you a bit more color as you'd imagine.

So you're right. We were, in fact, the Snowflake team had just left Sutter Hill maybe six months to a year before I joined. My co-founder, Jason, was actually advising at Snowflake during that first year, helping them build out their optimizer. And I remember I was at Sutter Hill when Snowflake came in, I think for their Series B. They did their pitch to sort of, you know, follow up with their investors and show off the product. And I vividly remember the presentation because it was, they were showing off at the time how you could elastically scale you could drag a slider and have it you know have more CPUs or less CPUs and obviously the queries run faster or slower and from you know honestly from the podcast right now people are gonna be like yeah that just sounds like what you do right but if you rewind your

mind back to like 2014 like what people used to have to do, and sometimes I, you know, feel like the old person who has to tell people like back in my day, but back in my day, you had to go like rack servers, right? So, you know, if you wanted eight CPUs, you were like dragging stuff around and putting cables in or most likely requisitioning someone from IT to go do it. So as a technology perspective, I was sitting there like this was mind-blowing. But when I watched them demo, they literally had pages and pages of these 700-line SQL queries. And so that was where I think a lot of the status quo has been in this environment. Like the interface that people have traditionally built on top of warehouses is designed for a very small number of people.

And it's designed for a very small number of people on purpose. If you had a traditional, that traditional warehouse where it was very painful to expand it, then you'd be very protective of it. You would say like, I do not want a lot of people running queries on this. The story I'll tell you is even when I was at Salesforce back in the 2000s, we had, as you'd imagine, we had an on-premise data warehouse. And at the end of the quarter, they would have to send out things saying, please stop refreshing your reports. You know, the warehouse is getting overwhelmed.

That was just the reality of how these systems worked. When you step back and say, I have something where I can actually scale it out, I can partition resources, I can make all these decisions about how I want to manage the workloads. That's when I think you really start thinking about how do I want to redesign the interface? And that was the fundamental sort of technology that inspired us to start that whole journey from over again. We were, of course, fortunate that we were there to see these. We were at the same VC firm. We saw the early work. We knew the founding team there. And so we had sort of an early bird's eye view into that change.

Sure. Well, I mean, that's the wonderful thing about Silicon Valley, right? Is that, you know, technologies can sort of emerge together. So Rob, that's super interesting. You know, at the time, you know, 2014, so almost a decade ago, some people might have said like, well, sort of the insights that you need, you can run queries on top of a data store, and you can visualize it. Great. Fast forward 10 years, maybe it's even more of a solved problem now. But the market would actually suggest differently. In many ways, there are new analytics, paradigms and technologies coming out that would, in some ways, suggest like, well,

maybe we're sort of in early innings in terms of what's actually possible with analytics. So I guess this is a question for both of you. Sipo, maybe I'll start with you. Are both of those things true? Like, is BI over? Are we in the early innings of analytics? Like, give us your perspective. I guess I'd start with by saying that the BI of old is dead. And I think there's a new era. We're in the early innings of a new era. And what I mean by this is certainly we are, I think the BI tools of old did provide more access to the centralized data stores and all the power that's there and then the size of the data that's there, right? I mean, crucially, that's sort of the most important piece of what they offer, which

is at the high trade-offs that they require, which is users can't work with data that they, the way they're taught to work with data, the way they think about data, instead, they have to be limited in the ways that these tools provide. So I think that model, I think, is what's really up, is being challenged. And certainly, it's what we are challenging. The core of this is really about going back to the basics and the fundamentals rather than giving tools to people and telling them to learn the tools to answer the questions that they have the new era of bi is to give people the tools that meet them where they are right that remove

the friction because being able to answer the question is almost the least interesting thing that they can do but the most interesting thing is asking the question and being able to get to the answer. And so, and when it comes to, and being able to do that with massive amounts of data, spreadsheets were able to do that and are able to do that on small amounts of data. So, you know, there are many things that we're doing as a product right now that's trying to do this.

For example, what we've just released, which is input tables. And it's almost unremarkable in how I'm going to describe it because it also seems just so absolutely obvious. And yet it's something that BI has not been in a position to be able to provide and technology hasn't been able to provide. And input tables are very simply UI managed tables

where users can add their own data, integrate it into their analysis, join it, and then modify that data, iterate on it. And it opens up a massive world of use cases that historically BI wouldn't be able to solve. And now these use cases that were once either in spreadsheets, offline, decentralized, all the bad things about working with data in the modern times, or they would happen in centralized, specialized tools that, again, even fewer people are able to

work with and use. And so now there's this middle ground, right? And that is the platform that we are building, which is it gives you the flexibility to work with that data, restablishes that relationship that we as humans natively have with data, which is we want to be able to manipulate it. No one wants to have to think about, I want to ask a what if, and so let me figure out a feature and take 20 steps to be able to do that. Instead, what they want to do is engage with that data and modify it. And just by nature of doing that, you can forecast, right? You can analyze data that doesn't exist because, you know, the centralized data stores are not all the data that exists, right?

There's so much human context with everything that happens. And really, so what, and then on top of that, once you capture that context, there's the question of what now, right? At a certain point, when you're able to capture data through your platform, you can capture decisions. At a certain point, when you're able to capture data through your platform, you can capture decisions, which is incredible because up until now, the BI of old was the end of the pipe. You perform your analysis, you get to your insights, and then you go bugger off and try and take action on that. And it all happens in this ephemeral kind of organizational gray area that's never captured. It's very difficult to follow through on. There isn't a common understanding. And now you have this data.

Now you're capturing this exactly where you're performing your analysis. And you can capture these decisions. You can learn from them. You know what you did last quarter. You know what was effective and what wasn't. And so you have this sort of compounding effect of what analytics and BI can provide in this new world. And then on top of that, if you're already capturing your decisions, why can't you take action? Why can't instead of, you know, capturing your decision that you're going to go to X, Y, and Z place to update X, Y, and Z thing, why can't you just do it in a single platform? So when I think about going back to your question of where are we in the state of BI?

And certainly the old BI is dead. But where the future is very much about maximizing your data and being able to work with it the way that you think about working with it. Yeah. So this is just a quick, nerdy personal question on input tables. But if I understand correctly, you know, you essentially have the spreadsheet interface, but it's, you know, it's actually a table that lives in the warehouse. And you can sort of augment that. And you're interacting with that data.

And so will it actually, you know, sort of if you, whatever, if I'm running a calculation or, you know, something of that nature, will it actually push that back down into the warehouse? It's your data.

And I think this is, you know, going back to, you know, the very beginning of my, you know, to your question about the decision to build a custom app, one of the things I mentioned is just all the layers that you had to really buy into on top of the BI tool or analytics tool itself. So we sort of sit directly on top of your warehouse, and your data is your own. So input tables will write to your warehouse. We are just a simple, clean layer on top that allow you to maximize the value of what you have.

And we also, this is a pivotal moment where we're allowing you to deal with the challenges of having a centralized data store, which is very simply that everything that you need isn't always there. So yes, that's exactly the point. And so what this means is you can add your data, it gets written to your warehouse, and you then also have it available to use it anywhere else you'd need as well. We're not locking you down.

We don't have, like, we're not going to ingest your data and hold on to it. It's your data, and it's there in the warehouse for you to be able to work and join it against all the other live data that you have. Yeah. Yeah. I mean, that's incredible because I think that one of the amazing ironies of doing analytics, even in modern forward-thinking companies, it's like, okay, we're running Snowflake, we're centralizing our data and all this sort of stuff. I mean, name a company where maybe it's Sigma customers who don't do this, but where there's someone in marketing, someone in

revenue operations or something, they ask the analyst to produce a view in Snowflake and export it so that they can work on it in a spreadsheet, right? I mean, it's pervasively common, right? That is unbelievably ironic, right? It's like an anti-pattern, you know, relative to some of the promise of like centralizing your data and querying it, right? It's like, wow, we did that literally

just to like get it back out into a spreadsheet. Yeah, I think there's an old joke that BI tools had three buttons that were by far the most popular. Okay, cancel, and download to Excel. Absolutely, absolutely. Well, Rob, that actually leads me to another question. So the reason that that is one of the most popular buttons is because the spreadsheet is,

you know, an interface. Many people say, no one's ever going to kill the spreadsheet. Maybe it gets reinvented, right? But I think to your point, Sipo, it's how people ask questions. I mean, visualization, you know, that problem

was solved a long time ago. But to your point, the problem is that in order to understand what you need to visualize, you have to actually work with solved a long time ago. But to your point, the problem is that in order to understand what you need to visualize, you have to actually work with the data and ask a bunch of questions. And then like, okay, once I get there, I can visualize it. SQL is similar to the spreadsheet in that, you know, many people say, you know, no one's ever going to kill SQL. Can you talk about the thinking behind sort of combining the two most common analytical interfaces into sort of this new interface that you've built for modern data stores? I mean, to me, that's fascinating and that's brilliant.

Because to your point, Sipo, you're meeting people where they are. But can you talk about the way that you... Were those in mind when you thought about creating a new interface or was that a conclusion that you came to after, you know, doing research and talking with potential users? I'll admit to you that it was not our first idea. It took several rounds of failing, like many startups, of figuring out what was the right way to solve the problem. So we've always been trying to solve the same problem. We've always looked at it as, I have this incredible advance in cloud infrastructure.

How would I build the right interface for it? I think there was actually a big moment in sort of, like any of these things, it was a big moment that took several months to realize it was a big moment. But a lot of our first efforts, I actually think, followed a similar paradigm to what many people do with dashboards, which is they build something that they think other people want. And they basically, at some level, even though we don't always want to admit this as technologists, we think, like, I'm a little smarter than the person who's going to use this. And so I'm going to give them only very simple things for them to do, but I'm going to take care of, you know, the hard part. And the irony in all of this is like, we all step back and say, look, like, I don't really know a lot about whatever department is consuming this, but in our minds, we're still like, no, you know, I need to be the one to tell them what they need

to analyze as person X. So I think that was one of the real sort of big realizations when we went and looked at like spreadsheet users and what they actually built. Most of the time I was like, oh my God, that is like this crazily complex thing that I had no idea of, you know, I don't know anything about what these people are talking about. And I look at it and from a, you know, math or statistics or, you know, analytics perspective, I can follow it, but like the domain knowledge I don't have, I would not have known to do this analysis. And so that was a big pivot in our interface design because we stepped back and said, I want to build an interface that you can build the equivalent of any SQL query without writing code. And if you think about that challenge,

that's very different than starting and saying like, okay, I just want to make it so that, you know, filter or, you know, change the dropdown. You instead say, I have to build an interface that's really powerful. And that's what makes it so hard is because honestly, it's very easy to say, I'm going to build an interface that's, you know,

as powerful as SQL, but as simple as a spreadsheet. It's very hard to actually make that possible. It's taken us many iterations. We actually redid our core interface even as recently as 2021. It's, again, something that you're going to iterate on with customers. You're going to learn so much. And it's fundamentally a hard problem to solve. On the plus side, it's the kind of problem I love solving because it's exciting technology to work on.

And you can sort of incrementally discover things every year and make it better. One thing that I would add on top of all of this is we're not necessarily choosing. Those two things are not necessarily at odds because there are people who love writing SQL and there are people who love spreadsheets and operate through spreadsheets. And what's really neat about our platform is the ability for both of those people to be able to work together and also build on top of each other's work. And so I think that's one of the most critical aspects of being able to have a platform for all. And it is, we're not compromising, we're empowering everyone. And the

fact that I can write SQL and hand something off to you, and you can then build on top of this, whatever analysis you want, that transition is incredibly powerful because it brings, there's wisdom that both parties bring. Certainly the people who tend to be to be more business oriented to have the knowledge and the context of the data and the people who are technically oriented to have more knowledge of the data structures, et cetera. And for those two to be able to collaborate in solving a problem also in real time, I think is just absolutely game changing. And I think that's, you know, more and more is going to become table stakes for what this industry needs to deliver. Yeah, I think working together and not over Jira tickets is just like, that is a fundamental change.

I hear great rejoicing among the audience. Steve-O, I have a question. You mentioned a couple of times about, let's say, the BI of the past, or how BI was done until today, or a couple of years ago before, let's say, Sigma started. Can you give us a little bit more context on that? What does it mean to do BI in the old way? How does it look like? What's the process and what's the experience that the user has? Absolutely. So the BI of the past is a lot of process. It is a lot of time and a lot of heartache. And I say that in the sense that at a certain point, when you have a reasonable question,

and if you're a curious person who's trying to do their best to just to do their work, to answer their question, to accomplish something, you would be stuck in this at this fork in the road where you make this. You're dependent on other people and everyone is dependent on other people. You're dependent on a bottleneck to be able to get to what you need. And so you have to make a decision of. Do I wait for my data or you have to make a decision of, do I wait for my data or do I just make a decision now? And the cost here is going to be two, three weeks of my time.

So from the user perspective and from the business perspective, what you end up with is a lot of suboptimal issues. You in the, and suboptimal results really, where there's no great path for you to success, despite trying to do everything you can. Now, from the kind of the entire process side of it, what is actually this flow?

It is you have people who are answered in order to make it worthwhile to invest in getting the right data in the right format. And then it is to build out what that person needs. Then it's to go to them and vet with them and validate that question is actually answered. And if it's not, you then have to go back to the drawing board because you've messed up somewhere, or rather, there was some sort of communication gap between the two parties. And you have to go rectify that and work through that process with the data. And now, it could be that, and this is in, you know, I say this agnostically without calling out a particular technology because this is just the standard, like, way to interact and way to engage. You know, it could be that all of your data is just in the warehouse. It could be that it's a tool that requires ingestion. It could be like that, you know,

you have different levers and different amount of mechanisms to be able to interact with the data in the end, but the story is always the same. And it's just small little optimizations on that. And so when I say, you know, BI of old, that is really what I sort of talk about and what I think about. And, you know, I think it's that it's where this really lands you is in a world of uninteresting questions being answered asked and answered because it's far too much work to be able to ask the the interesting ones because you need to be able to iterate and that you know that data those questions those answers are going to come when you're working with the data directly it It's not going to happen in three, you know, three-week cycle times to get one tiny little bit of obvious kind of feedback back.

Yeah, that makes sense. And I have a question actually for both of you, but from a different angle. One angle is going to be more of the product and the user experience and the other a little bit more technical for you, Rob. So we are talking here about Spreadsheet, which is like a very, I would say, like word defined way of working with data. It's almost like a paradigm of like computing or like writing code in a way, right? And then we have the relational model, right? The one that the data warehouses out there are using like Snowflake, BigQuery, et cetera, et cetera.

Now, these two, although let's say they have the same expressivity in a way, they are not exactly equivalent. Like they have their pros and cons. They do some things better. Some other things like are harder to do. Yeah, you can do everything if you want at the end, but it's not going to be as easy. And you mentioned earlier that one of the benefits of working with something like Sigma

is that, yeah, we have spreadsheets there. You can use this environment. But at the same time, if you prefer to write SQL, you can write SQL. We want to take people and collaborate regardless of what tools they want to use. So how is this achieved? Because personally, as someone who has tried to do similar things,

to take different users and put them together, work on the same platforms, it's a really hard problem, right? So, let's start with Steep on the products side of things, and the user experience, right? How you can deliver, let's

say, a consistent experience at the end, regardless of like the person there, and let's say the language that they are using. And then I'll come to your the end, regardless of like the person there and let's say the language that they are using. And then I'll come to you, Rob, and ask more of like, let's say what happens behind the scenes, right? How we can translate one thing to the other. So one of the most interesting things to me about Sigma is the model through which you

interact with data. Now, what I mean by this, and I'll also take this back to noting, when Sigma oversold, what really oversold me was when I saw what the product was at the time. And at the time, all it was was a table. It was a table with pivots. Now it is the smallest, really small little Lego of what our product offers. But it was just a table on which you can perform pivots and add formulas. Now, the reason that was so that that hooked me so quickly and so easily and to such an extent was because this model isn't what I'll go back to the traditional BI tools offer. I think what you typically get in a BI tool

is the concept of measures and dimensions, right? The measures of dimensions, it's like it's aggregates, it's group bys, right? It's very easy to translate dimensions and measures to the way that databases work. And I think there's the, what Sigma offers and the interface and the paradigm shift is that instead of

working through dimensions and measures while being on the warehouse, you're working with data and then building on top of that, right? So in the same way you open up a spreadsheet, someone sends you some data, you want to perform some calculations, you'll open up that data and then you just, you build your formulas, your aggregations. If you need to, you can work and transform the data. You don't think about, okay, like what is the combinations of columns that I want? It is, you have your data and then you have the playground to be able to interact with

it any way or any way, shape or form that you want. Now that is, I think that's such a, it's a, it's almost a subtle or an implicit shift. And when someone sees our product, they understand it. And I think I certainly did. But it's a remarkable shift in the way that you think about data at scale. And so to be able to relate to the spreadsheet users, that's what makes Sigma incredible. On the SQL side, I think the interesting piece is because, you know,

you've got SQL users who are very familiar with writing SQL and you want those users to be able to work with the spreadsheet users. I think the beauty of what the product offers

is a single common language, which is we translate that, the spreadsheet to SQL behind the scenes. We have, you know, translate that, the spreadsheet to SQL behind the scenes. We have, you know, an incredible, incredible team here that's built a compiler that will take whatever you do through our UI, translate it into performance SQL. And then by virtue of having that common denominator, you can join these data sources together. You can build on top of each other's and you can build on top of and reference each other's work. So the way it's kind of hard to say, in my opinion, that, you know,

to talk about this as a almost as an intended thing to have been built, it's almost like these worlds sort of naturally come together and they overlap. And what comes together is sort of this beautiful synergy. Yeah, that makes a lot of sense. And Rob, same question from a different angle to you. I remember, and I think like everyone who has used both SQL and something like Spreadsheet knows that doing, for example, pivots on a Spreadsheet is very easy, let's say, right? Doing that in a database system is not the most straightforward thing to do. And in a similar way, but opposite,

joining data is something very natural to do using a relational model. But joining data on a spreadsheet is not exactly straightforward, right? So I'm giving two very obvious examples of the differences between the two paradigms. How, from a technical perspective, do you bridge these differences? And how do you create a model that can deliver, let's say, the best from both worlds at the end? Right. I think the best of both worlds is a great way to think about it.

You know, if you step back and look at a spreadsheet, no one ever talks about a spreadsheet in these terms, but if you think about it, it is essentially functional reactive programming, right? And there's no spreadsheet reader who sits down and says, I'm ready to do some functional reactive programming. That's fundamentally what you're doing, right? If you're trying to explain to someone who had never, ever seen a spreadsheet before,

you would say, there's this amazing thing. You change this value here, and everything that depends on it updates. And that core idea, I think, really sort of is pervasive throughout a lot of how we think about the interface and also the technology. One of the fundamental things we built is,'s true for, you know, columns and formulas, but it's also true even as you combine different things together in a document, what we call a workbook. So you might build, you know, a table element where you're going to do a bunch of transformations.

You might build visualizations on top of that. You may have other table elements that you're linked to. And fundamentally, you have this directed graph of here are all the sources that come in, the different calculations, their dependencies. And the way I like to think about our technology is we've built essentially, even though we don't market this way, the technology we've built is essentially a data warehouse. What's different about it is instead of it being backed, normally you back a data warehouse by disk, we are backed by another data warehouse. And so that means we do everything from, you know, we do local execution. We'll actually do

execution in your browser. If we have a subset of the data available and we can do execution there, we'll do execution there. We do optimization. So we have to do things like, hey, you've got, you know, multiple different of these visualizations and dependent things. We're actually going to, you know, optimize that and only issue one query to cover all of these things. We have a lot of the elements of sort of a traditional, you know, database or data warehouse. The back end of it happens to be that we're going to, as the last step, translate our representation now down to a SQL representation, instead of reading blocks off a disk, we're essentially reading from a backing data warehouse. So that's kind of from a technical perspective. And then to your point, there are different aspects of this you think about in the interface. And you're thinking about design in the product and how you want to expose things. So I'll give you

one example because you raised it of joins are like a very traditional part of the relational model. When you go to an Excel user, you say the word join, they may or may not even know what you're talking about. When you say VLOOKUP, they light up and they're like, yes, VLOOKUP is my thing.

And so we actually intentionally have both concepts in our interface. You can write a formula, which is a lookup, and is very close to a VLOOKUP in Excel. It is, hey, I want to grab some information from somewhere else. And it doesn't change cardinality. So it's a very safe thing to do. You're not going to change your results or twist things around. Whereas you can also go into the interface you know, twist things around. Whereas you can

also go into the interface and say, you know, instead of writing a formula, I want to explicitly do a left join, for example, right? And that is where a more, you know, sophisticated or technical or just data aware user is going to perform that operation. But we treat them separately explicitly because they tend to be separate audiences or separate use cases. And so there's cases like that where we try to embrace both. And there's cases where we very explicitly take a concept like this reactive and apply it everywhere throughout our product. That's super interesting. And one of the innovations, let's say, that they had that made it also quite popular was something similar to what you say about having, let's say, more technical persons that can go and write SQL. In their case, they had LookML.

So there was this language there that allowed you to do some kind of modeling, let's say, that then can be used and consumed by the business user and work in their more abstracted environment. And it was super successful, right? Creating these clear boundaries between, let's say, the engineering persona and the business persona, it seems that it is important. How is this done in Sigma? We have, let's say, a very business-driven paradigm, which is the spreadsheet,

and we can also write SQL. But how do you help the engineer, let's say, to do the modeling, to do all the things that they have to do for their job before the business user starts consuming the data. Right. I think about the world and really sort of two big camps of work I have to do. I have the things that are centralized and governed and known. And that known part is a real big, important part of it. And then I have things that are ad hoc. We are discovering, we are still trying to figure out, we are iterating on. And so either of these two extremes is bad. If you sit in an interface and you say, hey, you can only model things and look ML and the business

user can't change anything, it is a terrible environment, right? Any change you want, you have to go back to some centralized person and say, hey, can you change this? And to be honest, you don't really know what you want changed, right? So you end up just sort of iterating on the centralized model and just getting things wrong constantly. And both sides are frustrated. The other extreme we all know is also wrong, right? If you just say, do whatever you want in Excel, I don't care. I'm sure you'll get it right.

We all know the answer is you probably won't get it right, right? So that extreme was also wrong. So what we try to espouse in Sigma is to say, look, there are a set of known things, and that set of known things is going to change over time, right? We're going to learn more and more about what other metrics we want to govern, what other dimensions, tables, all that things. Once you sort of have a known set of governed things, those are the things that you push down into version control. We've seen a rise of DBT. And so, you know, we see a lot of people say, I'm going to use DBT because I want something that is, you know, open source and not a proprietary way to model things. But they're going to use that for sort of their centralized modeling layer. They're going to expose those models into Sigma.

And then the power of what we try to provide for people on top of that is to say, there's going to be a million things that people don't even know yet they want to ask about. We want to give them the power to figure those things out. And we may then push things back down. And, you know, part of this, as Steve was talking about earlier, this benefit of having everyone the same plot set is that the, you know, the data engineer can actually see what's going on. What queries are they running? What are they analyzing? And they can actually say, oh, I'm going to pull that down, and now I'm going to make something and govern it and pull it into, say, like a DBT model. That was never really possible before, right?

Once someone downloaded to Excel, you were like, I don't know what they're doing. Hopefully it doesn't show up in the board deck. It probably will. That's kind of the problem we're trying to avoid. We're trying to keep people on a central governed system of data and let them bring things into that

governance over time. Yeah, yeah, 100%. Actually, that's very interesting what you mentioned about the data engineer also taking a look into generated SQL and all that stuff. And I have a question on that because I've seen

and it was like with Looker, but when you have systems that generate SQL, like automatically generate SQL, you very easily end up with code that has been generated that's pretty hard

both to debug, to optimize, and also to understand in some cases. There are bugs also in these systems. And it is a hard problem to create code that's ideal for the machine, but also easy to interpret from the human side. So how do you do that? I mean, and what do you learn by trying to do that?

Because I'm sure you've done a lot and there's probably still a lot to be done and it's a very interesting area of research and development in general. Yeah. So, I mean, to your point, it is a journey. It is a hard problem. Obviously, there are trade-offs. And, you mean, to your point, it is a journey. It is a hard problem. Obviously, there are trade-offs.

And, you know, for instance, you may want to write SQL that is going to optimally perform, but may be then harder for a human to understand. And so making those trade-offs. A lot of what we've tried to do is provide tooling at sort of the higher level. You can understand just even in our interface, hey, what are we running? What generated this query? So you can map those things.

We also try to push all that down into the warehouse itself. So it sounds like such a simple thing, but actually even just tagging every query with a comment in the query text of what actually generated the query. So one of the things that I feel passionate about is trying to, you know, different audiences are going to choose different tools for how they want to discover these things, right?

So some part of the audience may say like, hey, I only want to use, you know, the warehouse's query plans to look at what's actually going on. For, you know, someone who's writing a spreadsheet formula, that is not going to be a good interface, right? They're going to want a much higher level sort of understanding. So trying to show things in the right language for the right user, but offer different choices. Because the reality is,

it's often going to be a team effort for things that are complex or working at scale. Yeah, it makes a lot of sense. Okay, one question, Rob, about you more as a founder, like someone who starts something from zero and takes it to one before you keep scaling, right? You make the decision at some point to use something like a spreadsheet, right? Like as your interface with a user out there. And spreadsheet is, okay, obviously something that it's like very well adopted, very well understood by many like users out there.

But at the same time, there are like very well established vendors, right? You have Microsoft in one side with Excel, which is huge, right? And you also have Google on the other side with a free version of Google Sheets. And you are a new startup, right? And you have these two behemoths

that they own distribution at a scale that is like, I mean, you can't even imagine, right? How do you build that? And how do you go to market with that? Absolutely. So, I mean, the first part to answer your question is, if you pull on the logical thread when you're starting any company, you'll quickly realize it's like a terrible idea, right? I mean, almost any company you'll be like, you know, you're going to work super hard. Your assets are really low. There's all these established companies already, you know, in this space. It's easy to basically convince yourself that like,

this is not a good idea. And, you know, also being fair, a super high percentage of startups fail. So there's a logical progression that just says this is never a good idea. And yet, obviously, we all know some startups succeed and make it. So it's hard to pull in the threads and get to the logical thing. I think for us, we tried to do two things that early on I think were important from how we went to market. And then there's also sort of the product side. I'm going to start with the product side,

and then I'll talk about the go-to-market thing first. The thing I want to mention on the product side, when you look at a term like spreadsheet, one of the challenges you have early on is how do you actually describe your product to people? And when I was describing Signet to be in this show, I purposely didn't say spreadsheet probably until about a minute into it. Because I think if you start with spreadsheet, people's orientation is, it's going to be exactly like this existing product. And then they're going to be disappointed

when they try it. And they're like, but it doesn't, you know, doesn't do exactly the same thing. And even though in their mind, they know that's obvious, they know it's something different. It's very hard. It's, you know, anchor yourself on one of those things immediately that they just expect to clone. From a go-to-market perspective, I think for us, it's interesting when you're doing a product that is in many ways a kind of universal platform, right? The way people use BI databases, spreadsheets, it's not just like, hey, it's only done in the finance department or it's only done in marketing. You know, we're not, there's not like a particular,

by looking at a breakdown even of our own users and customers, it tends to be a fairly even distribution between all of the sort of departments you'd suspect, finance, sales ops, marketing, HR, people ops, you know, product management. And even the use cases people have, you'll see some, you know, concentration on things like, you know, financial ops or supply chain management or embedding and building out sort of custom data apps. So you'll see these concentrations, but you'll also see like a long tail of just like people do all sorts of things with these products. And that makes go to market hard for a platform because, you know, the worst pitch is you can do anything with it.

Like your customer is like, that doesn't match my problems, right? Like I need a real problem. I think for us, it was a few things. One was for larger customers, you know, the enterprise customers we have, you cannot go in with a pitch of like, hey, you know, we're going to make you dashboards. Like they already have dashboards. Like this is not a problem you're trying to solve. So we had to find new problems that we were uniquely able to solve that like we were not competing against an existing product. We were competing against they couldn't solve this problem. And then we had to find motions in the mid market and below where we could just go head to head with existing products. And that was a strong flow for us. Obviously, partnerships were a huge part of it. So we've been, you know,

these data products are interesting because by themselves, they're actually kind of useless, right? Like what would you do with a warehouse that had no data in it? What would you do with an ETL tool that couldn't talk to anything? Or a, you know, BI product

that couldn't talk to anything. So you end up actually having to buy a stack. And that means you have a natural set of partners to go to market with. And so that's also been a huge part of our motion. That's super interesting. Okay. And let's talk a little bit about the future now, right?

BI is not like a new concept, obviously. It's been there for, I don't know, since we started having mainframes and databases and businesses that wanted to use technology to drive growth. What's next? I think if you ask someone about BI, the first thing that comes into mind is reports, visualizations, that kind of stuff. And at the same time, we live like in an era where like everyone's talking about AI right now. There is, okay, ML becomes like much more accessible, more and more people, like they can use ML as part of like working with data from spreadsheets, right? Like something that exists for a very long time.

It's very mature. It's something that everyone likes. It's like a lingua franca, let's say, of data for business users out there to AI and large language models or whatever. It's like the next thing that will come out in the next couple of weeks or whatever. What do you see there?

What's next for both the BI industry and for Sigma more specifically, right? Sure. I can start and then I prefer Stipo to chime in as well. I think, you know, as you mentioned, everyone's talking about AI. And I think what's interesting when you look at this, so, you know, we tend to, as an industry, to go through these different waves of kind of innovation or concentration of kind of what people are talking about. And obviously right now, everyone is talking about generative AI and chat GPT, like this, you know, even my mom is very interested in this. And the, so I think the

question we think a lot about is like, for the industry, how is that, like what's going to change? And are we going to see like a new set of players? Are we going to see, you know, some fundamental transformations? I think this is a tough one because, you know, on one hand, it's changing so quickly that like some level I'm like, I don't even want to touch predicting what's going to happen on the AI landscape because next week there'll be something so different. But I will say what I've seen so far, especially in the last year as there's been a wave of things, I've seen a lot of things I would describe as features that everyone is going to already has. And that's probably the, on one hand, it's been this huge enabling technology, right? Almost any product right now is building an outer has a natural language interface. And so I think if you're a startup and you say, you know, the only thing we, what we

built is natural language interface. I think that's a hard thing to be defensible on because I think every product is going to have that, right? Every day, some product announces, hey, now we have, you know, product foo GPT with our natural language interface, right? And so I think you're going to see every product that has that. You're going to see every product enhanced by AI. And I think when you look at the BI and data space, there's a set of common features that people are generally doing. And I think the existing players honestly will probably check the box on all of those. What I haven't seen yet is what is like the wave of features that like we haven't even

honestly maybe even dreamed up yet, but this technology is going to enable. And I think that's kind of the interesting thing to watch over the next six months to a year. And it'll be an opportunity of whether people react or not. I think a challenge for like new entrants here is that everyone's eye is on AI, which also makes it so that even all the big players are reacting to it. A lot of what you count on as a startup is that the big players are asleep and that you can sneak in and get past it. I think that's the challenge for sort of the new entrants here is that no one's asleep on AI. We're all looking at it.

Yeah, 100%. And they have the benefit of owning distribution which is huge right like i don't think i mean if you haven't tried to start a company you don't really understand like how important distribution is like you can't grab like you might say yeah i understand like all the millions of like users that already use Excel, for example. But unless you try to build something, you can't realize how important and what a luxury this thing is. It is super, super important. As you said, I'm also very interested to see how things

will change in the next six months to a year. Stipo, what do you think about that? I think thinking about this topic pragmatically, I think what the tool at our disposal is really human-grade processing of data without a human being involved. And what's so incredible about that is I think it just lowers the barrier to entry for anyone to be able to perform their analysis. So now you can immediately, you can get the context of the data that you need to work with.

Now, something that just came out of the warehouse, you now have a way to be able to get going with that, understand what's going on there. Despite the space of sort of where of cataloging already existing, you know, the convenience of being able to just ask someone or ask an AI and be able to get that context is just super, super critical. So there's this, there's so much, I mean, there's so much in the analysis

that is done today that requires processing. Like if you have data coming from two different sources and they need to be matched together, there's some amount of human processing that's required there. Is it really, should it be required? Well, not anymore, right? You have these tools that you can now lean on. And so I think, you know, we can always speculate on where's the, like the end state going to be before where the, where these tools are today. I think that's the place, that's the end state going to be. But for where these tools are today, I think that's the area that is going to be

the most impactful in our day-to-day. Yeah, 100%. All right, one last question from me, and that's for Rob, and then I'll give the microphone back to Eric. So, Rob, you mentioned at some point about the excitement you had when you first saw the promise of cloud computing back in 2007-2008. We are so many years after that.

Do you think that cloud has delivered? Are we there? Are we done with cloud actually? Or there's still a lot of potential when it comes to the cloud part of it? For me, the amazing thing was just how fast you can move, right? And so if you think about if you were even just starting a company or starting a project at a company 20 years ago, or even more. When I first started my career, we wrote all the software in our stack. We didn't use it.

There was no kind of equivalent of open source. You had to build everything. And then you had to get all the hardware to deploy, all these things that you sort of do. And so for me, there's something amazing about how quickly you can get started on things, how quickly you can iterate, how quickly you can, you know, spend your time on sort of building out new things for value for your users versus spending time on sort of honestly like the

same old problems. And so, you know, I think we are well on our way. I don't think we're anywhere near done yet. I think in some ways we're still learning a lot. I think it's part of the, honestly, the great part about this industry, right? Is that we're actually, I think in a lot of ways, learning how to together move faster, right? In some ways, open source is a way that we saw sort of learned is like, you know, if you talk to a lot of people and said, what if we just gave away our product for free? It sounds crazy. And yet developers have sort of learned that there's a huge value in doing it for a lot of developer-oriented things because it's a way to promote community. It's a way to build on top of things.

It's a way to have building blocks that kind of act like compound interest and build on top of things. And so I think spreading those ideas further, there's a lot of opportunity there. 100%. Eric, all yours. Okay, I want to ask, this is a little bit going back to the AI question, but maybe I can turn this into a good concluding question. One really interesting thing about Sigma

is that in many ways, it gets people a lot closer to the data than SIPO when you were talking about traditional BI. You have this vertical integration and the consumer's at the very end, and so they're actually not very close to the data. When you think about giving someone a spreadsheet interface, it gets them very close to the data. And anyone who's tried to answer a question knows that in terms of ergonomics, looking at the data and just trying to wrap your mind around looking at a spreadsheet gives you a sense of what questions to ask and orients you in many ways to actually perform analytics, maybe even before you start doing analytics formally. One thing that's interesting about some of the AI, especially the chat interface that sort of has become the predominant paradigm, is that it obfuscates a lot of that, right? So when you think about closeness to the data in terms of

Sigma, and in terms of analytics in general, I just love to conclude on hearing about, like, how do you value that as someone who works with and uses and produces analytics every day as part of my job? That's really valuable to me. And I think it's an important part of it, yet at the same time, it can turn into a lot of, you know, unnecessary work. How do you think about closeness to data?

I guess a few things jump out at me. You know, as you were talking about the spreadsheet interface and I mean, there, there are, there are funny things, right? Like you,

if I just showed someone who was not, you know, it was a very much a novice in analysis, I just showed them some column and it has, you know, some data value that's very different than the others. Like their eyes would naturally go to that. Their questions would naturally go to that. They don't necessarily have to have a concept of, you know,

standard deviations and outliers or anything like that. But it's just, it's sort of human intuition to be curious about certain different things. And I think, you know, early on, sometimes we thought about like, what's the right interface for curiosity? And so at some level, an interesting interface for curiosity is a chat interface because it's a very lightweight interface for asking like, you know, I'm generally curious about like, how are we doing in marketing?

And so it's a very good interface for that. And it's a very good, I think, paradigm for sort of getting, hey, here's like a general high level, you know, here's how are we doing in marketing? And so it's a very good interface for that. And it's a very good, I think, paradigm for sort of getting, hey, here's like a general high level, you know, here's how we're doing in marketing. It's not necessarily a great interface for like a very detailed set of things. And so I think you're always going to see a spectrum

of like, what is the right, for lack of a better thing, tool for the job? But, you know, I love getting people engaged. I think one of the things that I've always been passionate about when I watch spreadsheet users is a spreadsheet user gets in front of the data and it's like they kind of almost want to like hug their Excel and they're like, you know, now that I have it here, I can do it. I can do anything.

And they like just jam out for like the next 30 minutes. And I remember watching like early Sigma users, I'd see the same thing. I'd watch them like, you know, do like 3000 things in a row. That type of thing and building out those types of interfaces, right? I don't necessarily want to type 3000,

you know, questions into chat GPT, but if I could type in like three really interesting ones that start me on a journey, that's a great, that's sort of a great win. Yeah, no, that makes sense. I think when you think about hugging the spreadsheet, I actually think it's a very apt analogy because in some sense, when you encounter a new data set, you need to understand the physical dimensions of it, if that makes sense, right? Like it's almost like, you know, walking into a new house and you kind of need understand, like, you know, how it's arranged in the size and other

things like that. But at the same time, like having an interface that encourages curiosity. Yeah, that's a wonderful answer. Sipa, any additional thoughts before we close it out? Yeah, the thing that I had out here is it's really about how people think, right? There's people who are very verbal, and they think in words. There's people who think in images and diagrams. And I think when it comes to data exploration, it's very tough to do it all verbally. And so in this regard, what I sort of expect is, so first off is you're verbally asking all of these questions, but the second off is, you know, there's, you need to have a level of transparency of what. And just in the same way that if you show up to a meeting, someone gives you aggregate numbers, you want to be able to drill down and actually understand how the heck did they come up with

the numbers, especially if it's something that seems amiss or stands out as an outlier. And so to Rob's point, I would just sort of underscore and agree that, you know, there's, it's a great place to sort of start for a high level and to ask the first question, but that those deeper questions and the way that those spreadsheet huggers work, you know, you really need to be able to see the data and the way that you sort of iterate on the next question to even your point when you were describing this question is that, you know, you sort of see the data and that drives how you interact with and what you're going to ask next and what you're going to do. And you don't need words, you just need the actions. And almost that going from what you see and what you need to do

to translating that to words, to then to data and going back and forth is almost a suboptimal way to go back and forth. But it's really sort of curious to see how technology will kind of progress in this realm. Absolutely. Well, we are very excited to see what you and the team at Sigma build as we figure out how these new technologies are going to influence analytics. So thank you so much for giving us time. Wonderful episode. And we'd love to have you back.

So let us know when you can come back on the show. All right. Thank you both. Thank you. Well, Costas, what a fascinating conversation with Steepo and Rob from Sigma. They have built a modern analytics tool that is a spreadsheet and SQL interface. So relying on the two most common paradigms for modern analytics. And it was fascinating to hear them talk about

how and why they made the decision to pursue that kind of interface. I think two things stuck out to me. One, they didn't start there. That seems like an obvious decision. Well, let's just bridge this gap between the spreadsheets and SQL, which have the most usage in terms of analytical interfaces than any other tooling in the world, but they didn't actually start there. Rob, as a founder, told us that they went through many iterations and did a ton of research, watched tons and tons of analysts use a bunch of different tools, and ultimately came to that conclusion. That, to me, was fascinating. The other piece that I really appreciated was they really had kind of a humble are pretty opinionated because they maybe think that

they need to create a lot of guardrails for the end users because they sort of know how analytics need to be done better than the end user. And Rob was pretty clear that's not actually true and that he seems to have a fundamental belief that that's a pretty bad way to build products in general and you know from their success it's clear that i think they made the right choice and sort of um you know giving different kinds of advanced tooling to different users so i loved it it was a absolutely great episode. Oh, yeah. 100%. I mean, there are a couple of things that I found very fascinating. It was a wealth of, let's say, wisdom there from some people with a ton of experience in the industry.

I really enjoyed the part where we talked about the differences between the relational model and the spreadsheets and how these can be bridged. What does this mean in terms of the product that we are building, in terms of the experience that you try to build there? And there were some very interesting insights there. But also, from a technical perspective, what it takes to engineer a system like that, which is also super, super interesting and helps us understand the difficulty and the complexity of the problem

that we are dealing with. At the same time, it's very interesting to hear that it is a journey. Solving a problem is always a journey. That's what I really keep from this conversation with both Stipo and Rob. We have done so far like an am like i would say and they've done an amazing job they didn't say the word amazing because like they are

very humble but sigma is like an amazing tool in terms of like how like the experience that it delivers at the end but rob was like very explicit on that there's still like a lot of work to be done there and many things that like can be improved and the other thing that i'd say and i'm not going to disclose exactly what because i want to keep that as like a surprise like for our audience is that there's also like a hidden gem in this conversation about go to market and building products and companies, especially when you are going out there to compete against some very established and big companies. So I would recommend to anyone like to pay attention there are like some very interesting parts

of the conversation not only from the technical and the product perspective but also the business perspective I agree all right well thank you for listening another great episode in the books subscribe if you haven't on your favorite podcast platform and tell a friend if you haven't on your favorite podcast platform.

And tell a friend if you haven't. We always love getting new listeners. And of course, give us feedback. You can go to the website, submit the form, tell us what you like, what you don't. And we will catch you on the next one. We hope you enjoyed this episode of the Data Stack Show. Be sure to subscribe on your favorite podcast app to get notified about new episodes every week. We'd also love your feedback. You can email me, ericdodds, at eric at datastackshow.com. That's E-R-I-C at datastackshow.com.

The show is brought to you by Rutterstack, the CDP for developers. Learn how to build a CDP on your data warehouse at rudderstack.com.