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

Jake Stauch (00:00:00) :
When I joined Verkada, I'd heard so much about this legendary sales team. I wanted to join a sales call and just see what 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, we're probably going to buy thirty 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.

Pablo Srugo (00:00:24) :
How fast did you hit a million in ARR?

Jake Stauch (00:00:26) :
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 ACVs. There was a week where I did probably ten 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 fifty percent 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 was one week where all the conversations, people were so excited that I knew it was going to work.

Previuos Guests (00:01:01) :
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 of the show is Product Market Fit.

Pablo Srugo (00:01:14) :
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.

Jake Stauch (00:01:30) :
Thank you. Thank you for having me.

Pablo Srugo (00:01:31) :
I'm excited to have you here. You've been on a pretty fast journey. It seems like from the outside, you just raised almost $50 million, if I'm not mistaken, Series A last month. And you started the business a year and a half ago. Is that right?

Jake Stauch (00:01:45) :
That's right. Yeah. April 2024.

Pablo Srugo (00:01:48) :
That's a quick eighteen months, man. So take us back to the beginning. Before this, I see, you had a different company, and then you were kind of the director of product. But maybe just walk us through a little bit of that journey. Set the context for us before you decided to start it at Serval.

Jake Stauch (00:02:01) :
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. We actually built an EEG headset that measured kids' brainwaves and then video games. The more they focused, the faster the dragon would fly or the further ahead they could see in a tunnel and other cool game mechanics, and it actually helped kids a lot with attention problems. I ran that for a few years and had the opportunity then to join Verkada, an early-stage physical security company building really cool products.

Pablo Srugo (00:02:34) :
What happened, maybe before you jump to that role. What happened with NeuroPlus?

Jake Stauch (00:02:38) :
No, it didn't work out. We ended up winding it down. I ran it for seven years and had some early success, but it never really became a rocket ship. So eventually, I just decided that it was not going to take off.

Pablo Srugo (00:02:50) :
Did you do the hardware device or just the software?

Jake Stauch (00:02:53) :
We did the hardware as well.

Pablo Srugo (00:02:54) :
Yeah, so I had my first company called GymTrack, which was in the wearable space, 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. It was just hard, at least in our case, to get things to work to the level that we needed them to work. And that was the bigger thing, more than 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?

Jake Stauch (00:03:25) :
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 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 severe 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 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 started to saturate that group, we realized that there wasn't really a broader market outside of that.

Pablo Srugo (00:04:29) :
That's a very clear but non-obvious example of this, the difference between a hair-on-fire problem and not, right? You think about ADHD as 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 and had huge side effects, now it's like, oh my God, I need to do something. 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 is kind of born in the nice-to-have camp.

Jake Stauch (00:05:01) :
Exactly, I think the other thing there was our buyer was really the parents, and oftentimes it was mom. 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. There are 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 an even more stark trade-off for them. If medication was working at all, it just wasn't a good customer for us. And that ended up being the entire market.

Pablo Srugo (00:05:39) :
I remember after I, you know, wound down GymTrack, 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 whatever I do next, I just need a win. After this much time of this much effort and getting, you know, a fail, I just need a win. What did you feel like when you decided, okay, NeuroPlus is over and I'm going to do something else? What drove you?

Jake Stauch (00:06:02) :
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 it turns out you probably just, you're not in the right market. You don't have the right product.

Pablo Srugo (00:06:24) :
Yes.

Jake Stauch (00:06:25) :
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. I got this call from a friend that had joined Verkada very early, and he said, I remember this very clearly. He said, you know how everything was 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 the clearest explanation of what product market fit feels 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, I got to figure out what this is like.

Pablo Srugo (00:07:04) :
I got to check that out.

Jake Stauch (00:07:06) :
I got to, I got to check that out. And so what was really fun is I had the first conversation with this company, and there may have been like twenty employees. And I was like, oh, 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 fifteen employees. And I was like, I got to fly out and I got to meet you. And I fly out to meet them, and there's seventy employees. And you get to see that crazy trajectory on the outside. And then just, I want to be a part of this. And so I joined Verkada in the summer of two thousand nineteen, and went from one hundred employees or so and stayed with them through probably about two thousand five hundred employees over five years.

