Retool CEO David Hsu on Finding Product-Market Fit via Sales 01:07:51

Hello, Acquired listeners, and welcome to another great episode of ACQ2, our interview show. We are very excited to have David Hsu on with us today. And David, I think this was one of the most like mind-expanding founder interviews we've ever done on this show. Totally. David and Retool are...

Super cool. I don't know anybody else who went to Oxford to do a custom dual major program in philosophy and computer science. And then started a B2B SaaS company basically immediately out of college. Right? Crazy. So fun. David is super cool. I'm really glad we had this conversation with him. Me too.

We want to thank our longtime friend of the show, Vanta, the leading trust management platform. Vanta, of course, automates your security reviews and compliance efforts. So frameworks like SOC 2, ISO 27001, GDPR, and HIPAA compliance and monitoring, Vanta takes care of these otherwise incredibly time and resource draining efforts for your organization and makes them fast and simple.

Yep, Vanta is the perfect example of the quote that we talk about all the time here on Acquired. Jeff Bezos, his idea that a company should only focus on what actually makes your beer taste better, i.e. spend your time and resources only on what's actually going to move the needle for your product and your customers and outsource everything else that doesn't. Every company needs compliance and trust with their vendors and customers.

It plays a major role in enabling revenue because customers and partners demand it, but yet it adds zero flavor to your actual product. Vanta takes care of all of it for you. No more spreadsheets, no fragmented tools, no manual reviews to cobble together your security and compliance requirements. It is one single software pane of glass.

that connects to all of your services via APIs and eliminates countless hours of work for your organization. There are now AI capabilities to make this even more powerful, and they even integrate with over 300 external tools. Plus, they let customers build private integrations with their internal systems.

And perhaps most importantly, your security reviews are now real-time instead of static, so you can monitor and share with your customers and partners to give them added confidence. So whether you're a startup or a large enterprise, and your company is ready to automate compliance and streamline security reviews like

like Vanta's 7,000 customers around the globe and go back to making your beer taste better, head on over to vanta.com slash acquired and just tell them that Ben and David sent you. And thanks to friend of the show, Christina, Vanta's CEO, all acquired listeners get $1,000 of free credit. Vanta.com slash acquired.

All right, without further ado, on to the interview. David Hsu, welcome to ACQ2. Thanks, excited to be here. We are very excited to have you. You are the founder and CEO, co-founder, founder? Founder. Founder and CEO of Retool, which I know many folks in the audience have used or have friends at other companies that use the product. What is the best one-liner to describe Retool? It's a fast way to build internal software.

Ooh, I like that. I've always thought about it as it replaces admin.mycompanyname.com. I feel like every company I've ever worked at has, like, taken Twitter Bootstrap and, like, built a whole bunch of custom stuff on top of it and then subdomained it admin. until Retool came along. Totally, yeah. It's actually a surprisingly hard thing to explain to your mom. Yeah.

Typically, we'll say it's like Legos for code or something is the best non-technical expansion we found. Well, we'll get into definitely more on the product side later. But listeners, just so you have a little bit of context on Retool, it's about 300 employees. They've raised $190 million. It's a six-year-old company founded in 2017, which is crazy that that is six years ago. David, you've actually been cash flow positive in recent years from what I've read. Yeah, that's right. Yeah.

backed by great investors like Sequoia, Bond Capital, Elad Gil, The Collisons, Greg Brockman from OpenAI, Paul Graham, Quiet Capital. You guys have made something that has attracted, obviously, a lot of investment and a lot of usage. But what we're here to do today is chat with you about a few different topics that I think you're pretty contrarian on.

And the first one is product led growth, where I think this has become something everyone is sort of accepted at absolute face value that this is the new way to go. This is how everyone should go to market. This is how especially for a tool like retool, your customers should adopt it with no salespeople. You and I were chatting before and you're like, yeah, I don't buy it. PLG is is not the way to go. What are your feelings here?

I think PLG is super dangerous at the beginning of starting a startup before you know you have product market fit or not. Because when you launch something, as we did with the retool, you'll launch out into the world and you honestly won't know what people think about it. You'll be like, okay, great. Seems like I got some signups. Are they converting? Not really. I don't really know why.

And trying to PLG your way out of that is kind of impossible. You probably actually don't have product market fit. You probably need to pivot your product a little bit. You pivot the market a little bit. But all of that is really only discoverable via sales. And sales is basically talking to customers. So I think nowadays, a lot of founders that I meet say, oh, you know, we're going to go start a great SaaS business. It's going to be PLG. It's going to be super efficient, which is great, I think, when your company finds product market fit, when it gets a few million in revenue.

But actually, when you're just starting out, that talking to customers is the best way of figuring out whether you have product market fit or not. When we started Retoy, it was all sales at the beginning.

It's very easy to digest the idea that you should do customer development at the beginning of your company and then transition to whatever go-to-market motion happens. I think this is sort of the organic way that most people start companies. Are you finding that having a true sales force is a way to sort of continue doing customer development in a more rapid way than you would get to otherwise?

Yeah, I guess another way of phrasing it is I would probably say sales is, I think, pretty underrated in the early innings of a startup. Where if you look at most PLGE kind of companies, Figma, for example, or a Notion or an Airtable, those companies, I think, existed for three or four years. And they were, I think, by their own mission, kind of wandering around in the desert at the beginning where they release a product. They're like, OK, great. I think people are kind of using it, but I'm not sure how I need to pivot my product in order to attract more usage.

And then I think after three or four years of iteration, they find, oh, here's like the insight that really works and we can really scale this up. But that took four years. If you talk to customers earlier, you can talk to Dylan about this. I think Dylan by his own admission again would say, I wish we had talked to customers earlier instead of just developing the product.

in a garage, if you will. So I think sales is maybe underrated at the beginning of a startup because it tells you so much about how customers think about your space, how they feel about the problem, how they feel about your solution, et cetera. That is gold when you're a pre-product market fit.

Were you doing all the sales? How did sales operate in early Retool land? Yeah. So how it worked, actually, was everything was outbound at the beginning. Because before we had launched, I mean, no one knew about us. So there was no inbound. No one would go to our website. At that point, it was Retool.in. It was like retooling. So no one, unsurprisingly, went to our website. Just retooling around. And the only way we knew how to get customers was by sending emails to them. There's no other way, basically. So...

Funnily enough, the first time I posted a retool to Hacker News, I think I called it something like, show HN retool. It's Excel-like with higher order primitives. And that was actually the messaging that we used in outbound emails, too. And unsurprisingly, that combined with the retool and domain name, no one really replied.

So after no one replied, we're like, okay, well, maybe we've got to pivot a few things here. Maybe let's pivot the subject line, for example. Maybe let's go pivot the messaging inside. Maybe let's go pivot the website, maybe the domain name even, et cetera. So we pivoted a lot of those things. But honestly, none of that stuff would have been obvious.

obvious to Pivot, really, had we not been doing outbound sales, basically. Because when doing outbound sales, what happened was, I remember one hypothesis we had for Retool going outbound was Retool conceptually is kind of similar to something like FileMaker.

