Ignite Startups: Why the Modern Data Stack May Collapse Under AI with Zac Choi | Ep306

Speaker A: So we think that the modern data stack cannot stand under the pressure of AI. Uh, and what that means is it was built for human latency work. Everything was built to be very predictable. The even semantic layers, which are snapshot definitions, were helpful because you were only allowed to ask predictable questions through surfaces like BI tools that had canned answers. And the moment you needed something else, you had to go to a human. In the world of AI, that expectation is the agent is the interface and the agent is the one who's going to be consuming the infrastructure. And the infrastructure did not contemplate AI. And so it's why you're seeing AI bills skyrocketing. It's not just token usage, it's also compute. Right? Every time you run a query, every time you, you add more context to store more things, there's storage fees. So everything is going.

Speaker B: Hey, everyone. Welcome back to the Ignite podcast. Today we are delighted to have Zach Choi on the MIC. He spent two decades inside enterprise data and AI, from Morton to McKinsey to Green Dots IPO before becoming a repeat founder. He's now building Big Context and Company, which he calls the first AI native services firm for the corporate data function, and is publishing an open standard called Pragmatics for how AI systems understand enterprise data. Thanks for coming on, Zach.

Speaker A: Of course. Thanks for having me, Brian.

Speaker B: Well, I'd love to start with your origin story. What's your Background?

Speaker A: So over 20 years in enterprise, I would say broadly, data functions largely focused on data driven growth, so supporting commercial functions, uh, whether it's sales, trade, marketing strategy. I started working for my alma mater at pen, the Management and Organizational Behavior Group at Wharton, essentially running studies for Fortune 1000 companies on how they, how folks work together. Like what are, what are the attributes of employees that make them better and more productive when in teams versus when not. I moved to, I guess, big brands. So I worked at General Mills, followed by Clorox, where I was working on category management, merchandising, analytics, trade and promotion strategy, pricing, et cetera. And so really interest work spread across a lot of brands that I think we're all very familiar with, from Cheerios to, to bleach. I ran, um, category services for Cat Litter at one point. So. And that brought me to kind of a stage where I was like, I wanted to move into something different vertical but carry over my expertise. I was fortunate to join the leadership team over at Green Dot, helping to run their revenue growth function in their early days, set up some of their rev ops, their, I guess, BI and I agreed. Now their trade function as well. So retail marketing, etc. How do you help the sales team essentially get reloadable prepaid products onto retail, um, shelves. Stayed there through the IPO, decided to join McKinsey, which is pretty opposite I think of where a lot of people go. I think folks generally can go to McKinsey after business school and then jump to corporate. I kind of went the other way. In fact it was funny because I was interviewing for my role and it was a lot of ex consulting junior partners and partners that were coming. So folks thought I was a little crazy reversing a stable trajectory after uh, IPO into going back to the grind of consulting. I personally thought it was a great way to take what I knew and try to impact as many businesses as possible. And so when I joined the firm it was in data driven growth. I was able to serve as I expected, um, many different companies on data transformation, applied machine learning, data science, how to essentially use your data to grow and how do you transform your organization so you can be more of a data driven company. So that was kind of from high to low. A lot of the work that I did, I ended up jumping ship again. Uh, after I, you know, while I was at the firm I actually started a um, practice called fuel by McKinsey. At the time we called it fast growth tech and it was serving growth stage. So call it series A to pre ipo, um, startups, whether you're in venture or kind of in growth private equity portfolios. And again using data around how you're doing sales, how are you doing marketing and then finding ways to serve smaller organizations at scale. So that was, that was sort of what got my brain thinking about so what would it be like if I went and built something outside of the safety net of a large organization and the rest is history. So I've been building for the last 10 years. What

Speaker B: was the, the first startup in, in your journey before this one?

Speaker A: Yeah, so it was a company called String AI. It was, we had a few very interesting pivots because when I left I thought I was going to build a company around. At the time, um, I think it was Reg A plus where crowdfunding became acceptable for private companies. And I said surely there's a vehicle here that can be built that I can help stand up. So that I actually left the firm to try to work on something in that area. And I didn't know enough about it. I ended up pivoting a couple times on the idea alone. Started as a consumer health App where you could coordinate help on kind of different life journeys. So if you had a homebound, ah, senior or if you were a family that was uh, just had kid, um, and needed help coordinating services, that didn't go very well and we ended

