Retool CEO David Hsu on Finding Product-Market Fit via Sales

24:32And alumni had this problem. So it's probably great network to go access them. YC I think is helpful for at least two reasons. One is there is a real competitive dynamic among 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 reason speakers every week. And we were talking a bit before this podcast. But what you really learned from the speakers is not really sort of tactical and strategic advice.

25:13It really is you learned 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 hearing stories about how fucked up those two companies were when they were two people, five people or ten people, it was so motivating to us because every startup has so many sort of warts and so many sort of problems to start up. And it's easy to over focus 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.

25:53Wow, maybe I could do that too. 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 or some feedback that can be discarded and I think is actually useless.

26:26But I think especially from other batch mates, 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 when batch mate actually, I think said that they wanted to save a few years of my life or something. But 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 re -tool, which is it's so hard to build something, you know, that sort of suits these as everyone.

27:01Well, if you look at JavaScript, for example, or React, for example, React is not verticalized. JavaScript is not verticalized. Programming language is not verticalized. Use them for everything. Social media companies use them. Banks use them. They always 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 an 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.

27:37However, 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, code is the best way to get a computer to do something. Yes, it is completely agree. 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 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.

28:13And 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 if you called them primitives earlier, but in your demo video, you can drag what looks like a table.

28:49You 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 crowd operations earlier. Could you define that for those who don't speak computer science in the room? Yeah. Crowd -based, it stands for, it's kind of a funny accurate sense, but create, read, update, destroy. So it basically is maybe, let's say, creating a record in your database, reading it, update. So hypothetically, if you are, for example, mowing lawns, you might want to record all the lawns that you've mowed without creating a record.

29:26Maybe someone put in a lawn that they want to be mowed and you want to say, I have mowed it. So it's updating, destroying, would be deleting a record. We have to say it actually that probably 50 % of all software in the world is basically just doing crud. And developers, day in and day out are just building the software and it is the most boring software port cut. And I think that's maybe sort of another reason why we think developers like retool is because no one wants to work on it. 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.

30:01Like it's a trope that programmers, if you're an extremely technical person and you're evaluating a new business opportunity, you could, 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?

30:32Well, 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 a lawn as, you know, to be moan or has already been moaned, build like 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 or 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 these three libraries that you don't understand.

31:13And somehow this is like, okay, it's 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 run it overnight and you come back the next day, you're like, oh crap. Well, okay, let me do it again. So the real 10X increase in productivity.

31:49But if you look at the past be 30 years or so, the languages are kind of the same. JavaScript has obviously gone a little bit nicer for 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 for him, which is a little bit smarter. But we're kind of doing the same thing. So if you sort of just graph like productivity of engineers over time, 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.

32:24So 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 what I'm 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 rate SQL queries, are they facile enough for the product to now be for them to? I think it goes back to what you were saying. Is that is sort of do they understood 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.

32:57And 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 it feels great for that. And we see a lot of that happening within a customer base today. I think maybe something like 25 to 30 % of retool builders are those kinds of people that I managed to pick up SQL or JavaScript, but we're not engineers to begin with. So I think the wave that we are writing that is probably different from the wave that I think no code aims to write is instead of democratizing programming and making sort of dumbing programming down.

33:29Instead, we're saying a lot of people that graduate college today maybe don't have a comp site degree, but have taken one comp site class or able to pick up SQL or pick up jobs we 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. So 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 co -pilot 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 your 30 % your time, your x -man faster, just the 50 % time, you do two times as fast, which is pretty good.

34:13But 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've had an AI that would go punch cards for you, for example. That's pretty good. You can still program, you know faster than punch cards yourself, but fundamentally if you as a human go read the program, you're like, oh, it's kind of hard to understand. I'm going to try to reason the holes here and we punch this hole. So what does that mean? So it's kind of hard to reason about. Then save with assembly, right? Let's say that, for example, you had co -pilot for assembly, that's great.

34:45You know, you could go right assembly, let's say twice as fast now, but you're still writing assembly. If 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 retrograms. And co -pilot does speed that up, which is great. But I think where we'll see hopefully something like a 10 or 20 x jump, maybe you see a 10 x jump, for example, by going higher level with retool and they see 2x jump at top of that, for example, by incorporating AI into retool. We think that program is still as too low level and we want to still make a much higher level and then you can graph day on top of that, which would be another 2x top so.