And FileMaker, it's the sort of product that was bought by Apple, I think maybe 10, 20 years ago. At least 20, I think. I think I used FileMaker in like the mid-90s. Yeah, it was great to sort of build a simple sort of line of business application. And so our hypothesis was, well, what if we emailed all FileMaker developers and tried to tell them that Retool is a better FileMaker? Which to some extent it kind of is actually. Yeah.

And we emailed maybe 200, 250 of them. Of those, maybe three replied. Two were no's, and one was no, and let me get on a call and tell you why your idea is so bad. And you're like, great, you're saying there's a chance. So I took a call. And we pretty quickly learned that actually FileMaker developers were kind of not the best audience for Retool. And

I can imagine sort of had I not hopped to the phone and just launched Retool as a, hey, FileMaker, but better. I might have been confused for a while about why this wasn't working. I'd be like, well, is it that there aren't enough FileMaker people, users out there? Is it that we're not sufficiently better than FileMaker? Whereas in a conversation, you can sort of learn that sort of much faster.

And so through a lot of pivoting, if you will, we try to sort of many different kinds of messaging. In the end, we found was Retool was particularly effective for a CTO or a VPE of a fast growing, operationally heavy company. So like a delivery company or a fintech company.

And that's a sort of insight that I think would have honestly been very hard to generate a priori in the sense that if I had just, you know, sort of looked at the world and said, here are the companies that would use Retoy, it actually would not have been clear, basically. And the best way to pitch it was saying that it was a fast way to build internal tools, which at that point, we were just almost this sort of generic higher level Excel, if you will.

Which is very different than like a fast way to build internal tools. Yeah, yeah. And so to get us along that path, it was really all talking to customers and all doing outbound sales. Horizontal productivity applications sort of have this very difficult process.

early day path. Because if you're a vertical SaaS application, you can say, hey, you were a system of record for lawn care companies, or we're a CRM for small businesses like wealth advisors who, you know, work with people in their local community. But

It's very easy to grasp it and understand it. But when you're inventing a new paradigm that can be used for so many different things, I mean, you used the phrase Legos or building blocks earlier. That has to be sort of a unique messaging challenge for helping people understand what

what you are. I'm curious if you had a moment where through some sort of demo or video or use case, you were able to make people go, oh, I see. I understand what you're talking about now. Yeah. So surprisingly, the best way right now to explain retool still is by showing someone the three minute demo video, because then it becomes sort of pretty clear what exactly retool is or what is going on.

Weirdly enough, though, we generally don't have the problem of sort of the horizontalness of the product making it difficult to adopt. In the same way that, like, I was imagining Notion as Ben was saying that, like, oh, you can use Notion for anything. Yeah. But what should I use it for? Yeah. Yeah.

The reason why I think it's been easier for us to sell a horizontal solution is because we sell to engineers. It actually, if you think about sort of the BATNA, if you will, that an engineer has, sort of the best alternative to Retool, it basically is build it from scratch via React. And if you think about React, React is a pretty horizontal platform too. It's not verticalized for Lawn Carrier, for example.

Whereas I think with Notion, it's probably more difficult because in the Notion case, maybe they are actually replacing verticalized software. So like you said, if you have a CRM, for example, and you're mowing lawns, you could choose to use Notion for that, or you could actually choose to use a specialized CRM for that. Whereas in our world, typically the baton up basically is you build from scratch in-house. And to do that, you use a horizontal product called React or JavaScript, for example, also very horizontal. So

I think we've been fortunate, but that's the example of something that was not an insight that we had when we first started Retool. It just so happened to be that way. And I think so many things about your business, you kind of learn and you're like, wow, I sure am glad we're still the developers, you know, four years later, for example. So.

In those early days, how did you have this philosophy? Or maybe the better question is, why did you have this philosophy that you needed to do sales and you needed to do outbound sales? You were making a very technical product for a technical audience, developers, who the standard traditional playbook is they hate being sold to, and sales is not a natural motion here. How did you end up coming to this, oh yeah, we're going to do sales?

Yeah, I think I thought of sales as sort of the best way to get a grip on reality, especially outbound sales. We actually did a bunch of investor intros, basically, of like, hey, can you tell your portfolio companies about Retool and maybe they can start using it.

And that actually gave us a very warped perception of reality because they were all very happy to take the call, but none of them converted. And we're like, wow, what's wrong here? Does their product just suck? Why is it so low converting? Whereas the outbound sales, if they don't like the product, like the file maker person, they will tell you exactly why they don't like it. They don't have any allegiance to you, basically. And so sales, I think, was the best way to understand what potential customers genuinely thought about you and your product.

Having a firm grasp of reality was always very important to me. Had you done sales before or like, you know, you don't seem like you were at all afraid to be told that your baby was ugly here. No, I mean, you might as well find out earlier that your baby is ugly. You figure out ways, you pivot your baby, for example. So I studied philosophy in college and I think I

Obsessed with reality, if you will. And it's fun to find it and understand it and pivot it, if you will. Did you start Retool right out of college? Yeah, I think maybe six months after college, we started Retool and retooled.

When we started Retool, it was because we ourselves had built so many internal tools before. And so a few friends and I, we had sort of worked on a bunch of other side projects, if you will. And we discovered sort of with every side project you work on, you have to go build, like you said, the admin dashboard for it. And building the admin dashboard is so painful. Every engineer hates building the admin dashboard. And so we thought there's got to be a better way. And so that's how I started Retool.

And these, you know, side projects, were these hustles? Were you like trying to make money in college? What was happening here? Those were pretty fun ones. Yeah. Some of them made money. Actually, some of them made what seemed to me like tons of money back in college. I went to Oxford in the UK and in the UK, they had these sort of balls, basically. And so I built a ticketing system for these balls that actually made quite a bit of money. Ah, balls. You mean like

Yeah, basically. That itself is actually a pretty interesting business where they sell maybe 500 or so tickets for maybe like 200 pounds each or something like that. And so it actually is like a reasonable sum of money that they are. Sometimes they sell maybe a few thousand tickets, for example. So they basically have to figure out how to burn something like a million pounds a night.

Which is pretty interesting. So you get fireworks, you get all sorts of fun things. But one way to earn that money is spending it on a ticketing system. I was going to say, what's your cut as the provider? Well, that was great because I could bill on a percentage basis. So I would say 5%. For example, I can negotiate a rate with Stripe that's, let's say, 2%. I'd get 3%. So it was a pretty good business.

So help me square a circle here. You're like starting all these startups in college at Oxford while a philosophy major, like self-taught computer science. How are you starting startups and studying philosophy? So actually, I studied philosophy and computer science, which is actually one degree, which is the main reason I actually went to the UK. I had grown up Palo Alto. Another reason was I just want to get as far away from my parents as I could. So that was another reason why.

I went all the way there. So it was actually one degree, which is really interesting because you learn about a lot of fun things. For example, can computers think? Nowadays, for example, generative AI. Is that thinking? Is that not thinking? What does thinking mean? Do you have an opinion on that? So I think GPT-4 is not sentient. That's a pretty weak claim, I think, because I don't know if many think it is. To what standard do you measure sentience?

