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

Brett: Well thanks for joining.

Jake: Thank you for having me. So the last big chapter of your career happened at Verkada, which is a company 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 roles 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?

Guest: 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 Verkada 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 and 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 Verkada owned the entire platform and so 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, this 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 Serval of what platform can we sell that there's existing spend, there's an existing category that we can go after but we can actually package something new and differentiated within that but they'll still buy the platform and they'll buy it because you're offering this new cool capability.

Brett: Is there anything you you have to get right that's unique to building an existing category other than building an excellent product?

Guest: 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, HRAS, 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.

Brett: What's the best Verkada story that sort of brings that idea to life?

Guest: I think one of the most powerful parts of the Verkada camera demo is when 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 straightforward that 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 and in a very distinct moment.

Brett: To your point, it it's slightly counterintuitive because it's not a killer use case that somebody's using 30 times a day.

Guest: What I was constantly reminded of when I was at Verkada 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 that 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 via 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.

Brett: What else did you learn about building more platform style products? I feel like every founder wants to build a platform or every founder wants to build a system of record. Very very rarely does that come along. And you're obviously working on a system of record style product in Serval, 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.

Guest: I think there's a few lessons. One is finding the things that are hard and just deciding to do them. When Verkada started it would've 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 'cause there's a lot of stuff that you stare down 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 Verkada gave me 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 and build those same things 'cause you decided to like go hard early.

Brett: What are the other examples other than the not sitting on top of existing camera systems?

Guest: 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 visitor management and kind of spreading yourself thin. That's kind of the outside in look. It's like are you sure you want to 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 sell the complete solution. And if you're selling something that you think is gonna unlock 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. Verkada is 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 Verkada did early. Verkada waited several years to support things like Skim and SSO and SOC 2 and various compliance frameworks. We did all of those things from day one because we knew that that was gonna be a 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 Verkada 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 Verkada when you're trying to go a market and a lot of that capability hasn't been built out yet.

Brett: Maybe sort of that's a good pivot point. What's the first kernel of Serval? Where did it come from?

Guest: The very first kernel of Serval was talking to customers at Verkada that wanted some way to automatically resolve device issues. And so we'd talk to customers that would have devices go offline. Sometimes Verkada devices like a camera that goes offline but sometimes just regular network devices, their wifi 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 are 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, is an idea I came up with, like we just proactively reboot cameras if we detect issues. Maybe that is scheduling a technician, maybe it's just, you know, sending a report of what might be going on or automatically updating the firmware. And so the initial concept was hey we can build a platform within Verkada outside of Verkada. 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. It turns out that was a very Verkada customer focused problem and that was very top of mind when you're 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 Serval.

Brett: So like 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 and this insight sort of pulled you into it?

Guest: No, absolutely wanted to start another company. I mean I joined Verkada knowing I wanted start a company. I thought I was gonna stay there a year. I stayed there five years because it was 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 Verkada, it's hopefully the only thing I'll do after Verkada. And so I was always looking at what could be the next thing. Now I didn't wanna just build a product that Verkada was gonna go build and just go back and compete with Verkada. 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 was interesting is like what else could you sell to IT that's like outside of the scope of Verkada? 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 Verkada and switches from Meraki, and then these uninterruptible power supplies from Schneider Electric. So two Silicon Valley tech companies and then one 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, you know, interviewing customers and you know, 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, were both founders before Verkada. We are 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 any chance that this business would work out. And so we interviewed a lot of customers trying to figure out, you know, 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 is 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 that.

Brett: Which is part of the issue with customer interviews I think. You end up managing for the outcome that you actually wanted. Yeah, exactly.

Guest: Because you want somebody to say that 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, "I'd 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 wanna offload to somebody else? And that's when we started getting really interesting answers around, "I want someone to just play around and like build me a bunch of automations. I want somebody to take on all these help desk requests. I wanna 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.

Brett: Why do you think that reframing of the question yielded such an interesting new set of insights that was not apparent before?

Guest: 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 nonjudgmental 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 free as 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."

