EP. 04: How to Make Strategic Product Bets | "In the Arena" Podcast

How do companies know which products to build? What are traits of a 10X product leader? Should national security startups pursue a portfolio of bets or take a couple concentrated big swings? What does it look like to balance buyer vs. customer demand in defense? In this episode, CEO Brett Granberg shares how Vannevar has navigated these questions while making strategic product bets. We explore Vannevar’s product evolution, from early failures to recent strategic moves.

“There there’s never a time where I’ve regretted going on a base and showing somebody something, even if it barely works or is feature limited.”

- Brett Granberg, CEO of Vannevar Labs

If you’re not afraid of spending most of your time with customers and iterating on high stakes problems, we want to talk to you.

We’re hiring: https://vannevarlabs.com/careers


Watch the full episode below, or listen wherever you get your podcasts:

YouTube

Spotify

Apple Podcasts

Episode Transcript

Hayley

Today, I want to get into actually building products. It's not always obvious how to decide what to build next, especially in defense. Feedback loops are a lot longer than they tend to be in commercial settings. So I wanna start by having you walk us through a product bet that you recently made. And what was that decision making process?

Brett

Yeah. I might pick economic warfare. So from, like, a macro standpoint, there's a lot of, activity right now between China and The US in terms of who has access to, basing an overflight, station. So for example, where can China's navy pull into port? Where can our navy pull into port? Where do we have air access? That sort of thing. That has kind of hit the news recently. Think, like, maybe two months ago now, there was a the Panama Canal Blackrock deal was sort of talked about publicly in the news of Blackrock buying from a Hong Kong entity, a couple of ports that sort of are on either side of the Panama Canal that would be pretty key to to control in the event of a conflict if we needed to move, the Navy from the Atlantic Ocean to the Pacific Ocean, for example. So you have this kind of massive problem where The US and China are kind of investing a lot of time and resources into how do we kind of get posture and kind of have access to these specific locations. And The US is just now starting to invest serious mission resources against kind of tackling that problem. And so we saw that with our first product, Decrypt, and some of the other early stuff we built. We ended up working on some of these missions in sort of an adjacent tangential way. But that gave us some, like, domain context of what was happening on the ground for that domain. And then recently with the new administration, economic warfare has risen to, like, a top I don't know if it's a top two problem for them, but, a top five problem for certain people in the administration in in certain senior roles. And so we started kinda hearing about what the plans were, saw sort of a macro shift in the budget for how much money is gonna be put on that mission. And then also knew from kind of on the ground experience, like, where the gaps were from, like, a product and technology standpoint, and had pretty high conviction that, we, you know, we're probably the best positioned company to kind of build some specific things for that area. So I think for that new product bet, in general for us, it's about having unique kind of mission or domain knowledge, and then combining that with some BD thesis that can tell you a lot about where to bet from a new product standpoint.

Hayley

Do you have any examples of a product bet that you made over the course of Vannevar lifetime that failed or just didn't work out as you hoped?

Brett

Oh, 100%. Yeah. Yeah. So I think, like, our whole our first product was, like, kinda pretty much a disaster, largely due to me making a bunch of mistakes. But, yeah, we we've told this story a bit before, but the first problem we bet on was a counter-terrorism problem that Nini and I had some personal experience with prior to Vannevar. And we picked, like, this very niche component of the problem, which is around Arabic optical character recognitions, so being able to recognize and pull out Arabic text from image files. And we spent all of our engineering points on that product for like a long time, I don't know, like probably six months or so, just adding feature after feature, like making the thing like increasingly complex, with the thought that, okay, it's not feature complete, that's why people don't wanna buy versus like, hey, we're not tapping into an important mission problem. And so, that's, like, one example. But we we make mistakes like that all the time. That's kinda just part of, like, making new product bets is you're you're not gonna have a 100% hit rate. That's the second thing that comes to mind for me, which is, like, a mistake that we sort of pivoted and was useful, was around information operations, so understanding sort of what's going on in the information environment. We built a feature that turned into like a product that was standalone that then had users and then became like crazy complex and we spent, like, fourteen months supporting. Where in the first month or two, we knew after releasing that product that actually the the thing that we were building was a smaller part of the problem and we actually needed to build something radically different in in order to own, you know, the the amount of that mission that we wanted to. And we kinda got in a trap of, like, investing investing investing as opposed to what we probably should have done, which is, like, shut that down and then spin something new up. But, yeah, in each of these cases, you're you're it's just all about getting the benefit of learning and iterating. But, yeah, you can get trapped around iterating on a local maximum versus a global maximum. I think that's the most common mistake.