I think intentionality is probably one, which is, does the computer have a will or have... For example, when GPT-4 says, I want ice cream, does GPT-4 really want ice cream or not? I think probably not. I think it's more sort of a statistical model that just so happens that if you prompt it with, ice cream is tasty, then it says, I want ice cream, rather than it actually feels that it actually wants. But it's quite tricky. I think a fun analogy here is

Ants themselves are actually quite dumb, but an ant hill or an ant colony is actually quite smart, and it actually displays intentionality. If you poke it in this way, it will react in this other way, although the sort of building blocks are actually quite stupid. And so I'm not sure. So it's pretty tricky and pretty interesting. We can spend all podcast talking about it. Let's follow this thread a little bit. How could we test a computer to determine if it has will or intent?

Hmm. Well, so I think one path you could go down, for example, is does the computer have a will of its own? So if it exists in the world, does it do anything by itself? And so a good example is if I put you, you know, as a baby, for example, on Mars, maybe it's not too hospitable, but probably you do something about it. Maybe you crawl around, maybe you die in a bit, but you do something probably. If I put an ant there, it would probably do something.

With a computer, probably not. I mean, the computer only kind of does what it's programmed to do, but I guess the computer doesn't really sort of have an instinct for survival like a human, but you could argue that a human is programmed to survive, if you will. But I don't think a computer, like a GPT-4 does not need to survive, I don't think. It doesn't have the will necessarily to do so. Hmm.

What do you think? It's not clear to me that I'm anything more than a statistical model. It is quite possible to predict how I will react in most situations if you have the training data of how I've reacted in every other situation before this. I don't think I'm particularly surprising in the way that I go about my day if you know me. Yeah, but you probably want ice cream sometimes.

Like literally experiencing the emotion or the clarity of thought of I want ice cream and it's more than just it is common for me at this time to say I want ice cream. Yeah. This is going to be a hard thing to test. Maybe another analogy is like if a calculator, for example, you type in 9 plus 9 into a calculator, the calculator splits out 18. But does the calculator understand maths or is it just sort of, you know, running the program as specified by the programmer? Yeah.

I'd probably argue the latter, but I suppose you get the question about sort of what programs you to... I think if you put a baby in a room, it probably will start crawling around, or maybe it'll cry at least. It'll do something, whereas I'm not sure a computer will. So it feels to me like there is a difference there, but...

You're getting to this idea of like even in isolation, if you eliminate nurture and you were to have a human that was never nurtured, you just have a baby that exists in an environment. That baby will figure out its environment. It may invent language depending on if there are other babies. It will map its world and try and develop an understanding of it and eventually have wants and needs, even if it.

They're completely different than anything we've ever seen because it was isolated from a society. Whereas if you put a GPT-4 language model there, it's unlikely it does anything at all, absent prompting. Yeah. I suppose, though, sorry to take this a little bit further, but I suppose you could program the computers to say they will do something. For example, if you said your sole goal in life, GPT-4, is to manufacture as many paperclips as possible, I guess it probably would do something. It would probably say, well, I'm in a room. How do I get paperclips? Yeah.

Right. Humans, we are genetically programmed to map our environment, consume, reproduce, et cetera, et cetera. Yeah. Anyhow, philosophy is really interesting. Yeah, it is. Well, okay. So now speaking of mapping the room in a mental model, my mental model of you, David, is a little more complete now knowing you came from Palo Alto. Yeah.

You went to Oxford and I was like, how did you end up like hacking and having all these hustles over at Oxford? I'm assuming you had some exposure to tech and startups from your time growing up before you went to Oxford. Were there other kids at Oxford who were like hustlers or was this a, were you an N of one over there? There were, but it's more like an N of five or something like that. I think part of the problem was I remember going to a startup, seeing the college hosted. I

I think I was the only comp sci person there. It was all otherwise MBAs. But this was in 2013. So I think things have changed a little bit since then, but probably honestly not very much. That was one problem with entrepreneurship in the UK, which is challenging when you don't have the community or role models to look up to. Would you say you knew before college that your goal was to start a startup at some point? Yes, yes.

So it's a pretty contrarian move then to move to England and go to Oxford. When we were chatting before this, you brought up the idea that you have to be both contrarian and correct, which we talk about a lot on this show, to go and start something new and big and successful. Did you think when you were starting Retool that you were doing something contrarian, or are you just like, I'm trying to solve my own problem? It was mostly the latter, but then the former became more evident as we told more people about what we were working on.

And I suppose maybe that's the best merger of the two in the sense that what is obvious to you is contrary to others or something like that. It was obvious to us, having built so many internal tools, that clearly there has got to be a better way of building all this crud software. There is no reason that we should be hiring talented engineers to go waste their time building this stuff.

And yet, I vividly remember when we were in YC, so we went through YC, I think, in 2017, there were multiple other companies that came up to us and said,

Hey, this idea is not going to work. In fact, we tried it before. And it's not going to work because it's going to be a consulting shop because you're going to go build this application development platform that no one's going to know how to use to be really complicated. And the only way to get people to use it is if you use it yourself, and then you basically have a consulting shop. And that's what happened to us.

And the classic pitch there is customer needs are so different from one another that it's actually very difficult to build a product that suits all of them well without ridiculous amounts of customization. So no product opportunity. Exactly. Yeah. So that was one counter argument. Another counter argument sounds actually pretty smart when you say it is. So at this point, we're already selling to developers and people are like, so you're selling a low code platform to developers who already know how to code.

Why would a developer purchase that? Why don't you go democratize programming and enable non-developers to be able to go build software? Surely that's the bigger opportunity, A, because there's a lot more of them, and B, because the need is a lot more acute because they actually can't do it and you're actually sort of really raising the bar, whereas the developer can already do it already. So just doing it faster, is that really that helpful? And I think this kind of gets to the point where

Any successful startup idea probably has 10 reasons why it won't work. And because if it didn't, probably somebody would have done it already. And so you have to say, well, yes, I can see why you might believe A or B or C, but I actually disagree with you and I'm going to prove it out. And so

For me, at least, when I heard these stories, it was actually mostly motivating because I was like, great, thank you for the input. I cannot wait to prove you wrong. What was the experience going through YC in regard to all of this? You mentioned that as part of being in YC, you had companies come up to you saying, we've tried this before. It's not going to work. What was that like?

I guess specifically there was some contrarianism there, but also like YC funds so many companies and so many of YC companies probably in your batch contemporaneously with you and alumni had this problem. So it's probably a great network to go access them. YC, I think, is helpful for at least two reasons. One is there is a real competitive dynamic amongst startups there.

And I think having to report back every week about what you achieved the last week and you're going to watch your friends achieve more or less than you is tremendously motivating. So that's maybe sort of one reason why YC was so valuable. The second was...

YC brings in speakers every week, and we were talking a bit before this podcast. But what you really learn from the speakers is not really sort of tactical or strategic advice. It really is you learn about how fucked up successful, now successful startups were back when they were your size. And so I remember when in our batch, I think we had both Airbnb and Stripe come and speak. And I remember when they were your size.