Speaker B: up, that's a hard, hard area to get right.

Speaker A: Yeah. And an area where I wasn't necessarily an expert in either. But one thing did come up from that which was when we were interviewing service professionals, many of them had the very similar complaint which is I'm coordinating hundreds of clients, prospects, et cetera and doing that over my phone. If there was some way I could have some kind of triage or some way to make those messaging conversations easier, that would be great. And, and so that's where we dug in. It became String AI which was essentially a copilot on top of VoIP, which helped with text messaging, with broadcast messaging. We're kind of in the same space as like attentive when they're focused on SMS or podium or I think it was called hustle but it was in community. So these are all like various kinds of SMS meets automation type plays. We had uniquely an AI copilot on top and these days that's pretty common to now put an AI on top of your phone number. But we were, we were doing that I guess before the age of gen AI and LLMs that eventually we were able to sell string to a telco. They're doing a roll up of virtual phone plays and ours made sense as part of that suite of tools for small business owners.

Speaker B: So what happened uh, next, Walk us through the journey towards big context and what is big. Big context.

Speaker A: Yeah. So you know, after a year after that transaction I, I ended up spending some time thinking about like the next idea to go to go build. But I wanted to focus on areas that one I felt I had expert expertise in from from the beginning. Um, you know I have 15, 20 years at that point of other experience and uh, I'm suddenly this telephony guy. Right. But the idea there was um, at the time I think Blockchain decentralized technology, Web3 was starting to create some waves and one thing I noticed was there was a lot of FOMO and fud around. What NFTs could do, what, what

Speaker B: FOMO and FUD for anybody who doesn't know what those acronyms mean. Yeah, there's gotta be one, at least one person out there going what's FOMO and fud?

Speaker A: So FOMO is fear of missing out fud. I wish I knew what the Acronym meant but it's basically fear,

Speaker B: uncertainty and doubt. Yeah,

Speaker A: that's what it is. Almost the other way. You don't want to miss out, but it's. You're scaring people into an action. Right. Fear, uncertainty and doubt. It's almost on the other ends of the spectrum. But

Speaker B: yeah, it's what you, what you. It's kind of like the shade you throw at your competitors. You throw FUD at your competitors, basically. Yeah,

Speaker A: that's right.

Speaker B: Do they even have sock to.

Speaker A: It must sock to not have that. You can cut that. But the. But yeah. So I think when, when a market is acting out of let's say fear or negative space, that means there's some level of irrationality involved. And one thing I was kind of looking for is well, if there's a market being built here, then what is a rational substrate that could be built? And one of the ideas I had was well, there's all these kind of transactions happening all the time, um, on the blockchain. Could there be a way for us to add a semantic layer over the blockchain? Could we help with data orchestration? As brands and businesses were trying to experiment with Web3 and perhaps other emerging technologies say like AR VR. And even at the tail end of that gen AI, all they, all they had to show for their efforts was I did it or I did not do it right, but instead could you find some way to show a business impact or some top line growth or some increase in customer engagement? And in order to do that you had to connect data from these new sources, uh, these new technologies to your own system or your own product and your own data. And that's very difficult to do if you're unfamiliar with these new sources. So started out as a data orchestration company between legacy systems and these new and emerging systems. And can we help folks rationalize the results that they were seeing? It uh, turns out there was not a lot of business benefit to some of these experiments. And then as AI started to take, pulled almost all those budgets that were in innovation and in these experiments literally shifted towards gen AI, we were a data play. And so that um, the thing that we heard the most was AI should let you speak with your or talk to your data. And broadly speaking as a data professional I didn't believe it. And largely it was because LLMs and gen AI are probabilistic tools and a lot of data work required deterministic work and deterministic outcomes. And so my prediction was people were going to try to dump data into context Windows, they were going to get poor results and then followed by many years of failed experiments and pilots. Fast forward, you know, three, four years later, that's exactly what happened. Right? We have entire field of folks with AI mandates again, FOMO and fud and they're looking for desperately some rational substrate and foundation underneath that. And so big context is tongue in cheek. You have big data and big AI and what is the thing that's going to bridge, bridge the gap between them in a meaningful way that can drive real results? Uh, that's big context. And so that's sort of our, our foray into the space is can we get your AI project to work? Can we have it work and produce correct results reliably on top of your enterprise data? And if you could do that, then perhaps we could unlock some value for enterprises.