35:22Changing 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 wipe over 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.

35:58At 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 at any time we built our own in a little 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 retool such as early product at that point of time, there were going to be issues. And when there were issues, we were immediately called the customer up and say, hey, we saw that this error came through.

36:33We love to help you out. The customer wasn't reaching out to you. You just like, intuitive 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, we were just 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 it to 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 right at the right time, really paying a lot of dividends.

37:07Because they would 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 them they wanted a problem, they knew I had a problem. And they fixed it for me. I love this product. So great. Can I interest you in every new one? I think it's an expensive one. Well, that's what it was actually just starting to the contract. So I think that's maybe one of the sort of customers 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 casual positive.

37:36How do you scale up, uh, I go to market and an EBD engineering product design team, while not being dependent on VCs was maybe another interesting one. Yeah. Come in, 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.

38:17Like in the sense that if you start burning a lot of money, you become basically beholden to VCs because it's very harder reverse. I think the sudden burning of a lot of cash. You could do 80 % layoff, for example, but I think your company's kind of toast if you do that. So that's 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, 1 ,000 or 5 billion AR, basically a team of maybe five or 10 people, I think.

39:00And 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 it's sort of you send yourself up for a lot of success. Because let's say if revenue is growing three extra on year, for example, it's actually pretty hard, in fact, to grow your company for the next year on year. And so what happens is if you start off in a roughly cashable positive state. So let's say, you know, a few million dollars of revenue, maybe plus than 10 people or something like that, then as long as revenue is growing pretty quickly, you pretty much will just be cashable positive for the next two, three, four, five years actually.

39:34So I think 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. 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, those first three or four years. Totally. Yeah. I'm wondering now if actually you were a YC batchmates, but close friends of the show, Vanta, this is basically their story of they did this too.

40:13Yeah. I look, we're see that 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 one, two, three, five and 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 an aggregate and let's say 2022, for example, the end of 2022.

40:55NDR 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 churns, for example, so they used 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 $100, $80 out of the $100 base basically. And if you can actually repeatedly do that, that basically means you sort of get almost quote unquote free 80 % growth a 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.

41:33A 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, it's actually 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 book 58 next year without you doing anything to reacquire them. Yeah, the year after the show with $2 .25 or something. So it's wild. This is kind of a new concept for me what you said.

42:10If 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 a lot of natural laws of business physics will prevent you from getting over your skis and burning too much cash. 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, what's the phrase, when they say it's expensive to be poor, but it's cheap to be rich.

42:49It's that sort of same thing where there's like extreme rubber band effect on either side. Yeah, it is painful at 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, six hours a day. And that's just how they should be. And then when you find yourself in a few million dollars in a year, or let's say five people at the company, or 10 people at the company, then you can start hiring. And then you're like, wow, this is like tremendous leverage actually to go hire people.

43:19I 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 acts 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 it? Were you ever tempted to be like, you know, I could just kind of stay keep doing this running a really nice cash flow generator business without venture capital? Was that tempting? Or were you like, do how did you make the decision?

43:55Yeah, 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, three, five billion dollars an ARR. And if you do the math, they would do giant evenly miles every one, which maybe is the fairest thing. And let's say you moved Hawaii, you could actually live, you know, it's actually a pretty good life. And so 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 three, four, five X without any outside capital I from here?

44:31The reason why we ended up raising that series in Sequoia was because we thought the opportunity was so much larger. We genuinely, truly believe that Ritual 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 this series A. And for that reason, it was not a high -more people to.

45:12And I think that maybe is now, I would say, the third chapter of Ritual, which is now proven out that clearly sort of the tab is incredibly large for Ritual. Today, we have many, many, many companies is a Ritual. 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 rather than either. And so we did get there. And I remember, uh, from the WS episode, yeah, the 80 billion and the most mind -blowing stat of AWS is the revenue backlog is over $100 billion.