Hayley

And what are some indicators that someone might be iterating around that local maximum?

Brett

Yeah. Well, a good indicator that you're not iterating on any maximum is, like, nobody wants to use or buy your product. I think that's, like, a pretty good indicator. So what that looks like is, you know, like, you're doing demos, nobody actually wants your thing, nobody calls you back, you can't sell what you're building. That's sort of the Arabic OCR use case for us. Beta rating around a local maximum is like a little bit harder to discern. That's maybe you're actually, like, getting users. So the reason we didn't shut that product that the other product down that I talked about is we had users that were using it, like, actually somewhat regularly. But what they were using it for was, like, an extremely narrow use case and we weren't going to be able to convert that usage into like a broader sales motion for us. And so I think, in that case, that looks more like you have users, like people actually want like, maybe you actually have strong internal advocacy. Also have people on our team that were like, hey, my users love this, we can't shut this down even though, you know, be because for them it's like helping them with their deployment but from like a macro standpoint, investing engineering resources is not the highest ROI thing we could have done there. So it's a little bit more difficult to pivot away from, like, the local maximum. But I think, yeah, both it's very easy to make mistakes in both categories, especially the first time you do something like this.

Hayley

How do you handle that situation where there's asymmetric demand between end users and then actual buying entities?

Brett

Yeah. You kinda just have to make hard calls. I think, like, there are and it's, like, pretty nuanced, actually. So there are situations for us where, we may have a product that only has maybe five or 10 users, and maybe they don't use the product that infrequently. But when they use it, the the impact to their mission is so disproportionate that we actually don't care if, like, the daily active usage number is low. And we and we also don't care if it's only used by a small number of groups because we can take that those mission wins and that momentum and apply that to a bigger program. That's, like, that's worth it for us. But there are instances where that's not the case. For example, this, like, small feature, we were making an impact on a mission, but it was maybe, like, a plus five or 10% impact versus, like, the other product where it's maybe, like, a 5x or 10x impact on the mission. And in those cases, you kinda have to make the hard decision to just stop supporting things. And for yeah. I tried to do that for that particular product a lot earlier, but I, you know, I I was like, I got a bunch of pushback and I was hesitant to kinda come in super top down and make it happen. But in retrospect, that would have been the right decision and I think I'm a little bit more I push a little bit harder on that now. Not necessarily in terms of killing things outright, but in terms of where we move resourcing, if that makes sense.

Hayley

Yeah. I guess on the flip side, like, you ever been so convicted by a product or a product idea that just felt like the future even though there was not necessarily demand there?

Brett

And Yeah.

Hayley

How, like, how do you deal with that?

Brett

100%. Yeah. So I think part of the zero to one product journey that is difficult is, like, you you need like, the person who is, like, deciding to do the new thing, you kinda you kinda have to be a little bit crazy and and, like, you have to have a lot of conviction and be a little bit crazy because you're oftentimes not gonna have enough information to justify the level of conviction you have. You yeah. You may have, like but the the most important thing is being right about the mission problem and, like, understanding that and having conviction against the mission problem, not your particular solution. And so that's what I that's what I have tried to evolve myself into doing now when I'm making a bet that I'm excited about. It's about the mission problem, it's not about the specific solution. And try to kind of encourage people on the team that way. There are examples of this now, like, we're thinking like, there's some offensive cyber stuff we're thinking about internally right now. There's also some, like, platform, like, RF type collection stuff that we're thinking about now. And the specific solution that I think we should you have to have a hypothesis to, like, start with and test on. But I'm almost positive that what I'm thinking is right is gonna be wrong. So it's just but it's like the the macro point of, like, it's not really about the specific in the beginning, it's not really about the specific thing we build, for example, for cyber. It's more about having conviction on that mission and getting there and iterating and learning.

