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

When I joined Verkada, I had heard so much about this legendary sales team. I wanted to join a sales call and just 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 ARR in the first couple months?

Yeah, it was pretty fast. We're still very early, but I think that it's going to grow, 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 crossed 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're 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 call that the Product Market Fit question. Product Market Fit.

Product Market Fit.

Product Market Fit. Product Market Fit. I mean, the name of 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 take out 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 the outside, just raised, like, almost $50 million, if I'm not mistaken. Series A, like, last month. And you started the business a year and a half ago, is that right?

That's right, yeah. April 2024.

That's a quick 18 months, man. So take us back to the beginning, like before this. I see. I mean, you had a different company, and then you were kind of the Director of product, but maybe just like, walk us through a little bit of that journey, set the context for us. You decided to start at Serval?

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 brain waves and then video games. So 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 tension problems. And then ran that for a few years and had the opportunity then to join Verkada, an early stage physical security company building really cool products.

What happened? Maybe before you jump to that role, 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 the software?

Did the hardware as well.

Yeah, it's. Dude. So I had. My first company was called Gym 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 6 million. The idea was to track reps in the gym sort of thing. Selling 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 were a better approach, then everyone would adopt this. And it was, 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 1 to 2% of kids that take these medications. They have severe side effects like seizures and really severe appetite loss and sometimes delays in growth and maturation. And 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, it became harder and harder and harder and I Realized that, well, we had crazy product market fit, but the market ended up being a very, very small niche of the broader 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 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, neuroplast might have been a bit better, but it wasn't Hair on fire. If you're that 1 or 2% where the medication did not work at all, had huge side effects and 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, is visceral. Whereas everybody else. It's kind of more than nice to have camp.

Exactly. And I think the other thing there was our buyer was really the parents and, and oftentimes it was mom and we were not really solving her problem, which is really about time. She didn't 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 where it's like, okay, now you have one more thing to do and we're not actually giving you any time back. And so it was 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's ended up being the entire market.

I remember after I, you know, wound down gym track, the biggest feeling was because I was exploring maybe starting a startup or I didn't know exactly what to do. But the biggest feeling I had was when I, 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, what did you feel like when you decided, okay, Neuroplus is over and I'm gonna do something else. What drove you?

I, 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, 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 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 Verkata very early, and he said, I remember this very clearly. Said, you know how everything is really hard at a startup 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 gotta. I gotta figure out what this is.

Like, I gotta check that out.

I gotta. I gotta 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, oh, like, I'll chat with you again in a few weeks. And, you know, I'm still figuring things out on my side. I chat with them again, and they're like 50 employees. And I was like, I gotta fly out and I gotta meet you. And I fly out to meet them, and they're 70 employees. And you just. You get to see that. That crazy trajectory on the outside. And then just like, I want to be a part of this. And so I joined Ricotta in the summer of 2019 and went from 100 employees or so and stay with them through probably about 2,500 employees over five years.

Crazy growth. The. 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 Chamath, you know, who's one of, like 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 know, you're like, oh, if we just do in 100 languages. We'll get a hundred times the growth. Like, yes, because of the core of something that's amazing, you know, that people love. And it's, it's crazy, mind 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, whatever it is that's going to lead to like the promised land when 99 point whatever percent of the time you just have something fundamentally wrong at 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 Verkada, 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 to see what do they do on the call, what kind of crazy Jedi mind tricks are happening?

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 you know, they get a few things wrong and they, they misspeak a few times. Kind of a junior rep. And then the customer at the end of call just says, okay, like we're probably going to buy 30 cameras. Send me the order form. It was just so stark 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, it was just so clear to me.

So you're there for about five years. What's the driving force behind leaving and starting? Serval, like what, what was kind of where the, where did the idea come from?

Yeah, so I joined Verkada having only been an entrepreneur. That was 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 Verkada was such a great experience and I got to build all these new products while I was there. I was director of product, so I was in charge of a lot of the new product initiatives 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 0 to 1, I had a director of engineering counterpart that I got to build with. And so we got to essentially be a CEO CTO within Verkada, 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 Verkada's development path for obvious reasons. Like, I just felt like Verkato is going to win all these adjacent markets. But I was spending a lot of time with the IT buyer.