Speaker B: And then so I understand the problem now. It's how do I feed into the context window the right data at the right time so the AI can actually execute my enterprise tasks and be successful? How does that work technologically? Like how are you able to crawl all my data and make it servable at the right time with the right context?

Speaker A: There's a few things. The first is one of the misconceptions about using um, AI, in particular LLMs and now agents, is that maybe if I can MCP or rag towards my tables, I'll, it'll know what to do and what to crawl and come up with it. So the first problem is that requires you to have a pristine map of your organization's data. So most people don't. Most enterprises have been trying for the last two, three decades on um, getting to a pristine record and it simply has never happened. And part of the reason is you might have the same word mean different things and they have to mean different things. So if my CFO says the word revenue, maybe I'm looking at accrual based methods or cash based methods or I'm um, excluding depreciation on certain types of flows. I'm looking at business lines if I'm a holding company across different things. But if I'm a salesperson I'm m looking at revenue against incentives I might have to track. Or if I'm a marketing person, I'm looking at revenue and attribution based on channel. And in some cases I might include returns and exchanges and in other cases I might not. And so all of that needs to be somewhere and it, and it's not anywhere. And so an AI, if they were exposed to your data systems, has to then guess what you were trying to say. And so there's this one is an indexing and mapping problem. The two is AI as a machine can only read what's been written down. So you either going to point them towards a semantic layer, dictionary or even ontology. If you're sophisticated, maybe you've built a knowledge graph of some kind and then you rely on the users. So the folks who are using the AI to fill in the blanks, yeah, I want to look for this or. And so you might build a markdown file, but the issue then becomes sprawl. A lot of folks are building their own inventory of um, definitions that are not, are disconnected to what's going on. And you can't expect each person on your team to have said the same things and define things exactly the same. And you still have the same problem. If I have a markdown file over here and an agent crawls that file, they might decide to stop at a certain point and think that's close enough to the answer and move. So there's still this weird tension between what is again a probabilistic tool, an agent is very probabilistic, and then what you've written down, which again may not be structured sufficiently well enough. And so then you have to figure out a way to harness the agent and harness that intersection. And so as we, as we're moving forward, we're, we're seeing that there's maybe seven or eight non trivial blocks of work that have to be done in this context arena, not just within the context window, but where context is stored. It's not just metadata, it's tribal knowledge. There are probably decision traces you can find within the tools that you're using today. And that's a, uh, that's a sophisticated play. And so for us, you know, we've first started by just building a context platform and there's now plenty of those kinds of companies out there. But one of the things we realize is it's not just a technology problem, it's a transformation problem. If I need to go and find where that context lives, I need to help set up infrastructure that might not fit inside that platform. I need to collect context and continuously hydrate that context from the organization. That's a tall order for um, a small data team or even a, a large data team to try to tackle in a meaningful way because we've never done it in the history of an enterprise. And so we're going in and doing some of the work that I was doing at McKinsey, which is data transformation. Now we're doing it for AI going in and I think we call it forward deployed engineering in some ways, but we say we're forward deployed context engineers and architects. We can help organizations set up that infrastructure correctly and if they use our technology, great. But at the very least we can make sure they get it done right.

Speaker B: Very interesting. So you're introducing Open Pragmatics as an open standard instead of keeping it proprietary. Walk us through what that is and why you guys decided to open it up rather than building the proprietary behind like a paywall.