Jake Stauch (00:07:42) :
Crazy growth. The thing you mentioned, by the way, around everything being easier 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, who's one of the growth leaders at Facebook 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, you have something that's just working. You're like, oh, if we just do it in one hundred languages, we'll get one hundred times the growth. Yes, because of the query of something that's amazing that people love. And 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 the promised land, when ninety-nine point whatever percent of the time, you just have something fundamentally wrong at the problem-solution piece of the formula.

Jake Stauch (00:08:39) :
It's so true. I mean, I remember the other moment that really crystallizes for me is when I joined Verkada. I'd 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 they do on the call. What kind of crazy Jedi mind tricks are happening?

Pablo Srugo (00:08:56) :
What's the magic?

1Jake Stauch (00:08:57) :
Yeah, what is the secret that I've been missing out on all this time? I joined this call, and the sales rep just kind of does a demo of the product. 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, we're probably going to buy thirty cameras, send me the order form. It was just so stark to me. It's like, oh, you actually 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.

Pablo Srugo (00:09:24) :
So you're there for about five years. What's the driving force behind leaving and starting Serval? Where did the idea come from?

Jake Stauch (00:09:31) :
Yeah, so I joined Verkada having only been an entrepreneur. That was the only job I had before that, running my own company. 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 a year later, I'm going to go right back out there. 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. 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 Verkada, building all these new products together. 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? I want to start a company with my counterpart on the engineering side. I didn't want to start something that was in Verkada's development path for obvious reasons. I just felt like Verkada was going to win all these adjacent markets. But I was spending a lot of time with the IT buyer.

Pablo Srugo (00:10:29) :
What was Verkada doing, by the way?

Jake Stauch (00:10:31) :
So security cameras, access control systems, environmental sensors, alarm systems, visitor management. You can think of it as building operations and building security and cloud-based physical security for the enterprise. In the early days, we called ourselves Nest for the enterprise, but eventually became a much bigger business than Nest, so we stopped using that. We were building all these cool products. IT was a buyer, so I spent all this time with IT, and I was basically doing customer discovery with IT for five years because I was trying to figure out what new things to build for them from the Verkada side. In that process, you end up hearing all their other problems. You're basically trying to see what new camera I should build for you. Instead, what you're hearing them say is, hey, actually, can you get me out of the help desk? Can you get rid of all these tickets? Can you make all my users go away so I don't have to deal with this queue? You just hear those comments all the time. It lived in the back of our mind that this is actually a problem. 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 Verkada deployments. I have thousands and thousands of devices. For various reasons, devices go offline. Here's what happens. Somebody reports it offline. It becomes a ticketed service now. 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 is solved. 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 Verkada just know when there's a ServiceNow ticket and run some diagnostics and fix it itself? That idea was really, really interesting. It kind of evolved our thinking: what if we built a product not just for Verkada, but a product that could sit on top of these ticketing systems, identify issues, and then resolve them? At first, we were very narrowly focused because of our background. We thought we should do this for network device issues. So we'd sit on ServiceNow and diagnose network device issues that come through, reboot the device, or schedule a technician, or do something. That was the seed of the idea that eventually became Serval. Then we actually started talking to customers and realized network device issues are a very tiny portion of the overall problem here, but it was enough to get us started.

Pablo Srugo (00:12:43) :
Where did you get to before you decided that you wanted to leave and really just go all in on this idea?

Jake Stauch (00:12:49) :
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. 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 of product. It never felt like me. It felt like, okay, this is a job I pretend to do to get a paycheck. It always felt like I was waiting for the next thing. The timing just started to align, and the timing lined up with my co-founder. We had a great run at Verkada, and we got them from an early stage company to a company with two thousand five hundred employees and crazy revenues. It felt like the timing was right.

Pablo Srugo (00:13:23) :
So your co-founder was somebody you met at Verkada?

Jake Stauch (00:13:25) :
Yeah, we joined, I think, the same week or within a couple of weeks of each other, and we instantly got paired up. 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, build teams around those products, and go to market with those products. Five years to test a co-founder relationship is more than most people can ask for.

Jake Stauch (00:13:50) :
And you guys left at the same time?