What was Verkata 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 cloud based physical security for the enterprise. You know, in the early days we called ourselves like nest for the enterprise, but eventually became a much bigger business than that. 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 ricotta side. In that process you end up hearing all their other problems. And so you're saying you're basically trying to see like what new camera I should build for you. And instead what you're hearing them say is, hey, actually like, can you get me out of the help desk? Or can you get rid of all these tickets and can you like, you know, make all my users go away so I don't have to deal with like this, 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 Mercado deployments. I have thousands and thousands of devices. For various reasons, devices go offline. And here's what happens. Somebody reports it offline, it becomes a ticket in ServiceNow. That ticket gets assigned to somebody else to go investigate. They've got to send somebody out, they assign it to somebody else. Two weeks later somebody reboots the camera and the issue solved. And or, you know, maybe they schedule a technician or maybe they update the firmware. He's like, why did all that have to happen? Why can't Verkada just know when there's a ServiceNow ticket and run some diagnostics and fix it itself. And that idea was really, really interesting and it kind of evolved. Our thinking is like, oh, what if we built a product not just for Verkada, but built a product that could sit on top of these ticketing systems, identify issues and then resolve them. And at first we were very narrowly focused because of our background. We're like, we should do this for network device issues. So we'll sit on ServiceNow and we will diagnose network device issues that come through and we'll reboot the device or we'll schedule a technician or, you know, do something. And that was, that was the seed of the idea that eventually became Serval. And then we actually started talking to customers and realized network device issues are like a very, very tiny portion of the overall problem here. But it was, 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, and that was just because, again, I, I'm an entrepreneur at heart. I, I've always felt like I was pretending to be a, a product manager, a director product. Like it, it never felt like me. It felt like, okay, this is a job I pretend to do to get a paycheck. And it always felt like I was waiting for the, the next thing. And the timing just started to align. And the timing lined up with my co founder and we had a great run at Verkada and we got them from an early stage company to company with 2500 employees and crazy revenues. And so it felt like the, the timing was right.

So your co founder was somebody you met at Verkato?

Yeah, we, we joined I think like the same week or within a couple weeks of each other, and we instantly got paired up. And it was probably the, 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 market with 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, yeah. On the same day.

How do you go from, you know, the general kind of idea of okay, we want to do something for it, maybe with this ticketing stuff to what ultimately became servo, 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 ricotta context. We kind of understood the ricotta 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 to leave and so 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 want to get on the phone with a bunch of IT folks.

How many calls did you do more or less during that period?

Over a hundred. So it was probably like a couple a day 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?

Some were in network a lot were actually at that point. VCs I think we're starting to circle the wagon and realize that like we were, we were kind of having these conversations. I don't know how they figured 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 unprompted were saying, hey, we'll introduce you to these customers, we'll introduce you to these customers and we'll have you talk to. It's also a way for them to due diligence, right? Because they get to debrief with a customer after the fact that and figure out like, hey, is there a there there? So that 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 kind of a few different ideas. But what's really started to crystallize was yes, there is this problem with these help desk tickets. The problem though seemed a little Bit deeper than that. Which was the solution there is obvious which is automate the help desk. That's not clever. Like just automate the requests and that way you don't have to like have so many 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 when we realized kind of the fundamental problem about all these tools, which is the process of building the automation is really hard. There's so much friction in building the automation, the dragging and the dropping and the rules engine. And if this, then that.

And is this more 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 Octa workflows, you

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 ten 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 because 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 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'd have them like go and build a bunch of automations. I'd wr. I'd had them script 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, 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 cerval.

Once we figured 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 because for you, these calls are very meaningful. You're trying to start a startup 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 kind of like go off the cuff. So you, 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 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 want to 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 going to 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 the classic, you know, what's your biggest pain point? Questions, but how might one of these calls, 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 going to be about network troubleshooting and we're just going to dive into network troubleshooting and try to like get really specific on what are the pain points there. And if we're wrong, we're wrong and we wasted a call. But that way we can actually get at 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 were 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, you know, 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. People are now it's like, hey, I have this giant pain point and no entrepreneur has ever come and asked 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 at a problem. And that aligns actually much better with how we think about AI is, 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 because we, we really had nothing built yet. And so we raised round before we had written anything, before we'd really even incorporated the business. We had the seed round committed and that was really exciting. And 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.