Speaker A: Well, we had this crazy theory that says a lot of the modern data stack that we're all very excited about. We call it the systems of record. We say data gravity is this kind of impenetrable force. And the more we thought about the problem, we asked ourselves what would not have existed if AI had been around the whole time? What would we have done differently? What's missing here? And in particular, what would we not have built and running that scenario through? And I always challenge people to think about that on their own time. But one of the things probably is you. You might have kept data wherever it was being formed, right? You would have started to collect knowledge before it became tribal, right? So you would have had some way in system to do that. And instead of having to aggregate and normalize data because you were doing human latency work, you might have federated a query, right? Like there are certain structural things you would have changed in that system. And almost every time in order to make an AI system work at scale, we realized actually it's really difficult to do that if you are if meaning. So context doesn't move, right? And today you have semantic layers and ontologies where and even the context platform that we were building created lock in, right? In order for us to create value for ourselves as a company, we have to hold your context, we have to gather as much of it as possible. And now you're dependent on us, similar to how data warehouses do did that with data, and they're also trying that with context. And that didn't make a ton of sense for us. And so we said, look, if context must move, so if data were to stay where it's forming, meaning must move, then then as a business, it doesn't make sense for us to then also lock it in, right? And so we decided to take our reference architecture, our standard for how we evaluate whether an AI is performing well, and just decided to open source it so that we can let folks do with it what they will the other Reason is we realize that correctness, which is the standard by which we measure our deployments, is tractable. So everyone will get there at some point. And so if you get to correctness and your context layer in the harness and this orchestration, you're able to build it out, then that becomes a commodity, right? Everyone reaches a hundred percent correct. And so that means it's a race towards latency and cost reduction, et cetera. And so then we might as well let everyone get to correctness first. And then we could help set the set and manage the standard against which deployments and whether it's internal or external, uh, are measured. And so that was the other strategic play is could we create a standard or conformance that's not people chasing accuracy measures or very particular metrics that don't make a ton of sense in the long run and then just presume everyone's going to get there and then just be the authors of that standard if we can.

Speaker B: I think the contrarian take here, which is interesting, is that you're giving away your, you know, m, your, your main technology that creates the moat, it creates the lock in. Right? But then you're betting on what happens after because your bet was, hey, everybody's going to get there eventually. So that won't be differentiated. What'll be differentiated is how scalable extensible, enterprise ready it is to be deployed, which is kind of the, the open source playbook, right?

Speaker A: That's

Speaker B: right. You give away a basic version, that basic version gets really good because you know, an order of magnitude or two orders of magnitude more people are using it and sending pull requests and standardizing and building integrations and connectors into your open source library. But then what becomes differentiated is this the service, right? The deployment, uh, the security. So walk us through. You've described this move actually as uh, services as soft services as software. Maybe you could tell us what that means.

Speaker A: Yeah. So services as software, I've seen it, I've heard it as like full stack AI. There's also AI, native services. Right. So in venture, there's a lot of terminology around this. The idea is what becomes differentiated is the know how, the judgment, the taste, the ability to go in and quickly, uh, deploy something within an organization. We see Palantir has been doing this quite a bit obviously in my previous career at McKinsey and actually even as at Clorox, where I was literally a forward deployed data experts. So Clorox would sponsor me to walk into a Target or Best Buy or Supervalue or some large chain and I would sit inside their firewalls and look at data from across the categories we were involved in. And my mandate was to help them build data models that would help them grow the category, grow the business. And so this consultative motion is, is one that makes a lot of sense for the data industry, and especially when you have such complex infrastructure. You know, we, we said even if you give away this reference architecture, it's actually really hard to stand up. Right. And it's really hard to get pull and elicit tribal knowledge. It's hard to hydrate that over time, businesses continue to move and evolve. And so there is this world where the services motion and expert motion, which has traditionally been very low margin, very high touch, uh, it's becoming cheaper and cheaper to operationalize, especially if you can productize it. So for example, one, one critical thing that happens almost in every engagement, whether you're Harvey or Palantir or McKinsey, is you usually spend a few weeks upfront having your experts embedded, learning the lingo, looking over people's shoulders, getting access to data, asking questions. Uh, we call it discovery and embedding. And that's usually an investment that's being, that's paid for by the service company. Right. What we've done is try to productize as much of that as possible. So we have ways to do automated elicitation, we have ways to quickly infer things from decision traces that are embedded within the technologies that you use. And we're agnostic to what technologies are in place right now. And so, you know, we're very proud to say that like there's, we can do a bi tool to bi tool migration, which often could take for large enterprises maybe a year. Right. Like a, uh, really long time, many, many months of work. And we can cut that down to days. Right. And, and that is what services as software is. We can go in there, embed ourselves, build emotions and try to productize that. And so it's basically services and the good stuff that comes out of services, so reputation, if you're an expert, so you can charge a premium against those things. And instead of billing by time and material or billing by a license, you can bill by outcomes. And if you can drive those outcome, uh, margins to near software margins, you're essentially built a really exciting business. And I think this was not possible until LLMs and agentic innovation because we can now productize quickly these kind of small bits of workflow that previously had to be done by hand and were very hard to scale.

