Thanks for having me. Excited to be here.
I'm excited to have you here. It's not common to have CEOs on the show and that's by design. I'm a founder and CEO. Nothing wrong about that, but sometimes CEOs tend to not build and I only want to have builders and that's why I wanted you to be here. You are not only just setting the strategy, you're also building with the team. So maybe we can start there and tell me more about how you are actually building Retool.
Yeah. Well, there's a lot of building all across and there's building of the product obviously, but there's also building the company. The company is itself kind of a product as well, right? You have to iterate on it, get better at it every day. So there's a lot of building and I'm also doing a lot of building myself personally. I've been playing a lot with Claudebot or I think it's now called Boltbox. I think we got sued with trademark infringement. But it's a really fun product. For those that don't know, it's a product that you can use to automate a lot of things. The idea is that you give the LLM tools and the LLM can do some pretty crazy things when you give it tools. So, yeah, building, I'm a builder at heart and Retool is all about building and so I'm excited to be here.
So, Retool has been around for like 10 years almost.
I think it's our 10 year anniversary next year, birthday next year.
So tell me a little bit more about how you ended up pivoting or focusing more on AI as LLMs became more mainstream.
Yeah. So when Retool first started, it was because my co-founder and I were both engineers actually and as engineers we were honestly very shocked that building a simple internal tool would take so long and so we spent so many hours every day building internal software. So we thought there's got to be a better way. So Retool first started, that was in 2017 and we mostly sold to engineers actually for the first five six years of the company's life. And over the last maybe 12 18 or so months there's been a real inflection in the number of non-engineers building in Retool and it actually started right before AI. Actually AI has accelerated it even more but even before AI we started seeing this trend of less technical people but people that could write a bit of SQL now able to go build full production applications and so we've gone all in on that over the last 12 18 months so now today the majority of people building actually are non-developers actually and so that's been a pretty interesting product pivot and happy to dig more into it but changing who the product is for, changing how complicated the product needs to be, that's been a pretty big evolution for us.
I want to dive into that because this is something that many founders or executives go through at some point, right? There's something new in the market and then you want to make it happen, but then you also have something else that is working. So the decision is how hard do you want to lean into this new thing versus how much you want to maintain the core business. So in your case as you saw LLMs proliferate what was your decision and how much do you focus on that basically today? Like if I were to look at your website how much of that do you think is new versus the core product that you started with a few years ago.
Yeah, this is such a hard question because it's really tough actually as a decision and I think we've made some great decisions. We've also made mistakes actually. So when LLMs first came out I was experimenting actually even before GPT-3.5 even trying GPT-2 back in the day and to be honest I was a little bit skeptical. I wasn't too sure about how smart they were going to get, how useful they were necessarily going to be. They can, it's almost like a Markov chain, a Markov chain feels smart in some ways but it's fully probabilistic underneath and so how far could you go? Obviously transformers are different but there was a question in my head and it was tough because actually we had a really strong business if you don't look at LLMs at all. So our sort of pre-LLM business was doing very well and the question was do we want to from a focus perspective do we want to go all in now on LLMs or do we keep on going and do two things at once for example. And so let me tell both a story of how it went well and a story of how it did not go well. So what did go well actually was we launched a new product and this happened I think mid last year, around May of last year and the idea was that LLMs are getting smarter and smarter, but today we really only use it for chat. And so the idea was, can we use it for doing things in your business? And we called it Retool Agents. We launched that product in May of last year. And that product today is doing really well. It's growing really pretty rapidly. And we can talk more about that product later. But to be honest, it was in some ways actually an easier product to build because we had no cannibalization because we were not trying to, it was, we started a new team actually to go and build it. We added more engineers on over time and so the team grew obviously but it wasn't competitive with our existing product. It was a separate product, a separate use case etc. So Retool is all about building applications. This was about allowing AI to go do things in your business. So pretty different. And so that to some extent actually went quite well. We can talk about some of the learnings there. But I would say isolating a team to go work on that separately was I think something that worked really well. Almost having a startup within a startup was quite effective. Giving them goals quite effective. So that's one area where it went really well. An area where it has not gone so well actually is as it relates to our core product which is our core product in let's say 2020, 2022, 2023 even it was a product that allowed anyone to go build applications in a drag and drop way and drag and drop, I think there are some upsides to having a drag and drop way of building applications but over time we've actually accumulated a lot of power and a lot of debt as well in that product. And so when 2024 came around and people started being able to say, hey, instead of using drag and drop to go build applications, what if I just generated code for these applications, we looked at that and we said, okay, that's interesting. And I can see how LLMs are very good at writing code, but we're going to double down on our drag and drop system because our drag and drop system is very powerful. And in fact, we believe that we can because of how fast LLMs are improving, we can actually teach LLMs to go use our drag and drop product. And we've done that actually. And so we launched that product in August of last year where we actually now allow an LLM to go use our product. And so the LLM if you ask to build an app, it doesn't actually write React code. It actually uses tools inside of our application to go build the application for you. Almost as if it were a human building the application, if you will. And to be honest, that's a mistake. That was a mistake. And today we're actually thinking about, we're considering and I believe we're going to go down this path. It's a very high conviction bet for us which is let's actually go totally rearchitect our product actually and throw away a lot of the work that we've worked on for the past five six years and actually go all in on why don't we just get LLM to actually go generate code that runs on top of our platform instead of LLMs trying to use the frameworks that we've put together and spent the last five six years on. And so I can talk more about why that was such a tough decision, why I think we actually made the wrong decision and now we're correcting that decision but it's a really hard thing when you have nine figures of revenue on an existing product and you have to figure out do I double down on the product or do I actually go build a new product that replaces that product because I think that's where the future is going and I think we made the wrong decision and now we're correcting the decision today actually as we speak.
Thank you for sharing the process. It's a messy process. It always is and I feel like especially for companies at your scale, we tend to hear founders just talk about the wins and I think the learnings are usually in those initial stages that ended up taking you to where the new product is. And I resonate with that as a founder as well because the logical first step when there's something that big is to do a progressive transition. The team is probably saying this is the right path. We need to protect revenue. Let's set up this new small team. But then at some point I think it requires a lot of conviction and courage from the very top to rip off the band-aid and go all in into what you believe in. But then I think the next move is how do you bring people along right? Like you have this level of conviction? I can imagine when the change is big there might be some reaction at some level. So how do you ensure that what it used to be like a smaller team on the side it's now the core team?
Brian Chesky, the CEO of Airbnb said something pretty interesting. I think this was maybe a year and a half ago or something like that. We were at a YC event and this is actually where I don't know if you heard about Founder mode from I think he wrote an article or I think PG wrote an essay about it later. This is actually where the essay came from was this talk that Brian Chesky gave and Brian made a very interesting point that I hadn't considered before which is that decision making is not zero sum and what he means by that is just because I make a decision as the CEO of the company doesn't mean that now this other IC in my company actually has less decision-making power. In fact it's actually if anything additive actually. And so to give you an example if the CEO does not make a decision we're gonna go all in on this or not actually there's more confusion inside of the company and so it's not like oh well the CEO didn't make a decision so everyone feels so happy and everyone else is so empowered and everyone can go make their own decisions. Instead if the CEO doesn't make a decision or the leadership team of the company doesn't make a decision actually no one can make any decisions actually. And so by making decisions, by making hard decisions that's I think the role of the CEO, the role of a founder of the company, you actually empower others to go make more decisions. And I've really taken that to heart because by default I was a philosophy major actually I studied philosophy in college and as a philosophy major I can be quite nuanced. I can say oh I think this or I think that and it's not always true in all instances what about this. But what I've learned as a founder over the years is that creates a lot of confusion for the team and nuance does not scale. You really have to make your company strategy has to be so simple and I used to almost be playing 3D chess in my head and honestly it was idiotic because most people don't want to play 3D chess. If you cannot communicate your strategy in a sentence or two you probably have a bad strategy. And so I believe that way now with decisions, with leadership is clarity and making a decision as quickly as you can even if it might be the wrong decision I think is so important.
I think that that part is also critical, right? That even if it's a wrong decision and then having the self-awareness to then make another decision, ultimately I think people need that type of clarity to know where are we trying to go and why and if that's not the right way, then where else are we going and why not let's try to meet in the middle just to try to please everybody because ultimately that's probably the worst decision.
Yeah, totally. And I think the hardest ones are, I think this is the one that we had to go through which is the architecture or the assumptions you made when building your app, when your existing product that again has substantial revenue attached to it are no longer true. And so how do you make a decision? Do you give up that much of revenue? It's very scary. Do you say, hey, we're going to put this product into maintenance mode now. We're not going to touch it. And that's going to piss customers off. It's going to piss team members off because a lot of our team members support our customers. And do you go all in on the future or do you have to balance it? That I think is such a tricky one. And I think especially with AI changing so quickly, I have no doubt this is going to happen again in the next few years. I think a lot of architecture decisions that people are making today, they're going to need to change again, honestly, in over 18 months. And it's almost like a curse when your startup is doing well because if a startup isn't doing well if you have no customers it's actually easy to pivot. You can pivot all the time. You pivot non-stop if you have no customers.
Totally. I mean on the topic of hard product decisions I think there's another one that's pretty surprising to me which is you decided not to be a system of record. That's kind of counterintuitive to me as a lot of the SaaS tools will put themselves in the middle and say we integrate with everybody. We are the system of record and now everybody has to be on top of us. So love to learn more about your logic behind that decision.
Yeah. So the way I think about product or winning a market or product differentiators, it's all kind of combined is I think you really have to understand who you are for and what your value prop is. And I think then you have to chart a path to how do I win this market and how do I compound over time over the next year, five year, 10 years. And I think it's natural for a lot of people to say, oh well, one way a product compounds, one way you can build dominance in a category is by being a system of record because a system of record is defensible. People can't rip you away unless you're a system of record. And I think that's true. No doubt. But I think it also comes with some big disadvantages, which is that if you talk to any enterprise, you talk to any consumer even, people don't want more systems of records actually. And so that's an example of a decision that we made that was pretty controversial that I think ultimately has led to a lot of our success and ultimately is a lot more customer friendly but seems like a pretty bad business decision at least in day one or even year one of the company and a lot of VCs would ask us surely this is a mistake why are you going down this path and we would explain by saying this is what we think customers really need and what they really want actually. And so specifically in your question one thing that's really unique about Retool is that we don't really store any data. We store user accounts obviously but we don't store your operational data. So how Retool works is you could use Retool to build applications. Retool allows you to go build applications very quickly with AI. We allow you to generate applications whether front end applications, backend applications, automations, whatever you want to generate all those apps on top of your data in your cloud. And one of the core pieces of advice we got for starting out is oh well you should go be this sort of full stack application generation thing where you store all the data you store everything and that's going to make it really easy to get started with and that's true. It actually does make it really easy to get started with when you don't have to connect to anything. But what we believed is that when you look at applications being built, how many applications being built in the enterprise, how many internal tools being built rely on external data? We think 90 95% of internal tools rely on external data. Whether it's data you have in Databricks, in a Postgres database, in Salesforce, in a spreadsheet, even wherever the data is, it's going to be somewhere else. It's very rare actually that people are building internal tools with sort of new data entirely from scratch. And so if that's the case then certainly you want the product to be usable by 95% of people who have your problem. And so it's almost intuitive, it's almost natural to say oh well Retool is actually going to connect to everything. And so that's one decision we made pretty early on is we said we're actually going to connect to data no matter where it is. Again any data system wherever you want. In fact we would allow you to deploy it to wherever you want. So if you don't like hosting Retool in our cloud you can host Retool in your cloud actually and that has unlocked customers like the US Air Force, the US Navy, the US Army are all Retool customers today. Coinbase is a customer too that's unlocked quite a bit for us. So I think that our product decisions like that that you really have to think about the market and you really have to think about what is best for consumers not just what is best for you yourself long term. This is something fair.
I'm loving this and kind of my takeaways as I hear you speak in terms of simplifying a strategy is making decisions that are bold but very clear about what you are and what you are not. Right. And I'm hearing you talk about focusing on non-developers as the new market. I hear you talk about focusing on internal applications versus external applications. And not being a system of record versus being a system of record. And I think all of that comes with implications not good or bad but like having that internal clarity then is what takes you to my next question which is that value proposition. How do you articulate that to someone who's not living and breathing the product and is trying to make a decision as of which one should I pick for the next few years, right? And speaking of value proposition, especially in the AI world, I've seen a lot of SaaS companies focus on productivity and that's a very vague definition, right? Because ultimately you're trying to compare, well, how many hours am I going to save? And that seems to be very limiting in terms of how much you can charge. But if you focus more on humans or how much more your tool can do versus what a human can do, I think that opens up a whole new world of possibilities which is also very risky, right? Because not everybody's prepared to talk about that. So I would love to learn more about that value proposition and how that lands with other clients.
The way that I think about a value prop is I think it has a few criteria. One is that your customers must care about it. So it makes some difference and ideally is unique. You don't have to be the only product in the world that has it but if you add all your different value props together that should be a package that is unique and then to your point I think your job is you have to go communicate that package to your prospective customers you have to deliver that demand generation or marketing like fashion. So I think that for us the value proposition honestly has always been pretty clear. I think for developers where this is where we started the value prop was you want to do anything but build internal tools. So it's almost like a boredom or a excitement kind of thing which is like you don't want to spend your time doing this crap go do something else. So that was a pretty clear value proposition or you don't want to be reinventing the wheel. I kind of think of it like AWS you could go build your own AWS you could go build your own cloud but do you really want to? Probably not. That's probably pretty boring and not relevant to your business. You actually could do that. So that was what our original value prop was. Today I think our value prop is much more around it depends on the product but for our core product again targeting what we call tomorrow's developers so data teams sort of non-developers but have the capabilities of building production software it's a lot more about now for the first time you can do something you could have never done before. So it's almost unlocking a it's almost anyone could be a developer now kind of mindset. But to your point, we actually think about the value prop honestly as going beyond that actually which is it's not just oh we save you a developer. It's actually what are all the apps that you're not building that even with a developer you probably wouldn't actually build because with Retool we find actually with our customers is they end up building hundreds if not thousands of applications they wouldn't have imagined by the time they first got started with Retool and so I think that there is some positioning or discovery there through a sales process you'll have to figure out in terms of landing that value proposition. To give you an example, there's this one company that has saved around I think $50 million with a single Retool application and that's awesome and when we think about that it's not just oh you save the developer time of building that application that application would have never been built even if you had all the developers in the world actually because it just was not, it was probably I don't know number 75 on the priority list had a 10% chance of success people just wouldn't have built it. Well, the product will reach when you can. And so I think apparently probably not just sort of a first order effect, but also a second or third order effect way. It's quite powerful.