And hearing stories about how fucked up those two companies were when there were two people, five people, or 10 people, it was so motivating to us because every startup has so many sort of warts and so many sort of problems in the startup, and it's easy to overfocus on those problems.

when you're in it day to day. But then hearing that, wow, these other startups had all these problems and still became these giant companies and changed their industries. Wow, maybe I could do that too. And so it's so motivating. I'm smarter than them, so I could do better, yeah. Were you taking feedback from all the haters and were you trying to like really narrow to like, why didn't it work for you? Or why don't you believe it will work to say, ah, I see, we're different in this way, so therefore we might work.

Or were you trying to just tune it out and say, like, look, I kind of have a vision here. We just have to get to launch and see. I don't really care that it didn't work for you in the past. I think it's mostly the former. There's some feedback that can be discarded and I think is actually useless. But I think...

especially from other batchmates, they generally have good intentions. They're not here to, like, shit on you. They're here to try to help if they can. And I remember one batchmate actually, I think, said that they wanted to save a few years of my life or something by not working on a very cool idea. So, you know, they have good intent. But...

I think understanding sort of where they're coming from and where you agree or disagree with them and why, hopefully, they're wrong is, I think, very important. And so in our case, at least the former objection to retool, which is it's so hard to build something that sort of suits these or everyone, well...

If you look at JavaScript, for example, or React, for example, React is not verticalized. JavaScript is not verticalized. Programming languages are not verticalized. Use them for everything. Social media companies use them. Banks use them. They all use JavaScript. And so for us, we said, well, we're selling to the developer and we're going to go build a developer tool that where the vertical does not matter. And so for that reason, we are sort of your objection. We understand it, but we don't think it's relevant.

For the second one, similarly. So in our case, we said, well, yes, we can see that democratizing programming sounds sexier. However, we think fundamentally that's actually broken. And so fundamentally, I don't believe in no code for this reason, because in order to go build complex pieces of software, right?

Code is the best way to get a computer to do something. Yes, I completely agree. It is so specific and so concise. And if you're trying to reinvent programming and then in a sort of visual way and then trying to get non-engineers to learn that language, they might as well have to learn Python or JavaScript to begin with. And so, yes, I think the feedback is valid, but we had reasons for not believing it.

This is such a good point. And I always sort of end up at this place mentally whenever I get excited about no code. And the place I always arrive to is the hard part about computer science is not the syntax. The hard part about computer science are the concepts. And if you have to represent all of the same mental models, it's going to be just as complex, even if you are learning a visual syntax instead of a language-based syntax. Totally. Yeah.

And in the same way that programming has data structures, Retool has these, I don't know, you called them primitives earlier, but in your demo video, you can drag what looks like a table. You can drag what looks like a search box. At the end of the day, most internal facing tools consist of like

five to eight very repetitive types of ways to display and input information. You said CRUD operations earlier. Could you define that for those who don't speak computer science in the room? Yeah. CRUD basically stands for, it's kind of a funny acronym, it stands for Create, Read, Update, Destroy. So it basically is maybe, let's say, creating a record in your database, reading it, update. So

So hypothetically, if you were, for example, mowing lawns, you might want to record all the lawns that you've mowed. That would be creating a record. Maybe someone put in a lawn that they want to be mowed and you want to say, I have mowed it. So that's updating. Destroying would be deleting a record. We estimate actually that probably 50% of all software in the world is basically just doing CRUD software.

And developers day in and day out are just building the software. And it is the most boring software to work on.

And I think that's maybe sort of another reason why we think developers like Retool is because no one wants to work on this stuff. Yeah, they can build this stuff, but they don't want to build this stuff. Yeah. Yeah. You can take this to too far of a logical extreme, though. Like, it's a trope that programmers, if you're an extremely technical person and you're evaluating a new business opportunity, you could pass on the investment because you're like, I don't understand. You're just building a relational database with a UI on top of it.

Why wouldn't anyone just use a relational database with a simple UI on top of it? How are you ever going to accrue market power? You know, what's your sustainable competitive advantage? This is dumb. It's a database. What is your view on like how much

above the computer science primitives there needs to be to sufficiently create an application? Well, I think if you look at modern application development, the fact that if you want to go create a simple form, for example, that marks Alana's, you know, to be mode or has already been mode, building a simple form like that and React today is probably like a thousand lines of code. You probably need to worry about using 30 different libraries in order to do that.

Our belief is that coding has got into this sort of maybe not even, honestly, local maxima, if you will, where somehow we have normalized that building a simple form like that needs to take a week or two and involves writing a thousand lines of code and involves using three libraries that you don't understand. And somehow this is like, OK, like, yes, this is the state of the art for coding now.

Whereas it really doesn't have to be that way. And I think if you look at the history of programming over the past 30 or 40 years, for example, I think there have been some major advances, let's say 40 years ago. So going from punched cards to assembly is actually a really major advance because if you're punching cards and you actually punch through a hole, you're

You run it overnight and you come back the next day, you're like, oh, crap. Well, OK, let me do it again. So the iteration speed is like a day. Right. Or going from assembly to compiled languages. Totally. It's a real 10x increase in productivity. But if you look at the past 30 years or so, the languages are kind of the same. JavaScript has obviously gotten a little bit nicer with ES6.

But it's actually kind of the same language as 20 years ago. If you look at C or C++, we still use C++ today. And the library is a little bit better, framework is a little bit smarter, but we're kind of doing the same thing. And so if you sort of graph productivity of engineers over time, basically, it's probably actually trailing GDP growth. So it's surprising that engineers are so inefficient, basically, and there's been relatively little innovation in programming at all.

So we hope that Retool is sort of like a much higher level way. It's almost going from punch cards to assembly or assembly to higher level language, basically. There's another jump left, basically, at least. That's why we're pretty excited about Retool.

Is it still true today that retool is for engineers? Or if someone's like an ops person who knows how to write SQL queries, are they facile enough for the product to now be for them too? I think it goes back to what you were saying. Do they understand the computer science concepts? Because if you don't know what a database is, for example, you don't know what an API is, then building a retool is still very difficult. And we frankly think retool is the right fit for you.

But if you know what a database is, you know what an API is, and you can pick up a bit of JavaScript or learn a bit of SQL, then Ripple's great for that. And we see a lot of that happening within our customer base today. I think maybe something like 25% to 30% of Ripple builders are those kinds of people that have managed to pick up SQL or JavaScript but were not engineers to begin with. So I think the wave that we are riding that is probably different from the wave that I think no code aims to ride is

is instead of democratizing programming and sort of dumbing programming down, instead we're saying a lot of people that graduate college today maybe don't have a comp sci degree, but have taken one comp sci class or are able to pick up SQL or pick up JavaScript if they really want to. And that, I think, is going to be such a fertile market for Retool over the next 10 or 20 years, especially with AI. Yeah.

