In this episode of In the Arena, Vannevar CEO Brett Granberg breaks down Vannevar’s first forays into building AI-enabled sensors. He shares why defense startups need to deliver complete systems (as opposed to just components), how hardware forces a different pace of iteration, and why real-world deployments – failures and all – are the only way to validate products.
We cover lessons from Vannevar’s RF sensing venture, the structural challenges and opportunities in defense acquisition, and what it takes to move fast in hardware while staying mission-first.
“The most important thing in defense is building complete systems that solve top mission problems. Starting from the mission and working backwards—not presupposing whether the answer is hardware or software—is how you actually win.”
- Brett Granberg, CEO of Vannevar Labs
Watch the full episode below, or listen wherever you get your podcasts:
Episode Transcript
Hayley
Today, we're getting into how hardware and software teams think, operate, and build differently, especially when they have to deliver together. So I'll start by asking you, is it important for a defense company to do both hardware and software? Or do you think pure play hardware or pure play software companies can be successful in this environment?Brett
I think the most important thing for defense is you have to build complete systems. The government doesn't know how to ingest like components of systems. And so a mistake we made when we started Vannevar was we built, you know, like Arabic optical character recognition, like a small like a API service that basically you feed it an image, it it outputs the text that's in that image and translates it. That's like a feature of a feature in DOD land. That's like such a small slice of the pie. And so the thing that's most important when building a defense is, are you building an end to end system that solves a top three mission problem? You can do that with software, you can do that with hardware and software, and I guess you can do that just with hardware. I think there's like different combinations of that that can work, but as you scale, I think, like, as you go after bigger and bigger mission problems and as you kind of build more and more complex things, you do eventually, like, at least for us, we ran into having to build a combination of both hardware and software to solve the types of problems that you wanna I don't think there's anything definitionally that, like, is going that requires that for certain companies. Think Palantir is, like, a great counter example of, like, they, you know, have spent a long time building just hardware for the government and they've done very well. But I I do think, like, as your ambition increases, like, the complexity of what you're trying to tackle increases in defense that can lend lend you to more of, like, having to be excellent at both hardware and software, which is hard to do. It's very hard to do.Hayley
I recognize that Vannevar is still pretty early in our hardware journey.Brett
Yeah.Hayley
Can you go into what that decision was like to get into hardware at Vannevar?Brett
Yeah. For sure. Yeah. And just to be clear, like, I'm I'm not I'm I'm speaking like I'm an expert on hardware. I'm not. We're we're very very early days. But for us, it wasn't a decision to get into hardware. I don't think about it as like we're, you know, we're only building software, we're only building hardware. Like, I don't I I think about it more as like what are the mission problems we're trying to solve and like what does it take to solve that mission problem. And so the specific mission problem that we started with for the first hardware product was which is like a combination of hardware and software, it's not just hardware. But the mission problem was, hey, there's a specific type of ship that we are seeing, the government struggle to detect in a useful way in a in a particular part of the world. And when we looked at that problem, we first approached it we we actually did first approach it from a software standpoint. We thought, okay, like, well, what types of data can we collect digitally, you know, like, in create via creative means, like, what can we get access to that provides us more, information on this particular type of ship? And we actually got a decent part of the way down that problem set, and we did some really cool stuff. But at the end of the day, it wasn't completely solving the mission problem that they had, which is like, I wanna know where the ship is and like what types of signals it's emitting. That's what caused us to say, okay, well, if we really wanna solve this, then we have to build an RF sensor. Because when we look around, we're seeing what the defense primes are putting out. It's things that cost, like, you know, literally two orders of magnitude of, like, the thing that we can build is, like, a 100x cheaper. And, yeah, the decision was not we're gonna build hardware, the decision was, hey, there's, like, an important mission problem that we know is a top three problem for, you know, a certain number of groups in the government, and we're just gonna do whatever it takes to solve that problem, which led us down a hardware route.Hayley
How do you make that decision between pursuing a bigger, exquisite system versus a multitude of smaller, attributable, less expensive nodes.Brett
I think it all goes back to, like, think about any time you're doing product development in defense, probably anywhere, like, you know, especially I only know defense. So it's any time you're doing product development in defense, the most important thing is starting from the mission problem, not starting from, like, your perceived, like, what the right, you know, answer you think is.Hayley
Yeah. I'll interrupt you there for a second too. I had this question come up in an interview recently, and I think one maybe misconception about Vannevar and how we approach problems that I want to set the record straight. But when we say that we're mission obsessed as a company, it's not necessarily that people care really deeply about national security, though they do. I think the thing that people miss sometimes is that, you know, Vannevar, we're not an AI company, so we build AI products. It's more so that we're obsessed with the mission of deterring conflict in The Pacific and what like, working backwards from that mission, what products then do we need to build? And then if the answer is hardware, then the answer is hardware. Does that resonate?Brett
I think it's exactly right. Yeah. Yeah. I think starting like, how you get stuck building the wrong thing is actually presupposing what you think the right answer is. Like, for example, we thought the right answer was Arabic OCR in the beginning, so we spent an enormous amount of time trying to build a perfect version of that, trying to sell it, didn't work. Instead of what we then started to do and started to realize was thinking about, okay, what are the top three problems that we're seeing across these mission groups and how do we sort of work back, like find what's common and then work backwards to building something that solves that problem. That's like the core. And I think good product development in defense is about doing that versus like, oh, I am a I build x thing. I'm an AI I build AI things or whatever. I think that's like a good way to not win. Yeah.Hayley
Well, I guess that said, are there any like, fundamental differences in your opinion between hardware builders and software builders?Brett
So developing hard hardware and software from, like, an engineering standpoint is completely different. I think for the main difference is your iteration speed is a lot slower on hardware. You have to be closer to being correct on the first bet that you make. Like, your idea of what you think is right on a particular mission problem, you need to be more on target than in software. And the reason for that is like, you might get three or four iterations of hardware in in, like, a given twelve month period, whereas for software, you get three or four iterations of software in, like, a couple hours, like, or, like, you know, a day or whatever depending on what you're working on. So I think that, you know, you're able to take hundreds of more maybe not hundreds, like, you know, tens of more, possibly hundreds of more shots on goal for the software side where you're able to like iterate and learn, iterate and learn. You you don't get as many shots on goal from a hardware standpoint. So that is like the big fundamental difference between developing hardware and developing software. Failure mode on the hardware side comes when you are you fall into the same trap of like, I am presupposing the specifications on this hardware are the right specs. Like, know, building a UAV, it's gonna have this, range, it's gonna be able to carry, like, this payload and and being really attached to those specifications versus being attached to the mission problem. I think that is I see a lot of companies build in that way. That can work if you're building like 10 different hardware products. You can kinda you have more room to like be wrong a few times, but the main difference between hardware and software is just how many shots on goal you have. And you need to be closer to on target, I think, hardware on your first couple go rounds than you do on software.Hayley
As the CEO of what was until recently a software only company, how did you or have you been getting smarter on hardware?Brett
I'm really relying honestly on, like, the the the team, like, which is, like, Scott and there's a few people Scott, our CTO, there are few people on the engineering and and and our product team, the mission strategy team that are kinda getting in there and blazing the trail for us on, like, the Vannevar side for how to do this. So that is, like, a huge part of it. In terms of other things that I'm doing is just, like, talking to defense CEOs where I can. Like, there's a few hardware CEOs that I that I talk to somewhat regularly, and that gives me a sense for how they think about the problem. And then I also pay attention to, like, what works for them from, like, a revenue standpoint. Like, there's some hardware companies that I've seen, you know, build a lot of products, and it's for me, it's been interesting to see, like, which of those products actually achieve growth and why. And what I've seen so far is kind of what I just described, which is the products where you had somebody predetermine, we're gonna build x hardware thing because it has y features, seem to do a lot worse than, like, the the situations where you're actually building from, like, a mission standpoint first and working backwards. There's, like, an additional challenge here on the defense side, which adds noise to this, which is, like, the program offices that write the biggest checks in defense actually are they buy based on hardware specification sometimes, like based on like a checklist of requirements. It's hard actually to tell from the outside, like, is this hard is this product actually good and is gonna work in the long term versus did this team just have like a really good strategy and like really nailed it from like a BD standpoint. So that kinda creates a little bit of learning noise for, you know, people people on the outside or people that are new to this. I'm like, okay, what how act what is actually the right way to go about it? The thing that is fundamentally true in either hardware or software is, like, your BD people and your engineers and your product people need to all for especially for new products, they need to all be working together on, like, doing customer facing things, like going to business development meetings, going to user meetings. That is, like, the very much, like, the common thread for things that have been successful that I've seen in the hardware space have that component to them.Hayley
Are there any other aspects of the government customer that shape how you build a product? Like, you mentioned the requirements piece, but is there anything else?Brett
Physical access and testing is really important for hardware products. I don't know if it really shapes how you do for us, it actually does shape how we do product development. So what we what we end up doing is like on the software side, again, you can release so quickly, that, you know, you're gonna iterate like much more quickly anyway. But what we what we did in the early days of Vannevar on the software side is we would pick, like, DOD operational dates, like things that our customers or our users were, like, doing from a mission standpoint that was, a live operation or, like, a live exercise on a particular date. You know, let's say it's April 30 or whatever. And we would use that date and then we would set that as like a, you know, deadline for like, for us internally to get our stuff together and really focus our product development effort because like, the end you know, we're going to be shipping something on that date whether we're ready or not. And that method works is critical on the hardware side too, partly because the development speeds are, like, it's so much longer to iterate. So we do the same thing of, okay, we're going to deploy our RF sensing kit overseas in, you know, these countries on this date. And that drives a lot of our, like, product and engineering effort in decision making. And I think that real world testing, setting those up and like doing it from a logistics standpoint for hardware is like hard and whole functions that are dedicated to doing that. But that concept of, like, use hard operational test dates to drive product development is, like, very key and possibly more key from, like, a hardware standpoint to, like, force yourself to have, like, real world at bets on certain things.Hayley
Maybe a rudimentary question. What if the hardware is not ready by that date?Brett
Yeah. So, like, the first time we shipped our RF sensor overseas, we did it kinda, like, in concert with one customer group, but we also sent some engineers to deploy it on a, on a beach in that in the country we're operating in by ourselves. And what we found when we did that was, like, turns out, you know, like, it's really hot when we were deployed, and so you have, like, more heating issues that you have to deal with. You have, like, power, like the battery that we tried to, you know, ship in country was, know, whatever stopped at customs or something. So we then have to find, like, an in country local battery source and, like, oh, wait, you didn't know we had to do that. So you're yourself to go through the exact same deployment mechanisms that you'd have to with a customer is, like, really important. But when we kinda deployed, let's say, I can't remember exactly what it was, let's say we deployed, like, six kits out, you know, in that one deployment and, like, four of them failed. We can't get them up and running, but two of them work. And what we found was actually we had a sensor overseas that was running and worked that that, you know, we actually kind of, on the van of our side, knew was there but we weren't tracking, like, the usage of what was going on super closely. And it turned out that the government actually, independent of us, took that sensor, did some really cool things with it and then just, you know, told us, like, after they got back from that: By the way, did all these things with your sensor, like, oh, that's great. So I think it it doesn't matter if you think you're ready, it's just like you have to make yourself deployed because that's the only way you're gonna figure out what's broken. And sometimes you'll get lucky, like we got, you know, maybe a little bit lucky that we had a sensor that, you know, worked and and actually was like put to good use out there. But you just yeah. You have to forcing yourself to deploy overseas even if you're not ready is good. It's a good habit.Hayley
You've talked a little bit initially about building a systems integrator and becoming a systems integrator. And in defense, software is often layered onto hardware. And defense still is a pretty hardware centric world. How do you build effective systems across those two domains?Brett
I believe that for new products, for us at least so far, the best results for zero to one always come when you have, like, a very, very small engineering and and mission team working together. When I say very small, I mean like less than eight people. I mean like a very small team. And so for us, for that RF sensing product, the engineering team is not three anymore, but it's not it's not 15. It's still like relatively it's still small enough that, there's there there's software engineers, there's kind of like RF signals experts and there's kind of like hardware engineers and that whole team is like sub 15 people right now. I think it's really hard to build like totally new zero to one products once the team gets big and like too big that not everybody knows each other. So we've had the benefit of like for the zero to one phase, we're just trying to keep the team really small, and that allows you to like actually, yeah, you can when everybody's on the same team and has the same incentives, you can fill things really quickly. It gets way more complicated if you once you have to split, you know, teams and, like, oh, there's a separate software team, there's a separate hardware team, there's different managers and they have different incentives and all that kind of stuff. That's more of a how do you deal with that when you scale versus, like, how do you figure out the zero to one product thing to build? Again, I'm not I'm not an expert on in this domain, but that's kind of what we're seeing so far for this.Hayley
Yeah. Knowing that we're still pretty early in this hardware effort, have you thought about how and and kind of how you mentioned, like, having this tiger team of people working on our nascent hardware product. Yeah. Have you thought about the differences between actually scaling structurally a hardware company versus a software company? And I'm sure it is also colored by the fact that we're 200 people now and things are, you know, sometimes go sideways anyway. But, like, have you thought about that distinction?Brett
Yeah. I think, some of the principles, I think, are all still the same. Like, small teams focused on building, you know, from, like, a mission first standpoint, like, on, like, live testing and deployment with people in the field. Those are all those principles are all the same. I think the difference is like when you're building hardware, you have to physically manufacture things in a place. And right now that's like a very, you know, we have like a very small office where that's where we do that. But I think, yeah, as you kind of scale that manufacturing out, that's like becomes like a whole operational challenge and you need people in person and you need like the right skills in person and you need like a regular cadence of when to do in person testing for for different different different types of like things that you're preparing for. The hardest part I think is like actually figuring out what the right problem to bet on is and then building the thing, the zero to one like initial concept that actually has like what we call product mission fit. I think scaling operations is, like, also difficult, but it's it's in the realm of, like, a solvable problem. You're not having to invent like, the inventing part, I think, is the hardest part. And I think that our sort of approach on the, you know, how we've done this for the last, you know, six ish years, I think is, you know, I think is gonna work too. But we'll see.Hayley
So with those teams and, you know, the hardware component and the software component, how do you think about aligning incentives when they operate on such different cadences?Brett
Yeah. So I think tying to operational, like, use is really important. This is what I mentioned, like, hard, like, dates if we are going to play this thing out with users, like, at this particular time. For us, that's been a great inter I've seen, like, a lot of that's worked really well internally for us. I'll give you an example. We deployed overseas somewhere in Europe and there's a partner, DOD group and partner that wanted to deploy this thing to track a very particular type of vessel, basically. That caused the hardware team to then think, okay, well, man, we have to be like, we have to have everything set up to be able to collect the type of signal that they want, but that also caused the software team to then be thinking about, okay, how do we like ingest the data that the kit is produced? Obviously, we're like thinking about this anyway and we've been working together on from like a product development standpoint to build the thing, but it's a forcing function of, right, we're gonna deploy this overseas with like a US partner that's like put like using a little bit of their capital to get us this type of access to support like an important mission. So like, we are going to make this work. And that hard date, and and having everybody singularly focused on that mission is what, you know, causes people to to work together. I think for us it's easy because it's you know, we think about building in small teams. It gets a lot harder, I think, when you're talking about, you know, like one hundred, two hundred, 500 person engineering team that's working on a hardware product. But it's not our yeah. We haven't had to deal with that yet.Hayley
I'll ask you something, maybe a hot topic.Brett
Okay.Hayley
Vannevar is a remote first company, which I think is the draw for a lot of our talent. And, you know, people can live anywhere, work from anywhere. I think that's, you know, a huge reason why a lot of people join, that tied with the mission. How do you think about building hardware with that setup?Brett
Yeah. You have to be in person. Like, you need some portion of the hardware team to be in person working together. Just it's, like, not possible to do testing and assembly and all these things remotely. It doesn't mean that the doesn't mean that the whole team needs to be there all the time. It does mean that people need to be kind of flying to the same place to do something at some regular interval. And so I think as as we scale by the way, think that's true for like new product development for software too. Like having, periods of time where you somewhat regularly get in person and work on a thing, is really important. The way that we have typically approached this is like working on military bases with users. From a software standpoint, that is like our forcing function for getting people together on like a regular intervals. Like, I think that that's what we've been doing for hardware too, but we also have two offices now that are kinda like two dedicated hardware spaces.Hayley
Where are they?Brett
Seattle and New York City. Moving to Seattle, I think, longer term. But hiring people that are local to that area and giving people also relocation bonuses for people that wanna move out there is kinda how we're thinking about it. But yeah, you definitely need people in person to build things, for sure. Yeah yeah. But you don't need the whole team and you can solve it with being aggressive in how you set up team travel and off sites and customer visits, that sort of thing.Hayley
What do you think traditional defense primes can learn from startups, or or just tech native software companies as as they're building hardware Yeah. Or their combined systems?Brett
Yeah. I think the primes are really good at building very low fill rate, super exquisite assets. I think the the key thing for defense primes is like velocity is the problem. Just kinda like speed of iteration and and kind of getting to getting to like a a product with like a in a reason with a reasonable cost is like a thing. Start ups, like us, have a lot to learn actually from defense primes. Specifically, I think for us, like, we spent a lot of time focusing on like the mission problem and the user. And it took us probably three years, I would say, before we started to focus on the program office and requirements and program managers and trying to map out how that all works and then also government relations and kind of like how does Congress relate to all this. All that sort of those are all things that the defense primes are world class in, like absolutely world class in in like all of those things. And it's something that we are very much, you know, we have to learn a lot from them. So I think a lot of the new defense companies, us included, benefit greatly from sort of understanding how all that works. Yeah, I think the on the defense prime standpoint, it's really a structural issue, I think, with them where, you know, like a lot of these programs are awarded on a cost plus basis. And so what I've seen for software programs that are cost plus, it incentivizes like delay, like just sort of delayed release and like, an exaggeration of the number of engineers that are required to build a thing and just sort of, like, compounding cost to to, you know, eke out whatever, like, the 7% margin. Like, that in order for that 7% margin to be meaningful, like, the cost basis on these programs needs needs to be really large. And I've seen that as like a complete failure mode for software programs. But that's, you know, cost plus is like how all of the most of the major acquisition programs on the hardware side are sort of run. And it just structurally incentivizes, in like, my opinion, like, kind of bad behavior. There are types of systems where, you know, maybe the defense prime can't front all the R&D money to get the thing off the ground, there's like very valid, like, big satellite thing or you're just not gonna have like a new unmanned surface vessel you know, program be successful run within a defense prime on like a cost plus basis. Like I would say the odds of that happening are like round to zero. I don't know what they are, but so yes, not high. So I think there's a lot of structural factors that are working against the primes that they it's not really in their business incentives right now to figure out. But that is sort of, you know, there's that's the key barrier for them in terms of product iteration from, like, a hardware standpoint.Hayley
People say that hardware is hard. And I'm sure you tempered your expectations before, you know, embarking on on this process. That said, is there anything that has, like, really, been unexpected for you?Brett
Yeah. I mean, I I think the fundamental, belief that we had when we started Vannevar is still largely correct, which is like, you have this, again, massive market, it's like 400,000,000,000 in procurement spend for defense that goes to defense companies. And you you largely have very old incumbents that haven't needed to think diff like, do try new things, and have sort of been structurally incentivized actually against, like, being innovative and trying new things. And so those are those are the dynamics of the market and that applies to software as much as it does to hardware, where I I think, yeah, what we're saying just using, like, you know, again, the RF sensing space as an example, we are right? We're not even it's not even a competition because they're just such wildly different systems, but you have like, the closest thing that we see from a competitive standpoint is like a $400,000, like, kit that like the you know, when we deployed forward with some of the DOD groups we were working with, they couldn't even set it up because it was so complicated, so it didn't work. And the thing we're building is like, we can build for 5,000 or less, you know, per per unit right now. And that's that's like, you know, that's two orders of magnitude different and it's just because we are using things that are not 20 years old, I guess. Like, we're just kinda like looking at whatever like the most recent technology is, both from a software standpoint and from a hardware standpoint. And we just have the ability to invest our own R and D to just try a bunch of things out and, you know, that's that's sorta, I think, what is lacking, I guess, a little bit on the defense prime side.Hayley
When it comes to building hardware and deciding as a company to do that, how did you think about or how are you thinking about the build versus buy equation?Brett
Partnerships are really key. They're they're key for software too, but they're they're, I think, probably more key for hardware. And so for all the component, like, we're kinda building this RF kit, we're constantly swap, like, trying different components, trying different, sub suppliers and swapping them out. And that is, yeah, really key. I think, like, partnerships and having good relationships with, for whatever you're building the subsystems that are required to build the thing is very, very important. So I think we are finding that I mean, just for this RF sensor, we're finding that a lot of the sub components we can find best in class systems and kinda combine them together to get something good. But we're finding that on the software and signal signal processing side specifically, that's mostly things that we have to build on our own with, you know, some exceptions of partnerships that we have there. But I would say for hardware, it's like especially important to have good partner relations.