Pablo Srugo (00:13:52) :
We left at the same time. Yeah, on the same day.

Jake Stauch (00:13:54) :
How do you go from the general idea of, okay, we want to do something for IT, maybe with this ticketing stuff, to what ultimately became Serval? Walk me through that customer discovery period, whatever it is that you actually did to get there.

Jake Stauch (00:14:05) :
Yeah, for sure. I had to talk to a lot of customers, especially outside the Verkada context. We kind of understood the Verkada customer, their contacts, but we wanted to talk to other folks. What helped me was I had a baby and went on paternity leave. 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. That's kind of how I, my one mental exercise during paternity leave was just getting connected to a bunch of customers and asking, what's your biggest pain point? I asked all 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 think about what that might look like. We had various different kinds of ideas in addition to the ones I've talked about with 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.

Pablo Srugo (00:14:56) :
How many calls did you do, more or less, during that period?

Jake Stauch (00:14:58) :
Over a hundred.
So it was probably a couple of days for a few months.

Pablo Srugo (00:15:02) :
And were you reaching out to people you already knew or how did you get these people on the phone?

Jake Stauch (00:15:06) :
Some were in network a lot. At that point, VCs, I think, were starting to circle the wagon and realize that we were 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. That was kind of the early game: all these VCs 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 them. It's also a way for them to do diligence because they get to debrief with a customer after the fact and figure out, is there a there there? That was super helpful. VCs made these intros. We reached out to friends of friends and just had conversation after conversation and danced around a few different ideas. What 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, because the solution there is obvious, which is automate the help desk. That's not clever, just automate the request in that way. You don't have to have so many tickets. Then it became, why don't they build these automations? There are all these workflow builders, a million workflow builders, cool custom scripting tools, all these ways to go and build automations. Why don't you do it already? That's when we realized the fundamental problem about all these tools: the process of building automation is really hard. There is so much friction in building the automation, the dragging, the dropping, the rules engine, the if this, then that.

Jake Stauch (00:16:27) :
Is this more the old school, pre-gen AI way of thinking and building automations? Robotic process automation, whatever, RPA?

Pablo Srugo (00:16:34) :
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, rules based, whether you're talking Zapier or Okta workflows.

Pablo Srugo (00:16:45) :
You got to cover every edge case.

Jake Stauch (00:16:47) :
Exactly. If you're doing something, especially 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. It might take weeks to build, and then somebody has to maintain it when something inevitably changes about your business process. What happens is there is no automation because there is so much friction in building and maintaining the automations. That's what got us really excited. I remember the question I asked that really got us down this path, which was so important, because I had asked a lot about what's your biggest pain point. You get a bunch of cybersecurity concerns and a lot of stuff that wasn't super helpful. But when I asked, 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? That is the question that really started to open people up. They started saying, well, I would have them go and build a bunch of automations. I would have 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 show me what they're able to do. We started to get a really consistent theme from that line of questioning. It opened them up to a different way of thinking about the problem. That's when I realized, hey, we can solve the automation problem. If we solve the automation problem, we've actually solved a much bigger problem, which is the IT service management, IT ticketing problem. We could build a better ITSM by building a better automation platform. That was the founding of Serval once we figured that out.

Pablo Srugo (00:18:12) :
It's funny how much the precise question you ask or how you frame it can change the answer. I think a lot of it has to do with, for you, these calls are very meaningful. You're trying to start a startup. For the recipient, it's just another call. Somebody's asking me some questions, whatever. They're not going to spend all day thinking about the best way to answer your questions. They're just going to go off the cuff. You have a lot of power. The simplest thing would be if you went in and asked, is this specific thing a problem? You get a lot of BS. A lot of people would say, oh yeah, that's kind of a problem, 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 somebody to get to, which clearly speaks to their own priorities and their own problems. Before we jump to the next phase of the business, maybe just give me a sense of how you structured these calls, because the devil really is in the details when you do this. I know you asked the classic, what's your biggest pain point questions, but how might one of these calls, like an example call, have gone?