45:49Yeah, it's nuts. And I think that maybe speaks to the, uh, tab of a horizontal developer platform. It really is just so large because there is so much software being built every day, every year. Uh, and it all needs to run somewhere, where does we built in something? Hopefully Ritual. 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 dollars in run rate.

46:31That'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 does the journey look like to get there? Yeah. If you look at the history of AWS, it basically starts with two product clients. It's S3 and EC2. And then they sort of add more product lines, but those databases, the greatest business model known to man, totally. Yeah. It turns out actually that even EC2 and S3 sort of have giant markets by themselves. You know, I would not be surprised if I'm EC2, I'm sure itself is, you know, certainly probably a 10 billion dollar plus run rate business too.

47:09And 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 through 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 the Zilvocitor front end builder. Which is great. You know, some percent of software's front ends, but some percent of it's not front ends.

47:36So we expanded out into sort of back end storage by the product called ritual DB. We expanded out into a back end logic product called workflows. We expand out of the mobile front ends. It's called ritual mobile. And so I think now we'll see as you've all probably seen this chart sort of sort of stacked revenue growth over time. And you could 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 to feature as well.

48:05So that's one lever is sort of more product lines that allow more software to be built inside of retool. The second really is just distribution. And I don't know if Tame is the right word, but the opportunity for that is basically important. 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 the challenging problem because developers actually are all they all know how to build a tool tools. If you ask me, if you have any other developer, you know, I want to you to go build a front end for me to go manage all the lines that I'm going, every developer is out of that.

48:43They're not googling how to go build on knowing 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 rapid replace, if you will. It's not like, oh, there's already this line out of everyone already buys, we're just a better version of that buy. Yes, instead, instead it is, oh, I didn't even know I needed a 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.

49:23So 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 maybe, let's say three weeks of full time work writing that post. And in most sort of ROI, there's no one he just had that ROI. Like we're running a blog post that has nothing to do with retool.

50:01And so the history of Visual Basic, it doesn't really tie the 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 place, you will. Verna blog post about like what is SAP? And why is the giant company, for example, verna another blog post about what Salesforce and why is it a giant company? Oh, this is great. Dave and I were just talking the other day, we're like, we're either about to understand SAP. So we have to do an episode on it. So this is good to all the primer. Yeah. Yeah. So we write sort of content marketing, if you will.

50:31I like that, but it's actually good content marketing. It's not just, you know, sort of a CEO junk, if you will. And that I think gets a lot of eyeballs. And some percent of those people are like, oh, interestingly, I actually could use virtual actually. What's this ritual 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 fire bases, they're back end, for example, for the lawn mowing CRM.

50:59And they're like, okay, now I need a front end for it. Well, let me Google best fire Ms. Frontend, for example. And so I see OSCM is on the major level for us. We're not experimenting a little bit now with the outbound. It's 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 of 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.

51:35So this is what might be 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 there'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 of 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.

52:26But to be honest, a lot of these things are kind of low impact. They are a lot of 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 do to bake. 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 point of 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, the problem 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.

53:00So 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 and 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 do it when you're wrong is also important too. There are definitely product lines that I thought we shouldn't start. I was wrong. Now there's nothing else. So I think those are maybe some principles that are like the group that I was in talked a bit about.

53:36But it was interesting. There was one founder of 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 service. Oh, it's a very good thing to say. I don't know. I don't know if I should buy more service. I know 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. She means going to be big. And that was the one decision that I think allowed them to scale revenue maybe 10X or something during COVID.

54:11And 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 to X instead of 10X. So I think it's hard to know when the decisions come up, but they do invariably come up many times a year. And you have to have heard by just knowing your business really well, being really sort of deep in your business. And also, I'll be willing to admit when you're wrong. So 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.

54:46I think those want 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 retool, which is we want to actually become the way software is built, it is kind of end -of -the -thetical 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?

55:28And 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 do prioritize revenue growth for the next little six three years? And instead of focus on how do we get instead of, you know, let's say, growing usage 2x3x3 on year, one of which are growing usage actually 10x3 on year. And if we can do that, then I have the full faith that revenue will grow 10 -100x, 5, 6, 7 years from now. Yeah, that's 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 5, 6, 10 years from now.