And 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 of the new company was April 8th. So we, 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 okta workflows they built. And they described this okta workflow in one sentence, which was I want to elevate approvals for certain expenses over a thousand dollars to an M5 manager or 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 in Octa Workflows. And it took up pages and pages of this branching tree structure flow diagram, catching all of the edge cases, the 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 a workflow. There's no way to do that with kind of a block based traditional workflow system. So, you know, 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, the ticketing and the IT service management, the help desk and the Slack bot and like 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, you know, what would seem like such a simple workflow has so many edge cases. Can you just walk me through like a couple? Like, you know that tree that was so long for something so seemingly so simple, like what will 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 a workflow. And you have to manually configure all that. So you have to, you know, 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 like 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 sending. And then what happens if the message recipient cannot be found? And how do you do the lookup on that message? You know, so you're, you're basically building together these blocks. Because if you 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 instantly into 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, is a lot of trial and error. And so we, 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 typed check the script versus the API spec. So we, 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, you'd output a string in one step and, and the next step actually expects the, the input variable to, to be an integer. And obviously that's not going to work. And so the type checking was, was actually a really key unlock there ingest an API spec and then using the LLM to actually do the type checking. And then a lot of trial and error. In 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'd 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. Like 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. And so that was, 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, like you, 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 leapfrogged. 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, you know, following Moore's law 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 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 and post. ChatGPT is the easy kind of delineating line of how you should be building in a kind of post gen AI 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, 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 that's actually gonna work. There's, there's this fine like 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 gonna 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 are constantly doing customer discovery and trying to get design partners. I think we didn't really have a design part in their first six months because there's just nothing there. And people didn't really know what to do with it, you know, 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 design partners that we started working closely with.

So this we're talking about, like, end of last year, like, we're talking about Q4, 2024.

Q4, 2024. Those were our first design partners.

And what does the team look like? You know, 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 in November. So ends up being like five people by the end of the year, but, you know, still a very, very small team. So we're as we're 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 where you're like, okay, this is. This product is now ready for primetime.

Yeah, this is an ongoing discussion because there's conventional wisdom is, is just go sell it and you know, 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, like 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 think it's neat, but it's. It's not a product they can buy. And so that was kind of the, 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. I would say 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 requests. And when you're that broad, you're also pretty shallow in the early days. So it's, you know, 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, no one wants like 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 bit higher for us in 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 a thousand 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 know, 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 could compete with legacy incumbents. We had had that from day one. So it was a lot of demos that I would pivot mid conversation, like, hey, sounds like you got a lot of feedback. Maybe we could be a design partner. And then they would, they would probably also say no to that in most cases. But it was, 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 all their 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, 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 entertained 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, 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, that was our very first sale. So over a year from spouting five,

six months ago, let's say.

Yeah, six months ago. Yeah.

What does a typical sale look like? 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, the 30 and 40K range and they're 50, 60K range and then they just keep going up and up and now we're, we're getting into seven figure territory and so it's been really exciting over the past six months. As the products matured, the ACVs just keep getting higher and higher. I think that, you know, 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 ServiceNow, most of that revenue comes from companies with ACBs over 5 million a year. And so that's ultimately where we're trying to get to as a business is play in the ServiceNow territory where 60% or so over revenue is $5 million ACVs. But we've got, 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 20k to over 100k in like 5, 6 months, let alone 7 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, you kind of like get a foothold in the mid market and you spend a couple years there and then you know, over time you creep up like a thousand 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, and we're still, we're still very early but, but I think that it's going to grow really, really quickly here as we start to unlock these big ACBs. Again. You look at some of the ServiceNow 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 ServiceNow. So as we're able to go into these large enterprises and because we're actually a full platform and this is, this is what's really important about what we built is we took a lot longer building than a lot of other companies. But because we built a full platform, we're talking about ServiceNow rip and replace. We're not talking about just being an AI layer on top of now.

I was just gonna ask like you're not right. Okay. You're taking customers away from ServiceNow.

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 ServiceNow is not something you do in a four week sales process. So I'm not saying we're gonna grab these contracts in the next six months, but these are the conversations we're having today that in one, two, three years all of a sudden are going to be converting into 10, 20, 30, $40 million deals.