Brett: 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 found either helped you rule opportunities out or you know, go deeper into what ended up becoming Serval?

Guest: 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, you know, they would use labor to, they would add extra headcount 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 wanna 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

Brett: And one of the most competitive categories in enterprise software.

Guest: Exactly. 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 you talk to IT, they weren't really using these. And so something is not solved. And that allowed us to double click and say "Okay well why aren't you automating this? Why aren't you using Okta 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 upfront thing is simple as resetting a password which often has all kinds of rules associated with it in the enterprise of don't let these people reset passwords, don't reset more than two passwords in 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 than to go into Google Workspace and reset a single person's password because then there's no trade off, right? 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, but 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. And meanwhile the help desk requests are piling up. You've got some new office to open, you've gotta 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 all of a sudden you're just gonna automate everything because it's easier to do that.

Brett: Now you hinted on this a little bit, you know, very early on you decided you were gonna build everything.

Guest: 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 Atlassian product or a ServiceNow product or whatever they're using.

Brett: And 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?

Guest: 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 want to 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 are most unsure about first, which is could you actually do what I mentioned? Could you actually build a system that made it faster to automate something forever than do it manually once? And this is a code generation platform. It's basically vibe coding for IT automation or vibe coding on rails really for IT automation because we really constrain 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 end to 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 a platform around it. It would've been very easy to start with an IT ticketing system and you can make it much better UX than Jira and ServiceNow and you could try to sell that. We didn't think that was really gonna be the difference maker. We said if we can build an automation builder and then build a ticketing 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 conversations with customers started to shift and they started to understand how the pieces together.

Brett: So 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?

Guest: 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 wanna get this in customer's hands as quickly as possible and then just iterate with them and build on top of a core value proposition. So much of the core value is 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 B+ 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 reach a certain level of maturity where people saw there was 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 need to get them to round up in their head of what the products will look like.

Brett: So how as the founder did you have the conviction to kind of keep plotting along 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?

Guest: 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 ServiceNow, IT ticketing, they spend a lot of money on Jira Service Management and Freshservice. People buy these tools and we thought deepen our bones that we could build a better version. And I think a lot of that conviction probably came from my time at Verkada 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. And 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 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.

Brett: What at Serval is the Verkada SMS part of the demo? Do you have that yet?

Guest: It's the workflow builder. Yep.

Guest: 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, 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 offboarding workflow and onboarding workflow and you describe all these steps, we're gonna add them to Google, we're gonna take a web hook 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 codes so you can see exactly what it's doing. It's not some kind of LLM black box of oh the LLM's 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 them. You show that it actually runs, it does all the steps it 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 help desk. 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.

Brett: 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 it just 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.

Guest: 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 ServiceNow," but actually a more powerful version of ServiceNow because now you can write underlying code that does anything. You're not even limited by ServiceNow's 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 at 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.

Brett: How did you think about defining the size and scale of what an early 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 is 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.

Guest: Yeah, we anticipated starting mid-market and 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 up 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 or at least 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.

Brett: How did it not lead to a dynamic where just the roadmap is not able to, it's just too substantial to be executed on?

Guest: They're just so similar mid-market and 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 and flexible 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 challenge, is making IT automation work in Rippling versus making automation work at Workday. It's not that different of a challenge. I think it we taken a different approach and we maybe had a set of like prebuilt 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 part of this opinionated platform then it'd be very hard for us to switch gears and go to 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 'cause 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, you know, serve those customers instantly and with very few hours of development versus if we built it in a more nature, which I think historically that's what SMB and mid-market focused tech companies did is they built a very opinionated, narrow focused product. We built this product that is built around a flexible code-based workflow engine that can then flex into large enterprises quite easily.

Brett: Is there any specific set of insights that have allowed you to have such a high rate of product execution?

Guest: Other than we hired very, very good people and Alex is very good.

Brett: Like it seems outlier, the amount of product that you've shipped on a monthly basis is a relatively small team there.

Guest: There's no substitution for just 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. You know, priorities shifted but the same core things that we're trying to build are true then 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've been able to just like 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.