Speaker B: Yeah, it's almost like you can go in and adapt the software very quickly as a forward deployed engineer or firm to their individual use cases. But some of that ends up being repeatable across clients as well, or a lot of it. So you're kind of building the platform, you're almost co developing the platform as you're deployed inside of organizations.

Speaker A: Yeah, it's a weird analogy

Speaker B: model. I think Palantir kind of does that, right?

Speaker A: Yeah, Palantir does this. And I think there's probably they were doing it in a way that I think is still heavy handed in terms of labor. I think there are now ways to even take those upfront investments and make them more productive and more efficient. It's one of those things where if folks say we're seeing a lot of big build or buy moment for a lot of enterprises and even if you build it though, like you, you likely need some guidance. And so the posture is we can come and build with you and, and it will bring

Speaker B: build and buy.

Speaker A: Yeah, exactly. You could do both. And so it's almost like you're building, you're bringing in your general contractor. But it's not like you're doing everything from scratch every time. Right. You know, there are certain parts that you can buy and you can construct pretty quickly and because you've done it many times, you can make that automatic. And I think that's, that's the new way of working, which is if you're going to build, then could we come in and help you build it? And there's likely some level of like maintenance or retainer we can do. One really exciting model we're we'll be introducing here in the next year is could we not only help you get to a sovereign context operating system, but could we also stand up sovereign models within your organization? So you know, one of the big things that we found with our clients is we can get you perfect context and perfect data. So like your agents are behaving appropriately, they're giving you correct answers. But if you pass that package to a generalized model, there's still some issues that come out on the other side. So is there a way to build, help you do kind of whether it's open weight and post train models, but they're sovereign to your company. But even in that world you still need tuning, you need folks maintaining and checking in if models improve. Do you need a, do you need a way to benchmark? And in most of these cases there's drift and decay. So you can set it up one time, but next month it might not be performing very well. We're seeing this for a lot of folks who are built internally. They get really good results after many attempts. But they can do it the moment you leave it alone. Accuracy, performance, reliability drops uh, within weeks or months. And so that's a pattern we're, we're trying to predict on behalf of enterprises when we roll out our deployment.

Speaker B: So I know it's early in the journey but any success stories from deployments so far?

Speaker A: Yeah, we're working with some global 1000 Fortune 500 companies already. What we're finding is that one, I think a lot of teams now are looking for sobriety in their partners. Again, the opposite of FOMO and fud. Can you like there's a mandate to get this to work. It's been three years of false starts and promising pilots that never make it to production. And so we have under our belt dozens of real success stories that are lasting and transformative. And so we can take that and bring that to larger and larger enterprises. And uh, given my partner and I, so my co founder and CTO and managing partner Joji, he comes from, he led Rakuten's um, AI and data organizations prior to then building a context platform himself. And then we joined forces when we saw that the direction shifting that folks needed not just technology but also help in installing and building it. And so I think the, the premise for us is if we can become a trusted partner and with open pragmatics, we are provably neutral and truly believe in, in data. So meaning movement, truly believe in sovereignty of your context. And if we go to market in that fashion, I think we can earn the trust of enterprises pretty quickly. And I think we've been able to prove that model. And I think that's at the end of the day that's what folks are looking for. They want reliability and trust. And so your vendors ought to be reliable, reliable, uh, and trustworthy as well.

Speaker B: So if you look three to five years out and open Pragmatic succeeds in the way you're hoping, what does the enterprise data stack look like?

Speaker A: So yeah, I think many people will think this is pretty heretical, but we have to believe it if we, if we think we're going to be successful. So we think that the modern data stack cannot stand under the pressure of AI. And what that means is it was built for human latency work. Everything was built to be very predictable. The uh, even semantic layers, which are snapshot definitions were helpful because you were only allowed to ask predictable questions through surfaces like BI tools that had canned answers, and the moment you needed something else, you had to go to a human. In the world of AI, that expectation is the agent is the interface and the agent is the one who's going to be consuming the infrastructure. And the infrastructure did not contemplate AI. And so it's why you're seeing AI bills skyrocketing. It's not just token usage, it's also compute. Right. Every time you run a query, every time you, you add more context to store more things, there's storage fees. So everything is going up. And the expectation, I think, will be very soon. How do we make this much more efficient? And the legacy systems that were incentivized by COMPUTE are going to have a hard time figuring out a way to make that efficient, especially right now as, as things are booming. So, long story short, we believe that the modern data stack, including the data warehouse, will face some severe compression and that value will have to escape somewhere. Some of it will go directly, obviously to the, to the enterprise or to the client's bottom, uh, line. But there likely have to be a, uh, reevaluation of what is necessary in order for AI to perform at scale.

