Go hard early: How lessons from Verkada shaped Serval's AI agents for IT teams | Jake Stauch (Founder and CEO)

Bercada game this confidence of just do the hard things, actually seek out the hard things that are harder for other people to do, that unlock a lot of customer value, and then once you've built them, it's so much harder for somebody to come in after you 'cause you decided to like, go harder early. For today's episode, I'm sitting down with Jake Staunch, co-founder and CEO of Serval, an AI native platform for IT teams. Last year, my partner, Bill Trenchert, led first-round seed investment in Serval, but for the idea was really crystallized. We knew Jake from Bercada where he and his co-founder, Alex spent years building products and observing IT's biggest pain points. After doing a lot of interviews, and I would say, "What keeps you up at night? What's your biggest pain point?" And you just wouldn't get anything really interesting? One of the questions I started asking is, if you could hire somebody today to just sit next to you and do work for you, what would you have them do? That led them to ticketing and automating the repetitive work of enterprise IT, a massive category dominated by legacy players. The product has to be so much better than the alternative, and you have to really understand why it's better, and what's stopped another company from building it. These days, Serval is seeing incredible traction, automating IT for customers like perplexity, for Cata, Mercor, and together. And just this week, they announced a $47 million series a led by Red Point. In our conversation, we dig into the lessons Jake learned from for Cata, and the unique choices he's making as he builds Serval, including building a full platform from day one, the interesting way they use forward deployed engineers, and the technique he uses to maintain a high bar for talent. When we're looking at candidates that we're bringing in, I like to make people tell me on the interview panel, who are they better than at the company? We evaluate every candidate on their ability to recruit the next candidate. Let's dive in. Well, thanks for joining. Thank you for having me. So the last big chapter of your career happened at Mercor, which is a coming that some people know about, other people don't know about, but it's a really fascinating, interesting company, sort of at the intersection of hardware and software, and then they had end customers that were government, enterprise, mid-market, et cetera. And you had a bunch of different product rules in the five or six years you were there. I'd be interested in hearing more about what are the big ideas that you took out of executing and building in that environment that are kind of a way that you think about company building as you sort of went out and started your own thing. One of the big ones is going after an existing market and an existing category of spend. I launched a lot of different products at Vercata, and I got to feel the difference between launching a product into a category where people were actively spending money on versus a category where no one had ever spent money on this thing before. And you can do both, and there's certainly examples of successful products in both worlds, but there's something really powerful about going in and just building a better product in a category where people buy that product and want that product. And Vercata owned the entire platform, and it was really cool to be able to sell a better camera to people that were going to buy cameras. And then you could also, by nature of selling cameras, also sell them these really cool AI capabilities. It's really cool video management software platform, but you did that by selling cameras, not necessarily selling video software or selling AI. You sold the actual entire platform. And I definitely took that concept with me to serve all of what platform can we sell that there's existing span, there's an existing category that we can go after, but we can actually package something new and differentiate it within that. But they'll still buy the platform and they'll buy it because you're offering this new cool capability. - Is there anything you have to get right that's unique to building an existing category other than building an excellent product? I think the product has to be so much better than the alternative and you have to really understand why it's better and what's stopped another company from building it before. A lot of times these categories obviously, other people have tried to go after the big leaders, whether it's ERP, HRIS, CRM, ITSM in our case. And so you have to understand what's been missing and is there actually an opportunity to go after it? In some cases, it's not gonna be enough to just build a nicer, cleaner UI and a faster experience. You have to fundamentally look at what's been missing. And so in my opinion, the experience just has to be 10 times better. It has to be undeniable. It can't just be a little bit better because people build their businesses around these systems. They're not gonna just transition and put up all of that investment and that change management process unless the ROI is obvious from the moment they see the new version. - What's the best Verkata story that sort of brings that idea to life? - I think one of the most powerful parts of the Verkata camera demo is when you can send the sales rep sends a live link of the camera footage to a customer on the demo call. And so they can show the demo, they can show the camera feed and they send a link through the UI to the customer. The customer can pull up the text message on their phone and then start streaming to the camera. That sounds pretty basic, pretty straightforward, but this capability had never existed in any of these on-prem security systems, on-prem camera systems. There's just no way to do anything like that. So if you wanted to see a quick link into something that's going on in your facility, you couldn't do that. You'd have to do some kind of remote access into some on-prem NVR server to see what was happening. And having a sales rep just send you a quick text message and you can pull up the camera feed that blew people's minds. That is an example of taking something that is straight for the people understand cameras and adding a capability that no one had ever seen before that was so much better than anything they'd seen. And that kind of encapsulates all the benefits of the platform. Having a cloud-based system, having a modern user experience, it put it all together into like one moment where you got the text message and it started to click, like, oh, these are all the things I can do. Not that that use case is that valuable. People don't really need to send out text messages with links to camera footage, but it really showcases what a modern platform is capable of in a very distinct moment. To your point, it's slightly counterintuitive because it's not a killer use case that somebody's using 30 times a day. What I was constantly reminded of when I was at Ricotta is that these enterprise buyers are also consumers in the sense that they use these very sophisticated, very complex systems that work all day, but then they go home and they use nest cameras and ring cameras and modern technologies and they have that contrast and they see it. And so when they see something in their enterprise, it starts to look like what they expect at home. That's when it starts to click for them how much better the experience can be. And so we were basically delivering a consumer quality experience to these enterprise buyers. And so something as simple as sending a text message to that video feed and pulling up their phone, it started to feel like a consumer experience of you get a notification from your ring camera and you pull it up and you can see what's going on. And it started to make them connect the dots of why don't I have this same capability. Once I go into the office, I go 20 years in the past and I'm dealing with ancient technology just because I'm at work instead of at home. What else did you learn about building more platform style products? I feel like everybody thought every founder wants to build a platform or every founder wants to build a system of record. Very, very rarely does that come along in your advocacy working on a system of record style product in survival. But I'm curious if you had any other reflections on building a platform, building multiple products, multiple use cases, sort of those types of things. I think there's a few lessons. One is finding the things that are hard and just deciding to do them. When Furcata started it would have been much easier to just build software that sat on top of existing cameras, building cameras that have to be installed, one manufactured, two installed. That's so much harder and it's such a big barrier before you can actually get traction. But it's the better long-term solution and so just biting off that really hard thing is I think so important when you're building a platform because there's a lot of stuff that you shared on the barrel of building out a full ticketing system, building out a system that can be deployed on-prem, building out all these roles and permissions and all these enterprise integrations. And it just seems so hard and daunting. And I think Furcata gave me this confidence of just do the hard things. I actually seek out the hard things that are harder for other people to do that unlock a lot of customer value. And then once you've built them, it's so much harder for somebody to come in after you and build those same things because you decided to go hard early. What are the other examples other than the not sitting on top of existing camera systems? I think the other thing is going multi-product early, relatively early. That's another thing that's very daunting. You've got a camera business that's going really well and then why mess anything up by going into access control, going into sensors, going into alarms, going to visit management and kind of spreading yourself thin. That's kind of the outside and look 'cause like are you sure you wanna build all those products? There's a recognition that you had to to build a platform. That you really wanted to go multi-product into selling complete solution. And if you're selling something that you think is gonna lock a lot of value for the customer, like just biting off all that surface area is another thing that's related to the first point but is slightly different and just deciding to like, "Hey, we're gonna do it." And it's gonna be hard to build cameras and a best-in-class access control system and a best-in-class alarm system and like put all those together. There are things I learned to do differently as well. We're kind of as interesting in its go-to-market and that a lot of small employee-count customers actually had very large real estate footprints and were fairly large accounts despite being fairly small companies. I think that's a little bit different in my market. It's more traditional where kind of spend increases with headcount. And so we have to go up market if we're gonna unlock large account sizes and large deals. And so there's a lot more that we had to build for the enterprise than Verkata did early. Verkata waited several years to support things like SKIM and SSO and SOC2 and various compliance frameworks. We did all of those things from day one because we knew that that was gonna be blocker to sell into the large accounts that unlocked the bigger ACVs. We also decided to build a lot of things in the platform that Verkata only added much later when it was required for them to go up market. We knew from the beginning that we really didn't have a business unless we could go up market very quickly. And so that a lot of things around user management and permissions, a lot of things around being able to deploy on-prem and have flexible deployment options. All of that are things we bid off very early because we knew where we'd end up and we saw the pains of being at Verkata when you're trying to go up market. And a lot of that capability hasn't been built out yet. - Maybe sort of that's a good pivot point. What's the first kernel of serval? Where did it come from? - The very first kernel of serval was talking to customers at Verkata that wanted some way to automatically resolve device issues. And so we'd talk to customers that would have devices to go offline, sometimes Verkata devices like a camera that goes offline, but sometimes just regular network devices, their Wi-Fi goes down or a switch goes down. And there's a lot of frustration with the process of resolving something so basic as a camera being offline. Somebody has to report that it's offline. Somebody then has to investigate what's going on. They maybe have to assign that ticket to somebody else. And at the end of that process, that back and forth, that assignment, you're gonna reboot the camera, you're gonna reboot the switch, you're gonna install new firmware, or you're gonna call a technician, there's a defined set of things that you're gonna do that are very simple, that you're gonna resolve that problem, but every single time something happens, you have to go through this long journey. And so the first idea was, what if we could just sit on top of that ticketing system, notice when there are device issues that are propping up, and then automatically resolve them, whether that's a reboot as a service as an idea I came up with, like we just to proactively reboot cameras, maybe detect issues, maybe that is scheduling a technician, maybe it's just sending a report of what might be going on, or automatically opting to firmware. And so the initial concept was, hey, we can build a platform within Recorder outside of Recorder, we can build a platform that diagnoses device issues, and resolves those automatically. We took that to a lot of customers, I did customer discovery, and nobody cared. Turns out that was a very Recorder customer-focused problem, and that was very top of mind when you were talking to customers, doing a big device deployment, but after those devices are deployed and you got through the early troubleshooting, it didn't become a long-term problem. But when we talked to customers about that, they said, yeah, that's something, but here's my other problem, I've got a lot more tickets than just device tickets. I've got access requests, I've got password resets, I've got people just asking me the same question that they could just look up in the knowledge base, solve that for me, and that became the evolution of circle. So how did you end up chasing that down after you started to sort of see that opportunity? And how much of it was you had decided you wanna start your own company again? And what should you do versus it wasn't on your radar to start another company in this insight, sort of pulled you into it? No, absolutely wanted to start another company. I mean, I joined Vercada, knowing I wanna start a company, I thought I was gonna stay there a year, I stayed there five years, because it's such a great place to be, but the itch was always there, it's something I had to do, is the only thing I'd done before Vercada, it's hopefully the only thing I'll do after Vercada, and so I was always looking at what could be the next thing. Now I didn't wanna just build a product that Vercada was gonna go build and just go back and compete with Vercada, I think it was hard to compete with a platform that's so robust and powerful. So I was looking for things that were adjacencies, and one of the areas that I thought was interesting is like, what else could you sell to IT that's like outside of the scope of Vercada? And there's a lot of different ideas that I chased down at one point, I was very interested in, hey it's really interesting that when we sell a big camera project, a lot of times customers are buying cameras from Vercada, and switches from Iraqi, and then these uninterruptible power supplies from Schneider Electric. So two Silicon Valley tech companies, and then 150-year-old French company is part of the bill of materials for all these massive projects. It's like maybe you could build a better power supply for these switches. Another idea that you start interviewing customers and trying to get them to say, you almost hope that they say, this is a huge pain point for them, no one cared. One, very hard to get people to even talk about it on the phone, and two, they don't know what they buy, they don't know what the pain points they have, they're totally uninterested. The other idea that we chased down a lot was this idea of, okay, there's something around people frustrated by these tickets, initially offline devices, but more broadly, let's chase that down. We just did a lot of customer interviews. Alex and I, my co-founder and I were both founders before Vercada, we were at companies that didn't really find crazy product market fit. So we just had this deep skepticism, and I think a lot of strictness, and we needed to hear a lot of things, a lot of good things before we thought there was anything, any chance that this business would work out. So we interviewed a lot of customers, trying to figure out, is this real? And I think one of the things that was a really interesting insight from this process of interviewing, to back up, you hope when you get on these interviews, that somebody's gonna be like, I have this pain point. I wish somebody would solve it, and I will spend this much money for somebody to solve it, and then it's like, oh, we could solve it. Which part of the issue with customer interviews, I think? You end up managing for the outcome that you actually want, because you want somebody to say that, but, you know, and especially today, it's very rare that you're gonna hear something that sounds like that. People have mostly solved the problems that they're very aware of, and they've got some tool in place. And so one of the questions, after doing a lot of interviews, and people would say, you know, let's say, what keeps you up at night, what's your biggest pain point, and you just wouldn't get anything really interesting? One of the questions I started asking that I thought was really interesting is, if you could hire somebody today, to just sit next to you and do work for you, what would you have them do? And it's another way of getting at, what are you spending time on that you really want to offload to somebody else? And that's when we started getting really interesting answers around, I want someone to just play around and build me a bunch of automations. I want somebody to take on all these help desk requests. I want to offload all these manual repetitive tasks that I have. I thought that was really interesting, because they never identified ticketing as a pain point. Nobody said they wanted a new ITSM. No one said they wanted a new workflow builder, or a new access management platform. They just said they wanted somebody to go and like handle a bunch of these requests for them, and somebody to go and build cool automations for them. What do you think that reframing of the question yielded such an interesting new set of insights that was not apparent before? The IT buyer in particular, really prides themselves on figuring things out and being a problem solver. And so they don't think about a lot of this process as being problematic because they figured it out, it works. And it's quite effective, and obviously it works, because they're at organizations that are quite successful, and no one doesn't have access to the internet or the software they need. So a lot of it feels like a solved problem, because IT has taken on all this work and solved it, and there's a lot of pride that comes from that. And they wouldn't identify that as broken or painful, because it's their job. They did it, and they did it successfully. But then when you frame it as, hey, if you had somebody else to help you, what is the work that you'd give them? That's like a non-judgmental way of saying, like, what are the pain points? Because you're saying, what would you push over to this new person? And then they can be much more freeway. It's like, I don't like to do these things, or I am doing a lot of this, and I think somebody else could do it for me instead. And it just allows them to have more of a neutral perspective, instead of saying, like, this is problematic, or this is painful. It's like, no, there's a lot of work in this category that I can shift. How else did you spend time with customers, maybe chasing down any of these different ideas? Are there other questions that you asked or other things that you've found either helped you rule opportunities out or go deeper into when it ended up becoming cerebral? One of the challenges we had with a lot of these interviews is that we couldn't get somebody to say that X, Y, and Z was a big pain point. We got some information around things that they would use labor to add extra head count to go do a thing. That was really interesting. So then we started really digging down this automation concept. Of it seems like they want help to do a bunch of stuff, and they want help building automations. They want to automate more things, which sounds super obvious and not super helpful. But one of the areas that we thought was really interesting was why isn't this already solved because it looks from the outside in, like there are a lot of great automation tools out there. And one of the most competitive categories in an enterprise software. Yes, there are tons of workflow builders. There are all these kind of cool automation tools. This feels like such a solved problem. And yet when he talked to IT, they weren't really using these. And so something is not solved. And that allowed us to double click and saying, okay, well, why aren't you automating this? Why aren't you using Octo Workflows or Zapier or these other tools? Walk me through this process. And a lot of it ends up being that there's just friction in building these automations. Not that those tools don't work, they do. But it takes an investment for often an unclear ROI. And so you have to invest all this up front thing. It's the simplest resetting a password, which often has all kinds of rules associated with it in the enterprise. Don't let these people reset passwords. Don't reset more than two passwords and four hours, whatever. And so building out something as simple as a password reset workflow ends up taking days, sometimes weeks to get all the logic into place. And so the core insight that we took from those conversations was automation doesn't actually work for this IT use case unless it's faster to automate something forever than to do it manually once. You have to take away the trade off. So it's actually just easier for you to automate every single password reset for everyone for always. Then to go into Google Workspace and reset a single person's password. Because then there's no trade off, right? It's just, you're just gonna build the automation 'cause that's better than doing it manually. But if you force the trade off, then it's like, I don't know, you're busy. You've got all these requests coming in. Why are you gonna like go into some blank page workflow builder and figure out how to construct this workflow, which again might work that's gonna take you a lot of time. Meanwhile, the help desk requests are piling up. You've got some new office to open. You've got to cut down some spend on some bill. You've got a lot of things on your plate. Automation doesn't fit into that. So barring you, hiring somebody to go build some automations for you. What are you gonna do? You're just gonna do things manually 'cause you know it's gonna take a certain amount of time and you know you'll be able to do it. And so if you can flip that, if you can say it's faster to build the automation, then I'll send you just gonna automate everything because it's easier to do that. Now you hinted on this a little bit. Very early on, you decided you were gonna build everything. You know, I think a lot of founders when they were poking at this general space, they would say, okay, we're gonna build some automation point solution. It's gonna integrate into whatever you're using. And then over many years, we're gonna chew our way backwards to sort of own the entire system of record product, whether it be they're using an Alasian product or a service now product or whatever they're using. Maybe other than kind of the general idea of the value of doing the hard things first, what else kind of informed actually what you were gonna build in what order? I think what we wanted to do here, so we had this strategy, which was to build the platform obviously and that strategy was one, because we wanna go after existing spend, but also we felt long-term. You could build a much better product experience if you actually own the platform. It's not a novel insight. I think everyone could look at it and take that away and then we decide, hey, we're gonna invest everything and go do it. I think we tackled the thing that we were most unsure about first, which is could you actually do what I, what I mentioned, could you actually build a system that made it faster, automate something forever than do it manually once? And this is a co-generation platform. It's basically vibe coding for IT automation or vibe coding on Rails really for IT automation because we really can strain the use case here. And can you describe a natural language what you're trying to automate and can on the other side of that you get an automation that works and end. And the early experiments, the answer was maybe. It worked in some cases, it didn't work in a lot of cases and we had enough hope, we saw enough signal that we said, you know what, I think that this is gonna work and we decided to just double down and then build the platform around it. It would have been very easy to start with an IT technique system and you could make it much better UX than Gira and ServiceNow and you could try to sell that. We didn't think that that was really gonna be the difference maker. We said, if we can build an automation builder and then build a technique system around that, then that would be really, really powerful. So we started with the automation builder, we showed it to customers. They didn't really know what to do with it but they thought it was really cool. But we kind of pushed through the early skepticism and just kept building and iterating. And then as the platform started to emerge around it, the conversation with customers started to shift and they started to understand how the pieces took again. - Talk more about how it shifted. Like what was changing in the product or the way you were educating the customer that went from this is cool to in production, driving actual value for the company. I think this is one of the hardest parts about this business is that it took us a year to build something that was actually valuable. And so you really want to get this and customers' hands as quickly as possible and then just iterate with them and build on top of a core value proposition. But so much of the core value was actually combining these tools together. No one wants a mediocre ticketing system and a mediocre workflow builder and a mediocre access management system all kind of stitched together. And they don't even want to be plus version of any of those by themselves. So how do you build something compelling? You really just have to focus and build. The tenor of the conversation just started to change when all of those products reached a certain level maturity where people saw. There's enough there that they could project out in their imagination, oh, I see where this is going and I see how this is gonna be awesome. I think when you're in an immature state on the product across those three categories, it's hard to have the vision to see how this is gonna get so cool and so much better that it's ever gonna work because you just see all the gaps. You see, well, you've got a ticketing system but it doesn't do all these things my ticketing system does and you've got a workflow builder but it doesn't do any of the things that my workflow builder does and you've got an access management system and it's the worst access management system on the market, what are you doing? But then I don't know what the percentage is but there's a certain percentage where there's just enough surface area that even though people still see the gaps, they're able to imagine those gaps being filled much easier and saying, oh, I see where this is going and I see that once you add X, Y and Z, this becomes a really powerful platform. You almost get, you need to get them to round up in the head of what the product's gonna look like. So how is it found or did you have the conviction to kind of keep plotting a long month after month? You know, you ideally want to give this thing to a customer and they're like, I need this thing. I like this thing. I'm using this thing. It's really valuable for me. I'm telling my friends about this thing. Was there anything that kind of kept you just grinding on it? I think that the thing that helped us maintain conviction even in times where we just weren't getting the feedback we wanted was that there's a market here. People spend a lot of money on service now, IT ticketing. They spend a lot of money on Geras Service Management and Fresh Service. People buy these tools and we thought deep in our bones that we could build a better version. And I think a lot of that conviction probably came from my time in Vercata knowing that if you could build just a better version of a product that already exists, that you could have a lot of success in the market. Maybe that was naive and that was over optimistic, but that was where the conviction came from is, no matter how bad of a week I'd have, I'd have a couple of customer conversations in a row where they didn't really get it and they didn't really see what we were doing. I just kept coming back to the fact that these products exist in the market and they make a lot of money. People do buy these things and I am certain that we can make a better one. And this new technology that we're incorporating into the IT ticketing to actually automate these requests is unlike anything these customers have seen and it's going to work and we just have to keep building and finish the dream. But we could have been wrong. I could have gotten to the end of that and I was still wrong and so it may have been lucky that we just kept going and we ended up being right, but it was scary and some weeks were pretty rough. What at Circle is the Vercada SMS part of the demo? Do you have that yet? It's the workflow builder. Yep. The demo can be kind of broken up into everything that comes before showing the workflow builder and then everything that comes after because before you show the workflow builder, people are bored and everything you show them, they think they've seen before or they've seen some version of it so it's not impressive. You show them this workflow builder where you describe a very complex IT automation that could be an off-boarding workflow and onboarding workflow and you just describe all these steps. We're gonna add them to Google. We're gonna take a webhook in from Rippling. We're gonna send this manager a Slack message. We're gonna add them to all these applications and then you just hit Enter and the workflow just generates before your eyes and it actually gets written out in code so you can see exactly what it's doing. It's not some kind of LLM black box of, oh, the LLM is gonna go and figure this stuff out. It's writing the actual code and then you just hit publish and then you run it for that. You show that it actually runs, it does all the steps that says it's going to do and people's minds are blown because they can abstract from that all the things they could do. Whether it's Password Resets or it's Reporting Workflows, Compliance Workflows, all the things that come through the helpdesk, they know that everything that they've always wanted to automate is now just one prompt away and it's showing them live how that works that starts to click of all the things they could do with it. Would you think about next generation companies going after these large existing markets that generally have some sort of oligopoly structure? Is part of the takeaway, at least thus far in the journey and when you've thought about other companies, the general idea of people have this old clunky software and we're just gonna build a modern, better version of it. Like, that doesn't actually work. You need a true insight, in this case, it was actually quite technical in nature to crack one of these existing markets. Yeah, I think that's exactly right. I mean, I think so much of this legacy enterprise software, it's powerful and it's sticky because of its configurability. And if you're gonna disrupt them, you have to disrupt them in a way that actually attacks that configurability head on. And so the way we've done that is not say, "Hey, we've got a simpler, more opinionated version of service now," but actually a more powerful version of service now because now you can write underlying code that does anything, you're not even limited by a service now as domain-specific language or the way they've constructed workflows. So it's even more configurable and more flexible than the previous generation. I think a lot of the startups that have tackled these enterprise softwares have done the other approach of let's make a simpler version. Let's make it more opinionated and more constrained. And I think what large enterprises want to do is not adapt their process to your software but adapt your software to their business process. And these large enterprise software platforms like Workday and Salesforce and ServiceNow, they're very good at that. They can be adapted to whatever the internal business process is. We wanna do the same thing but actually make it even easier and more flexible and configurable. How did you think about defining the size and scale of what a nearly customer was gonna be? I think sort of conventional wisdom is narrow and tight in the ICP to make it as tiny as possible, monopolize that ICP and then kind of slowly chew out from there. Relatively early on you started farther up market and increasingly have been straddling. A company might have 200 employees, they might have 5,000. But I think it's fairly atypical. There's like Workday getting started and your mega enterprise from day zero. But this sort of straddling mid market and enterprise is fairly atypical. Yeah, we anticipated starting mid market and they're in the low side of mid market and sticking around there for a very long time. So that was my plan as the conventional wisdom, narrow the ICP, VC backed tech companies with 500 employees. That would be where we lived for a long time and then we'd gradually bit by bit go a market. What we started to see is that the problems we're solving in the mid market were not any different than the problems that large enterprises faced. And a lot of the tools weren't even that different from the tools that large enterprises faced. As AI became more and more dominant as a topic of conversation in the boardroom, there also started to be more of a internal momentum at these large organizations of we should look at this stuff. And I think those two factors ended up being really important that what we built was actually quite flexible for the enterprise, partly because it's all code based, partly because of some decisions we made early on around the architecture to eventually move up market. So we didn't have to push ourselves that much on the product side to go there. But then also these enterprises, which historically are very late to the party, they're feeling a little bit more momentum around internally and pressure from the board and the C suite to start implementing and release exploring AI solutions that those kind of two factors met. We had a product that was ready for the enterprise and then we had enterprises that were actually ready for early stage products in a way that hasn't been true in a long time. How did it not leave lead to a dynamic where just the roadmap is not able to, it's just too substantial to be executed on. They're just so similar mid market in enterprise. They're shockingly similar, especially because of the way we've built the product. So because the way we think about integrations and workflows is all code based, we make a really good inflexible code based platform for building all these workflows, extending the capabilities of the platform. The only difference is what endpoints we're hitting in these applications. And certainly workday is more complicated than rippling, but that is still fundamentally the same kind of challenges making it automation work and rippling versus making it automation work at workday. It's not that different of a challenge. I think we've taken a different approach and we maybe had a set of pre-built actions of things you could do in rippling, things you could do in these different platforms, and those were set and hard-coded, and they were a part of this opinionated platform that would be very hard for us to switch gears and go market because then you're starting from scratch and you're basically doubling your service area. So supporting Microsoft ends up being much, much harder than supporting the current stack of products because you have to rebuild every single thing that you're doing. For us, it's a symbol as giving our system context on the Microsoft API and now we support everything Microsoft. And that architecture decision allows us to just serve those customers instantly and with very few hours of development versus if we built it in a more opinionated nature, which I think historically that's what SMB and Midmarket Focus Tech companies did is they built a very opinionated narrow focus product. We built this product that is built around a flexible code-based workflow engine that can then flex into large enterprises quite easily. Is there any specific set of insights that have allowed you to have such a high rate of product execution other than we hired very, very good people and Alex is very good? Again, it seems outlier the amount of product that you've shipped on a monthly basis is a relatively small team. There's no substitution for this great talent. I think we have an incredibly talented engineering organization. I think relentless focus. Everyone knows what they're working on and why. We embed our engineers really tightly with customers so that every customer, in addition to having a forward deployed owner, also has a member of the regular engineering team as an assigned person. So every engineer on the team has a deep appreciation understanding of what we're building, who it's for, why we're building it. And we've had a very focused roadmap. Our roadmap hasn't really changed in a year and a half. When we first pitched first round, those slides are basically our roadmap today. Priorities shifted, but the same core things that we're trying to build are true than as they were true now. So I think a lot of delays on software teams is because of thrash, because you change direction and you try different things and you pivot around. I think we had a lot of conviction on what we were trying to build here and we'd been able to just hammer it out because we never had to reverse. We never had to backtrack and we just get to move forward. So I think when you combine talented engineers that understand the customers and problems really well so they don't need to be micromanaged and they don't get confused. And a very consistent roadmap with a lot of vision of what we're trying to build. You're able to move much, much faster than if you're kind of making it up as you go. What about the opportunity allowed you to have such a relatively fixed roadmap? I have to attribute some of it to luck. I think we expected when we pitched first round, we said, hey, I think all of this is going to change in the next two months because this is our theory of the case. And so I think a lot of it was we guessed right about a lot of things. But if I want to give us more credit, Alex and I built hundreds of new products together at Vercutta. We talked to IT and security teams all day long for five years, figuring out what new products to build, and then we shipped hundreds of different skews while we were there. So I think we also had a really good intuition of how to build what was going to work, what was not going to work. And so when we were doing all these customer interviews, I think we're pretty dialed in into what we are hearing them say and what we needed to build and what the market looked like. And so maybe it was experience that helped us be right. But I think a lot of the success just happens to be that we were right the first time. And we didn't have to kind of regroup the company. And in fact, one of the engineers that joined our team said that they were most impressed because our vision every time they talked to us along the journey had been consistent. And we knew exactly what we're doing. And we just did exactly what we said we were going to do in terms of product development, in terms of like customer traction. We just did exactly what we said we were going to do. Is there anything else that you've learned about selling a next gen product into an existing category that you haven't talked about? You landed on this aha moment, which is the way in which you build, the way in which you go about building automation's generates code, you can do whatever you want with that code once generated. But when you're engaging a prospect and they've been using X thing for nine years, there's 7,000 people, is there a specific way that you have to go about that sale that is unique to bringing a product into an existing market? There has to be top down alignment. That's what we found is that there has to be alignment from senior leaders that this has to be done. Because as you get into large organizations, the actual folks doing the implementation, it can be a very large team. And the chances that all of them are going to be completely aligned and excited about this new tool are close to zero. And so you need somebody with a drum beat that says, no, we're doing this because I believe in the vision here and I believe what we're trying to accomplish and I'm going to keep pushing the team to do it. Selling them ends up being the hardest thing as you have to get them on board. It's now really a bottoms up approach where you can get 50 different 90 score leaders excited about it and then they tell their CIO. And that's what comes down to the demo. I mean, you have to build a product that when somebody sees it, it starts to click and they start to envision all the things that they could do with it. That's what does it for us. As if we can get the demo with that senior leader, it just, it's just clicks. I did a demo recently to the CISO of a Fortune 50 company. And he saw the demo. He's like, where are you right now? I'm going to drive to see you. It's an hour away. I'll be there in an hour because I want to meet you because they saw the demo and it was just so powerful that they wanted to go deeper and explore further. I think the second piece is finding those champions at the lower level that are really excited and that look really good because of our tool. I think one of the coolest things we've done that was not expected that we did not anticipate is we turn IT into builders. They get to be creative and they get to build really cool stuff with a workflow builder. And I think very much there's some parallels to what Clay's done with the go-to-market engineer where we've turned these IT professionals into these makers, these builders that get to create amazing workflows and they want to share them with us. They want to share them with other people. They want to show the org what they were able to do. That's cool. And they actually surprise us. They will tell us, hey, we built this workflow that does x, y, and z. And we say, no, it's not really possible. We were probably confused about how it works and then they'll show it to us and say, no, it works. We ping somebody if they're octa one time password and then they enter it into Slack and then they get this alert that goes into their Slack message. And it's so cool to see if somebody do something with your product that you didn't think was actually possible. And now it's happened probably half a dozen times. It's not even surprising where people just find ways to do cool things with the product. And I think that's going to be something we want to increasingly lean into because that's how you can kind of combine the top down pressure from the executives or just essential at these large enterprises. But also make sure that you've got this upswell of support from the folks that are actually implementing the tool where they look good. They don't look like you're just replacing the stuff that they decided implement and they're big fans of and they're very comfortable with. But you're actually giving them the opportunity to be superstars and build things for the rest of the organization that make them really appreciate it. - Shifting the conversation a little bit. When you think about what's happening in enabling technology and AI, what's your sense of like what is the role of software today and humans today? Because as you were talking about kind of creative builders at companies, you kind of quickly go to, well, why can't software just do everything? Why can't software come up with all the automations and then ship all the automation or test and then ship automations and like, but there's still, and it might be a context piece, a judgment piece, an intelligence piece, a creativity piece. But like there's a critical role in all of this, which in this case is the IT professional. I think the gap here that humans are solving is translating the business rules and requirements into the underlying product. What's really interesting about all of these AI products today is they can basically do anything. You're not really limited on the capabilities of these products. You're actually more limited on somebody saying what they should do. And at least today, they're not at the point where they're able to understand the business without some kind of human input. Telling them, hey, here's how I want to adapt this product to meet the rules and policies and processes of this organization. And so IT can come in and they know these policies. They know these processes. They know all the business rules and what we're trying to achieve. And they can construct the workflows and the piece of the product to go and execute that in a way that was very hard to do before. They're still essential in that translation layer. Though we are trying to make that translation layer even easier for them. I think today, one of the things we're working on on the product side is how do we make it easier for you to translate that business logic, describe what you're trying to accomplish, and translate that to the primitives of the product without you even having to be an expert in the product. You don't have to know the intricacies of how our system works and the nuances of how different components fit together. You just describe what it is you want the product to do and how you want it to be configured, and how you want it to work, and the system figures out all that underlying logic. But I still think you need somebody there that says what's important to the organization and there's shocking diversity from company to company, not even mid-market enterprise, but even within mid-market companies within enterprises, on how they want password resets to work, on how they want people to get access to applications. All of that ends up being very, very unique from company to company. And so you need people to describe what those policies are, even if the system is able to translate them very effectively. Maybe sort of on a similar point, what's gotten vastly easier in the 18 months that you've been building the company from an enabling technology perspective? Code generation works super well now. So when we take these prompts to code, there used to be so many gotchas where the code wouldn't actually work, whether the API is not well supported or it makes a couple of mistakes here and there, and now it's hard to break the system. It's hard to just put anything into that prompt and not have code that spit out, that runs and does exactly what you wanted to do. If I had the product in front of me, it would be hard for me to come up with an idea that wouldn't work in the system, which is really, really cool. And that was certainly not where we were at a year and a half ago, where if you weren't on a kind of a predefined list of things we knew very, very well, it wouldn't work. So we used to, for example, have defeated a bunch of contexts of here are all the possible workflows somebody might want to build, and here's the code. Here's what it looks like. You might want to use this code as like a reference point. And then as long as what you're trying to do was somewhat similar to the workflows that we provided as context, it would work fairly reliably. But as soon as you went off the rails and you want to do something crazy creative, it would just fall over and it would just get stuck. And that doesn't happen anymore. Now you can be as creative as you want, touch as many applications as you want. Internet search capabilities built into the models have been really, really powerful. So that, say you get stuck on some obscure API, and that isn't well documented, the system will go and find forums and information on how that API might be constructed and how to build the workflow that you're looking for. And so it can solve its own problems very easily, and that's all gotten just so much better. I also think the end user interaction experience, AI has gotten much better at following instructions. And so we've been able to tune that interaction, so it doesn't feel like you're talking with a chatbot. The way we want server to feel to the end user is it somebody that solves your problem or gets out of the way. And it's not somebody that's trying to talk to you or have a conversation. 'Cause I think everyone has had that experience of the chatbot where it's not being helpful, it's just talking a lot. And we want the experience of a you want to pass a reset, you've got to pass a reset. You want to access this application, you've got it. You spilled coffee on your laptop. I can't help, I'm tagging in John, he's gonna help you with that. And we want that interaction to feel like server always helpful and never in the way. That was hard to tune in the early days. It was hard to get it to follow those instructions and now that's gotten much easier. Did you think about the rate of improvement with the underlying models in conjunction with how you were thinking about building the product and it was a huge bet or is it just icing on the cake 'cause the stuff gets better and better. It was absolutely a huge bet. When we started especially, the stuff we were doing today was not possible and it was not clear that it was going to be possible. We were betting on what we were trying to do is just outside of the capability of these models. It doesn't take a crazy leap of faith to believe that they'll get there one day but it was not clear that they would be good enough to work. And so we had to bet that what we were trying to do, the models would one day unlock. And I think that that's paid off. I don't know if I would make the same bet today on those same increases and model capabilities. I'm really happy with where the models are at today because they don't have to get any better for us to build a massive business. How they work today is actually good enough for our use case. Obviously it'd be great if they get better but they don't need to get better for our product to work really, really well. Do where there's a future state where they actually get too good that it's strategically disadvantageous to the business that there's a Goldilocks. - Yes. - Level of power that you want. - Yes, I think about this a lot. People ask me what are the competitors that I'm most worried about and the competitor I'm most worried about is the one that doesn't exist yet. The one that comes along a couple years from now and maybe these tools have unlocked so many crazy capabilities that they're able to move very quickly and build so much of what we built so much faster and get to a level of parity in a very short amount of time. And so yeah, I do think that there's a world where the models get so good that it starts to erode some of these advantages. I think that's why even today I'm pushing the team to think about what are the hard things we can be investing in now? What's our next bet? So we made this big bet with code-based workflows and code generation is a source of truth for work automation. It was a great bet, it paid off. That's working really well. What is the next big bet we should be making? We're investing in the next generation of models and we're hoping that a lot of these tools get better and that it'll lock some crazy amount of value to customers. I think things like translating business needs into automations automatically without human interaction. That's a huge area of interest for us. I think looking at things that are not neatly automated via API is a really interesting category. Things that still require a lot of click-ups and logging into tools and making changes manually. Obviously, the universe of things that you might want to automate is much bigger than the things that have very neat, clean APIs. And so that's another area that we're very interested in. But we're always looking at what are the hard things we can be doing now that make it very, very hard for somebody coming in after us, even with great models and great AI capabilities that we didn't have to ever reproduce the full scope of what's possible. So going broad, going deep, continuing to bite the hard things off. I think the benefit we have is that we're in a moment where all these AI tools are coming to all these different layers of the organization. And IT is witnessing sales have amazing AI tools and design having amazing AI tools and engineering, of course, having amazing AI tools and they're just sitting watching, often implementing those tools for the org and paying for them, but not having their own tools. And that's creating a contrast that, as these IT leaders look at it, they start to realize, oh, we could be much better and we could also benefit from these same kind of tools. And I think Serval has a unique position there of being the tool that they can adopt that gives them the same kind of superpowers that cursor and cloud code give to engineers and these other incredible tools give to sales and design teams and other parts of the organization. One of the things that I really like about startups is that you generally end up innovating in product and/or distribution and both or both. And in a lot of ways, the company itself and the structure of what it means to build a company gets innovated on, that you take five great companies and maybe 50 or 70% of the companies look somewhat similar but 30% in the actual way that the company is organized and accomplishes work, et cetera, is actually quite different and like a lot of interesting stuff comes out of that 30%. And I'm interested in the context of you building Serval as your second company, the last big chapter for Kata doing things in a very specific way. How could you share or articulate like what the 30% of the stuff that you've chosen to really push and innovate on in the company itself? I'm really interested in this evolving role before deployed engineer. I don't think we're unique and being very excited about that role where we are unique as we really consider these individuals to be full time software engineers. People that are building product but are building product with deep integration with the company, with the customers at their service. So why has it become like a topic to sure of forward deploy engineering now when it was kind of a fringe thing for a while, at least in the early days of Palantir it was looked down upon and glorified consulting and now it's sort of like the topic to sure. Like maybe start with like why you think that is and then how it applies to what you all are doing. Yeah, I think the software platforms became so powerful that the capabilities of the platform were no longer the rate limiting step of the value the company could get at the customer could get out of it. It's not what features the product had. It was actually how the product was configured was a rate limiting step and AI really unlocked all of these long tail capabilities. So it could theoretically do everything imaginable that you want it to do, but somebody has to tell and configure the product to do it in that way. I think that that's what's happening. Where if you really want to unlock the value you need somebody that's kind of steering it and directing it versus in a more traditional model maybe you get some of that value with consultants that are doing implementation. I think in many ways what the forward deployed engineer role has actually replaced are the implementation consultants for large organizations, large companies like Workday and ServiceNow and Salesforce that are customizing that software to meet these organizations needs. Now the forward deployed engineer is coming in and doing that for AI products for startups instead of large enterprise software companies. So I think that that's what's happening is trying to unlock this value of these AI agents. The way I see it is yes, do that, but also treat these as actual members of the software engineering team and let them not just do implementation but actually build software because they're the ones talking to customers all day long. And what I wanted to really break from tradition here is in a company like Verkata, really any company, traditionally you've got solutions engineers, you've got customer success staff, sales AE, they talk to customers, maybe the SE here's a good idea. They communicate that to a product manager, product manager talks to the engineering manager about that, maybe gets scheduled in a sprint one day or added to some quarterly plan. But there's this gap from a customer saying I want this thing or I wish it worked this way or this is broken to that being fixed or added. That can be months, even for a great company that can be months as it goes through that full cycle. And it would just be so much better if an engineer heard that feedback and then just went back to their desk and built it. And AI tools have made the development cycle so fast that a lot of the things they're asking for can actually be built in that timeframe. And so we wanted to kind of weaponize that new capability and say, I want engineers talking to customers every day and then just going and building the things they're asking for. And it's basically trying to recreate what happens in the early days of a startup when it's just a couple of founders, talking to customers, what do you want, cool, we'll build it, talk to them the next day, is this fix your problem, what else do you want? Can you scale that energy? And that really tight feedback loop as the company gets larger and larger. That's what we're trying to do. We're trying to build out a four-deployed engineering organization that is embedded with customers and is building for them day in and day out in the same way that founders would be building with a customer. Will they build a one-off feature that's only relevant to the one customer? No. So their job is to build things that are valuable for a lot of customers. Now, we have ways to customize the product for customers, that's the workflow engine, right? So they will also help customers write code in the workflow engine if they want, but they're more focused on what is missing from the product or would make the product even more powerful. You know, one example is our workflow builder can actually work on Serval itself because Serval has an API. You can build workflows in Serval that do things in the Serval product, which makes it incredibly powerful. You basically get to write your own features for the Serval product, but not everything in the Serval API and not everything in the Serval platform is exposed via the Serval API. So one thing you can do is a four-deployed engineer and say, oh, it would be really cool if we had this feature. I could build this feature of the workflow, but I need to add all these API capabilities. So let me just go and do that. Or you could say, hey, I think it would be really cool if we had a deeper integration with this software tool and if we had more context on that API and how it worked because there's all these nuances, I'm gonna go and build that integration in the Serval platform. And the ability to just talk to customers and ship for them on this really tight feedback loop, I think is really miraculous. I'm wondering how big that four-deployed role can be and can it ultimately replace what has historically been solutions engineer can replace a lot of what's been customer success? Because if you think about what someone in customer success is often doing, a customer is complaining about something that's broken or something they don't understand and the only people that can really fix that are engineers. So why have them tell that to somebody that's not an engineer who's just gonna go around and have to give that to somebody? I think that there's something there where you can actually have everyone talk to an engineer and in tighten that feedback loop. And we're gonna see how far that we can get with kind of four-deployed. In this model, what is the difference between a four-deployed engineer and an engineer? There is very little difference other than we expect the four-deployed engineer to be spending 20% or more of their time talking to customers. And so it's a lot of a deeper embedding and we wouldn't necessarily expect that for a software engineer. A four-deployed engineer is also probably gonna be building mostly product capabilities, not necessarily working on infra or the platform or other initiatives that might be outside of the scope of the current product. So do you think over time it ends up, you end up having a traditional infrastructure or platform, internal platform team? And instead of having normal engineers that are working on features, just it's that same type of engineer, but they're just spending all their day with customers. I think the need for a lot of product managers is probably gonna go down if you hire really product-oriented for deployed software engineers, then they're gonna be increasingly making decisions on what makes sense to build for the maximum number of customers and what's gonna unlock a lot of value. I think you're gonna need a lot less or maybe no solutions engineers. I think you're gonna need a lot less and maybe very limited set of customer success dedicated folks. So I'm very bullish on this concept and it really comes from this idea that if all of the feedback from customers ends up going to the engineering team anyway, why do we have all these middlemen? How do you keep this from not just turning into a mess, just like a free-for-all of stuff getting shipped in all sorts of random ways? I don't think it's that different of a problem that you face even if you have people in the middle because you're basically replacing this middleman that's trying to allegedly collect all this information and then streamline it directly to the folks that matter and do it in some kind of curated way, kind of getting rid of a little bit of the curation and kind of going direct to the source. It really comes down to the people that are receiving that information. Are they high caliber enough both from a product sense and from an engineering capability to know what to build and know how to build it in a way that's really robust and is not just kind of producing slop. So it comes down to caliber. I don't think this scales if you just kind of throw random people into the mess and say like, "Oh, just like build stuff and ship product." But if you actually have your four deployed engineers to be the best engineers on the team, I think it's basically, again, reproducing this early co-founder energy where it's a CTO that's hearing the feedback directly from the customer and going and just fixing the product or making it better. And everyone knows that that is great. Everyone knows that when a CTO talks to a customer and goes and builds product features that that's awesome, if you can scale that, you can scale the awesomeness. There is a question though, how much that scales? Like it probably is hard to hire 100 people with that kind of caliber of talent. How can you find ways and systems to make that scale as much as possible as something will have to figure it out? We certainly haven't solved it yet, but I think there's something interesting there that I'm really interested in seeing how far we can go with it. Are you finding the customers? It's just immensely delighting. Exactly. The fact that a customer can ask for something and just get it same day, we have a call at 10 a.m. and their feature they ask for is shipped at 4 p.m. That's so powerful. People love, we know that people love great customer support. Even if the customer support is just very quickly telling you they're gonna fix a problem and they're listening to you and they're, people appreciate that, even if the problem's not fixed. Now, if you take that to the next step of not only are we fast at listening to you, but we were actually also solving the problem, I think you build some customer loyalty that is really hard to reproduce. And then as a side effect or the principle effect, the product's also getting much better. And you're covering so much service area because the chances are that whatever they ask for, if you're forward to playing in your team is really good and product-oriented, they're solving a problem that a lot of other folks have. What is the role of a p.m. at certain point in the future or is the goal to never hire traditional product management? The goal is to delay the hiring of product management for a very long time. I think the role of p.m. is gonna be similar to what it was at Fricata, which is more of a general manager of a business unit. I think there will be a time when we have a big enough product portfolio that there are areas of the product that are massive and distinct in some ways. And it is valuable to have a single directly responsible individual that kind of owns that category, maybe owns the revenue line of that business unit, has come some kind of ownership over the p.n.l. And so thinking of p.m. is more of a general manager in charge of a broader function or a product area. I think that's how we'd want to structure p.m.s. I mean, Fricata was 1,000 people and had two p.m.s. And I think we can do the same and keep that team very, very lean and really focus on p.m.s that actually own a business unit. What's your theory of what's going on in your brain or other business, builder, GM style product people that give you that sort of taste and sensibility to kind of get that multivariate problem solved? They're the best people that have done this. Develop this deep customer empathy and this understanding of it is almost irrelevant what they say they want. They're kind of ambivalent about all the features, suggestions, all the feature requests. At Fricata, we had a site called Feature Garage and that's basically how it was treated as sales reps would jump a bunch of feature there and no one would ever look at it. And I think the really good product leaders, they hear all that, but they actually just understand what the customer is trying to do. They don't hear any of the feature requests. They just hear the understanding of, oh, they've got this problem. And we want to solve that. And I think it's very much what we're trying to do in the early days of serval is not pay attention to the fact that they want to, you know, this feature, this feature. Certainly no one asked for a new ITSM and no one asked for a new workflow builder any this. It was just, they had this problem they're trying to solve. So they wanted somebody to come and build a bunch of automations for them and make a lot of these tickets go away, just building that empathy and then saying, OK, what would that look like? I agree. There's not many people that have that. I think in our model, the way I think about it is a lot of the stuff when you get to a level of product maturity that we have, so much of the things that are asked for are non-controversial. And I think Ford Deployed has a huge role in driving Ford progress on all these non-controversial product capabilities. You should be able to sort a column on a list of tickets. Right? No one needs to have a conversation or a brainstorming session or a roadmap around like when we're going to slot that in, you can just go in, you can build it. I guess the only question there would be prioritization, but I think your point is you want to be shipping so quickly that just do it in an afternoon kind of a thing. And I think it actually ties into this prioritization conversation because I think you can over-prioritize. And it's also a mistake that actually the really good product leaders do is because they're so focused on prioritization, they never touch the P2s. P2s stack up. And you can get a lot of them that just completely erode the product experience. And if you're never having anybody that looks at the P2s, you're going to end up with such an inferior product, even though you were technically focused on all the right things, but nobody addressed the fact that you can't sort of call them and you can't export this report and you can't do this. And so that's another side benefit of having this for a deployed is that the P2s actually get looked at and the P2s matter. So other than what you were explaining a second ago, which is you just need to ship a lot of software, is there anything else that helps someone develop? You have to spend time with them. You should be visiting them in person. And you have to spend time with them, not just in a work context, but hopefully outside of that. Advocat, I got the chance to visit customers. We took a customer to the club in Vegas and we got to know customers, got to go and site with them. It has to be being embedded. I always think of this as like, you have to be embedded with the customer. And it's not, oh, I'm going to schedule a customer interview. And I'm going to have an engineer talk to a customer for 30 minutes because we're doing a customer interview and they've got a list of questions they're going to answer. It's more, you have to be in a Slack channel with a customer. You have to have a weekly call with the customer. The customer should be texting you when they run into problems. Like you really just have to embed yourself in the lives of these customers for you to understand them at that level. And there's no substitute for it. And you don't have to do that for every single customer all the time, but you should have kind of a bank of customers that you have deep, deep relationships with that are fairly representative, that you can just lean on and feel like you just know them. So when you're making a product decision, you're not thinking in some analytical way about whether or not this unlocks $x revenue. You're saying, oh, you know what? Scott's going to love this. We can't do that. Remember, Dana hates this stuff. And you just have to have these people live in your head because that's what drives really great product decisions when they're actually in your head and you understand what they're going to like and not like and you understand what they need. - What are some of the examples when you think about the products you've worked on of? You could not have landed on that thing if you did not embed and go deep in that way with customers. - Yeah, one of the most striking examples from Vercada was panic buttons. We didn't know if they were even necessary. You know, it was a category that was kind of controversial whether or not they even needed to build those. And I went on site to a customer that was a payday loan customer. I actually spent time talking to their cashiers that spent all day behind a layer of bulletproof class. Every single one of them had been held up again point at some point while working at this company. I asked them about, you know, their day and what we could do to make their day better. And I was thinking about this from their perspective of what new products could I build. And the thing they said to me was the ATM is in the lobby on the other side of the bulletproof class. Is there anything I could do to move the ATM to be closer to the door so they don't have to spend so much time in the unsafe part outside the bulletproof class 'cause they're worried that something's gonna happen to them when they walk out the door and they have to empty the ATM. That was their biggest fear was being in the lobby and having to cross this hallway. And that lived in their head as the most important thing that they wanted from us. And then we're having this conversation of whether or not you can carry around the panic button or if it should be mounted to the desk. It's like, of course you have to carry around the panic button. Of course you have to carry around the panic button and it needs to work in the parking lot and it's just non-negotiable because they're terrified of just walking into the lobby. And so as an example of like if you're just looking at it, you're probably gonna do some market report and be like actually most hold up buttons or not mobile panic buttons. And you know, like this is the market size of this and involved a lot but you just talk to that customer and you're like, no, it has to be. As the role of product is potentially changing as certainly the role of engineering is changing, at least in the sense of like what an engineer is doing day to day. Has it made you think about the type of people you wanna hire in your next 20 or 40 and then ultimately hundreds of people? Or do you think if you were building a different version of this company five years ago, it's kind of the same types of people? No, I think we've definitely decided to buy us more on really smart journalists that hopefully are technical or quantitative in some way because I think all these technologies are gonna change very quickly. The way of doing things is gonna change very quickly and you just want the people that are gonna be able to grow and adapt the fastest. We are biased a lot less towards experience even from where I was at a couple of years ago which I didn't really value experience more than anything else but it just become much more a factor of how smart is this person? How adaptable do we think they're gonna be how high agency and self-motivated are they? How ambitious are they? And some of, you know, more of these intangibles than have they done the job? Because the job's gonna change, I don't know what the job's gonna look like, how we build software's gonna change, how we mark is gonna change, how we sell is gonna change. So you're really looking for a different kind of person that you feel like is gonna succeed in this abstract future world that we don't really have a lot of predictability around. And so it's certainly changed. I think I'm also biased towards, you know, shockingly, I think there's higher order returns to being technical and being able to code. Then there were, I think there was this moment where maybe we thought everything would be no code. And I think this era of these models being very good at code generation has actually made it much more valuable to have some familiarity with building software and being able to code. And that's also been very interesting and that now an IT professional, for example, with some degree of program experience is incredibly valuable to the organization because of all the things that they can build for the company. Whereas five years ago, there were maybe marginally more valuable than their peer because they weren't a full software engineer. They were just kind of dabbled in stuff. They're marginally more valuable than their peer. Now they're incredibly more valuable because they can use serval and other tools to build really, really cool products on services. And so I think about it the same way in our team. I think the people with technical abilities, quantitative abilities that are really smart just have enormous returns on their productivity with all the new technologies that are becoming available. Do you have for anybody that's going to join the company? Do you have certain things you do during the interview process to sort of get at these type of things like high agency or just raw intelligence or those types of things? I love a storytelling interview where I ask people to tell me their story, starting with where they went to school, why, what they did there, internships, why they went into their first job, their next job. And then I just double click into things that I find interesting projects, you know, big life decisions. I really like interrogating the life decisions. I think that tells you a lot about the agency of is somebody just kind of drifting and they're kind of like, oh, this thing came up so I did this or did they have a plan or, you know, what are they motivated by? And how do they evaluate different opportunities and different alternatives? And so that is a really fun, open-ended way for me to get at what they're trying to do. So I basically do that interview with everybody that we bring in as I just give them to tell me some segments of their life story. If they're more senior than, you know, it probably doesn't go all the way back to high school, but I just want to understand the big life decisions they made and really double click into the stuff they've done. And I think you learn a lot about general intelligence that way and a lot about agency that way. I think that's the best thing that we do. The other thing that I do that I think is very different is when we're looking at candidates that we're bringing in, I like to make people tell me on the interview panel, who are they better than at the company? Because I think what often happens at your company, yeah. What often happens in this company's scale is you bring in people that are good enough that are maybe, you know, better than some of the people at the company, they pass the bar, they pass the screen and they get a thumbs up and they join, but they're actually at the 40th percentile, the 25th percentile of the people in the company. Or sometimes early stage, you bring in somebody who is definitively the worst person in the company, but they're good. And I think if you just make a habit of that, all of a sudden you just bring the talent bar your company down so quickly without you even realizing it because they passed the bar, they're good enough, they're better than some of the folks here. And so we make it a point to say, is this person actually raising the overall talent bar of this company? - Oh, on your interview, you're not asking the candidate who went better than us. - 'Cause I thought that would be very interesting. - I was like, ah, yeah. - It's truthful with they've been there. - And then we bring them in. It was just like a head-to-head, like you just do a battle for yourself. - Yeah. - Like, hey, this person thinks they're better, so I do a quick test. - No, we do it in like kind of the deeper way. - I say there's a interview panel. - Just to make sure that we're never bringing in somebody that we feel like it's just good enough and just like kind of pass the bar, but would probably be like the bottom-run and the ladder on the team. We want to say no, that they're really good. They're like better than all those folks. They're like amazing. And we want people that are excited to bring in people that are better than them. Like, hopefully every person I bring in is better at the job that they're doing that I would be. And hopefully everyone that's on those interview panels is excited to bring people in. That's gonna elevate that group, that team. - Is that how you avoid the dynamic of just desperation hiring? I mean, you're starting to grow really quickly. - There's such a temptation to bring in somebody because-- - I don't think it can be emphasized enough. - It's so hard. - Especially, and it's easy to say no to bad candidates. Her run is candidates, but solid, yeah. - Yeah, but the good candidates that pass, there's nothing wrong with them. They're good and they pass the interview and we really like them, but they're not great. And they're not really gonna make the company definitively better. You just have to say no. At this stage, especially, have to say no. And the other thing that we think about is do they make it more likely that we'll get the next great candidate? If they make it less likely, you'll get the next great candidate and you're just getting yourself into this vicious cycle where you're making your workplace a less and less attractive place to work for the best talent. And so that is how you say discipline about it and I've never regretted it. I've never regretted waiting because there's always somebody better. And every time you're on the fence, you're like, I don't know if they actually raise the bar. Just wait 'cause there is somebody better from a talent perspective. It feels at least from a distance in the last call it three or four months that the amount of people that are joining the company even at a relatively early stage has ticked up dramatically. It feels like there's this talent vortex that's starting to get formed. Is there anything else you've done that's sort of gotten you to sort of that set up? I think we evaluate every candidate on their ability to recruit the next candidate. And we consider that very highly. And that could be them actually being somebody that goes out and makes phone calls and recruits or also just being somebody who's so good that we know when they join, they're gonna bring other people with them or other people are gonna be more likely to join 'cause they see that. So how do you figure that out? Some of it is, what does their network look like? And you can talk to them about like who your network is, we can do back channeling, we can do reference checks, we can see like, do they have deep network of people that respect them? A lot of it is like personality. I mean, are they people you wanna spend all day with? Are the people, we're all in person in the office every day in San Francisco? And so is it, is this somebody that when we bring a candidate on for lunch, they're gonna be more likely to join because they had lunch with this candidate? That factors a lot into our decision, which is a lot of like energy and enthusiasm. Energy and enthusiasm, just being friendly and a nice person. Some of it is like profile of like, does their LinkedIn look like, oh yeah, I'm really excited to work with that person, they've worked a great company, they've accomplished a lot, like I can't wait to work with this person. And so we look at candidates through that lens, like every single person that joins, we think about if this person joins, or is it more or less likely that we're gonna get the next person that we really want? And there are some candidates that that has been a tiebreaker. On, hey, I think this person might be good, but I'm just not sure that if they were here, the next person that comes in and we, do we want them to have lunch with that candidate one-on-one? And we think that's gonna like make the candidate really excited about joining. And I don't know that every company really thinks about every hire in that way of like having a positive or negative impact on the next hire. And I think that's why you get kind of a flywheel is you start to stack people that are just awesome to spend time with, that are really, really talented, that have a great background that are really engaged with their community and their network. And as those people start to join, they talk to their friends and you bring candidates in and you're more likely to close them, you're more likely to attract the talent. - So are you finding you have an outlier referral rate into the company? - Yeah, we actually formalized referrals because we felt bad on how many referrals there were and no one was getting like really rewarded for it, other than like bringing great people in as it's on reward in many ways, but it's gonna create a lot of shareholder around with this person. - Yeah, exactly. But yeah, there's some folks on the team that have done quite well financially that are probably making more money from referrals and they are from their salary. - I always thought referrals should be done in equity and not salary. - Yeah, I mean, we could explore that. It's been great to really weaponize that. I think every person that's joined, we're starting to formalize that more and say like, hey, people bring in people and we're also getting the point where because the company's doing really well and we've raised great funding, it's easier to outreach to your friends and your network. You're not joining like, hey, there's four guys in a garage and I think you should be the fifth. It's more, hey, there's something really special happening here and there's all these external signals that this is in fact a rocket ship. So as that becomes more and more true, it becomes easier to bring somebody in knowing that you're not making crazy, crazy recommendations of them to take a risk that maybe might not be it. Now, the other interesting thing on the talent side at least in the past six months is now you're starting even as a very early stage company to aggressively build out the go-to-market function. What can you say about how you think about staging that? Yeah, we've been a little contrarian there in that a lot of times this, the go-to-market function just kind of evolves gradually. It's founder-led sales for a really long time and then you kind of bring in people onesy twosies, you bring in an AE and then you bring in maybe somebody that does a little bit of growth and you just kind of like develop this team. We kind of brought in a fully-baked team and we continue to scale that team very rapidly. I think one is just the rapid adoption of our product and the customer love we're seeing gives us a lot of confidence that this is working and we just need to grow to hit it. To the size of the market, we know we're not tam-limited. People buy this stuff and they're buying our stuff so it's really just a matter of time. And three, now that we're getting out there, the demos are starting to really stack up to the point where it's actually pulling us along and there's no time on the calendar's left and we need the support. And so all those things kind of happened fairly close together but we definitely made the bet before we had the market traction that this is working. We know it's working, we know the market's massive. We're gonna go and build this out knowing that we've got a limited amount of time that I think really sees the market because there's gonna be a early stage competitor service now. Somebody is going to build an ex-generation ITSM and we've got a short amount of time, I think, to position ourselves is where the ones to do it. Do you think, just given the rate of competition and startup creation, et cetera, et cetera, that sort of land grab dynamic today in 2025 is much more substantial than three years, five years, seven years ago? Absolutely. The land grab is happening and I think because there's so much of that top down pressure from boardrooms, execs to implement AI solutions, a lot of large organizations are gonna make their bets now on startups that are fairly early stage. And yes, it's gonna take a long time for implementation and the sale to go through, but you could get boxed out of a lot of these accounts if you're not moving quickly. And so it has created an environment where you wanna get in front of as many customers as possible, even if you know the product might not be there or you know that it's gonna be a very long sale cycle, you gotta get in now and it is a moment in time that you have to take advantage of. Are there other structural things like that that are informing the way that you're executing the business that things are changing in this way or that way in 2025 and that means we need to build this company in a very specific way? - I think the biggest one is that there are category leaders that are emerging and that emergence is starting to feel sticky and that you're starting to see, oh, this is the company that is the next ERP company and this is the company that's building the new HRS dynamic. - New HRS dynamic. - Exactly and people are claiming the mantle of this is the next version of X. And that dynamic is really exciting but it's also scary because you wanna make sure that you're that and you don't wanna be the number two player, you don't wanna be the number three player. And that's really driving us to move very, very fast. Building out the go-to-market, building out the product, going out market much faster, raising funding much faster. Like everything is aligned around this idea that we have a window, we have a moment and we need to go after it now and we don't know how long it's gonna be there. You know, the companies that kind of took over in the cloud transformation, they got a foothold and they just became so dominant and the number two players were so small, relative to the number one players. And I think the same thing is gonna happen in AI and in this case, a lot of times it might be the incumbent that still wins but there are gonna be AI native competitors creating a massive, massive value in these categories and I don't know that it's gonna be a diverse, evenly split market. I think there's definitely gonna be one player that dominates. It's interesting 'cause we could just be at the, at the very head end of this secular change but the thing that's felt a little bit counterintuitive is how much startup opportunity there has been in this technology transformation in the past two years that it feels like in every one of these categories while it's still very early, there is a really exciting next-gen startup that has a chance to really go after this category. What's kind of your working theory, building software, delivering it to customers around why there is an opportunity for new startups as opposed to pick any system of record company, you slam an LLM on the side and now they owned AI plus X or AI plus Y. My biggest theory here, if you look at these enterprise software companies that dominated in this previous era, it was because of the configuration flexibility and it was very hard pre-LLM to deliver that same kind of configurability, flexibility, customization while delivering on product simplicity which is where startups generally begin. I think that's exactly right. So startups are coming in these new markets, they do it with simplicity, like what linear does to Gira, a simpler, better user experience. And I think for these large enterprise players like Workday and ServiceNow and Salesforce, their value proposition is so much around the customizability and not the simplicity. And so if a startup's gonna compete with that, purely on simplicity, they're gonna miss on the configurability. But AI gives them a chance to compete both on simplicity and user experience and also configurability because you're using AI to set these configurations or maybe achieve value propositions that these other platforms just can't touch. And while it's theoretically possible for these large platforms to add these AI capabilities and they are, they have this classic innovators dilemma that it makes it hard to steer the big ship to add these capabilities while still protecting their existing product and revenue, not making drastic changes that are not backwards compatible. And so they're just naturally going to be slower at adopting the full capabilities of this new wave of tech. And startups are there to take advantage of it and can so much faster reproduce these capabilities that have taken decades for other companies to build out. We built ticketing in months and that used to take years. You can multiply that across all the different capabilities that we're trying to go after on all these platforms and that's what's happened. - So wanna wrap up where we always do, which is with the question, when you think about who has taught you the most and shaped you the most as a founder and product person, who sort of comes to mind and what do they teach you that is not a family member? I benefited a lot from this dynamic at Vercata where you have these two leaders, the CEO, Philip, the chairman, Hans, and they had a often a unique, differing perspective on product. Hans was very interested in looking at these existing established markets and building a better version of products for markets that already existed. Philip often looked at a lot of these problems from first principles on what we build if we were building it today and how might it look different from what's come before. I think both perspectives are really valuable and often I have both in my head and from that experience working at Vercata for so long, I'm able to kind of have both voices and say okay, how do we go after a category and know that there's a market there and build something better? But also question why that category exists, how it came to be, does it still make sense anymore? It's kind of like weighing those two is more valuable than adopting either one wholesale. I think a lot of companies struggle to create new categorization scratch and they kind of ignore the fact that we should maybe look at why there's a category called ITSM and maybe look at that spend because there might be something that the history is telling us there. And then other companies say, "Oh, we should forget about ITSM. We should just build something new that doesn't think about taking it all," are also throwing away a lot of the value that's come before. And so I think looking at both options of yes, you wanna build something better, but you also wanna think about why this category gory exists and that maybe there's some truth to the history and the history is telling you something and it's signal and not something you just ignore and build something scratch. - So you're sort of, you're touching on this a little bit, but if you think about where serverless today, how are those two ideas and the tension between the best expressed? - Yeah, exactly. So serverless a combination of these two ideas, one of which is build a better version of something that's existed before, which is build a better version of ITSM where there's a massive market and a lot of customers that buy ITSM. And also build something that's never existed before, which are AI agents that build IT automations and answer help desk requests. And we are combining both of those. The first principles, what would you build today for IT if you could build anything and the historical look at TAM and where there's an existing opportunity of ITSM and merging both of those, building an ITSM with a layer of AI on top of it that both replaces your system record and automates these help desk requests and helps IT build these really powerful automations. - Nice, great place to end. Thank you so much for joining. - Thank you, Brett. (upbeat music)