Brian Bell (00:00.593)
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 Wharton 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.
Zac Choi (00:26.008)
Course, thanks for having me, Brian.
Brian Bell (00:28.43)
well I'd love to start with your origin story. What's your background?
Zac Choi (00:32.622)
So over 20 years in enterprise, I would say broadly data functions, largely focused on data-driven growth. So supporting commercial functions, whether it's sales, trade, marketing, strategy. I started at working from my alma mater at Penn under 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 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 interesting work spread across a lot of brands that I think we're all very familiar with from Cheerios to Bleach. I ran 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. like 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 RevOps, their I guess BI and at Green Dot their trade function as well, so retail marketing, etc. So How do you help the sales team essentially get re reloadable prepaid products onto retail 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
Zac Choi (02:52.982)
my role and it was a lot of ex-consulting you know junior partners and partners that were kind of coming in so folks thought i was i was a little cr crazy kind of reversing a stable trajectory after 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. There I was able to serve as I expected many different companies on data transformation, applied machine learning, and 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 after I, you know, while I was at the firm, I actually started a 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 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 ten years.
Brian Bell (04:32.933)
What was the first startup in your journey before this one?
Zac Choi (04:37.206)
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 gonna build a company around at the time, I think it was Reggae 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 of 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 senior or if you were a family that was just had a kid and needed help coordinating services that didn't go very well. And we ended up Yeah, very well 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, etc., and doing that over my phone. If there was some way I could have some kind of
Brian Bell (05:37.905)
Yeah, it's hard. That's a hard area to get right. Yeah.
Zac Choi (06:06.254)
Triage or some way to make those messaging conversations easier, that would be great. And so that's where we dug in. it became String AI, which was essentially a co-pilot on top of VoIP, which helped with text messaging, with broadcast messaging. we were kind of in the same space as like I think attentive when they're focused on SMS or Podium, or I'm trying to remember the name of the company. I think it's 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 LOLMs. that eventually we were able to sell string to a a telco. They were doing a roll-up of kind of these virtual phone plays and ours made sense as part of that suite of tools for small business owners.
Brian Bell (07:13.361)
So what happened next, walk us through the journey towards big context and what is big t big context?
Zac Choi (07:19.788)
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 the beginning. you know, I have fifteen, twenty years at that point of other experience and I'm suddenly this telephony guy, right? But the idea there was at the time I think blockchain decentralized technology web three 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
Brian Bell (08:09.851)
FOMO and FUD for anybody who doesn't know what those acronyms mean. There's gotta be one listener who's like, What's FOMO and FUD? Yeah, there's gotta be one out at least one person out there going, What's FOMO and FUD?
Zac Choi (08:16.194)
FOMO, I guess would be fear of missing out. So FOMO is fear of missing out. FUD, I wish I knew what the acronym meant, but it's basically a deliberate Yeah, that's what it this the almost the other way. You don't want to miss out, but it's you're scaring people into an action, right? that's right. Fear, uncertainty, and doubt. It's almost on the other ends of the spectrum, but it's
Brian Bell (08:27.931)
Fear, uncertainty, and doubt. Yeah. Yeah. Yeah.
Brian Bell (08:41.935)
Yeah, so it's what you what you it's kinda like the shade you throw at your competitors. You throw foot at your competitors, basically. Yeah.
Zac Choi (08:47.086)
That's right. But I
Brian Bell (08:50.267)
D do they even have SOC two? I mean.
Zac Choi (08:54.414)
It must suck to not have that.
Brian Bell (08:58.499)
Mm-hmm.
Zac Choi (09:00.822)
You can cut that. but the but yeah, so I think when a market is kind of 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 the rational substrate that could be built? And one of the ideas I had was well, you know, there's all these kind of transactions happening all the time 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, 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 sort of 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? Turns out there was not a lot of business benefit to some of these experiments. And then as AI started to take hold 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 the thing that we heard the most was, hey, 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 were probabilistic tools.
Zac Choi (11:21.55)
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're gonna 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 an 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 sort of tongue in cheek, you know, you have big data and big AI. And what is the thing that's going to bridge the gap between them in a meaningful way that can drive real results? That's big context. And so that's sort of 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 can unlock some value for enterprises.
Brian Bell (12:33.135)
And then so I understand the problem now. It's how do I, you know, 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?
Zac Choi (12:48.844)
That's right.
Zac Choi (13:00.46)
Yeah. Th there's kind of a few things. The first is one of the one of the misconceptions about using AI and particularly LLMs and now agents is that maybe if I can MCP a 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, you know, two, three decades on tr getting to a pristine record, and it simply n 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 you know, accrual-based methods or cash-based methods, or I'm I'm I'm excluding, you know. 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 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 kind of 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, a dictionary, or even like an ontology. if you're sophisticated, maybe you've built a knowledge graph of some kind. and then you sort of rely on the users, so the you know, the folks who are using the AI to fill in the blanks, like, yeah, I 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 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 defined things exactly the same.
Zac Choi (15:23.564)
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 a 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, you know, 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 that's a sophisticated play. And so for us, you know We 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 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, you know, 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 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
Brian Bell (17:13.606)
Right.
Zac Choi (17:19.956)
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.
Brian Bell (17:28.347)
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 it proprietary behind like a paywall.
Zac Choi (17:42.403)
Well, we have this kind of 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? Like, what would we have done differently? Like, 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 well, one of the things probably is 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're 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? Like 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 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 data must move, then it can't be locked in. And sorry, if context must move. So if data were to stay where it's forming, meaning must move, 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
Zac Choi (20:07.608)
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 deployment, 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 100% correct. And so that means you're it's a race towards kind of latency and cost reduction, etc. And so then we might as well let everyone get to correctness first. And then we could help set this set and manage the standard against which deployments and whether it's internal external are measured. And so that was so the other strategic plays could we create a standard or conformance that's not, you know, 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.
Brian Bell (21:24.227)
I think the contrarian take here, which is interesting, is that you're giving away your, you know, 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 gonna 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 open source playbook, right?
Zac Choi (21:53.39)
That's right.
Brian Bell (21:53.648)
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, the security. So walk us through you've described this move actually as services as soft services as software.
Zac Choi (22:14.562)
That's right.
Brian Bell (22:22.885)
Maybe you could tell us what that means.
Zac Choi (22:24.62)
Yeah. so services as software. I've 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 deploy something. within an organization. we see, you know, 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 expert. 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 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 one that makes a lot of sense for the data industry. And especially when you have such complex infrastructure, you know, we s 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 pulled And illicit 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, be it's becoming cheaper and cheaper to operationalize, especially if you can productize it. So for example, one critical thing that happens almost in every engagement, whether you're Harvey or Palantir or McKinsey, is you usually spend a few weeks up front having your experts embedded, learning the lingo, looking over people's shoulders, like getting access to data, asking questions, you know, 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
Zac Choi (24:51.918)
quickly infer things from decision traces that are embedded within your 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 really long time, many, many months of work. And we can cut that down to days. Right. And that Is sort of what services as software is. We can go in there, embed ourselves, build the motions, 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 margins to near software margins, you're essentially built a really exciting business. And I think this was not possible until LLMs and and 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.
Brian Bell (26:16.207)
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. kind of like almost like a Palantir model. I Palantir kind of does that, right?
Zac Choi (26:36.812)
Yeah, it it's a crude analogy. Yeah, Palantir does this and I think there's probably, you know, 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 kind of upfront investments and make them more productive and more efficient. You know, you know, it's one of those things where y you know, if folks say, we're seeing a lot of kind of a big build or buy moment for a lot of enterprises. And even if you build it though, like you s you likely need some guidance. And so the posture is we can come and build with you. And then we'll bring 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 you're doing everything from scratch every time, right? You know there's certain parts
Brian Bell (27:17.295)
Yeah. You can build and buy.
Zac Choi (27:32.345)
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 sort of the 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 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-trained 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 improved. do you need a 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. And we're seeing this for a lot of folks who are built internally. They get really good results after you know, many attempts, but they can do it. The moment you leave it alone, accuracy, performance, reliability sort of drops 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.
Brian Bell (29:15.173)
So I know it's early in the journey, but any six success stories from deployments so far?
Zac Choi (29:20.94)
Yeah. we're working with some global one thousand and fortune five hundred 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 given my partner and I, so my co-founder and CTO and managing partner, Joji, he comes from, he led Rackaten's AI and data organizations. prior to then building a context platform himself and then we joined forces when we saw the direction shifting that folks needed not just technology but also help in installing it building it. And so I think the premise for us is if we can become a trusted partner and with open pragmatics we are provly neutral and truly believe in data sort of 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 and trustworthy as well.
Brian Bell (31:07.345)
So if you look three to five years out and open pragmatics succeeds in the way you're hoping, what does the enterprise data stack look like?
Zac Choi (31:16.026)
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 gonna 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 Even like 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. Any 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. Gonna have a hard time figuring out a way to make that efficient, especially right now 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 cli to the enterprise or to the client's bottom line, but there likely have to be a reevaluation of what is necessary in order for AI to perform at scale.
Brian Bell (33:21.179)
What's a scalar role inside data teams that you think is underrated right now, given what you see on the gram?
Zac Choi (33:28.022)
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 how is AI interpreting what that business does? Like 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 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 they are likely going to evolve into the AI teams and we'll need We'll need folks who have great judgment, who have good discipline, and then also understand that data context and models 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 is rare today because there really hasn't been an opportunity. And 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.
Brian Bell (35:33.297)
So what's a popular idea out there in that data and AI in that world that you think is wrong?
Zac Choi (35:41.951)
I think data gravity is a lie. It's a it's not a lie. So I 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. That's relatively cheap. The reason why people don't move out of their systems of record is because of the meaning layer on top. Like 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 gonna leave it there for now, right? And so the entire thesis for us is context lock-in or 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, 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 migration team does takes a long time doing? It's to codify what the data means, right? And so that becomes the exercise that we can try to automate for folks.
Brian Bell (37:32.369)
Awesome. let's wrap up with some rapid fire questions. what's the best advice you've ever received?
Zac Choi (37:35.927)
Sure.
Zac Choi (37:43.187)
this is something 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 you know, my dad's very disciplined person. And I thought he was just gonna 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 y y you find ways to try to find that balance.
Brian Bell (38:23.321)
What's a piece of advice you hear founders getting or giving each other that you think is wrong?
Zac Choi (38:31.298)
Hmm. maybe this is more timely today. I think I think Brian, you might not like this either, but it's 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 kind of looking on the other side of things. Obviously ho it's hard in venture to understand NRR if you don't if the lifespan of the company hasn't been long enough but
Brian Bell (39:10.937)
Maybe you could explain the difference and why and net revenue retention is so much more important.
Zac Choi (39:16.076)
Yeah, so at the end of the day, AR 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? they bill me I can bill my client again and again and again for the same service and that makes my 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 service, I have retainers, right? 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 earn from that customer? remained with my business. And if they churned or if they up 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 subs you know, ARR I think is getting a bit disruptive because licenses are starting to become less predictable as kind of 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 something I always caution them like if wa 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 NRR number is going to be going up and to the right? And I think that's sort of something the industry will be sort of wrestling with over the next couple of years.
Brian Bell (41:24.793)
What's a failure that you're most grateful for?
Zac Choi (41:31.587)
I mean 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 or 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, that's embarrassing, it didn't work out, to 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 sort of helped with our business today. I mean, we went from a really fast growing platform business. And then when we had that insight that actually maybe our clients need transformation help, we let go of a of something I mean Puller, which is Puller AI, which was the name of the platform, was growing something like near 30% month over month for like fifteen, sixteen months straight. And we kind of paused all of that almost immediately when we got to the result, went into semi-stealth for all just over a quarter, re-jiggered the way we did it and asked all of our customers if they wanted to join us on this next log 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 at our peak in in the previous world. And so for me it my previous self would have been that's the dumbest idea ever. You're growing quickly, keep pushing.
Brian Bell (43:39.941)
Yeah, pi pivoting once you reach seven figures of ARR is quite the Yeah. So just staring into the abyss a little bit. Yeah.
Zac Choi (43:44.224)
Yeah. But I I think it what we're
Brian Bell (43:49.01)
Especially if it's growing. But like what did you see that you're was it just like as you looked out, you know, five or ten years with that business, you realize that you were conquering a smaller problem. and there was this bigger problem over here that you could solve in a better way? Like what does that take as a founder? Yeah.
Zac Choi (44:04.578)
Yeah, it was it was actually 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, you know. usually that means it's 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 yeah, but
Brian Bell (44:17.595)
What is that? What is that floor? tell us what that is.
Brian Bell (44:29.649)
So the space is getting crowded and you're undifferentiated.
Zac Choi (44:32.748)
Yeah, and it feels undeferentiated, 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.
Brian Bell (45:00.399)
Yeah, what's my cloud strategy? Maybe I build my own cloud, right? Yeah.
Zac Choi (45:02.702)
Yeah, exactly. And so we're in that phase again. It's gonna take enterprises a long time to either figure out they don't have the talent or the wherewithal or they're gonna 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 kind of the one. And the last one actually a lot of sophisticated partners or customers and prospects were telling us, I wish there was an open source version of what you're building. And so yeah.
Brian Bell (45:43.867)
Right, because we need to adapt it in this way, right? So you're you're basically d doing the Palantir playbook for data systems enterprises.
Zac Choi (45:52.867)
Yeah, it's like Palantir meets call it iceberg, maybe meets a little bit of like early, early a scale AI motions, right? Which was they were they're essentially tagging unstructured data so that AI could consume it. We're not doing that for structured data s estates so that AI could work really well with big data. And so that's there's a 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 kind of it was a force functional 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. Like it's it feels like I 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. Be because it it's a service motion that didn't need to we still need to go through procurement, right, as a vendor, but
Brian Bell (46:59.121)
That but the service motion still leads to ARR and NRR, right? Because you're still going in and you're 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 it each time, which a lot of it's repeatable anyway. It's just a different, it's almost like a different go to market.
Zac Choi (47:02.786)
That's right. Yeah. And you can do that through
Zac Choi (47:15.0)
That's right.
Zac Choi (47:19.672)
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 analogy. Yeah.
Brian Bell (47:31.877)
Or a pre built house, right? You can buy the house. the you know, we're we built thirty of in this neighborhood or whatever, and you can buy one of Or like you just tell us what you need and we'll we'll we'll take a lot of the same components and build the house of your dreams.
Zac Choi (47:46.787)
Yeah, and a lot these planned 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 through TaskRabbit and then someone sets it up for you, right? There it's it's a 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, like 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 advice, you're you're you can actually charge a premium for that work as well.
Brian Bell (48:51.771)
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 services layer, as you get more sophisticated and there's more zeros on the contract, you get more F for deployed engineers. You get more service wrappers. And you know, Microsoft, yeah, Microsoft, 95% of their revenue comes from their ecosystem, of SIs and CSPs and that go.
Zac Choi (48:57.645)
Yeah.
Zac Choi (49:08.236)
Yeah, you have you have customer success. Yeah, you have dedicated
Brian Bell (49:19.685)
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.
Zac Choi (49:27.234)
Yeah, it 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. It's and so you're kind of borrowing from you know those premium consulting models where 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 sales.
Brian Bell (49:57.775)
Yeah. Well, where can folks find you online?
Zac Choi (50:01.371)
Bigcontext.com is a great place. Also, you know, I love I I love it You know it it wasn't we had to find someone they I I I forget exactly I think they were in healthcare and I'm not sure what the name did, but they're generous enough to you know to negotiate a fair price for us. Yeah.
Brian Bell (50:05.777)
I can't believe that a URL was a domain was available. Big context.
Brian Bell (50:24.315)
Sell you. Yeah. Yeah, yeah, totally. Well, Zach, it was great to catch up. Thanks so much for coming on.
Zac Choi (50:31.224)
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.
Brian Bell (50:42.226)
Thanks, I'll pay you later for that.
Zac Choi (50:43.663)
Appreciate it.