Speaker B: What's a scale or role inside data teams that you think is underrated right now, given what you see on the ground?

Speaker A: Yeah, so I think on data teams we'll likely see a lot of skill and evolution around what we call context engineering and context architecture. So this is not just metadata and semantic layers, but it's also like, how is AI interpreting what that business does? And so that's never been captured, it's just sort of been assumed. It's in your heads. And how do you make a discipline out of that? And how do you create an architecture and practice and even governance around that? I think governance will become more and more important. So these are the tastemakers, but also the vanguard of defense around what is, um, sovereign to the company. So data remains sovereign, context remains sovereign, maybe even the models become sovereign. And so in that world, the data teams are likely going to evolve into the AI teams and, and we'll need, we'll need folks who have great judgment, who have good discipline, and then also understand, uh, that data context and models are, are something you need to really balance out both financially but also from a performance standpoint. And then finally, I think it's how do you, like, how do you test whether things are working well and continue to work well, not just efficiently? And so we talked a little bit about drift and decay, and I think those are things that, because There hasn't been a ton of success at this, at this layer at the enterprise yet. There also hasn't been a ton of opportunity for folks to maintain success. And so I think that's going to be a skill in the next few years. That, that is rare today because there really hasn't been an opportunity. So these are all things that are generally new disciplines that I think are going to come from the data teams, while AI replaces some of the grunt work that's been going on as well.

Speaker B: So what's a popular idea out there and that, uh, data and AI, uh, in that world that you think is wrong?

Speaker A: I think data gravity is an illusion. And why I say that is folks think that because you store a lot of data and that means the companies rely on you. And today that's very true. But it's actually not because of the amount of data you have. The reason it's always been, and it's becoming even more efficient to move data from one place to another. Uh, that's relatively cheap. The, uh, reason why people don't move out of their systems of record is because of the meaning layer on top. That is the thing that's not movable. Right. I can move a table from here to here, but if I don't know what that table means, I can't move it. I'm just going to leave it there for now. Right. And so the entire thesis for us is context lock in, or M meaning lock in is a reason why we're so dependent on the systems of record today. It's not that they're storing all of your data, it's that they've locked in the meaning around that data. So tongue in cheek is it's not data gravity, it's context gravity. And if you can create a really good map, a living map of that meaning, then migration becomes super simple. And that's sort of, I think in the next few years you'll hear us being a little louder about that, which is, hey, uh, if you want an easy button out of your warehouse dependency or your systems of record dependency, it's not about ETL process or getting a migration team in place. What is the work that's that that migration team does takes a long time doing. It's to codify what, what the data means. Right. And so that, that becomes the exercise that we can try to automate for folks.

Speaker B: Awesome. Um, let's wrap up with, uh, some rapid fire questions.

Speaker A: Sure.

Speaker B: What's the best advice you've ever received?

Speaker A: This is something my, my father told me When I was young, which is when you work, you work and when you play, you play. And it struck me as really interesting in two ways because my dad's very disciplined person and I thought he was just going to say you always have to work. Right. But I think he was saying when you're doing one thing, do it really, really well. And then when you do the other thing, do it really, really well. Don't let those things bleed into each other. As a founder that's really hard to do. But if you have that as a, as a North Star, I think you find ways to try to find that balance.

Speaker B: What's a piece of advice you hear founders getting or giving each other that you think is wrong?

Speaker A: Maybe this is more timely today. I think, I think Brian, you might not like this either, but it's uh, I think ARR is stupid. And in particular recurring revenue as a concept makes a ton of sense. It's a good leading indicator of something. But the real value I think comes from net revenue retention. So it's just looking on the other side of things. Obviously it's hard in venture to understand NRR if you don't. If the lifespan of the. Maybe you

Speaker B: could explain the difference and why uh, net revenue retention is so much more important.