Brett: What about the opportunity allowed you to have such a relatively fixed roadmap?

Guest: 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 gonna change in the next two months because this is our like 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 Verkada. 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 SKUs while we were there. So I think we also had a really good intuition of how to build, what was gonna work, what was not gonna work. And so when we were doing all these customer interviews, I think we were pretty dialed in into what we were 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 were doing and we just did exactly what we said we were gonna do in terms of product development, in terms of like customer traction, we just did exactly what we said we were gonna do.

Brett: Is there anything else that you've about selling a next gen product into an existing category that you haven't talked about? You know, you landed on this aha moment, which is the way in which you build, the way in which you go about building automations, generates codes, 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?

Guest: 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 larger organizations, the actual folks doing the implementation, it can be a very large team. And the chances that all of them are gonna 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 gonna 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 not really a bottoms up approach where you can get 50 different IT support leaders excited about it and 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 starts to click and they start to envision all the things that they could do with it. That's what does it for us is if we can get the demo with that senior leader, it 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 gonna drive to see you, it's an hour away. I'll be there in an hour 'cause I wanna meet you." Because he 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 wanna share them with us, they wanna share them with other people, they wanna show the org what they were able to do.

Brett: That's cool.

Guest: And they actually surprise us. They will tell us, "Hey, we built this workflow that does X, Y and Z." And we say, "No that's, it's not really possible. Like you're probably confused about how it works." And then they'll show it to us and say, "No, it works.: You know, we ping somebody for their Okta 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 anymore. People just find ways to do cool things with the product and I think that's gonna be something we want to increasingly lean into because that's how you can kind of combine the top down pressure from the executives, which is you know, 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 know, you're just replacing the stuff that they decided to 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.

Brett: 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 in 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, and intelligence piece, a creativity piece, but like there's a critical role in all of this, which in this case is the IT professional.

Guest: 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, 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, how I wanna 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.

Brett: Maybe sort of on a similar point, what's gotten easier in the 18 months that you've been building the company from an enabling technology perspective?

Guest: 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 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 want it 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 to feed it a bunch of contexts of here are all the possible workflows somebody might wanna build and here's the code, here's what it looks like. You might wanna 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 wanna 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 the chat bot. The way we want Serval to feel to the end user is it's somebody that solves your problem or gets outta 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 with the chatbot where it's not being helpful, it's just talking a lot. And we want the experience of you wanna pass a reset, you've got a password reset, you want 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 Serval's 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.

Brett: 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 as this stuff gets better and better?

Guest: It was absolutely a huge bet. When we started, especially the stuff we are 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's paid off. I don't know if I would make the same bet today on those same increases in 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.

Brett: Do you worry there's a future state where they actually get too good that it's strategically disadvantageous to the business, that there's a Goldilocks?

Guest: Yes.

Brett: Level of power that you want?

Guest: 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 parody in it 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 workflow 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 unlocks 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 ops and logging into tools and making changes manually. Obviously the universe of things that you might wanna 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.

Brett: One of the things that I really like about startups is that you generally end up innovating in product and/or distribution 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, Verkada 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?

Guest: I'm really interested in this evolving role of the forward deployed engineer. I don't think we're unique and being very excited about that role. Where we are unique is 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 that they're serving.

Brett: So why has it become like a topic du jour 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 as glorified consulting and now it's sort of like the topic de jour. Like maybe start with like why you think that is and then how it applies to what you all are doing.

Guest: 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 and 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's what's happening. Where if you really wanna 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 organization's needs. Now the forward deployed engineers coming in and doing that for AI products for, you know, startups instead of large enterprise software companies. So I think 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 Verkada, really any company traditionally you've got solutions engineers, you've got customer success staff, sales AE, they talk to customers, maybe the SE hears a good idea, they communicate that to a product manager. Product manager talks to the engineering manager about that. Maybe it 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 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 forward 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.

Brett: Will they build a one-off feature that's only relevant to the one customer?