Hayley

If your feedback is from customers, which it sounds like you're saying it is, how, like, how early is too early to put something in front of a customer for that feedback?

Brett

Yeah. Never too early. In my opinion, I think people differ on this a little bit. In the like, you know, like, the reason is, like, you just go back to the Arabic OCR example. Like, we were doing a bunch of demos. That was good. We we were not having anybody wanting to buy our stuff. That was, like, not great. But we were also investing engineering resources against the problem. And a better way to do that is to not like, we shouldn't have built anything. Like, we we could have gotten all the information we needed from users with, like, PowerPoint, like, Figma mock ups and, like, a demo video that we hacked together instead of investing, like, months of engineering time. And I think that is more like, when you're, really early on the zero to one phase, you're you're you're using user feedback to try to just understand the problem better. And oftentimes, you can get that information without doing any engineering. And so, like, you should be testing with users, like, before you've built literally anything, preferably, if you're able to do that. Sometimes you're not. But, yeah, earlier There there's never a time where we've, like, I've regretted going on a base and, like, showing somebody something, even if it's, like, doesn't like, barely works or, you know, it's, like, very feature limited, if that makes sense.

Hayley

What do you think is the best way to structure a team where people are comfortable making those new product bets?

Brett

It's like a hard job. It's like not everybody, I think, is going to want to do that or be able to do that. Like, what what's really required is you need somebody with conviction and the right mission context and some intuition on what to build. And that can come come from, like, different backgrounds. It's not like one background where that comes from. That could be like an engineer that has that conviction. We've had stuff invented by engineers on the team that has been awesome. And I initially heard the idea and I was like, no way. Like, that's not that's not a good idea. And then they build the thing and it's like it's a it gets a bunch of users and generates a bunch of mission wins wins and I've been wrong. And so it's more I think about it more as like finding people with conviction that have the right domain experience for the problem that they're trying to solve, and then letting them, like, enabling them to make bets even when people disagree, including myself. I think that is, like, the most important thing. If you try to do, like, invention by consensus, it's, like, not gonna work. Once you have, like, a zero to one product that, like, starts to get a little bit of traction, then it becomes really important to have, like, a not just the product person and but also, like, some sort of BD, or customer facing person enabling that team to have a bunch more customer meetings and try to sell the thing and have that team sort of iterating and working together. You kind of earn the right to do that, like, the further along you get. But at the beginning, I think it's like enable people that have conviction and the right experience to make bets.

Hayley

Like, I wanna talk about making a bunch of new bets for a minute because we're at a point in Vannevar right now where we're starting to think about the next big swings that we wanna take from a product standpoint. But how do you know where to draw the line between a portfolio of shots on goal versus, like, concentrating a few big bets?

Brett