Jake Stauch (00:19:19) :
Yeah, for sure. We learned a lot through the process and it evolved over time. In the early calls, which were not as helpful, we asked a lot more general questions, biggest pain point, what keeps you up at night, tell me about your day, what's hard about this and that, textbook customer discovery questions. You just get generic answers. You ask generic questions, you get generic answers. 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. We are going to dive into network troubleshooting and try to get really specific on what the pain points are. If we are wrong, we are wrong and we wasted a call, but that way we can actually get at something that might be more interesting. That helped us a lot. We would go into the call with a more narrow focus on what we were trying to do discovery around. Once we discovered this line of questioning, what would you do if you had somebody working for you, the other way we phrased it was, if I come to work for you tomorrow and you have your own custom development team that works right next to you, what is that team building for you? That is another way of getting at the problem. What we found was that people are not having a lot of problems anymore. Software has solved a lot of the top of mind problems. People are not thinking, 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 does not exist in a lot of categories today. What we found is you have to go a level deeper. All the point solution pain points that are top of mind have been solved and they do not maybe feel like pain points anymore. We really have to think about what you would do if you had extra labor to throw at a problem. That aligns much better with how we think about AI. What if you had extra labor and intelligence to throw at a problem, what would you do with it?

Pablo Srugo (00:21:10) :
Once you figure out that that's kind of the more specific place that you want to go, which is, you know, 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 a round?

Jake Stauch (00:21:25) :
We were lucky enough that there was so much interest in what we were building that we were able to raise a round. When I say what we were building, I mean what we were thinking of building, because we really had nothing built yet. We raised our seed round before we had written anything, before we had really even incorporated the business. We had the seed round committed, and that was really exciting.

Pablo Srugo (00:21:47) :
And how much was it?

Jake Stauch (00:21:48) :
That was a $4.5 million seed round led by General Catalyst and First Round Capital.

Pablo Srugo (00:21:53) :
And when was it?

Jake Stauch (00:21:54) :
That was in April two thousand twenty four. So that was committed in March and closed in April of two thousand twenty four, right when we started the business.

Pablo Srugo (00:22:03) :
And what's your first step after you have the money?

Jake Stauch (00:22:05) :
Once we had the money committed, we were happy to give our two weeks notice and we resigned. Our last day was April fifth, and our first day of the new company was April eighth. We left on a Friday, took the weekend, and then we started on Monday, ready to go. We decided to go after the hardest problem we could think of first, the biggest risk where we were not 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? The idea we had was that you should be able to describe your automation in natural language and then just have that automation be built for you. The way we arrived at that being the core idea was another customer conversation where they were very excited about the Okta workflows they built. They described this Okta workflow in one sentence, which was, I want to elevate approvals for certain expenses over $1,000 to an M5 manager or above and make sure an M5 manager approves it. If you reach the CEO, you have gone too far, so go down to an M4 manager if the CEO is the next highest manager. One sentence to describe what he wanted to build. Then he showed us this workflow in Okta 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 it took about two months to build. That idea was so impactful for us. It was like, he could describe that workflow in one sentence, and it took all this time and all this logic to get it working. We were like, what you really want is to describe that workflow in one sentence and then just get that workflow on the other side. If we could build that, then we really had something. That is what we started off building. How do we make that possible? The only way to make that possible is to take the natural language, use that as a prompt, and generate code that executes the workflow. There is no way to do that with a block based traditional workflow system. If you think about it, code is a really efficient, compact way of representing complex logic. We decided to build this natural language to code system and see if it would work. If we could build that and get it to a state where we believed it was going to work, then the rest of the capabilities, the ticketing, the IT service management, the help desk, the Slack bot, and all the things that come next, we were very confident we could build those things. There was no real technical risk there. The real technical risk was whether the core idea could really work, and that is where all the early development went.

Pablo Srugo (00:24:46) :
You love this show. You do not want to miss the next episode. Why would you? So hit that follow button. Trust me, it is in your own best interest. So a few questions, maybe just the first one. It is very surprising to me what seemed like such a simple workflow has so many edge use cases. Can you just walk me through a couple, you know, that tree that was so long for something seemingly so simple? What would be some of the edge cases on there that would be unexpected, just because it gets to the crux of the value that you are ultimately delivering with your kind of easier product solution.