And so you're still sub like 10 million ARR, right? Like you're probably somewhere between 1 and 10.

Yeah.

Why do you decide to do this full platform replace ServiceNow? Like I get that as for sure, as a 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 ServiceNow and then like we'll build the rest of the stuff and then do a rip and replace.

Yeah, it's a really good question. It was a, it was a decision we made from day one. We didn't come to 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 ServiceNow 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 Verkada as well. That was a big inspiration is Verkada. 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 and 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 a story of how they're replacing vendor spend, replacing existing budget category instead of adding on to their budgets. And AI has 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 more fruitful pond to swim in than just kind of relying on excess budget, experimental budget. And so both from a product perspective and a business model, it made sense to actually go after the real category.

ServiceNow is like a 20 year old company. How can you in let's say under a year, rebuild enough of that product that customers are willing to ditch that and move over to 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 has allowed really both of those things. So AI on the table, stake 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 ticking system, you could vibe code a basic ticketing platform in a weekend now it would be broken in a lot of ways and that's certainly not what we did. But just to give you a sense of how much faster it is to build so many of these capabilities and 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 for 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 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 servicenow where they're strongest, which is in the configurability, the customization and build workflows that do anything in 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 going to say, I mean the other option is you do this kind of 9010 where like we'll give you 90% or 80% of the features for 20% of the price or like will be more of a needed, will be vertical specific. And so yeah, you can't do these things here or maybe stage specific like we'll go to SMB mid market. We won't give you everything because you don't need everything. We'll give you this like that's the classic thing. But what I'm taking is that you actually just went for like across the board like feature parody on I mean I don't know about everything but the vast majority.

Yeah the core value. Right. We, 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 ServiceNow because it looks beautiful obviously. So making a product that looks prettier than ServiceNow 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 ServiceNow 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 serval 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 with 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, like you said hit them where they're strong is almost like where is the value prop. 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 Genai. This is not available pre2022.

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, as we built it today in 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 we were talking about the AI features that you've added 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 pregen AI just, 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 looks like. If you look at what Rippling had to do in the early days. And Rippling is 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. What's kind of the next move?

Yeah, I have these customer conversations every day and it's always like the leading indicator of what's going to 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 going to work, people are going to buy this. And so yes, I started closing the first deals. But we, 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 joining the team. A 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, and then kind of how do you structure it from there to, to a close?

It's all inbound at this point. So people come in through the website. We have got a lot of marketing engine activities, so LinkedIn, we do a lot of events, we do get inbound intros from, from VCs and portfolio companies and VCs that talk to their investors and want to see, see the latest tools. A lot of even large enterprises go to these VCs and say, hey, we're, we're thinking about our AI strategy. What, what is the hot tool in it and CRM and HR. And so we get a lot of inbound intros.

By the way, do you price under ServiceNow today?

We do. Today I think we're going to be less expensive than ServiceNow. I don't 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, in the early days, we end up being less mostly because, you know, they have all these modules and they sell a lot of shelfware. If you look at the utilization of a typical ServiceNow 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're, we don't have a lot of shelfware to sell them at this point. So the contract sizes will end up being.

But in terms of the value prop, like, you know, 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 in 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 crossed 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 going to fix all the things and, and we're going to add all the capabilities. And so yeah, there's, there's one week where all the conversations. People were so excited that I knew it was going to work.

What's like, roughly what's your demo to close rate?

I would say over 50%. It's pretty insane.

Crazy. I ask is that like as a, as a product market fit indicator? It's a great leading indicator. Like if that demo close rate is really high, the velocity just, you know, 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 because it's like saying, and it's funny, I just, I just realized I started doing this, like I would get 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 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 and I like, I push through. But if I'm being like very honest with 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 with my co founder and wondering, should we turn this around? Should we, should we like 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, we're right around the corner and it's, it's so tough because you can delude yourself into thinking that that's going to be the case. But we were right. It was the case and I'm glad we, we kept at it.

And then, last question. What would 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 worked, some of which didn't advocate 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, you even start to think that you, you're onto something. And I think that that, that led us down the right path. It, it, it's not great for the mental health, but it's, it is good for knowing that you've got something and not deluding yourself and, 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, Pablo. Really appreciate it. Great to be here.

Wow, what an episode. You're probably in awe. You're in 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.