Guest: 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 as a forward 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 lemme 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 like really tight feedback loop I think is really miraculous. And I'm wondering how big that forward 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 tighten that feedback loop and we're gonna see how far that we can get with kind of forward deployed.

Brett: In this model, what is the difference between a forward deploy engineer and an engineer?

Guest: There is very little difference other than we expect the forward 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 forward deploy 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 you end up having a traditional infrastructure or 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?

Brett: 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.

Guest: 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, you're replacing this middleman that's trying to allegedly collect all this information and then streamline it, you know, directly to the folks that matter and do it in some kind of curated way. You're 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 you know, 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 forward deployed engineers 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 is great. Everyone knows that when a CTO talks to a customer and goes and builds product features that's awesome. If you can scale that, you can scale the awesomeness. There is a question though how much that scales. 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 is something we'll 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.

Brett: Are you finding the customers it's just immensely delighting?

Guest: Exactly, the fact that a customer can ask for something and just get it same day. We have a call at 10:00 AM and that feature they ask for is shipped at 4:00 PM, 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 the 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're actually also solving the problem. I think you build some customer loyalty that is really harder 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 your forward deploying engineering team is really good in product oriented, they're solving a problem that a lot of other folks have.

Brett: What is the role of a PM at Serval at some point in the future? Or is the goal to never hire traditional product management?

Guest: The goal is to delay the hiring of product management for a very long time. I think the role of PM is gonna be similar to what it was at Verkada, 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&L. And so thinking of PM as more of a general manager in charge of a broader function or a product area, I think that's how we'd wanna structure PMs. I mean Verkada was 1,000 people and had two PMs. And I think we can do the same and keep that team very, very lean and really focus on PMs that actually own a business unit.

Brett: What's your theory of like what's going on in your brain or other like business builder GM style product people that give you that sort of taste and sensibility to kind of get that multivariate problem solved?

Guest: 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 Verkada, we had a Slack channel 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's 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 wanna solve that. And I think it's very much what we were trying to do in the early days of Serval, is not pay attention to the fact that they wanted, you know, this feature, this feature. Certainly no one asked for a new ITSM and no one asked for a new workflow build or any of this. It was just they had this problem they were 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, "Okay, 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 forward deployed has a huge role in driving forward 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 gonna slot that in. You can just go and you can build that. 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 afternoon kind of a thing. And I think it actually ties into this prioritization conversation because I think you can overprioritize 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 gonna 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 forward deployed is that the P2s actually get looked at and the P2s matter.

Brett: 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?

Guest: 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. At Verkada got the chance to visit customers. We took a customer to the club in Vegas and we got to know customers got to go on site with them. It has to be being embedded. I always think of this as like you have to be embedded with a customer and it's not, oh I'm gonna schedule a customer interview and I'm gonna 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 gonna answer. It's more you have to be in a Slack channel with a customer. You have to have a weekly call with a 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 like this unlocks X dollars of revenue. You're saying, "Oh you know what? Scott's gonna love this." We can do that, remember like, Dana hates this stuff and you just like 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 gonna 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 Verkada 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 glass. Every single one of them had been held up at gunpoint 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, you know, 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 holdup buttons are not mobile panic buttons and you know, like this is the market size of this and blah blah blah, but you just talk to that customer, "You're like no it has to be."

Brett: As the role of product is potentially changing, 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?

Guest: No, I think we've definitely decided to bias more on really smart generalists 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 are 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 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 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 market's 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 than 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 in that now an IT professional for example with some degree of programming experience is incredibly valuable to the organization because of all the things that they can build for the company. Whereas five years ago they were maybe marginally more valuable than their peer because they weren't a full software engineer, they were just like kind of dabbled in stuff. They're marginally more valuable than their peer. Now they're incredibly more valuable 'cause they can use Serval on other tools to build really, really cool products and services. And so I think about it the same way in our team. I think that 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.

Brett: For anybody that's gonna 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?

Guest: 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 and took 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 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 segment of their life story. If they're more senior than then, you know, it probably doesn't go all the way back to high school. But I just wanna understand the big life decisions they made and like 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 often happens...

Brett: At your company.