Jake Stauch (00:25:15) :
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 the 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 does not exist? Or what if that value is null and that has been deleted? Then, okay, you have to go and take the next step. You have to send a message. Well, how do you send the message? You have to connect 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? So you are basically building together these blocks, because we think about what a no code workflow builder is. It is these blocks that have certain inputs, certain outputs, certain steps in the middle, and you connect them with this logical flow. 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 being very, very complex. Whereas obviously, if you are writing this in code, you would be using these APIs and you would be able to get this data very, very quickly. You would hit these endpoints, get this information, and pass that instantly into the next step. All of this is very simple from a code perspective, but it is very complex from a no code perspective, and that is the case with a lot of these workflows.

Pablo Srugo (00:26:33) :
And to get rid of that technical risk, what is the test that you set up? How do you know that the output, the code that your system outputs, for example, covers all the edge cases?

Jake Stauch (00:26:41) :
That's the hard part, right? It's a lot of trial and error. We started building, and 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 these inputs and these outputs match and this should work, it should not fail. That was kind of the biggest failure case, that as a simple example, you would output a string in one step and the next step actually expects the input variable to be an integer, and obviously that is not going to work. The type checking was a really key unlock there, using an API spec and then using the LLM to actually do the type checking. Then there was 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 is a known good workflow. We would build workflows that we knew worked, and we would store those in the system as context so that when you went to build a workflow, the system would say, it might look like this if it is working. That worked pretty well because you could give it a bunch of different examples, and as long as what people were prompting was somewhat close to those examples and used APIs that were fairly well documented, it would kind of work. What is very important here, and this is something that is true in this AI era, is that it did not actually work all that well, but it was close. We had to take this calculated risk of whether we think the models are going to get good enough where this actually works, because it did not work yet. We thought this does better than we expected, and we think the things that have to change about these models, the things that have to get better, are small enough that we are confident we are going to figure this out. We passed that check internally where we were like, this is going to work. This fundamental idea that people can prompt and get a workflow on the other side, we believe it is going to happen. It works in a set of cases that are not very interesting, but it will work for more and more cases over time, and we are confident in that. That was basically the first phase.

Pablo Srugo (00:28:51) :
That piece that you mentioned of operating under the assumption that these models are going to get better is critical. 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 do not quite work, to know that they are going to work, because otherwise you risk getting leapfrogged. It is the same as if you think about back when chips were the rate limiting step, twenty or thirty years ago, CPU stuff. If you do not assume that these chips are following Moore's law and getting better and better, you are going to design applications that do not use enough RAM, do not use enough memory, because they are built on the constraints of today. Then tomorrow, the new chip comes out and somebody was building for that, and now you get leapfrogged. It is not straightforward at all, but I think that has really changed. I would almost say pre and post ChatGPT is the easy kind of delineating line of how you should be building in a post-gen AI world that is changing so fast.

Jake Stauch (00:29:45) :
Yeah, absolutely. And it is such a tough balance, because you can delude yourself very easily, which I think entrepreneurs are very good at with this optimism bias of no, it will work. You can delude yourself into thinking that yes, this does not work today, but we are just a few months away and that is actually going to work. There is this fine margin of it does not work today, but actually will work very quickly. It is very unpredictable because the progress that these LLMs are going to make is going to be, I think, in fits and starts. There is going to be a long period of time with maybe not a lot of progress, and then there is probably going to be step changes. You have to kind of take risks on when that is going to happen.

Pablo Srugo (00:30:22) :
Were you building with design partners during this phase, or was it just in the lab, kind of in the background, just trying to see if this thing could work?

Jake Stauch (00:30:29) :
We're constantly doing customer discovery and trying to get design partners. I think we didn't really have a design partner 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 is kind of a mediocre, very limited workflow builder. And it's cool that it's natural language to workflow, but it can only build a very small set of workflows. So what's the value of that? 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.

Pablo Srugo (00:31:04) :
So this, we're talking about the end of last year, like we're talking about the fourth quarter of 2024.

Jake Stauch (00:31:08) :
Q4 2024, those were our first design partners.

Pablo Srugo (00:31:13) :
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?

