His 1st startup failed. His 2nd became a unicorn in just 18 months. | Jake Stauch, Founder of Serval

When I joined Verkata, I had heard so much about this legendary sales team. I wanted to join a sales call and to see what do they do on the call? What kind of crazy Jedi mind tricks are happening? And I joined this call, and the sales rep just kind of does a demo of the product. And then the customer at the end of the call just says, "Okay, like, we're probably going to buy 30 cameras, send me the order form. You don't have to be perfect and magical to do this. You just have to be selling something people want." How fast did you hit like a million in AR? In the first couple of months, yeah, it was pretty fast. We're still very early, but I think that it's going to grow really, really quickly here as we start to unlock these big ACBs. There was a week where I did probably 10 different demos. And every single one, their face lit up when they saw the product. They didn't care about all the missing stuff. And it was almost like we'd cross this 50% threshold where they started rounding up what the product could do. They believed we were going to fix all the things and we were going to add all the capabilities. There's one week where all the conversations people were so excited that I knew it was going to work. That's Product Market Fit. Product Market Fit. Product Market Fit. I called it the Product Market Fit question. Product Market Fit. Product Market Fit. Product Market Fit. Product Market Fit. I mean, the name on the show is Product Market Fit. Do you think the Product Market Fit show has Product Market Fit? Because if you do, then there's something you just have to do. You have to pick up your phone. You have to leave the show five stars. It lets us reach more founders and it lets us get better guests. Thank you. Jake, welcome to the show, man. Thank you. Thank you for having me. I'm excited to have you here. You've been on pretty fast journey. It seems like from that side, I just raised almost $50 million from my mistake in Series A like last month and you started the business a year and a half ago. Was that right? That's right. Yeah, April, 2024. That's a quick 18 months, man. So to get back to the beginning, before this, I see you had a different company and then you were kind of a director of product but maybe you just walk us through a little bit of that journey and set the context for us before you decided to start it. A circle. Yeah, for sure. So I started my first company out of college. I actually dropped out of Duke to start this company called NeuroPlus where we made brain-controlled video games for kids with ADHD. So we actually built an EEG headset that measured kids' brainwaves and then video games so that the more they focused, the faster their dragon would fly or the further ahead they could see in a tunnel and other cool game mechanics and actually help kids a lot with attention problems. And then ran that for a few years and had the opportunity then to join Vercada in an early stage physical security company and building really cool products. What happened maybe before you jump to that role? Like what happened with NeuroPlus? No, it didn't work out. We ended up winding it down. So ran it for seven years and had some early success but never really became a rocket ship. So eventually just decided that it was not going to take off. Did you do the hardware device or just a software? We did the hardware as well. Yeah, it's, dude, so I had my first company called Jim Track, which was like in the wearable space, like similar time frame actually, like 2013. I mean, IOT, all this quantified self-stuff was super hot back then, right? So it was 2013 to 2018, you know, raised like six million. The idea was to track reps in the gym sort of things like B2B and similar story, man. Like it was just hard to, at least in our case, it was hard to get things to work to the level that we needed it to work. And that was the bigger thing more than like demand. I'm not sure in your case if the thing worked flawlessly and it was more about demand or what was the core issue. Yeah, it worked really well. And what I think happened was the market wasn't actually there. So we thought the market was the universe of people with ADHD because no one actually wants to take ADHD medications. And so if there are a better approach than everyone would adopt this. And it was a little bit misguided. What we found was our actual market were families of kids that had severe side effects taking medications, which is, you know, they're one to two percent of kids that take these medications. They have severe side effects like seizures and really cigarette appetite loss and sometimes delays in growth and maturation. So those are the families that just lined up in droves and it gave us a lot of false signal of product market fit because we thought, hey, this is working because in the early days it felt like, wow, this is crazy, our customers are rabid fans. And then it became harder in harder and harder. And we realized that well, we had crazy product market fit but the market ended up being a very, very small niche of the abroad market. And so as soon as we kind of like started to saturate that group, we realized that there wasn't really a broader market but outside of that. That's a very clear but non-obvious example of this like the difference between hair on fire problem and not, right? Like you think about ADHD is a big problem but the kind of path A solution for most people, frankly, is medication. If the medication works well enough, you're almost in this good enough state where it's like, you know, neuroplus might have been a bit better but it wasn't hair on fire. If you're that one or two percent where the medication did not work at all at huge side effects, now it's like, oh my god, I need to do something. Like what is it? And when you show up, you're like, oh, this is like, you know, my savior sort of thing and that pull is visceral. Whereas everybody else, it's kind of born in the nice to have camp. Exactly. I think the other thing there was, our buyer was really the parents and oftentimes it was mom. And we were not really solving her problem which is really about time. She'd have time to devote the energy needed to help kids with attention problems, to get through their homework, to get ready for school on time. Like there's all these time constraints and what our product was doing was basically adding to those time constraints. But I said, okay, now you have one more thing to do and we're not actually giving you any time back. And so it's even more stark trade off for them. So if medication was working at all, it just wasn't a good customer for us and that ends up being the entire market. I remember after I, you know, wound down Jim Track, the biggest feeling was, because I was exploring maybe starting his startup, I didn't know exactly what to do, but the biggest feeling I had was whatever I do next, I just need a win. Like after this much time of this much effort and getting, you know, a fail, like I just need a win. What did you feel like when you decided, okay, your plus is over and I'm going to do something else? What drove you? I felt the same way. I wanted to see what it looked like to win, to see what product market fit actually felt like because I clearly didn't get that. And I didn't know what I was doing wrong. You know, I think when you're in a startup that doesn't have product market fit, you're constantly optimizing around the edges. You're looking for all these things that could be a little bit better and turns out you probably just, you're not in the right market, you don't have the right product. Yes. But you're optimizing like, oh, if I only I could sell better and I was a better leader and, you know, our marketing was better and, you know, we had one more feature. And so I wanted to just go somewhere where it was clear that it was working. And I got this call from a friend that had joined Vricata very early. And he said, I remember this very clearly, he said, you know how everything was really hard to start up and nothing seems to work. Here it's different, everything works. Like everything we do, if we do it well, everything works. And that I think is like the clearest explanation of what product market fit feels like is like, yes, you have to execute. But if you do things well, everything kind of seems to work and seems easier than you thought. And I said, I got to figure out what this is like. I got to check that out. And so what was really fun is I had the first conversation with this company and there may be like 20 employees. And I was like, I'll chat with you again in a couple of weeks and I'm still figuring things out on my side. I chat with them again and they're like 15 employees. And I was like, I got to fly out and I got to meet you and I fly out to meet them and they're 70 employees. And you get to see that crazy trajectory on the outside and then just like, I want to be a part of this. And so I joined Vricata in the summer of 2019 and went from 100 employees or so and stayed with them through probably about 2,500 employees over five years. Crazy growth. The thing you mentioned by the way around, everything being easy if you have product market fit. This is why I focus so much on product market fit. I remember I was listening to an episode where Timoth, who's one of the growth leaders at Facebook early early on was talking about the sort of growth hacks that they did at Facebook. And one of the growth hacks was effectively translation. And I'm like, man, if translation is the growth hack, like you have something that's just working. You're like, oh, if we're just doing 100 languages, get 100 times the growth, yes. Because of the query of something that's amazing, that people love. And it's crazy, my blowing to me just how much time is probably spent, frankly, mainly wasted by founders who don't have product market fit and they're trying to find that growth hack, that go to market motion, that virality on LinkedIn or Twitter or whatever it is. That's going to lead to the promised land when 99 point whatever percent of the time, you just have something fundamentally wrong like the problem solution piece of the formula. - It's so true. I mean, I remember the other moment that really crystallizes for me is when I joined Verkata, I had heard so much about this legendary sales team. And it was a very successful, very good sales team, but I wanted to join a sales call and just see what do they do on the call? - What's the magic? - Yeah, like what is the secret that I've been missing out on all this time? And I joined this call. And the sales rep just kind of does a demo of the product and they get a few things wrong and they misspeak a few times, kind of a junior rep. And then the customer at the end of the call just says, okay, like we're probably going to buy 30 cameras, send me the order form. It was just so start to me. It's like, oh, you actually, you don't have to be perfect and magical to do this. You just have to be selling something people want. It was just so clear to me. - So you're there for about five years. What's the driving force behind leaving and in starting service? Like what was kind of, where did the idea come from? - Yeah, so I joined Vricata having only been an entrepreneur. The only job I had before that was running my own company. And I thought, okay, I'm going to join this company for maybe a year, see what a startup's like. That's working. And then I'm going to, like a year later, I'm going to go right back out there. And Vricata was such a great experience and I got to build all these new products. While I was there, I was director of products. So I was in charge of a lot of the new product in the ship. And I just didn't see a reason to leave. It was like, this is a lot of fun. I get to build new things from zero to one. I had a director of engineering counterpart that I got to build with. And so we got to essentially be a CEO, CTO within Vricata, building all these new products together. And that extended my expected tenure from one year to five years because it was such a great experience. But the whole time I'm there, I'm thinking, what's next, you know, like I want to start a company with my counterpart on the engineering side. And I didn't want to start something that was in Vricata's development path for obvious reasons. Like I just felt like Vricata's going to win all these adjacent markets. But I was spending a lot of time with the IT buyer. - What was Vricata doing by the way? - So security cameras, access control systems, environmental sensors, alarm systems, visitor management, you can think of it as like building operations and building security and a cloud-based physical security for the enterprise. You know, in the early days, we called ourselves like Nest for the Enterprise, but eventually became much bigger business than Nest so we stopped using that one. Yeah, so we were building all these cool products. IT was a buyer. So I spent all this time with IT and I'm basically doing customer discovery with IT for five years because I'm trying to figure out what new things to build for them from the Vricata site. In that process, you end up hearing all their other problems. And so you're basically trying to see what new camera I should build for you. And instead what you're hearing them say is, hey, actually, can you get me out of the help desk or can you get rid of all these tickets and can you make all my users go away so I don't have to deal with this queue? And you just hear those comments all the time. So it lived in the back of our mind that this is actually a problem. And then one day we had this very specific conversation with a customer that said, here's what you can do for me. I manage all these Vricata deployments. I have thousands, thousands of devices. For various reasons, devices go offline. And here's what happens. Somebody reports it offline. It becomes a ticket and service now. That ticket gets assigned to somebody else to go investigate. They've got to send somebody out. They assigned it to somebody else. Two weeks later, somebody reboots the camera and the issue's solved. And, or maybe they schedule a technician or maybe they update the firmware. He's like, why did all that have to happen? Why can't Vricata just know when there's a service now ticket and run some diagnostics and fix it itself? And that idea was really, really interesting. And it kind of evolved our thing and is like, oh, what if we built a product, not just for Vricata, but built a product that could sit on top of these technique systems, identify issues and then resolve them. And at first, we were very narrowly focused because of our background. But we should do this for network device issues. So we'll sit on service now and we will diagnose network device issues that come through and we'll reboot the device or we'll schedule a technician or do something. And that was the seed of the idea that eventually became serval. And then we actually start talking to customers and realize network device issues are like a very, very tiny portion of the overall problem here, but it was enough to get us started. - Where did you get to before you decided that you wanted to leave and really just go all in on this idea? - I was convinced that I wanted to start a company and leave and it was time for me before we really had settled on an idea. And that was just because again, I'm an entrepreneur at heart. I've always felt like I was pretending to be a product manager, a director product. Like it never felt like me. It felt like a job I pretend to do to get a paycheck. And it always felt like I was waiting for the next thing. And the timing to start a line and the timing lined up with my co-founder and we had a great run at Vricata and we got them from an early stage company to company with 2,500 employees and crazy revenues. And so it felt like the timing was right. - So your co-founder was somebody you met at Vricata? - Yeah, we joined I think like the same week or within a couple of weeks of each other and we instantly got paired up. And it was probably the most lucky fortunate event of my professional life because we just started working together from early on as a pair that would go and chase new product lines and build new product lines and build teams around those products and go to Marco of those products. And so it's like five years to test a co-founder relationship is more than most people can ask for. And you guys left at the same time? - We left at the same time, we on the same day. - How do you go from the general idea of okay, we wanna do something for IT, maybe with the sticketing stuff to what ultimately became server-like, walk me through that customer discovery period but whatever it is that you actually did to get there. - Yeah, for sure. So I had to talk to a lot of customers, especially outside the Vricata context. We kind of understood the Vricata customer and like their context, but we wanted to talk to other folks. What helped me was I had a baby and went on a paternity leave. And so I had very little mental or physical energy to do anything but I could get on customer calls and just talk to random people and ask them about their problems. And so that's kind of how I, my one kind of mental exercise during paternity leave was just getting connected to a bunch of customers saying like, what's your biggest pain point? You know, I ask all like the normal customer discovery questions because I knew that at some point I wanted to start something new and I wanted to use this time and space to like think about what that might look like. We had various different kinds of ideas in addition to the ones that I've talked about with the network device troubleshooting. But I knew I wanted to solve a problem for IT. So I wanted to get on the phone with a bunch of IT folks. - How many calls did you do, more or less, during that period? - Over 100. So it was probably like a couple of days for a few months. - And were you reaching out to people you already knew or like how did you get these people on the phone? - Somewhere in network, a lot were actually, at that point, VCs, I think we're starting to circle a wagon and realize that like we were kind of having these conversations. I don't know how they figured out these things out, but they were offering to make a lot of intros for us. And so that was kind of the early game was, there's all these VCs that unpromptu were saying, "Hey, we'll introduce you to these customers, "we'll introduce you to these customers "and we'll have you talk to you." It's also a way for them to do diligence, right? Because they get to debrief with a customer after the fact and figure out like, "Hey, is there there there?" So that was super helpful, VCs made these intros. We reached out to like friends of friends and yeah, just had conversation after conversation after conversation and danced around to kind of a few different ideas. But what's really started to crystallize was, yes, there is this problem with these helpdesk tickets. The problem though seemed a little bit deeper than that, which was the solution there's obvious, which is automate the helpdesk. That's not clever, like just automate the request in that way you don't have to like have some of your tickets. So then it became, well, why don't they build these automations? There's all these workflow builders. You know, there's a million workflow builders. There's all, you know, there's cool custom scripting tools. There's all these ways to go and build automations. Why don't you do it already? And that's one to realize kind of the fundamental problem about all these tools, which is the process of building automation is really hard. There's so much friction in building automation, the dragging and the dropping and the rules engine. And if this, then that and-- Is this more of the old school, like pre-gen AI way of thinking and building automations, robotic process automation, like whatever RPA? Yeah, it's RPA, but it's also just workflow builders. Even today, every single workflow builder works the same way. It's if this, then that, then that, you know, rules based, you know, whether you're talking Zapier or Octo Workflows. You've got to cover like every edge case. Exactly. And so if you're doing something, especially like a help desk workflow, which maybe only takes you five to 10 minutes to reset somebody's password or give somebody access to an application, it just makes no sense to go through this crazy process of building automation that may or may not work when you're done with it might take you weeks to build. And then somebody's got to maintain when something inevitably changes about your business process. And so what happens is there is no automation because there's so much friction in building and maintaining the automations. And that's what got us really excited. And I remember the question that I asked that really got us down this path that was so important 'cause I'd asked a lot about what's your biggest pain point? And you get a bunch of cybersecurity concerns and kind of just like, you know, a lot of stuff that wasn't super helpful. But when I asked, hey, if you hired somebody today and you just have them sit next to you and do work for you, what would you ask them to do? And that is the question that really started to open people up and they started saying, well, I have them like go and build a bunch of automations. I had had them scripted all these things so that I don't have to deal with it. I'd have them experiment with these automation tools and like show me what they're able to do. And we started to get a really consistent theme from that line of questioning. And it opened them up to a different way of thinking about the problem. And that's when we realized like, hey, we can solve the automation problem. And if we solve the automation problem, we've actually solved a much bigger problem, which is the IT service management, IT ticketing problem. And we could build a better ITSM by building a better automation platform. And that was the founding of server once we figure that out. - It's funny how much the precise question you ask or how you frame it can change the answer. And I think a lot of it has to do with because for you, these calls are very meaningful. You're trying to start up for the recipient. Like it's just another call. Somebody's asking me some questions like, whatever. And so it's not like they're gonna spend all day thinking about the best way to answer your questions. They're just gonna go off the cuff. So you have a lot of power. You know, the simplest thing would be like, if you were to go in and be like, hey, is this specific thing a problem? You get a lot of BS. Like a lot of people would be like, oh yeah, that's kind of a problem. Like whatever, because you just framed it so directly. But that framing of if you hired someone, what would you have them do? Is a very clever way of getting at what is the work that's on top of your pile that you for whatever reason can't get to? But that would be the first work that you'd wanna have somebody get to, which clearly speaks to their own priorities and their own problems. Maybe before we jump to the next, because we're obviously gonna go through the phase of the business. But maybe just give me a sense of like, how did you structure these calls? Because the devil really is in the details when you do this. I know you asked that classic, you know, what's your biggest pain point questions? But how might one of these calls, like an example call have gone like? - Yeah, for sure. And we learned a lot through the process and it evolved over time. So in the early calls, which were not as helpful, we asked a lot more general questions, you know, biggest pain point, what keeps you up at night, you know, tell me about your day, like what's hard about this and that, all kind of textbook customer discovery questions. And you just get generic answers. You ask generic questions, you kind of get generic answers and it was hard to pinpoint what we started to do that helped a lot was having a thesis going in and not talking about the product, but having a thesis about what the problem was and saying this call is gonna be about network troubleshooting. And we're just gonna dive into network troubleshooting and try to like get really specific on what are the pain points there. And if we're wrong or wrong and we wasted a call, but that way we can actually get it something that might be a little bit more interesting. And so that helped us a lot that we'd go into the call with more of a narrow focus on what we're trying to do discovery around. And then once we discovered this line of questioning really around what would you do if you had somebody working for you, the other way we phrase it was, okay, if I come to work for you tomorrow and you've got your own custom development team that works right next to you, what is that team building for you? Yeah, that's another way of kind of getting at the problem. And what we found to your point was that people are not having a lot of problems anymore. Like software has solved a lot of the things that are top of mind problems. We were not like, hey, I have this giant pain point and no entrepreneurs ever come and ask me about it and no software exists to solve it. That just doesn't exist in a lot of categories today. And so what we found is you have to go that level deeper of okay, all the point solution pain points that are very top of mind have been solved and they don't maybe feel like pain points anymore. We really have to think about what you do if you had extra labor to throw out a problem. And that aligns actually much better with how we think about AI is what if you had extra labor and intelligence to throw out a problem, what would you do with it? Once you figure out that that's kind of the more specific place that you want to go, which is, you know, and is kind of using AI to deliver a bunch of automations in a way that the old workflow tools can't do it. What's your first step? Do you start building? Do you get design partners? Do you raise around? We were lucky enough that there was so much interest in what we're building that we were able to raise around and when I say what we're building, what we were thinking of building 'cause we really had nothing built yet. And so we raised our seed round before we'd written anything, before we'd really even incorporated the business, we had the seed round committed and that was really exciting. How much was it? That was a four and a half million dollar seed round led by General Catalyst and First Round Capital. And when was it? That was in April 2024. So that was committed in March and closed in April of 2024. So right when we started the business. What's your first step after you have the money? Once we had the money committed, we were happy to give our two weeks notice and we resigned and our last day was April 5th. And our first day, the new company was April 8th. So we left on a Friday and then took the weekend and then we started on Monday, ready to go. And we decided to go after the hardest problem we could think of first, like the biggest risk where we weren't sure if it was even possible, which was that fundamental idea of, can we make it faster to automate something forever than to do it manually once? Can we build a tool that takes all the friction out of automation? And the idea we had was you should be able to describe your automation natural language and then just have that automation be built for you. And the way we arrived at that being the core idea was actually another customer conversation where they were actually very excited about the Octo Workflow they built. And they described this Octo Workflow in one sentence, which was, "I want to elevate approvals for certain expenses over $1,000 to an M5 manager above and make sure an M5 manager approves it. If you reach the CEO, you've gone too far, so go down to an M4 manager if the CEO is the next highest manager." So one sentence to describe what he wanted to build. And then he showed us this workflow and Octo Workflows. And it took up pages and pages of this branching tree structure, flow diagram, catching all of the edge cases that if this, then that, and took about two months to build. And that idea was so impactful for us, was like, he could describe that workflow in one sentence. And it took all this time and all this logic to get it working. And so we're like, well, what you really want is to just describe that workflow in one sentence and then just get that workflow on the other side. And if we could build that, then we really got something. And so that's what we started off building is how do we make that possible? The only way to make that possible is basically to take the natural language, use that as a prompt to generate code that executes the workflow. There's no way to do that with kind of a block-based traditional workflow system. So if you think about a code is actually like a really efficient, compact way of representing complex logic. And so we decided to build this natural language to code system and see if it would work. And if we could build that and get that to a state where we believed it was going to work, then the rest of the capabilities that ticketing and the IT service management, the help desk, and the Slackbot and all the things that come next, we were very confident we could build those things. There's no real technical risk there. There was a lot of technical risk. Could the core idea really work? And so that's where all the early development was is in that core idea. - You love this show. You don't want to miss the next episode. Why would you? So hit that follow button. Trust me, it's in your own best interest. - So a few questions. Maybe just the first one, it's very surprising to me that it would seem like such a simple workflow has so many edge cases. Can you just walk me through that tree that was so long for something so seemingly so simple? What would be some of the edge cases on there that would be unexpected just because it gets at the crux of the value that you're ultimately delivering with your kind of easier prompting solution? - Yeah, a lot of it is if you think about it, the mapping of the inputs and outputs from one step to the next in workflow. And you have to manually configure all that. So you have to get this user object and then you have to manually connect, okay, how do you find the manager of that user? And then what if the manager doesn't exist or what if that value is null and that's been deleted? And then, okay, then you gotta go and take the next step. You gotta send a message, well, how do you send the message? Well, you gotta connect now a different application for the message's sending. And then what happens if the message recipient cannot be found? And how do you do the lookup on that message? So you're basically building together these blocks because we think about what a no-code workflow builder is. It's these blocks that have certain inputs, certain outputs, certain steps in the middle and you connect them with this logical flow. And so to be able to represent something that sounds very simple and handle all of those cases and all of those tools that have to happen, it ends up just being very, very complex. Whereas obviously if you're writing this in code, you'd be using these APIs and you'd be able to get this data very, very quickly. You'd hit these endpoints, you'd get this information, you'd pass that and still lean to the next step. And so all of this is very simple from a code perspective, but it's very complex from a no-code perspective. And that's the case with a lot of these workflows. And to get rid of that technical risk, what's like the test that you set up? Like how do you know that the output, the code that your system outputs, for example, covers all the edge cases? That's the hard part, right? It's a lot of trial and error. And so we started building, we made this decision early on to use TypeScript so that the LLM could actually do type checking on the final result of the workflow that was generated. That helps a lot if you type check the script versus the API spec. So we know generally that, hey, these inputs and these outputs match and this should work. It shouldn't fail. That was kind of like the biggest failure case was that you just, as a simple example, you'd output a string in one step. And the next step actually expects the input variable to be an integer. And obviously that's not going to work. And so the type checking was actually a really key unlock there in just the API spec. And then using that LLM to actually do the type checking. And then a lot of trial and error. And the early days, because LLMs were not strong enough, we also had to feed it a lot of context of, here's a known good workflow. So we build workflows that we knew worked. And we basically store those in the system as context so that when you went to build a workflow, the system would say like, we would say, hey, it might look like this if it's working. And so that worked pretty well because you could give it a bunch of different examples. And then as long as the things people were prompting were somewhat close to those examples and used APIs that were fairly well documented, then it would kind of sort of work. And what's very important here-- and this is, I think, something that's true in this AI era-- it didn't actually work all that well. But it was close. And we had to take this calculated risk of, do we think the models are going to get good enough where this actually works? Because it doesn't work yet. And we thought that, hey, this does better than we thought. And we think that the things that have to change about these models, the things that have to get better are small enough that we're confident we're going to figure this out. And so we kind of passed that check internally for us where we're like, this is going to work. This fundamental idea that people can prompt and get a workflow on the other side-- we believe it's going to happen. And it works in these set of cases that are not very interesting, but it will work for more and more cases over time and we're confident in that. So that was basically the first phase. That piece that you mentioned, by the way, of operating under the assumption that these models are going to get better, is critical, by the way. You have to, in these days, in order to not fall behind, be putting out features, or at least working on features where they almost work, but they don't quite work, to know that they're going to work. Because otherwise, you just risk getting leapfrog. It's the same as, if you think about back when chips were the rate limiting step, you know, 20, 30 years ago, like CPU stuff. If you don't assume that these chips are falling more and getting better and better, you're going to design applications that don't use enough RAM, don't use enough memory, because they're built on the constraints of today. And then tomorrow, the new chip comes out and somebody was building for that, and now you've got leapfrog. So you really, I mean, it's not straightforward at all, but I think that's really changed. I would almost say just pre-imposed to GBT is the easy kind of delineating line of how you should be building in a kind of post-genie world that's changing so fast. Yeah, absolutely. And it's such a tough balance, though, because you can delude yourself very easily, which, which I think entrepreneurs are very good at, this optimism bias of, no, it'll work. And you can delude yourself into thinking that, yes, this doesn't work today, but we're just like a few months away, and it's actually going to work. There's this fine margin of it doesn't work today, but actually will work very quickly. And it's very unpredictable, because the progress that these LLMs are going to make, it's going to be, I think, in fits and starts. Like, there's going to be a long period of time with maybe not a lot of progress. And then there's probably going to be step changes. And you have to kind of take risks on when that's going to happen. Were you building with, like, design partners during this phase, or was it just, like, in the lab, kind of, in the background, just trying to see if this thing could work? We're constantly doing customer discovery and trying to get design partners. I think we didn't really have a design partner for six months, because there's just nothing there. And people didn't really know what to do with it. Because we started with this hard thing, that by itself, it's, like, kind of a mediocre, very limited workflow builder. And it's cool that it's natural language to workflow, but it can only build, like, a very small set of workflows. So what's the value of that? And it took a while. But eventually, I would say, maybe six months in is when we had enough interesting things that we had a couple of design partners that we started working closely with. So this we're talking about, like, end of last year. Like, we were talking about Q4, 2024. Q4, 2024, those were our first design partners. And what does the team look like? Is it just the two of you building? Do you hire people right away? And what does it look like by the end of 2024? It's the two of us until September, 2024. So the first five months, it's just two of us. Then we hired our first person September, our second person October, and our third person November. So ends up being like five people by the end of the year. But still a very, very small team. So we're in the design partner phase. You're talking four or five people that are building everything. Which is the way to do it, because at that point, the thing that matters most rather than just how much code can you put out is just can you stay aligned? Can you change fast? Can you be flexible? And really, like, having no overhead when it comes to alignment and communication, all these sort of things. So you're working with these design partners, Q4, 2024. Like, what's the line at which you decide to launch? Like, what are you waiting for in terms of the product? We're like, OK, this is-- this product is now ready for prime time. Yeah, this is an ongoing discussion, because there's conventional wisdom is just go sell it. And get it out in front of people as soon as possible and sell it. We do think that it's good to expose people to it and constantly be getting feedback. But we didn't feel like we had a sellable product. It was very clear. Every time we show the product, people could poke 20 holes in it. And so the way I kind of did this was I would put the product in front of people, and I would treat every conversation as a sales conversation. And I would see if I could get far enough in the conversation where I felt like, hey, I can close this deal. But what I'd find is 10 minutes and it was very clear, like, there's no chance that they're going to buy this. It doesn't do any of the things they needed to do. It does 10% of the things they needed to do. And they think it's cool and they think it's neat, but it's not a product they can buy. And so that was the experience, basically, for the first five months of 2025 even, is we were in design partnership. We were building a lot of capabilities, but we just did not have a sellable product. There's two reasons for that. One is we have this very big ambition about what the product should be. We're building this giant platform. And yes, there's this cool workflow builder at the core, but it's also a full ticketing system. It's an access management system to automate access request. And when you're that broad, you're also pretty shallow in the early days. So we've got a mediocre ticketing system and a mediocre workflow builder and a mediocre access management system and trying to sell that just makes no sense. No one wants a broad mediocre platform. I think the second thing that was tough is small companies, small startups don't have IT support as a function. You really only bring in IT support when you have hundreds of employees. And so the bar was also a little bit higher for us than that we couldn't sell the startups. We couldn't really sell to anyone less than 200 or 300 employees. And even that was, they didn't have a really strong pain point. You really don't feel the pain until you're 500 or 1,000 employees. And so the bar ends up being much higher because you have to kind of go up market faster than a lot of startups where you can start selling to other startups or 20 person companies or 50 person companies that move faster and have more tolerance for incomplete products. We had to have something that was real that couldn't compete with legacy incumbents and we had to have that from day one. So it was a lot of demos that I would pivot mid conversation like, hey, it sounds like you got a lot of feedback. Maybe it could be a design partner and then they would probably also say no to that in most cases, but it was a lot of building in the dark. It was really hard. Did you try to sell to like outsource IT like the MSP space as well? We had a lot of those conversations. One of the challenges there is that when you sell to them, you're also selling to other end customers. So it's very hard. There's actually more requirements because you're selling to this MSP that's then working with a dozen or so end customers in order for them to really use your product or you have to meet the needs of these dozen end customers. And so it's much harder to kind of like pick your customer and pick the tech stack you want to work with, pick the capabilities that make the most sense. And so we entertain a lot of those conversations but they never really went anywhere because it was actually harder to support. And then you end up supporting a lot of small companies with really messy IT organizations. So we explored it but it wasn't a good fit. When do you decide to launch publicly? We never really did like a launch launch. We kind of, we were building in public kind of the whole time. But the first time we had a product that we could sell and the first sale that we made was in May of 2025. And that was our very first sale. So over a year from Saturday. Five, six months ago, let's say. Yeah, six months ago, yeah. What does a typical sale look like? What kind of ACVs are we talking about? Yeah, it's funny that if we graphed our ACVs over time, it would be basically like almost a vertical line. So the early ones were like in the 20K range and then the 1340K range and their 5060K range and then they just keep going up and up. And now we're getting into seven figure territory. And so it's been really exciting with the past six months as the products matured. The ACVs just keep getting higher and higher. I think that they'll probably settle in as an average in the like, you know, mid six figures, low to mid six figures. But then I think over time, we'll see more and more go up market and we'll see more and more in kind of the seven figures. If you look at service now, most of the revenue comes from companies with ACVs over 5 million a year. And so that's ultimately where we're trying to get to as a business is play in the service now territory where 60% or so over revenue is $5 million ACVs. But we've got a little ways to go to get there. I mean, it's normal for ACVs to go up over time, but it's not normal for an ACV to go from 20 K to over 100 K in like five, six months, let alone seven figures. - Yeah, that's taken us by surprise because we thought we'd be hanging out in the mid market for a very long time. And that's generally how startups have done it, right? Is you kind of like get a foothold in the mid market and you spend a couple of years there. And then over time, you creep up like 1000 employees and 2000 employees and like, you know, eventually one day you can service a large enterprise. And we found from pretty early on that large enterprises were interested in what we were doing and had a lot of the same pain points that mid market companies had. And they move slower, but the product requirements are not different. And that's what is really unique here. We didn't have to kind of reinvent the product to serve these customers, they just move slower. And so if anything, I think we would have had faster growth in ACVs, but it's just the natural order of things that a 200 person company is going to buy a couple weeks after a demo and a 200,000 person company is going to take six months to make a purchase order. How fast did you hit like a million in AR? In the first couple months, yeah, it was pretty fast. And we're still very early, but I think that it's going to grow really, really quickly here as we start to unlock these big ACVs. Again, you look at some of the service now deals, it's not uncommon for them to have eight figure contracts. And there are a lot of companies spending 10, 20, 30 million a year on service now. So as we're able to go into these large enterprises, and because we're actually a full platform, and this is what's really important about what we built is that we took a lot longer building than a lot of other companies. But because we built the full platform, we're talking about service now, Rupert and Replace. We're not talking about just being an AI layer on top of some, no. >> I was just going to ask, like, you're not, right? Okay, you're taking customers away from service now. >> That's the goal, yeah, exactly. And we know that that takes a while, right? These contracts are three years long. Unwinding 100,000 employees off of service now is not something you do in a four week sales process. So I'm not saying we're going to grab these contracts the next six months, but these are the conversations we're having today that in one, two, three years, all of a sudden they're going to be converting into 10, 20, 30, 40 million dollar deals. >> And so you're still sub like 10 million error, right? Like you're probably somewhere between one and 10. >> Yeah. >> Why do you decide to do this full platform, replace service now? Like I get that as, for sure, as long term vision, that would have been like the kind of no brainer thing you want to do. But why did you choose, and it sounds like it was the right choice, but like, why did you choose not to just start with, okay, we'll build on top of service now, and then like, we'll build the rest of the stuff and then do a rip or replace. >> Yeah, that's a really good question. It was a decision we made from day one. We didn't come into this over time. And there's a couple reasons for that. One on the product side, we just fundamentally believe you can't build a differentiated product on top of somebody else's product. If you're fundamentally reliant on their product for your product performance, you're just always going to be tied to those limitations. And we saw that with MoveWorks, right? MoveWorks in many cases existed on top of service now, and never really built out the full platform and kind of got stuck as a layer. And so the product experience we thought just couldn't be good if you didn't own the full stack. We saw that at Vricata as well. That was a big inspiration is Vricata. It was pretty counterintuitive to build the video software and to build the camera system itself and to build and own the entire platform. And it had so many dividends to customers in terms of that experience. So doing the really hard thing of building the full platform from a product experience perspective made a lot of sense. I think the second piece is just the business model in the go-to-market. We know that IT wants to consolidate spend. They want to cut costs. They want less vendors, not more vendors. And so we'd much rather go to them with the story of how their replacing vendor spend, replacing existing budget category instead of adding on to their budgets. And AI is presented an opportunity where you can get additional budget kind of out of nowhere. But we don't want to rely on the fact that, hey, there's some discretionary experimental budget and that's how we're getting these deals. We want to actually go after core systems of record with established spend. Because long term, that's going to be a much more fruitful pawn to swimming than just kind of relying on excess budget, experimental budget. And so both from a product perspective into business model, it made sense to actually go after the real category. Service now is like a 20-year-old company. How can you, let's say, under a year, rebuild enough of that product that customers are willing to ditch that and move already you? Yeah, I think we have to thank AI for a lot of the capabilities to move so quickly. You know, you can think of it as a combination of, there's the table stakes functionality where you just need feature parity. And then there's the innovative capabilities that get people so excited they're willing to make the move. And AI is allowed really both of those things. So AI on the table stakes side, building out a really robust ticketing system five years ago would have taken years. And now we're able to do that so fast. I mean, all the capabilities of the ticketing system, you could vibe code a basic ticketing platform in a weekend. Now, it would be broken a lot of ways in that certainly now what we did, but just to give you a sense of how much faster it is to build so many of these capabilities in features. So that's helped a lot to be able to build so much of the table stakes so quickly. We actually rely a lot on our four deployed engineers that are working with customers to just every time a customer makes requests, we're just pumping these features out, left and right. And an AI allows us to move much faster there. So on the surface area side, AI allows us to do that. And then obviously on the differentiation, we're able to tackle service now where they're strongest, which isn't the configurability, the customization, and build workflows that do anything and any application. And most startups don't go after the legacy incumbents that way. They go after them with more opinionated, more limited functionality, instead of actually going after them. - I was didn't say, I mean, that the other option is you do this kind of 1910, where we'll give you 90% or 80% of the features for 20% of the price or we'll be more opinionated, we'll be vertical specific. And so yeah, you won't can't do these things here, already state specific. We'll go to SMB and market. We won't give you everything 'cause you don't need everything, we'll give you this. That's the classic thing, but what I'm taking is that you actually just went for across the board, like feature parity on, I don't know, everything but the vast majority. - Yeah, the core value, right? We wanted to understand why are you using this platform and let's build a better version of all the things that you actually care about and use and attack them where they're strongest, which is the customization configurability. People don't buy service now 'cause it looks beautiful, obviously. So making a product that looks prettier than service now is not gonna get them to buy it because they didn't buy it for that reason. They bought it because they could support any business workflow you could throw at it. And with enough time energy and effort, you could build whatever you want on the service now platform. So that's what we went after is make it easier and faster and more configurable so that you can build anything you want on the server platform, but you can do it in minutes instead of months. - Because yeah, the most classic place would have been to go down market, but then you would limited feature set. But because you're going enterprise, you've been able to go enterprise, you've really used AI to kind of feature match and in fact, use AI to give them even more configurability, like you said, hit them where they're strongest, almost like where is the value, okay, here's the value. Let's 10X that value and then give them the table stake stuff, which is like fundamentally, I would say, this is a new go-to-market approach that's unlocked by Gen AI. This is not available pre-2022. - No, no, we could not have built this company before we built it. And when we started, as I said, as we started, we could not have built this company as we built it today and the early days of this company. I mean, the timing could not have been better for us. - But that's to be clear. A lot of that is where we were talking about the AI features that you better on top. But I mean, just the fact of being able to rebuild somebody else's enterprise-grade product in this amount of time, even that alone. I mean, pre-Gen AI, I don't see any way it could have done that. - No, no, we would need hundreds of engineers. I mean, you can kind of get a preview of what that looked like. If you look at what Rippling had to do in the early days and Rippling's an incredible company, they had to hire hundreds of engineers, almost from day one to build a robust payroll system that could be competitive in that market. And so much of their early story is just building a really massive team and going after all these categories. And it's amazing how a smaller team with AI can build so much, so much faster. - As you start selling in mid 2025, tell me a little bit more about how you structure the go-to-market. I assume you were doing sales at first. You started seeing the sales were actually closing with the next move. - Yeah, I have these customer conversations every day and it's always like the leading indicator of what's gonna happen to the business because the sales is a super lagging indicator. I have these conversations and I kind of can know where things are going. And I think it was around April when I first started having these conversations and realizing, hey, this is gonna work. People are gonna buy this. And so yes, I started closing the first deals but we immediately once we realized we had something started looking for outside sales talent. We brought in our first full-time AE in August and then we brought in the VP of marketing from Rippling actually joined us as COO and we also hired some other incredible go-to-market folks. And now we've just spun up a crazy go-to-market engine building out a great sales team with a head of sales and a VP of sales that joined them just in the past week. Additional sales reps joined the team of really robust marketing engine. So we kind of decided to go early and hit go on all the go-to-market functions as soon as we started to feel that pull. - What is the go-to-market motion today? Like where do most of the leads come from and then kind of how do you structure it from there to it too close? - It's all inbound at this point. So people come in through the website. We have got a lot of marketing engine activity. So LinkedIn we do a lot of events. We do get inbound intros from VCs and portfolio companies of VCs that talk to their investors and want to see the latest tools. A lot of even large enterprises go to these VCs and say, hey, we're thinking about our AI strategy. What is the hot tool in IT and CRM and HIS? And so we get a lot of inbound intros. - By the way, do you price under service now? - Today we do. - Today I think we're going to be less expensive than service now. I think that that's going to be true long term because we're obviously unlocking all this value in the labor, but at least in the early days we end up being less. Mostly because they have all these modules and they sell a lot of shelf wear. If you look at the utilization of a typical service now customer, they're utilizing very little of what's been sold to them. And so I think we're probably pricing equivalent to what they actually use, but we don't have a lot of shelf wear to sell them at this point. So the contract sizes will end up being. - But in terms of the value prop, if you think about that sales call, you are saying to them, listen, you're going to get way more, you're going to get all this AI stuff, workflow stuff. And frankly, you're going to pay less, which is kind of that double where it's just like, that tends to close really fast. - And a lot of the cost savings is going to be on the implementation because it's going to be implemented by your team and weeks instead of an external consultant in years. - Perfect, well listen, let me stop it there and ask the last three questions you always end on. When was the point when you felt like you'd found true product market fit? - There was a week. It was not a single moment there, but there was a week where I did probably 10 different demos and every single one, their face lit up when they saw the product and they didn't care about all the missing stuff. And it was almost like we'd cross this 50% threshold where they started rounding up what the product could do versus rounding down. And in the early days when you're dumbing the product, I think everyone kind of rounds down and like, oh, like I don't, I don't really understand any of this stuff. It's not going to do the things I need. And we just got to a certain point where it became clear that no, they believed we were gonna fix all the things and we're gonna add all the capabilities. And so yeah, there's one week where all the conversations people are so excited that I knew it was gonna work. - What's like roughly, what's your demo to close rate? - I would say over 50%, it's pretty insane. - Crazy. I ask as a product market fit indicator, it's a great leading indicator. If that demo close rate is really high, the velocity just tends to take care of itself. - It's so high that when I get an intro into a customer, I kind of mentally bank it. And I'm always shocked if we don't win it. - That's insane. - It's like, it's funny. I just realized it started doing this. Like, I would get an intro. It's like, oh cool, we'll get them as a customer. And it's like, that's a crazy assumption to make. - Right, how much is that 100k cool? - Yeah. - It's ridiculous. The other question, the opposite is like, was there a time, especially when you were kind of building at the beginning where you thought this might not work? And it would just like fail? - I would say up until April of this year, it was 50/50 for me. I mean, I have a lot of like confidence that I push through, but if I'm being like very honest myself, I felt we were still on a knife edge in April of this year. So just, you know, six, seven months ago, I remember going on a really long walk of my co-founder and wondering should we turn this around? Should we change direction? Like, this isn't working. People are not excited about what we're doing. Like, are we wrong? We walked around the block a few times and then we just came to the conclusion that, no, I think we're right. I think we just need to keep going. And I think we're right around the corner. And it's so tough 'cause you can dilute yourself into thinking that that's gonna be the case. But we're right, it was the case. And I'm glad we we kept at it. - And then last question, what will be like your number one piece of advice for an early stage founder that's trying to find product market fit today? - I think just be such a skeptic that you found it. I was so deeply skeptical after my own personal startup after launching a lot of products, some of which work, some of which didn't advertise. A decade plus of launching products and seeing some work and some take off, it made me very jaded and just so cynical and skeptical about every single customer conversation where you just assume everyone's lying to you, assume you don't have product market fit and build that bias in so that you keep having to hear it from customers before you believe it. And so it actually takes a dozen good conversations in a row before you even start to think that you're onto something. And I think that that led us down the right path. It's not great for the mental health, but it is good for knowing that you've got something not deluding yourself and not thinking you found it when you haven't. - Awesome, well, Jake, great chatting with you, man. Thanks for jumping on the show. - Thank you so much, Paul. I really appreciate it, great to be here. - Wow, what an episode. You're probably in all your absolute shock. You're like, that helped me so much. So guess what? Now it's your turn to help someone else. Share the episode in the WhatsApp group you have with founders. Share it on that Slack channel. Send it to your founder friends and help them out. Trust me, they will love you for it.