Guest: 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 or 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 of your company down so quickly without you even realizing it because they passed the bar, they were 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?"

Brett: Oh, on your interview, you're not asking the candidate who am I better than?

Guest: No.

Brett: because I thought that would be very interesting.

Brett: I was like, how truthful would they be.

Brett: And then we bring them in a head to head. Like you just do a battle for your job.

Guest: Exactly.

Brett: Like, hey, this person thinks they're better. Like let's do a quick test. No, we do it in like kind of the debrief with 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 rung on the ladder on the team. We wanna 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 than 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.

Brett: Is that how you avoid the dynamic of just desperation hiring? I mean you're starting to grow really quickly.

Brett: There's such a temptation to bring in somebody because...

Brett: I don't think it can be emphasized enough.

Guest: It's so hard especially, and it's easy to say no to bad candidates, horrendous candidates but solid. 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 you 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 then you're getting yourself in 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 stay disciplined 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 and you're like, "I don't know if they actually raised 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.

Brett: 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 setup?

Guest: 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.

Brett: So how do you figure that out?

Guest: Some of it is what does their network look like? And you know, you can talk to them about like who your network is. We can do back channeling, we can do reference tracks, 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, you know, we're all in person in the office every day in San Francisco and so 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 of the person.

Brett: Energy, enthusiasm, just being friendly and a nice person.

Guest: 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 at great companies, 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, 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 good talent.

Brett: So are you finding you have an outlier referral rate into the company?

Guest: 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 is its own reward in many ways.

Brett: Right, well it's gonna create a lot of shareholder value for themselves.

Guest: 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 than they are from their salary.

Brett: I always thought referrals should be done in equity and not salary.

Guest: Yeah, I mean we could explore that. It's been great to really weaponize that and I think every person that's joined, we're starting to formalize that more and say like, hey, you know, people bring in people. And we're also getting to the point where because the company's doing really well and we've raised great funding, it's easier to outreach to your friends in 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 to them to take a risk that maybe might not be it.

Brett: 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 sort of say about how you think about staging that?

Guest: 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 onesie 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 broaden 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 calendars 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 to I think really seize the market because there's gonna be a early stage competitor ServiceNow, somebody is going to build an next generation ITSM and we've got a short amount of time I think to position ourselves as we're the ones to do it.

Brett: Do you think just given the rate of competition and startup creation, et cetera, et cetera, that that sort of land grab dynamic today in 2025 is much more substantial than three years, five years, seven years ago?

Guest: 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 sales cycle, you gotta get in now and it is a moment in time that you have to take advantage of.

Brett: 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?

Guest: 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 .

Brett: The sort of X dynamic.

Guest: 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 up 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, you know, evenly split market. I think there's definitely gonna be a one player that dominates.

Brett: It's interesting 'cause we could just be 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.

Guest: 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.

Brett: Which is where startups generally begin.

Guest: I think that's exactly right. So startups that come in these new markets, they do it with simplicity like what Linear does to Jira, right? 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 and not making drastic changes that are not backwards compatible. And so they're just naturally going to be slower at adapting 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 in all these platforms and that's what's happening.

Brett: So I 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 did they teach you that is not a family member?

Guest: I benefited a lot from this dynamic at Verkada where you have these two leaders, the CEO, Filip, 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. Filip often looked at a lot of these problems from first principles on what would be built if we were building it today and how might it look different from what's come before. I think both perspectives are really, really valuable and often I have both in my head. And from that experience working at Verkada 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 categories from 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 like build something new that doesn't think about ticketing at 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 want to think about like why this category exists and that maybe there's some truth to the history and the history is telling you something and its signal and not something you should just ignore and build something from scratch.

Brett: So you're sort of, you're touching on this a little bit, but if you think about where Serval is today, how are those two ideas and the tension between them best expressed?

Guest: Yeah, exactly. So Serval is 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 that both replaces your system record and automates these help desk requests and helps IT build these really powerful automations.

Brett: Nice, great place to end. Thank you so much for joining.

Guest: Thank you Brett.