Yeah. So in defense, I I think it's true that, like, your revenue or just, like, the sales that you have is gonna be determined by, like, a relatively small number of things that you work on. Like, there's there's a small number of deals that determine most of your revenue every year. And in my opinion, those deals are driven by, like, a small subset of the products that you're working on. So I think, you yeah. It's kinda like and it's also true that in defense, you have to be inventing new products and new business units, like, all the time in the growth stage, especially. Not really when you're, like, totally zero to one seed stage, your your goal is just, like, build one thing that works and sell it to anybody. That's, like, super hard. But once you've done that, then your goal is, like, okay, how do I how do I open up multiple business units and kinda build products that that support these business units? You're trying to figure out, like, over the course of a year, kind of, over the course of, like, two or three like, slightly broader over two or three years, but really in the course of each year, like, what do you think? Like, what do I think? Or what does Scott or Nini or, you know, what do we think like the top few things that are gonna matter are from like a deal standpoint and and from like a product standpoint? Like it's and it's kind of trying to feel that out and then investing in making sure we knock those out of the park while also, again, like supporting people and enabling people with conviction to keep working on the things that they have conviction in. Because sometimes we're gonna be wrong about what we think the things are that are gonna drive impact in that given year. So it's very much like a jazz, like, on the fly, Like, you're kind of, yeah, figuring out how to do resourcing in these things. Like but but it it I think it is true in defense that, like, you have a small number of deals that are gonna generate most of your revenue and you have a small number of products usually, like, relative to all of what you're working on that drive, like, the impact on those deals.

Hayley

Are there other ways in which your approach to building products has changed as the company has gone from you mentioned, like, being series a and, you know, just focusing on one thing versus now post series b, more growth stage. Like, are there other ways that your approach to building products has has changed?

Brett

I think I'm not particularly good at scaling products that are working. And so that is, like, like, that's where, like, the we have, like, some really good VP of engineering people on the team that are, like, really good at that and sort of, like, them to run with, like, roadmaps and how they want to to roll with things, I think is really important. I think the main change is, yeah, focusing on finding high conviction people and empowering them. Like, for example, for the the RF sensing bet that we've I've been that that is 99% not me, perhaps a 100%, in terms of like and that's awesome. Like, there's like a few people on the team that have been running it from like zero and are learning a lot of the things that like, you know, we learned in the earlier days but are able to do it a little bit quicker because they have they're surrounded by more support. And I think that is, like, how we're gonna need to evolve. It's gonna be it has to be a broader set of people that are making new product bets than just, you know, a couple.

Hayley

Which one of our new product bet areas are you the most excited about?

Brett

Yeah. I like a lot of them. I think, like, the the things that are most exciting to me right now are probably ones that open up radically different verticals than we're already in. And and those, to me, right now are probably cyber and probably, RF sensing. For cyber, we've kinda done some things that have, you know, are cyber adjacent and have enabled, like, certain types of operations with groups. And so we have some domain expertise and some user access and some reps are doing things there, which is great. We can build on that. For RF sensing, it's like wildly new for us. And it's not just about, like, sort of we're getting some reps that, okay, what does it mean to, like, actually build and prototype hardware and deploy that overseas and make sure it works in us to your environments? All that's, like, super important. We're also kinda developing expertise in, like, platforms a little bit. Like, we because we're we're putting these things on platforms and we're kind of learning about like what's in the market, what works, what doesn't work, what are like the requirements for some of the groups that we're working with. And I think RF sensing is interesting to me not in and of itself, but because it's gonna enable us to make more bets in, like, adjacent spaces. So I think those those two are are interesting to me right now.

Hayley

Beyond domain expertise, is there anything particular that you look for in product leaders when you're hiring for that type of role?

Brett

Such a hard role to hire for. I think for new product leaders, everybody has been grown internally to this point pretty much. I think for the the key things for product leaders, I think, are your ability to understand, like, decompose and deeply understand, like, mission problems and prioritize, like, bet on what mission mission problem you're wanting to solve. That's probably number one. Number two is, like, the ability to work with engineers to, like, get things going and test things and and, like, deploy those things to users. And the third thing is more like a BD function, like the ability to be compelling in customer meetings, but also partner with BD and customer facing engineers to, like, work together on deals. Those are three pretty different skill sets. And that's why it's hard to hire people externally that can just do that off the bat. It's pretty hard to hire like a leader and put them in that role. Yeah. We we've grown people internally to date, but we're we're definitely actively recruiting for folks that, have experience doing this and and have a lot of defense domain expertise specifically.

Hayley

Is there any area that Vannevar would never try to innovate in?

Brett