Jake Stauch (00:31:19) :
It's the two of us until September 2024. So the first five months, it's just the two of us. Then we hired our first person in September, our second person in October, and our third person in November. So it ends up being 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.

Pablo Srugo (00:31:41) :
Which is the way to do it, because at that point, the thing that matters most, rather than just how much code you can put out, is just, can you stay aligned? Can you change fast? Can you be flexible? And really, having no overhead when it comes to alignment and communication, all these sorts of things. So you're working with these design partners in the fourth quarter of 2024. What's the line at which you decide to launch? What are you waiting for in terms of the product where you're like, okay, this product is now ready for prime time?

Jake Stauch (00:32:07) :
Yeah, this is an ongoing discussion because the conventional wisdom is just go sell it, 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 showed the product, people could poke twenty 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 ten minutes in, it was very clear 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 ten percent of the things they needed to do, and they think it's cool and neat, but it's not a product they can buy. And so that was kind of the experience, basically, for the first five months of 2025. We were in design partnership, building a lot of capabilities, but we just did not have a sellable product. I would say there are 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 we've got a mediocre ticketing system, a mediocre workflow builder, and a mediocre access management system. 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 bit higher for us in that we couldn't sell to startups. We couldn't really sell to anyone with less than two hundred or three hundred employees, and even then they didn't have a really strong pain point. You really don't feel the pain until you're five hundred or a thousand employees. And so the bar ends up being much higher because you have to go up market faster than a lot of startups, where you can start selling to other startups or twenty-person companies or fifty-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 to have that from day one. So it was a lot of demos where 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 probably also say no to that in most cases. But it was a lot of building in the dark. It was really hard.

Pablo Srugo (00:34:37) :
Did you try to sell to outsourced IT, like the MSP space as well?

Pablo Srugo (00:34:41) :
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. It's very hard; there are actually more requirements because you're selling to this MSP that's been 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 pick your customer, pick the tech stack you want to work with, and pick the capabilities that make the most sense. 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.

Pablo Srugo (00:35:24) :
When do you decide to launch publicly?

Jake Stauch (00:35:26) :
We never really did a launch, launch. We were kind of building in public the whole time. But the first time we had a product that we could sell, the first sale that we made was in May of 2025, and that was our very first sale. So over a year from the start.

Pablo Srugo (00:35:42) :
Five, six months ago, let's say.

Jake Stauch (00:35:44) :
Yeah, six months ago. Yeah.

Pablo Srugo (00:35:45) :
What does a typical sale look like? What kind of ACVs are you talking about?

Jake Stauch (00:35:49) :
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 in the $20,000 range, then the $30,000 and $40,000 range, then the $50,000 and $60,000 range, and then they just keep going up and up. Now we're getting into seven figure territory. It's been really exciting. Over the past six months, as the products matured, the ACVs just keep getting higher and higher. I think they'll probably settle as an average in the mid six figures, low to mid six figures. But over time, we'll see more and more go up market, and we'll see more and more in the seven figures. If you look at ServiceNow, most of that 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, playing in the ServiceNow territory, where sixty percent or so of our revenue is $5 million ACVs. But we've got a little ways to go to get there.

Pablo Srugo (00:36:41) :
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 five or six months, let alone seven figures.

Jake Stauch (00:36:53) :
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? You kind of get a foothold in the mid market, spend a couple of years there, and over time you creep up to a thousand employees, two thousand employees, and eventually one day you can service a large enterprise. We found from pretty early on that large enterprises were interested in what we're doing and had a lot of the same pain points that mid market companies had. They move slower, but the product requirements are not different, and that's what is really unique here. We didn't have to reinvent the product to serve these customers; they just move slower. If anything, I think we would have had faster growth in ACVs, but it's just the natural order of things that a two hundred person company is going to buy a couple of weeks after a demo, and a two hundred thousand person company is going to take six months to make a purchase order.

Pablo Srugo (00:37:49) :
How fast did you hit a million in ARR?

Jake Stauch (00:37:51) :
In the first couple of 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 ServiceNow deals, it's not uncommon for them to have eight figure contracts. And there are a lot of companies spending $10 million, $20 million, $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 what's really important about what we built, we took a lot longer building than a lot of other companies, but because we built the full platform, we're talking about ServiceNow rip and replace. We're not talking about just being an AI layer on top of ServiceNow.