Yeah, I was going to ask, we're sort of flipping back and forth between talking about AI and not talking about AI here. Do you have a view on the current state of the landscape, specifically Microsoft's GitHub Copilot, on the leverage that that brings to programmers? Yeah, I think it provides maybe something like 30% to 50% leverage, which is great. Because that, if you save 30% of your time, you're X amount faster. If you save 50% of your time, you're two times as fast, which is pretty good.

but it's not really an order of magnitude jump. And I think the reason for that is it's kind of like

Let's say you had an AI that would go punch cards for you, for example. That's pretty good. You can still program, you know, faster than punching cards yourself. But fundamentally, if you as a human go read the program, you're like, oh, it's kind of hard to understand. Let me try to reason the hole is here and we punch this hole. So what does that mean? It's kind of hard to reason about. And same with assembly, right? Let's say that, for example, you had Copilot for assembly and

That's great. You know, you can go write assembly, let's say twice as fast now, but you're still writing assembly. You're trying to debug assembly. It's still pretty difficult. And I think that's kind of where we are with JavaScript, which is JavaScript is still too low level of a language to be using to go write your programs. And Copilot does speed that up, which is great. But I think where we'll see hopefully something like a 10 or 20x jump, maybe you see a 10x jump, for example, by going higher level with Retool. And you see a 2x jump on top of that, for example, by incorporating AI into Retool.

We think that programming still is too low level, and we want to still make it a much higher level. And then you can graft AI on top of that, which will be another 2x on top of that.

Changing gears, I want to ask you, what is an area or a playbook that you feel you've developed really well at Retool such that if a founder of a new company comes up to pitch you and asks you some question, you're like, oh man, I have got exactly the answer for you. Let's sit down for an hour and I can whiteboard you the exact right way to do X with your company. What do you think X is?

I think there are a few chapters of Retool. I think the early, the first chapter of Retool, it was probably finding product market fit via sales. We can go much more in depth into that. I think it's actually pretty interesting. At the beginning, there was never a time that someone would use Retool without us watching them. So we were always sort of spying on our users basically at the beginning. And

Physically or digitally? Digitally. So basically we had this integration where anytime we built our own analytics server, where if anyone was using the product, we'd immediately get notified and we'd immediately go on a full story and watch exactly what they were doing. And,

Obviously, you know, because virtual is such an early product at that point in time, there were going to be issues. And when there were issues, we would immediately call the customer up and say, hey, we saw that this error came through. We'd love to help you out. The customer wasn't reaching out to you. You just like intuited from what you were seeing that they were having some problems. Yeah. And I think when we reach out to customers or as an early stage, when we were first getting started, when we reached out to customers, basically no one wanted to talk to us because they're like, just go away. I'm a developer. I don't want to talk to you.

Whereas if you reach out exactly when they're using the product and just ran into an issue, they would love to talk to you. That is an example, I think, of sort of sales really paying a lot of, like talking to customers at the right time, really paying a lot of dividends because then we'd go fix the issue for them and be like, wow, this is like the best support experience I've ever had. Where before,

I even told anyone I had a problem. They knew I had a problem and they fixed it for me. I love this product. Great. Can I interest you in a renewal and an expansion? Well, at that point, it was actually just signing the contract. Yeah.

So I think that's maybe one sort of customer acquisition at the beginning. I think the second chapter of Retool is about sustainable growth, which is sort of how do you grow quickly, but actually be cashflow positive. How do you scale up a go-to-market and an EPD, engineering product design team, while not being dependent on VCs is maybe another interesting one. Yeah. Can we double click on that a little bit for two reasons? One, I think that is probably...

highly relevant to people listening today in 2023. And also to our earlier conversation about contrarian, I suspect highly contrarian for you to have done during a zero interest rate environment. I assume you probably had available to you options to burn a lot of money. Why did you decide not to and how did you do it?

I think it was mostly a sort of sovereignty thing or something like that. Like in the sense that if you start burning a lot of money, you become basically beholden to VCs because it's very hard to reverse. I think the sudden burning of a lot of cash. You could do, you know, a 80% layoff, for example. I think your company's kind of toast if you do that. So that's, you know, pretty difficult. So that was one of the main reason. The second was I just didn't believe that there was that much work.

In the sense that with a SaaS company, I think what's really pretty phenomenal about software nowadays is that it's so leveraged in the sense that you can get to probably, I think, in almost any industry, probably, I think, one mil or five billion ARR with basically a team of maybe five or 10 people, I think.

And if you're able to do that, I think one maybe underrated phenomenon is it's actually very hard then for you to actually burn that much more cash in the future even. So sort of you set yourself up for a lot of success. Because let's say if revenue is growing three X year on year, for example, it's actually pretty hard, in fact, to grow your company for the three X year on year. And so what happens is if you start off in a roughly cash flow positive state, so let's say a few million dollars of revenue, maybe less than 10 people or something like that,

Then as long as revenue is growing pretty quickly, you pretty much will just be cash flow positive for the next two, three, four, five years, actually. So I think – Right. You're set on the right direction. Because you're saying if you are actually tripling revenue and you haven't staffed up a large organization, it's kind of hard to triple your burn, which is mostly headcount. Like it's hard to triple your people revenue.

Like there are a lot of counter forces to hiring 3x year over year over year, whereas for at least the first three or four years, it is quite reasonable to 3x and a product that people want, you know, in those first three or four years. Totally. Yeah. I'm wondering now if actually you were YC batchmates, but close friends of the show Vanta. This is basically their story of they did this, too.

Yeah, I know Christina. I have immense amounts of respect for what Vanta has accomplished and will accomplish yet to come. And I think this is a playbook that now is becoming more available to startups because it is becoming more clear that you can, through the power of software, actually achieve 1, 2, 3, 5, an ARR that's recurring. And if you have positive NDR, it's sort of such a strong tailwind that you don't need to hire that much at the beginning, actually, in order to do so.

Can you define NDR for us? So NDR is net dollar retention, which is if let's say you have 10 customers paying you, let's say $100 in aggregate, and let's say 2022, for example, at the end of 2022, NDR is basically at the end of 2023. How much are that exact same set of customers paying you at the end of 2023?

And so let's say one customer turns, for example. So they used to all pay you $10. Now you're down to $90. But actually, the remaining nine customers actually expand. They double usage of your product. Then you actually are generating $180 out of the $100 base, basically.

And if you can actually repeatably do that, that basically means you sort of get almost quote unquote free 80% growth year on year, which is really phenomenal if you're able to pull that off. It's serious leverage when you multiply that times your actual growth from new customers. A lot of the growth is being done for you. So it's an extreme tailwind to growing revenue as long as you have a sort of fixed go-to-market motion to acquire a new customer base. Totally. Yeah.

I heard a crazy stat this morning, especially in the acquired slack in the random channel. Someone was posting that snowflakes NDR is 158%. Just like an astonishing customer that's paying you a dollar this year just shows up with a buck 58 next year without you doing anything to reacquire them.

Yeah, the year after the show for $2.25 or something. So it's wild. This is kind of a new concept for me. What you said, if with a very small team, three to five, maybe 10 people, you're able to go and get millions of dollars of revenue before staffing up.