Speaker A: Yeah. So at the end of the day, ARR or I guess annualized recurring revenue is often a predictor of how healthy your revenue is over time. And so that means I've got, I've got a business that recurs, right? Uh, they, they bill me, I can bill my client again and again and again for the same service. And that makes my uh, you know, margins go up and my business lasts a lot longer. The, that's a leading indicator. So how do I tell that is if you have a software subscription, If I'm a ah, service I have retainers, right. These, these kind of indicate to me that maybe the customer will stick around a long time. Net revenue retention is a lagging indicator. So as after it happened, when I look back, how many of my customers or how much of the revenue that I earned from that customer remained with my business. And if they turned or if they upgraded or downgraded, you can see retent net revenue retention moving up and down. And so that's also a system of okay, they actually enjoy my business or they find a ton of value for it, so they continue to pay me for it. So the lagging indicator is much more useful. And you know, I think is getting a bit disruptive because licenses are starting to become less predictable. As revenue models, we're seeing consumption models take over in many ways. And so I think we as an industry are going to be struggling or not struggling, but looking for what is the next generation of the forward looking or leading factor. And so right now just saying AR is the answer today it feels like uh, something I always caution them M like if, if your business is not a subscription business and you don't have that recurring line in the contract, what are you doing today in your business to ensure that that NRR number is going to be going up into the right? And I think that's something the industry will be wrestling with over the next couple years.

Speaker B: What's a failure that uh, you're most grateful for?

Speaker A: Every time I think my first company, when I, every time I pivoted I thought that was like, that was it like I was very ashamed that my idea didn't work, that the team didn't work out or whatever it might have been. And I, I realize now that when it's actually it happens all the time, you're, you're, the market changes, you get deeper and better insights about your customer, about the industry and that and you ought to pivot. In fact that's probably one of the most important jobs of a founder is to move when you're supposed to move. And I think that for me went from being oh that's embarrassing, it didn't work out to ah, uh, actually that's a, that's a feature, not a bug of my job and in fact I ought to be seeking that movement faster and letting go of something that's not working quickly. And I think that's helped with our business today. We went from really fast growing platform business. And then when we had that insight that actually maybe our clients need transformation help, we let go of Polar AI, which was the name of the platform, uh, was growing something like near 30% month over month for like 15, 16 months straight. And we kind of paused all that almost immediately. When we got to the result it went into semi stealth for uh, just over a quarter, uh, rejiggered the way we did it and asked all of our customers if they wanted to join us on this next leg of the journey. So we went from you know, kind of low seven figures to zero and then within a matter of two, three months are now back up higher than where we were uh, at our peak and in, in the previous world. And so for me it, my previous self would have been that's the dumbest idea ever that you're growing quickly. Keep, keep Pushing.

Speaker B: Yeah. Pivoting once you've reached seven figures of ARR is quite the.

Speaker A: You

Speaker B: know, it's just staring into the abyss a little bit. Yeah.

Speaker A: But I, I think especially when it's

Speaker B: growing. But what did you see that you're. Was it just as you looked out five or 10 years with, with that business, you realized that you were conquering a smaller problem and there was this bigger problem over here that you could solve in a better way?

Speaker A: Yeah.

Speaker B: As a founder. Yeah.

Speaker A: It was actually three things. The first was the noise floor started getting so high in our space, which is also a great indicator. So noise floor high, growing very quickly, usually.

Speaker B: What is that floor? Tell us what that is.

Speaker A: Uh, it's when everyone is saying that there's an opportunity here and then they're also saying we're doing this thing as well. But then now I have to battle. So

Speaker B: the space is getting crowded and you're undifferentiated.

Speaker A: Yeah. And it feels undifferentiated. Even though we knew we had probably the best platform, the most tested platform. And then the second thing was our customers started going, hey, I don't want another layer right now. I think I can build this. The last builder by cycle. I remember it was. We had CTOs that were literally thinking that they needed to build their own cloud. Right. Like you had like consumer food companies thinking they had to set up their own cloud.

Speaker B: Yeah. What's my cloud strategy? Maybe I build my own cloud. Right,

Speaker A: exactly. And so we're in that phase again. It's going to take enterprises a long time to either figure out they don't have the talent or the wherewithal or they're going to hit the same failure modes. And so instead of trying to sell another platform, I said, let's just give it away for free. We'll go in there and we'll become the trusted partners to help folks build or buy. If they buy. We have a fully functional, really well tested platform they can license from us or they can use some of the parts and build it themselves. And so that's one and the last one. Actually a lot of sophisticated partners or, uh, customers and prospects were telling us, I wish there was an open source version of what you're building. And so