Pablo Srugo (00:38:27) :
I was just going to ask, like, you're not, right? Okay. You're taking customers away from ServiceNow.

Jake Stauch (00:38:33) :
That's the goal. Yeah, exactly and we know that that takes a while, right? These contracts are three years long. Unwinding a hundred thousand employees off of ServiceNow is not something you do in a four week sales process. So I'm not saying we're going to 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 they're going to be converting into $10 million, $20 million, $30 million, $40 million deals.

Pablo Srugo (00:38:55) :
And so you're still sub $10 million ARR, right? You're probably somewhere between $1 million and $10 million?

Jake Stauch (00:38:59) :
Yeah.

Pablo Srugo (00:38:59) :
Why did you decide to do this full platform replace ServiceNow? I get that as a long term vision, that would have been the kind of no brainer thing you want to do. But why did you choose, and it sounds like it was the right choice, why did you choose not to just start with, okay, we'll build on top of ServiceNow and then build the rest of the stuff and then do a rip and replace?

Jake Stauch (00:39:18) :
It's a really good question. It was a decision we made from day one; we didn't come to this over time, and there are a couple of 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. 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. Verkada was pretty counterintuitive, to build the video software, 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 fewer vendors, not more vendors, and so we'd much rather go to them with the story of how they're replacing vendor spend, replacing existing budget categories, instead of adding on to their budgets. AI 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 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 pond to swim in than just relying on excess budget or experimental budget. Both from a product perspective and a business model, it made sense to actually go after the real category.

Pablo Srugo (00:40:57) :
ServiceNow is like a twenty 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?

Jake Stauch (00:41:08) :
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 the table stakes functionality, where you just need feature parity, and then the innovative capabilities that get people so excited they're willing to make the move. AI has allowed really both of those things. 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 ticketing system—you could 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. 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 forward deployed engineers that are working with customers to, every time a customer makes a request, pump these features out left and right. AI allows us to move much faster there. 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 configurability, customization, and building workflows that do anything in any application. 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.

Pablo Srugo (00:42:26) :
I was gonna say, I mean, the other option is you do this kind of ninety-ten, where we'll give you ninety percent or eighty percent of the features for twenty percent of the price, or we'll 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. 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 mean, I don't know about everything, but the vast majority.

Jake Stauch (00:42:51) :
Yeah, the core value, right? We wanted to understand why people are using this platform and build a better version of all the things that they actually care about and use, and attack them where they're strongest, which is customization and configurability. People don't buy ServiceNow because it looks beautiful, obviously. So making a product that looks prettier than ServiceNow is not going to 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. With enough time, energy, and effort, you could build whatever you want on the ServiceNow platform. So what we went after is making it easier, faster, and more configurable so that you can build anything you want on the platform, but you can do it in minutes instead of months.

Pablo Srugo (00:43:29) :
Because yeah, the most classic place would have been to go down market, but then with a limited feature set. But because you're going enterprise, you've been able to go enterprise, and you've really used AI to feature match. In fact, you used AI to give them even more configurability. Like you said, hit them where they're strongest, almost like, where's the value prop? Okay, here's the value. Let's ten times that value and then give them the table stake stuff, which is fundamentally, I would say, a new go to market approach that's unlocked by Gen AI. This was not available pre 2022.

Jake Stauch (00:43:57) :
No, no, we could not have built this company before we built it. And when we started, as I said, we could not have built this company as we built it today in the early days of this company. I mean, the timing could not have been better for us.

Pablo Srugo (00:44:07) :
But to be clear, a lot of that is the AI features that you've added on top. But just the fact of being able to rebuild somebody else's enterprise grade product in this amount of time. Even that alone, pre Gen AI, I don't see any way you could have done that.

Jake Stauch (00:44:20) :
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. So much of their early story is just building a really massive team and going after all these categories. It's amazing how a smaller team with AI can build so much, so much faster.

Pablo Srugo (00:44:47) :
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, and you started seeing the sales actually closing. What was the next move?