I think we should only make new bets in places that are maybe like one hop adjacent to us and that can mean, from a technology standpoint, we know, you know, some things about a problem and maybe we have some because of that, have some unique inside in like a tech area over here. That's, to me, is like a one hop or it can be within a customer group. We have really deep relationships with a customer group and we are kind of, using that to get to know a mission problem really well. Maybe it's a new tech area that we haven't worked on, but we have, you know, the right relationships and the and we feel like we have some of the right technical expertise to build something, that's like a good hop. I think trying to do something that's like two hops away, for example, I don't know, like ballistic missiles. Don't know, we would I don't know. Pick like something really hard and like very different than what we're doing with different economic buyers, I think that is probably a bad idea. But I think sort of over time, like, one of the reasons why we're focused on kinda getting making bets in different mission areas, like, meaning, like, across space and cyber and all these things, is so we can start to develop wedges in these groups and under kinda understand what their mission problems are so that we can, you know, more of the universe is one hop away versus two hops away, if that makes sense. Yeah. And that's like a long it takes that's a long game for us. Yeah.

Hayley

We talked a little bit about this in another conversation, but I wanna get more of your thoughts on the build versus buy equation when it comes to new products. Yeah. Is your opinion that we should always start by trying to build something ourselves, or do you think that it makes more sense to go to market and see if someone is already has a kind of finished solution?

Brett

I think acquiring components and partnering for components is a good idea. I think it's pretty rare that you can buy, like, for example, like through M&A, buy a a company that has like an end to end system and have that end to end system sort of live on in its current form. There's probably a lot of reasons for that but I think you kinda need to own like the engineering and like product vision and strategy for you to build something that's actually better than what other people can provide. It's really hard to outsource that. So when I've looked at M&A, like other companies that do M&A, for example, Anduril and Shield and others in in the defense space, the deals or the investments that they made that seem to have worked out are ones where they're getting access to programs and, like, unique customer access, not necessarily access to platforms. There are there's one exception that I'm thinking of, in Shield's case, but, for the most part, I am pretty skeptical that you can really build a better system without you yourself kind of organically owning, like, the technical vision and and product development. And I think in order for you to really do that in, like, a 10x better way, you kinda have to go through the pain of, like, sort of, like, inventing the thing yourself. I don't think it's something you can buy your way out of. I could be totally wrong here though. Think, like, many people would probably disagree with me.

Hayley

Yeah. Yeah. What do you think a 10x product leader looks like?

Brett

That's a great question. I don't know if there's one profile. I think that's the thing. Like, I think when I say crazy, I mean, like, extremely high ownership. Like, high agency. Yeah. Like, high agency and, like, irrationally like, are willing to do irrational things to make whatever they're working on work. I think that's, like, one key characteristic. The I think the other is just like good product leaders, I think, are way more outward focused than they're than they are inward focused. This is something that I think is very obvious when you're in a startup and you kinda like see this. But if you haven't worked in startups before, like, don't want a downward focused product leader that's focused on, like, process and engineering and, like, you want people focused on the best product leaders, especially for zero to one, are gonna be, like, almost a 100% outward focused. Like, talking to users, talking to customers going on-site, obsessing over, like, understanding the mission problem, not obsessing over like, you know, the process or whatever for how we build the thing internally. And I think the other thing that's key for product leaders that sort of I kinda already mentioned this, but it's like you have to be a very you have to be really active from a business development standpoint. I I don't know if this is specific to defense or not, but you're not going to know if you're on the right track unless you are trying to deploy and sell your thing, like, all the time in partnership with BD. It's just it makes it way harder to know if you're doing the right thing, if you're not, you know, deeply involved with with BD. So I think those are some of the things that I think about from a product leader standpoint.

Our mission is urgent

Join us to meet the challenge

We’re hiring for roles across the company.


Related Posts

EP. 03: Building Winning BD-Engineering Partnerships in Defense |
EP. 02: Hardware vs Software and Building Complete Systems |
EP. 01: The Case for Working in Defense Tech |