Speaker B: because we need to adapt it in this way. Right. So you're, you're basically doing the Palantir Playbook for Data Systems Enterprises.

Speaker A: Yeah, it's like a Palantir meets, call it Iceberg, maybe meets a little bit of early, early, uh, scale. AI motions. Right. Which was. They were they're essentially tagging unstructured data so that AI could consume it. We're now doing that for structured data estates so that AI could work really well with big data. And so that's, there's a few of those models that I, we think made sense for what we were doing and nobody was approaching it that way. And so that was, it was a force function differentiation. We also saw the market going a certain way and then the buying patterns change. In fact we have one Fortune 500 customer that we were literally in procurement for maybe 10 months, maybe more. It's, it uh, feels like I've become really good buddies with the, with the buyer. And then the moment I told them we're pivoting to this business model, we're right in, right past the gates. Because it's a service motion that didn't need to, we still need to go through procurement. Right. As a vendor. But

Speaker B: the service motion still leads to ARR and nr.

Speaker A: Yeah. And you can do that going

Speaker B: in. And you're basically customizing this platform that you would have built anyway with a bunch of features and you would have charged money for it, but now you're customizing in each time. That's right. A lot of it's repeatable anyway. It's just a different, it's almost like a different go to market.

Speaker A: That's right. It's, it's, I like to put it as a, as a services wrapper on a platform instead of like selling, you know, furniture pre built. We're, it's like this is probably the crudest

Speaker B: announcement. Right. You can buy the house. We built 30 of them in this neighborhood or whatever and you can buy one of them or like you just tell us what you need and we'll take a lot of the same components and build the house.

Speaker A: Yeah. A lot of these plant communities there. It's not like you're like custom built. You have all the modular pieces. You just carry that to the work site and stand it up and it's the same thing. It's or the other is like instead of buying a piece of furniture from a furniture store, you go to Ikea and they bring the parts and they deliver it through TaskRabbit and then someone sets it up for you. Right. It's a different delivery model. The outcome is the same. You still have the operating system, except now you're also trust the partner and they can give you advice as well. So by the way, advice is also high margin business. Right. If I can tell you the best practices of Something else. This was, this is all embedded cost within solutions teams, sales engineering teams, account management. Right. These are all folks that literally sit on large enterprise accounts. But if the same delivery person who is the expert in the space is helping you build it, but also giving you device, you're, you're, you can actually charge a premium for that work as well.

Speaker B: Very fascinating. And a lot of people don't understand this is how enterprise software gets bought and sold. Right. This is, you know that, that services layer. As you get more sophisticated and there's more zeros on the contract, you get more for deployed engineers, you get more service wrappers and

Speaker A: yep, you have customer success. Yeah.

Speaker B: 95% of their revenue comes from their ecosystem SIS and CSPs and uh, that go build all the service wrapper around the core Microsoft tech. And you guys are just doing this for this particular area. So it makes a lot of sense.

Speaker A: And it's also more efficient. Bundle. Right. The same person who's the expert is also the integrator, is also the builder is also. So we don't need a necessarily as large of a sales team. And so you're borrowing from, you know those premium consulting models where you, you sort of eat what you kill but you're also the expert who goes and deploys it. Right. And so I think the, that model in some ways is even more efficient than classic enterprise. Yeah.

Speaker B: Well, where can folks find you online?

Speaker A: Bigcontext.com It's a great place. Um, also I, I

Speaker B: can't

Speaker A: believe that

Speaker B: uh, URL was a domain was available. Big context.

Speaker A: It. It wasn't. We had to find someone they. I forget exactly. I think they were in healthcare and I'm not sure what the name name did, but they're generous enough to, you know, to negotiate a fair price for us. Yeah,

Speaker B: totally. Well Zach, it was great to catch up. Thanks so much for coming on.

Speaker A: Brian, thanks for having me and you know, appreciate all your support. You've been phenomenal and Ignite Partners is definitely one of our favorite investors. So I appreciate you having us on.

Speaker B: Thanks. I'll pay you later for that.

Speaker A: Appreciate it.