Jake Stauch (00:44:58) :
Yeah, I have these customer conversations every day, and it's always the leading indicator of what's going to happen to the business, because sales is a super lagging indicator. I have these conversations and can kind of know where things are going. I think it was around April when I first started having these conversations and realized, hey, this is going to work. People are going to buy this. So yes, I started closing the first deals, but once we realized we had something, we immediately 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, who actually joined us as COO. We also hired some other incredible go to market folks. Now we've spun up a crazy go to market engine, building out a great sales team with a head of sales and a VP of sales who joined just in the past week, additional sales reps joined the team, and a really robust marketing engine. We decided to go early and hit go on all the go to market functions as soon as we started to feel that pull.

Pablo Srugo (00:45:58) :
What is the go to market motion today? Where do most of the leads come from? And how do you structure it from there to a close?

Jake Stauch (00:46:04) :
It's all inbound at this point. People come in through the website. We have a lot of marketing engine activities, LinkedIn, events. We also get inbound introductions from VCs and portfolio companies of VCs that talk to their investors and want to see the latest tools. Even large enterprises go to these VCs and say, hey, we're thinking about our AI strategy. What is the hot tool in IT, CRM, and HRS? So we get a lot of inbound introductions.

Pablo Srugo (00:46:33) :
By the way, do you price under ServiceNow?

Jake Stauch (00:46:35) :
Today we do. Today I think we're going to be less expensive than ServiceNow. I don't think that will 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. If you look at the utilization of a typical ServiceNow customer, they're utilizing very little of what has been sold to them. I think we're probably pricing equivalent to what they actually use, but we don't have a lot of shelf to sell them at this point. So the contract sizes will end up being.

Pablo Srugo (00:47:05) :
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 win, and that tends to close really fast.

Jake Stauch (00:47:17) :
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.

Pablo Srugo (00:47:24) :
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 had found true product market fit?

Jake Stauch (00:47:30) :
There was a week. It was not a single moment, but there was a week where I did probably ten different demos, and in every single one, their faces lit up when they saw the product, and they didn't care about all the missing stuff. It was almost like we'd crossed this fifty percent threshold where they started rounding up what the product could do versus rounding down. In the early days, when you're dumbing the product, I think everyone kind of rounds down and thinks, oh, I don't really understand any of this stuff. It's not going to do the things I need. We just got to a certain point where it became clear that no, they believed we were going to fix all the things and add all the capabilities. And so yeah, there was one week where all the conversations, people were so excited that I knew it was going to work.

Pablo Srugo (00:48:14) :
What's like roughly, what's your demo to close rate?

Jake Stauch (00:48:16) :
I would say over fifty percent. It's pretty insane.

Pablo Srugo (00:48:18) :
Crazy, I ask because 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.

Jake Stauch (00:48:28) :
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.

Pablo Srugo (00:48:33) :
That's insane, dude.

Jake Stauch (00:48:35) :
It's funny, I just realized I started doing this. 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.

Pablo Srugo (00:48:44) :
How much is that one hundred thousand? Cool.

Jake Stauch (00:48:45) :
Yeah,

Pablo Srugo (00:48:46) :
It’s ridiculous. The other question, the opposite is, 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 fail?

Jake Stauch (00:48:55) :
I would say up until April of this year, it was fifty-fifty for me. I mean, I have a lot of confidence and I push through, but if I'm being very honest with myself, I felt we were still on a knife edge in April of this year. So just 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 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 because you can delude yourself into thinking that that's going to be the case. But we're right. It was the case and I'm glad we kept at it.

Pablo Srugo (00:49:36) :
And then last question, what would be your number one piece of advice for an early stage founder who's trying to find product market fit today?

Jake Stauch (00:49:43) :
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. A decade plus of launching products and seeing some work and some take off 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 led us down the right path. It's not great for mental health, but it is good for knowing that you've got something and not deluding yourself and not thinking you've found it when you haven't.

Pablo Srugo (00:50:29) :
Awesome. Well, Jake, great chatting with you, man. Thanks for jumping on the show.

Jake Stauch (00:50:32) :
Thank you so much, Pablo. Really appreciate it. Great to be here.

Pablo Srugo (00:50:35) :
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.