then like a lot of natural laws of business physics will prevent you from getting over your skis and burning too much cash. And it's only when you sort of staff up a big team, but you're not at any meaningful revenue. You could imagine we all know lots of companies that are 30, 40 people, but with

500k of revenue, 2 million of revenue, something like that, because they raised a lot of money. It's really hard to come back from that. So it's this interesting, like, what's the phrase when they say it's expensive to be poor, but it's cheap to be rich. It's that sort of same thing where there's like extreme rubber band effect on either side. Yeah. Yeah.

And it is painful in the beginning, but actually it's not that painful because if you haven't hired anyone, you don't know what that feels like. And so you're like, well, great. I'm used to working, for example, six days a week, 16 hours a day. And that's just how things should be. And then when you find yourself a few million dollars in an ARR and let's say five people at the company or 10 people at the company, then you're

you can start hiring. And then you're like, wow, this is like tremendous leverage actually to go hire people. I see why having a larger team could actually be really helpful. But then at that point, it's actually hard to grow the team, you know, three, four X here and here. So would you categorize that as kind of the next chapter of retool after your, you know, let's get to five, 10 million in ARR on a small team. At some point, clearly, you know, you did raise a lot of money. How did you think about that? Were you ever tempted to be like, you know,

I could just kind of stay, keep doing this, running a really nice cash flow generated business without venture capital. Was that tempting or were you like, how did you make the decision? Yeah, we did think about that, actually. The reason why that option was available was because we were small and we were actually making, you know, $3, $5 billion in ARR. And if you do the math, even if you tried to evenly mouse everyone, which maybe is the fairest thing, and let's say you moved to Hawaii, you could actually live, you know, it's actually a pretty good life.

And so when we raised a Series A from Sequoia, we did actually kind of think about that, which is, hey, you know, should we go raise a Series A and actually go raise VC dollars? Or do we just want this to be sort of a pretty good lifestyle business that could probably honestly grow another 3, 4, 5x without any outside capital from here? The reason why we ended up raising the Series A from Sequoia is

was because we thought the opportunity was so much larger. We genuinely, truly believe that Retool could be the way that maybe something like 10, 20, 50% of all software is built in the future.

And in order to achieve that, it's going to take really heavy, sustained investments in the product on the go-to-market side to make that happen. But if we're able to do that, I think the opportunity is so, so, so large. And so for that reason, we decided to go raise more capital in Series A. And for that reason, we decided to hire more people, too. And I think that maybe is now, I would say, the third chapter of Retool, which is

We've now proven out that clearly sort of the TAM is incredibly large for Retool. Today, we have many, many, many companies using Retool. But when I look at something like AWS, for example, AWS has, I think, around a million or so customers. We're not at a million customers yet.

And I think they are doing something like maybe $60 billion in run rate. We're not there yet either. And so we need to get there. I remember from our AWS episode, yeah, the $80 billion and the most mind-blowing stat of AWS is the revenue backlog is over $100 billion. Yeah, it's nuts. And I think that maybe speaks to the TAM of a horizontal developer platform.

It really is just so large because there is so much software being built every day, every year. And it all needs to run somewhere. It has to be built in something, hopefully Retooled.

For that reason, I think the opportunity was so large that we thought, hey, you know, even if, let's say, it's a 30% chance or a 10% chance of getting there, for example, we'd rather go for that rather than have this be a lifestyle business. And so that was sort of the impetus behind raising capital. And I think that's what now we're mostly preoccupied with is how do we get to a million customers and eventually one day $80 billion in run rate. That's going to be challenging, but it's the ride that we're excited about. So.

As you sit here today, what are those big items on the roadmap or roadblocks along the way to like, what is the journey look like to get there? Yeah.

If you look at the history of AWS, it basically starts with two product lines. It's S3 and EC2. And then they sort of add more and more product lines. But those... Databases. The greatest business model known to man. Totally, yeah. And it turns out, actually, that even EC2 and S3 sort of have giant markets by themselves. You know, I would not be surprised if EC2, I'm sure, itself is, you know, certainly probably a $10 billion plus earn rate business, too.

And so I think the story is somewhat similar for us, which is I think we now have actually four product lines. So we actually launched three product lines in the past 12 months or something.

And that's pretty exciting too. But we now have four product lines that each are all sort of growing pretty rapidly. But we want to go launch more product lines. We want to get to the point where sort of all software can actually be built inside of Retool. So we started off, for example, just a front-end builder, which is great. You know, some percent of software is front-ends, but some percent of software is not front-ends. So we expanded out into sort of back-end storage with a product called RetoolDB. We expanded out into a back-end logic product called Workflows. We expanded out into mobile front-ends. It's called Retool Mobile. And we expanded out

And so I think now what we see is you've all probably seen this chart, a sort of stacked revenue growth over time. And you can see, you know, at the beginning, the new product lines are starting off very small, but actually getting bigger and bigger and bigger and bigger. And our plan now is to continue growing all those product lines, but also to launch new product lines in the future as well.

So that's, I think, one lever is sort of more product lines that allow more software to be built inside of Retool. The second really is just distribution. It's how do we get... And I don't know if tame is the right word, but the opportunity for that is basically infinite. I mean, like, how many product lines does AWS have now? Yeah, totally. Yeah.

And the second lever, I think, is awareness, which is how do we get more developers aware of retool? And I think this is a challenging problem because developers actually are all, they all know how to build internal tools. If you ask me, if you ask any other developer, you know, I want you to go build a front end for me to go manage all the lawns that I'm mowing. Every developer knows how to do that. They're not Googling how to go build lawn mowing front end CRM. There's like

No problem. I got it. I'm going to go start a database. It's been one up. Right. So it's hard to capture them when they're in the intent phase. Exactly. Yeah. In that way, Retool is a challenging startup because it's not like a rip and replace, if you will. It's not like, oh, there's already this line item that everyone already buys. We're just a better version of that. Buy us instead. Instead, it is, oh, I didn't even know I needed the internal tools development platform. Is that even a problem that I have?

And so I think from an awareness building perspective, that probably is our biggest challenge now is how do we get more people aware of the product and the problem and the solution, if you will. What are you doing on that front? Yeah.

Right now, we have maybe five or 10 different engines that are all going on how we build more developer awareness. And so some engines, for example, are we might do honestly just brand marketing. So for example, we recently wrote this post about Visual Basic that went viral. And our head of design probably spent maybe six months writing that post. Not full time, maybe let's say three weeks of full time work writing that post.

And in most sort of ROI, there's no way to justify that ROI. Like we're running a blog post that has nothing to do with Retool. It's on the history of Visual Basic. It doesn't really tie into Retool at all, actually. And yeah, we spent a lot of time on it. And it really paid dividends, actually. And so that's maybe sort of one almost like brand awareness play, if you will. We've written a blog post about like, what is SAP? And why is it a giant company, for example? We've written another blog post about what's Salesforce? And why is it a giant company? Yeah.