56:06And 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 not because it sort of, you know, it affects all the way, or is the company affects how quickly you hire, how fast your company's growing, it affects everything. And does that mean your revenue could actually temporarily go down? Like, well, 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? And I myself have never received email like that before, but I think that's going to be hopefully incredibly energizing for customers to see even hopefully they'll actually tell their friends about retool.

56:44From our perspective, we care more about can we genuinely change the structure of how software is being built today in the world, rather than can we maximize a 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, hey, let's go, you know, make a retool, let's go double the value to sell the company. No, the goal is actually to grow the value. Hopefully, 10 maybe even 100x over here today, even if it's let's say a few percent chance of that actually happening. So you can attribute this in part, of course, to the first sightedness 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.

57:29If 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. Because if, for example, we were 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 would be very nervous about these kinds of decisions because we're like, oh man, like, we actually can't do that.

58:03In our sort of our backs, the wall, we cannot prioritize usage of revenue. We just have to prioritize revenue because otherwise we're going to go to business and we're really fortunate that we're none of 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 the sum of sense, the downside of having a sales first motion and the early days, because what happens when you have a sales first motion is you sort of vacuum up a bunch of weird use cases.

58:42And you have to decide whether to serve them or not. Your memories actually quite failable when it comes to this stuff. If someone else asked to be, or there really is a ritual like, oh, yeah, I was like, great. You know, we hopped on calls because deals life was super easy. It was great. But then just for fun, the other day, I was looking at my calendar from three, four, five years ago, I wonder what I was doing five years ago. Let's take a look at a day of the life of David five years ago. And I was like, wow, I remember the customer that I talked to. I remember that customer that I have to and none of them closed actually.

59:10And 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 fire base like platform. So sort of a developer platform, like a Haruka like platform. And they were like, hey, I really want to go buy a retool for all of my customers because, you know, we have all the data in our platform. And we want to sort of at 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 as distribution like crazy. The fact we should go target fire base, we could target parts, another sort of afterball platform, we should go sell retool to all these companies.

59:51And they'll never close to 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 and, 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. I'm going forward. And I was totally wrong. So I had what that incident for my memory entirely because maybe it was a bad memory or something. So I really like you're 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.

1:00:28Just thinking about like acquired, you know, like I'm 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. Look, it just list a bunch. There are so many, but it's paid podcasting or having bigger and bigger guests and those people are going to promote our episodes for us. And that's going to get us a whole bunch of new listeners. Are there any embarrassing ones? Oh, yeah. Definitely. We renamed the show. Like this, this was a terrible.

1:01:02I'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 a moronic decision. Does Rolex ship a watch one day that they're like, oh, by the way, it's a 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.

1:01:39Like, oh, 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 customer as 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 at a colleague that day, and we were like, how do sales people like, what is it go to market motion around this?

1:02:13And 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 happens so organically. But I think simply 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. 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 our shareholders to pressure you and so many public companies and allergies here that could be fun to bake, but you are probably not being motivated about the right things.

1:02:54I am motivated to maximize your holder value, but we do that in the way that we think is right. Not because some shareholders called us up and said, oh, what about this or what about that? So I think intrinsic motivation is maybe if anything sort of a court value that I think a lot of retools should call retool, he's 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.

1:03:34That's disgusting. Back to GPT4. 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 it 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.

1:04:14If you want a quick mockup 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 get to 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, 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 also just pick exactly the red that you want.

1:04:43And so I think natural language is great for many tasks. Just not quite for all tasks. Code is great for many tasks, but also not for all tasks. Visual program 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 they will lead to great outcomes. But it is definitely not the only tool. And this I think it's back to sort of I've stuck it to Ryan Lucas, our head of design recently. And his perspective was when we talk to each other, use a natural language, we already between humans have so much misunderstanding.

1:05:17And 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 poll 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.

1:05:55So 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.

1:06:30What are we doing? This is like math equations exist. We could just do math without equations and without any notation. And we just talk about math all the time. But it would be incredibly imprecise. Probably none of us would have any of what the other person is talking about. But when you write it down specifically, it's so much more helpful. So 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, finance at retool .com or me at DVDHSU. That's great. Well, thanks so much for joining us.

1:07:03Listeners, we'll see you next time. We'll see you next time.