Oh, this is great. David and I were just talking the other day. We were like, neither of us understand SAP, so we have to do an episode on it. So this is good to have a primer. Yeah, yeah. So we write sort of content marketing, if you will, like that. But that's good content marketing. It's not just, you know, sort of SEO junk, if you will. And that, I think, gets a lot of eyeballs. And some percent of those people are like, oh, interesting. I actually could use Retool, actually. What's this Retool thing? Let me go click on the logo, for example. So that's maybe sort of one engine that we have.

There are other engines ranging from, oh, well, maybe people to Google for, let's say, lawn mowing front end, but maybe people to Google for, let's say, Firebase front end. So maybe they're lawn mowing, they've chosen Firebase as their backend, for example, for the lawn mowing CRM. And they're like, okay, now I need a front end for it. Well, let me Google best Firebase front ends, for example. And so SEO, SEM is another major lever for us.

We're now experimenting a little bit now with Outbound, which is pretty interesting. But Outbound is a sort of pretty fickle, if you will, engine, because I think it depends a lot on do you get them at exactly the right time.

Because if I emailed you with a problem that you're having literally 10 minutes ago, you probably would reply, actually. But 99% of the time, you're not going to reply. And so figuring out how can we identify people that are building internal tools and are really experiencing the pain, for example, or frustrated at it is challenging, but something that we're working on. So those are maybe a few examples of engines, if you will, that we're working on. But yeah, it's fun.

I want to change directions. When you first started the company, it was your idea and your force of will that created the company at all. And I'm sure now there's a lot of things where if you are still doing them, it's a problem. And it's a massive game of trust and finding the right talent and delegation. I'm curious what things you think it's still important for you to hold on to as the CEO. Yeah, this is a...

Really fun topic. I was chatting with a few founder friends recently. We were discussing what are decisions that you made in your company that actually made a difference in the sense that every day, I think we all make a lot of decisions. But to be honest, a lot of decisions are kind of low impact. They are a lot of them reversible. It doesn't really matter that much.

I think the consensus we got to was every year, there's probably maybe three decisions that are actually important that you need to make. The problem is you don't really know what those three are beforehand, but in retrospect, it generally is obvious. And I think maybe it's a weird analogy, but I think in life, it's also similar too. In life, you make a lot of decisions about do you have ice cream today or not, for example, but probably that doesn't matter that much. Probably the path that got all of us here comes down to probably five or 10 decisions you made in your life. And so-

I think preparing yourself for those maybe three important decisions is important. I think being very close to the business so you understand at a very granular level what is going on so you have a very firm grasp on reality so you can increase the probability of making the right decision is also very important. I think maybe sort of having a low ego or being willing to admit when you're wrong is also important, too.

There are definitely product lines that I thought we shouldn't start. And I was wrong. I had never been successful. So, yeah, I think those are maybe some principles that at least the group that I was in talked a bit about. But it was interesting. There was one founder in the group that they were the founder of maybe a popular streaming site you may have heard of.

And his perspective was there was really only one decision that he made over the past two years that really mattered. And it was during COVID, he decided to buy more servers, which is a very contrarian decision. Everyone was like, oh, I don't know. Like, I don't know if I should buy more servers. Who knows? There's a lot of uncertainty. And he was like, no, I think we need to buy more servers. I think people are going to be cooped up at home. Streaming is going to be big. And that was the one decision that I think allowed them to scale revenue maybe 10x or something during COVID.

And had they made the decision even three weeks later, for example, they would not have been able to scale revenue. Maybe revenue would have grown 2x instead of 10x. So I think it's, yeah, it's hard to know when decisions come up, but they do invariably come up many times a year. And you have to be prepared by just knowing your business really well, being really sort of deep in your business, and also be willing to admit when you're wrong.

Can you recall an instance, I'm sure recent examples are a little bit harder to talk about publicly, but an instance earlier in the company where you had one key decision that changed their trajectory based on the decision that was made? I think there's one that we're making actually right now, which is pricing related, which is to date, Retool has mostly priced. I would broadly say we're testing the waters to understand the value that we provide.

And the pricing that we have reflects that. Where in some cases, if we're delivering a lot of value, we might price commensurately. And when I think about our mission of Rattery Tool, which is we want to actually become the way software is built...

It is kind of antithetical to that, which is revenue is obviously helpful, but it's actually not the one thing that's important. In fact, the one thing that's important is how do we get more people building in retool? And so while it's great that we're growing revenue very quickly, I think there's actually a bigger opportunity of, hey, what if we deprioritize revenue growth for the next, let's say, three years and instead focus on how do we get, instead of, you know, let's say growing usage 2x, 3x year-on-year, why don't we try growing usage actually 10x year-on-year?

And if we can do that, then I have the full faith that revenue will grow 10, 100x, five, six, seven years from now. That's an example of a decision that is not easy to make. I mean, it will involve us deciding to actually forego revenue growth over the next, let's say, year or two in order to capture substantial revenue growth five, six, 10 years from now.

And so that's an example of a decision, I think, that in the end has to be the founder CEO's decision of do we make that better or not? Because it sort of, you know, it affects all areas of the company. It affects how quickly you hire, how fast your company is growing. It affects everything. And does that mean your revenue could actually temporarily go down? Like, will these pricing changes affect existing customers? It does. Yeah. In fact, we will be sending emails to customers saying, hey, did you know your bill is now lower actually than before? Yeah.

And I myself have never received email like that before, but I think that it's going to be hopefully incredibly energizing for a customer to receive. And hopefully they'll actually tell their friends about Retool. From our perspective, we care more about can we

to genuinely change the trajectory of how software is being built today in the world, rather than can we maximize our revenue in 2023? And I think we're fortunate to have a board that is so supportive and investors that are so supportive of that, because they're also not here to say, like, hey, let's go, you know, make a retool, let's go double the valuation to sell the company. No, the goal is actually to grow the valuation, hopefully 10, maybe even 100x from where we are today.

Even if it's, let's say, a 50% chance of that actually happening. You can attribute this in part, of course, to the farsightedness of your investors, but a huge amount of it is because you've left yourself the flexibility as the operator of the company to make decisions like this in not having an enormous cash burn.

But generating a good amount of revenue, if you do make less revenue, it's not like, oh, my God, now we've massively widened our cash burn in a way that makes our business unsustainable. You spent years buying yourself the optionality to make a decision like this. Totally. And I think that's maybe another underappreciated aspect of sort of the cash flow positivity or the sovereignty, if you will, is that it gives you a lot of space to make these kinds of decisions. Right.

Because if, for example, we're burning a lot more money and we had, let's say, a year or two of runway left, which is not the situation we're in, but if that were the case, I'd be very nervous about making this kind of decision because we're like, oh, man, like, we actually can't do that. You know, we're sort of our backs to the wall. We cannot prioritize usage above revenue. We just have to prioritize revenue because otherwise we're going to go out of business. And we're really fortunate that we're not in that position. So.

All right. We talked a lot about sort of the rosy parts. Do you have an example of something that you were hopeful would be trajectory changing for the company, but was a failed initiative? Yeah, there are so many examples of this too, especially in the early days. And this actually may be to some extent is the downside of having a sales first motion and the early days.

Because what happens when you have a Salesforce motion is you sort of vacuum up a bunch of weird use cases. And you have to decide whether to serve them or not. Your memory is actually quite failable when it comes to this stuff. If someone else asked me, what were the early days of retail like? I'd be like, oh yeah, it was like great. We hopped on calls, we closed deals. Life was super easy. It was great.

And just for fun, the other day, I was looking at my calendar from, you know, three, four, five years ago. I'd be like, I wonder what I was doing five years ago. Let's take a look at a day in the life of David five years ago. And I was like, wow, I remember that customer that I talked to. I remember that customer that I talked to. And none of them closed, actually. And I remember there were so many sort of things that I got so excited about where there was one example of a customer that was...

They basically have built a platform, almost like a Firebase-like platform. So sort of a developer platform, like a Heroku-like platform. And they were like,

Hey, I really want to go buy Retool for all of my customers because, you know, we have all the data in our platform and we want to sort of an app building experience on top of our platform. And I was like, wow, this is huge. This is the future of Retool. These guys will get us distribution like crazy. In fact, we should go target Firebase, we could target Parse, another sort of app development platform. We should go sell Retool to all these companies.

And that deal never closed because there was not really, you know, the sort of person on the other side of the call was kind of broadly interested and curious in, you know, adopting Retool in that way. But it was honestly not that much intent or urgency for that person to go make a purchase. And I remember getting so excited about it. I was like, this is literally how we're going to be distributing Retool going forward. And I was totally wrong. So I had wiped that incident from my memory entirely because maybe it was a bad memory or something. So.

I really like your framing, you know, from earlier, going back to your philosophy degree of like understanding reality and trying to, I would, I was smiling as you were talking about that, just thinking about like acquired, you know, like a very, very different business and product. But like Ben and I have had so many conversations like that too, over the years. Oh, this is the future of acquired. It turned out.

Many of those were not the future of Acquired.

Are there any embarrassing ones? Oh, yeah, definitely. We renamed the show. Like, this was a terrible, terrible decision. I'm like, it's painful even to think about this. This was totally my fault. We spent five years building brand equity behind Acquired. And then in one stupid phone call, David and I said, wow, COVID hit. We should, for some reason, change the show name to Adapting to show how serious we are about changing to telling stories about people that are adapting to COVID. And like...

We destroyed. It was truly a moronic decision. Does Rolex ship a watch one day that they're like, oh, by the way, it's Roblox or, you know, like, no, no. That's like the one thing you can't change. Yeah. Oh, it turns out we're in a brand business. Like, oh, yeah.

It's been interesting realizing we're in a business at all. We're in this period right now where we're like, oh, wait, we do sales. Oh, right. Neither of us have any idea how to sell. We work with, I don't know, a dozen customers a year who are our sponsors. To date, those have just been relationships where they sort of come to us and we're like, oh, we love the idea of working with you. We love your product. I think we can write a bunch of really unique copy around it. Like, here's a cool thing I think we can do together. And David and I were on a call the other day and we were like, how do salespeople...

Like, what is a go to market motion around this? And it's so embarrassing because you would think this is a thing we would be good at right now. But you just don't realize the business you're in because it happened so organically. But I think similar not to make this about acquired, but like what a lot of what you've been saying resonates with me so much of we even more extreme than you control our own destiny. Like we have no shareholders except us. Nobody's forcing us to do anything. Yeah.

Do you think having shareholders is beneficial to light a fire or motivate you in some way that you wouldn't have been otherwise?

No, I don't think so. If you are counting on shareholders to pressure you, and there's so many public company analogies here that could be fun to make, but you're probably not being motivated about the right things. I am motivated to maximize shareholder value, but we do that in the way that we think is right. Not because some shareholder called us up and said, oh, what about this? What about that? So, yeah.

I think intrinsic motivation is maybe, if anything, sort of a core value that I think a lot of retools, which we call retool employees, actually really share. And that is such a powerful fire. People succeed at doing what they want to do. And people do things that they don't want to do for all sorts of reasons. But ultimately, you're not going to do it as great as if you wanted to do it.

Yeah, we have agency and intentionality. That's disgusting. Yeah, right. Back to GPT-4. As we drift toward a close here, I did want to ask, do you imagine AI playing a role in retool in the future? And will we program with natural language? How do you think about that? I certainly think AI will play a role in retool. I think natural language will play some role, but not as big of a role as Twitter may make you think.

And I think when we think about the past, or even just sort of using tools in general, you typically use the right tool, the right medium for the job. And so natural language, I think, is great, for example, for getting something started. If you want a quick mock-up of something, natural language is really good for that. But oftentimes, you want something specific. We're trying to pick a color, for example.

probably if you have a color picker, you can get to your specific color exactly what you want, you know, the color wheel thing, you can pick exactly what you want very quickly. Whereas if you're forced to only use natural language for that, you could be like, oh yes, it's more red or less red than this. Oh, more red. Even more red than that. Yeah, please, yeah. That's just honestly pretty inefficient. You might as well just pick exactly the red that you want. And so,

I think natural language is great for many tasks, but it's not great for all tasks. Code is great for many tasks, but also not for all tasks. Visual programming is also great for many tasks, but also not for all. And so I think sort of, if anything, AI or natural language is sort of another tool in the toolbox, if you will, that I think we have to provide to all of our customers. And I think it will lead to great outcomes, but it is definitely not the only tool. And this, I think, gets back to sort of

I was talking to Ryan Lucas, our head of design, recently, and his perspective was, when we talk to each other using natural language, we already, between humans, have so much misunderstanding. And if that is the only way you have to program a computer, we're going to be in a world of pain. So...

It's funny, I had a very similar conversation recently where if two engineers send each other a pull request, it is exact what the communication is. Like it is literally saying these are the instructions to a machine. Can you look at them to ensure that they are doing what this contract says that it should do? But if two people are having a conversation...

at least this is my understanding, the brain's capability, the spectrum for information in the brain is much higher bandwidth than any given language. So when I translate a thought into English, it is going through severe compression. And I am communicating that to another person for which they could misunderstand it. Like a word could trigger a different emotion for someone else than I mean when I say it. And then

they go through a decompression where they extrapolate that onto their brain and it could light up a completely different set of neurons than was originally lit in my brain. But we only have this lossy low bandwidth medium to communicate through with language. And now we're trying to use that same terrible, terrible high compression, low bandwidth language to interface with computers where we can have exact specificity. What are we doing? Yeah.

This is like why math equations exist. We could do math without equations and without any notation, and we just talk about math all the time. But it'd be incredibly imprecise. Probably none of us would have any idea what the other person is talking about. But when you write it down specifically, it's so much more helpful. Well, David, this has been a blast. To close down the episode here, where can people learn more about you and Retool if they're sort of curious to explore some of this conversation further? Yeah, find us at retool.com or me at dvdhsu.

That's great. Well, thanks so much for joining us. Listeners, we'll see you next time. We'll see you next time.