In this episode of In the Arena, learn how defense companies can close deals faster and build better products by getting business development and engineering on the same page. Vannevar CEO Brett Granberg explains why engineers should be in the room early, how forward deployed engineers shape both products and customer trust, and why time on-site with users drives the best results. Brett and Hayley also discuss avoiding the “services trap,” how to balance conviction with customer needs, and why cross-functional teams consistently win the largest defense deals.
“Customers are not always going to know how to solve the problem they have… it’s better for engineering to look for information about the problem than to look for customer ideas about the solution.”
- Brett Granberg, CEO of Vannevar Labs
Watch the full episode below, or listen wherever you get your podcasts:
Episode Transcript
Hayley
I'm Hayley, and I'm here with our CEO at Vannevar, Brett Granberg. Today, we are gonna look at how engineering and business development, or as we call it at Vannevar mission, just the mission vertical, actually collaborate in at a at a company like ours. So I'll start out by asking you just kind of level set. In an ideal world, what does a great relationship between mission and engineering look like?Brett
Business development and engineering partnerships are absolutely key for both product development but also for sales. We had a period of time where, like, the number one priority for us as a company was making sure that with every deal team that we had, there was a engineer that was partnered with a BD person and that they were working well together. And the reason for that is, like, when engineering and BD join forces for, for sales, you're you're gonna see a lot faster close times. Like for us, it was like three to six months. Deals were closing like, you know, multiple months faster and the deal sizes are also also get a lot bigger. And there's a lot of reasons for that. One of them is just and like credibility that, you know, having like a a good customer facing engineer brings to the conversation can be really huge and can allow you to kind of skip several meetings as you kind of go through the process. And then also, sort of like the storytelling piece, having like a BD person, an engineer, and then oftentimes somebody that's focused on telling the mission story, which might be either of them or might be more of like a product focused person. That trio of people just it's just like such a good tree when it gets going. So that's my macro take on like why like what, you know, why it's important. And think a lot of it, like, Palantir is really good at this, Andruil is also exceptional at this. Like, every big deal has, like, a very compelling customer facing engineer and a good BD person. What a good relationship looks like I I think, first, it kinda comes down to like the humans, you know, involved. I guess, like, on the engineering side, like, every engineer needs to be involved in sales. There there are, like, great product engineers that actually don't wanna talk to customers at all, but they're exceptional functionally, they're like very, very good at the function and that's fine. Like you want them to be working on product development. And then you have some engineers that are great engineers but just love like the mission and customer side of it and love like getting involved and talking to customers, that is that's like a good candidate for, you know, one of these engineering leads. So I think the first thing for BD and engineering partnership is you need, you know, you need like a engineer that actually wants to be customer facing and like wants to do, you know, user facing stuff and and gets motivated by that. You also need a BD person who is comfortable sharing the stage, I guess. I don't really know how else to put that, but is comfortable kind of pulling people together and letting others kind of be the voice or face of something in in in a meeting, and knows kind of like when to tap which people and what. Like, I guess from a BD standpoint, he's like a good quarterback who's also like lower ego.Hayley
Are there any leading indicators or I guess lagging indicators if you have them of what a broken relationship between engineering and BD look like?Brett
Yeah. I think, trust is the most important. Here's a bad example of what what like a breakdown would look like. If if BD is kind of, I don't know, in Slack or Jira or whatever, right, whatever systems people are using, just throwing a bunch of features at engineering that are like, hey, I met this customer and I want you to build y button on like z product, something like that with no context on like the mission side or the user side. And also no prioritization of like where does this stack with me. Like that is a in the engineers just kind of being inundated with these like non prioritized feature asks. I would say that's an example of like not what we're talking about. That's not what we're talking about here. I think the other, you know, bad examples like the engineers sort of distrust everything, you know, distrust what PD is saying. Let's say, you know, they and honestly, usually this comes to down to either communication or just like involvement. So, if an engineer feels like they're not being invited to these customer meetings to see some of these user problems first hand, you you might have like an initial lack of trust developed. So I think yeah. And then the other symptom is like, is when the BD person is going on these meetings, is the are there engineers with them? Is there any engineer with them on on, like, the most important meetings? That's a good sign of, like, is there a well functioning relationship here or not.Hayley
How early in the sales process, the sales cycle should mission or business development bring in engineering?Brett
When I approach early business development meetings, the most important thing for me by far is just getting whoever we're talking to. We call it, like, irrationally excited, like, just really, really excited about any mission problem that we can work on together. Oftentimes, that can involve, like, an engineer, you know, coming to a meeting and and, like, talking about a mission problem credibly. Sometimes it involves us doing Palantir does this really well too. Like, we will do, in some cases, like a couple like multiple weeks of preparation ahead of a meeting, if it's an important sales meeting, where we're trying to understand who are we meeting with, what missions do they care about, can we like find somebody on their staff to sort of understand how they think about a particular problem. And then we're maybe on the engineering side, just iterating, like testing some of our own ideas and building building prototypes that, you know, we then will bring to the meeting. And so if you're really trying to hit a, like, a home run on, like, a new product or a new mission problem, you know, like, having engineering involvement, like, well before the meeting actually happens can be, you know, really useful. It just kinda depends on, like, how much you're trying to invest in in in the outcome that you're creating.Hayley
Vice versa. How early should mission or business development be involved in product decisions? Brett: Yeah. So I think it's important to have, like, a human that owns, like, what the product vision is, like, what are we doing. And I don't think, like, kind of decision by consensus is a particularly good idea for new products. Actually, fact, like pretty much every product we built at Vannevar would not have been built if this is kind of product by consensus because you you just you need someone you need one person who's high conviction and has the right domain experience to be making calls on what to build, it's not super productive to have like a committee. But that person needs to be whoever that is, could be a BD person, could be not, could be an engineer, it could be a mission strategy slash product person. But whoever that person is needs to have ground truth on like what is going on from a user standpoint on what they're building and also what's going on from a business development standpoint. So if it's not the BD person, that person needs to be really closely partnered with BD and going to all the important sales meetings. Otherwise, they're not gonna have this signal to figure out like, am I iterating in the right direction or not. And then I guess maybe the last thing I'll say is, like, feedback from BD to engineering is, like, always welcome. Like, that is important to have happen regardless of, like, what the circumstance is. But it it's not in my mind, it's like the most useful feedback is about mission problems and context, it's not about specific features, if that makes sense. And it's more about it's, you know, kind of the engineer and sort of the product person, if if there's a person on the team that's playing that role to make the decision of, yes, we're gonna do this or not.Hayley
Yeah. More like the what versus the how.Brett
Yeah. Exactly. Yeah.Hayley
You mentioned about someone being responsible for the product having high conviction. How do you balance that conviction aspect with a requirements or being more customer centric?Brett
In terms of inventing something new, that's so hard to do that nothing new ever gets invented unless there's one person who's crazy. It's like, I'm just gonna do this. I'm gonna make this happen regardless of, like, how, like, what anybody else thinks of it and whatever. Like, you kinda need somebody who's kinda crazy with a lot of conviction, hopefully with a lot of mission and user domain knowledge that's that is taking a bet on something. That's like required. So that's like necessary but not sufficient for that to become like an actual biz like well functioning business. What you need on top of that is that person also needs to be really plugged in from a business development standpoint and have some BD chops themselves usually to be going to customer meetings, pitching the thing that they have conviction in and getting a read on like, does this Is this resonating or not? It's kind of a It goes back to like have conviction on the mission, not necessarily like the solution that you're trying to build. And so think about it as like inventing the product requires that you need to be iterating on like the mission problem and being creative on that mission problem. And you also need to be trying to sell the thing because it's like not sufficient to build something really cool. For us, like we have to build something that's that solves a mission problem and also we believe can generate like a few $100,000,000 in revenue when it fully scales. And so whoever is making that, driving that from a product side needs to be having all that context in their head and it's like super hard to do. But just kinda getting in there, being in the meetings and like building all that context and conviction on where to bet. It's a very hard role.Hayley
I wanna ask, kind of drill down a little bit into that, in like shiny object syndrome. Like, how do you determine what should be a longer term engineering priority versus what customers and like the BD team really believes in right now?Brett
I think having a long term engineering roadmap for zero to one products is usually a bad idea. In fact, it's usually a terrible idea. And I think the reason is you actually don't know until you are really, really confident on deeply understanding the mission problem and and pretty like start to have some traction on something that you've built where you feel like you can kind of see ahead, you know, six to twelve months, that takes that's a that's a high bar to even get to that point. But until you get to that point, having a long term roadmap is completely useless because you're gonna be planning for things that like don't matter. So in the beginning, any like your whole iteration cycle should be around customer touch touch points. Like it could be beauty touch points or user touch points, but like, your whole roadmap should be based on pretty much that. It should not be based on like, oh, I think that it'd be cool if like we, you know, this, you know, we did like computer vision or what ML on this thing. Like, that should not be part of the roadmap.Hayley
We need a dark mode.Brett
Dark mode. Yeah. Like, dark mode's great. But I think it's like that yeah. You kind of earn the right to have a long term roadmap once you've hit product mission fit. But until you hit product mission fit, where you're actually people wanna buy your thing, you've like made some sales, you have users regularly using whatever product you built, it makes zero sense to have a long term roadmap.Hayley
I used to work at Splunk and I remember the day we rolled out I did business development there. Remember the day we rolled out Dark Mode.Brett
Oh, nice. It's a big day.Hayley
How should engineers be thinking about customer feedback, especially when it's like either fuzzy or not super relevant or premature or contradictory?Brett
Customers are not gonna know how to solve the problem they have. So them giving you kind of like feature requests or product ideas, sometimes it's really useful. Most of the time it's not as useful because they don't understand everything that we can possibly build. And so it's better from an engineering standpoint to look for information about the problem than it is to look for, you know, customer ideas about the solution to the problem. Yeah. I think it's just like a 100% focused on like what is understanding the problem and then iterating off of that. The other thing I'll say is like getting on-site, having engineers go on-site is like by far the most important thing. I think you can do it from, like, a zero to one product development standpoint. We had a trip, I think it was two, three week maybe two weeks ago now, where we used the you know, there was, like, a report meeting. It was, a mission user focused meeting. We the engineering team for one of the products we were it's a zero to one product, built a bunch of stuff for that meeting. We get on-site, the engineer, like, first hour, you know, we're showing them stuff, nothing's really resonating. It's, you know, it's kind of a sad meeting. And then we the sec the the next two hours, we hit this the new feature that the engineer just released, like, the night before we got on-site and started running actual mission examples through hit the thing that he built, like, the night before. And you could see him just getting more and more energy as they were kind of, like, oh, we're act like, doing mission planning in front of us for like a thing that, you know, based off a thing that he built. And I think what ends ended up happening was on that customer meeting, we discovered that they had a different type of data that, you know, we figured we could ingest and enable one of the an operation that they're running to run, like, more quickly. And because the engineer was on-site and he saw them do actual cool mission things and he also saw the problem that they were trying to solve firsthand, this new problem, he he was, like, super amped to solve it. And so they gave us that data later that afternoon and then he built the thing in, like, whatever, six hours. Then we released it that night and then we went back on-site the next morning and that's the kind you know, it was it was it was on it was like what, mattered for that mission, you know what I mean? And so I think there's like a really positive feedback loop that can happen from like an engineering standpoint where you're on-site, you're seeing what you're building actually having an impact, you're actually getting better information that tells you what you need to build, you're not you're not relying on like a product manager to like, whatever, be it sit in between you and the user, but you're first hand getting that knowledge. I think that is kind of like gold, like gold standard for a zero to one product development.Hayley
You touched on it a little bit. I think that our forward deployed engineer role slash model is a really good example of BD and engineering kind of coming together. Yeah. Can you talk a little bit about what that looks like at Vannevar?Brett
Yeah. So four deployed engineers are like, have two job like, jobs, but, like, two main jobs. That's probably what makes the job hard. One job is around zero to one product development. So, you know, hey, there's like a new mission problem, it's maybe pretty ambiguous, it doesn't quite fit like the exact mold of a current product we're working on. Let's deploy some engineers with some mission folks and see if we can make a product, like invent something new that like solves that mission problem. That's really hard in and of itself. Like it's you're like it's like special engineers that can do like invent something from scratch. It's also a different set of engineers that are equally special and scale the thing that you invented and have to like rewrite the whole base and all that stuff, but So that's a hard job. The second part of the FD job is more just lending I don't even know how to like, getting people really excited and lending technical credibility to what we're building in meetings with, like, senior folks. Could be, I don't know, like, yeah, like a one star that wants to talk one star general that wants to talk about AI or whatever it is. And having somebody in-depth who can tell tell them how we're, you know, whatever, applying machine learning to signals processing for the RF hardware product, that can just that terrible credibility can get people really excited from a from a customer ambition standpoint. So, yeah, those are the two roles that they play. It's like, one is like inventing new things, which is really hard and then there's like a completely different set of skills, which is, like, how do you get a customer group, like, really a senior customer really excited about something.Hayley
So at Vannevar and I think in defense tech in general, there's kind of a trap that or I only call it a trap because of my VC background, so, like, maybe other people don't actually care. But, we built a lot of custom solutions for customers. Yeah. But we're not a services company. And the reason I mentioned, like, investing background is because that distinction is important when it comes to, like, multiples, for example. How do you kind of square that where, like, we are building custom solutions but we're not a service services company?Brett
Yeah. Any product that we have to that we make, we have to believe can hit a few 100,000,000 in revenue. That's really important for us being able to believe that what we're building can scale to like a business. So anything that we don't think can hit 300,000,000 as at the floor, we don't we're not gonna invest a ton in trying to scale. But it you know, to me, doesn't really matter if that 300,000,000 is coming from, you know, like three customers or if it's coming from 50, like the the that that's enough to build a business around. You know what I mean? And I think, like, when we first raised the seed round, that was like a controversial thing. I don't know, like that's controversial for some reason, like, hey, you know, we build a thing and it generates 300,000,000 in revenue, like, is that a is that a tech product or not or is that services? Like, I think, yeah, in defense you have to you can't really think about it that way. In defense, your job is to build multiple business units and multiple products that can cover like several really important missions. And so you have to be way more aggressive about the product bets that you're making and the mission areas you're going after. And as long as you are as long as you believe that the whatever you're building can scale to a few 100,000,000 in revenue, you're you're fine. Like in terms of it doesn't product services like that distinction doesn't really matter. So I think the risk that I think we have as a company is actually we because we weren't, you know, like, defense wasn't as popular when we started, we we didn't have, like, a ton of venture capital funds to, you know, like scale in some crazy way and so we actually were super disciplined in how we scaled. Very focused from a product standpoint, only had one product for about three and a half years. And that was great because it you we could keep a small team, we were able to achieve profitability if we've been profitable for about two and a half years. It's not in our DNA to make tons of product bets. And so I actually worry about the thing that I worry about is not like, are we gonna make too many product bets, the thing that I worry about is are we gonna make too few? Like, are we not gonna be aggressive enough in terms of the missions that we go after? And I think that's largely gonna be true for most I could be wrong, but I think that's largely gonna be true for most successful defense technology companies. Like, the people that succeed are gonna tend to make more aggressive, broader bets, like multiple different areas that they're going after. In ten years, the ones that are maybe gonna fail are gonna be maybe a little too narrow. So I think that's kind of how I think about it.Hayley
Have you ever seen kind of a mission or business development person go rogue without looping in engineering? And what did that look like?Brett
Oh, 100%. I think this happens everywhereHayley
You're like, yesterday?Brett
Yeah. Every every every company, I think, yeah, experiences this. But I think, like, when that happens, I think the first thing to think about is, like, okay, do I have the right people on this team? And that could be, like, okay, on the engineering side, do I have the are these folks that wanna be sort of customer facing and and, like, user deployed? Or are these people that are more comfortable working, you know, like, on a product, maybe a little bit, you know, removed from from the user. So first thing is like, okay, and then same with the BD person. Is this is this person again, our biggest deals, we we only win our biggest deals with like a team effort across functions. It's only BD plus engineering plus mission, you know, product or mission strategy. That combination of functions has resulted in our biggest deals. And so is the BD person that's leading this deal, are they cross functional or not? And does that matter to us? Does it matter that they're pulling together the, you know, multiple people across functions? So your first area, like, way to diagnose it is just like, do I have the right people on the team or not? You know, if you do, if not, then you need to, like, figure that out. You know, like, yeah, make team changes or or just, like, accept sort of where across all the things you're working on, where you are comfortable not having that relationship work as well. If you do have the right people on the team, then it's probably a trust issue. It's like, who are you know, what what is it about these two individuals relationship that's like making it difficult for them to work together? Can you get them in person, like either at a customer site or at an off-site? Just get them in person to do anything. And then the other thing I think about is like when a team is not working particularly well, often like people just generally wanna like win, like feel like they're on a winning team. And so how do you help that team just get like one win? And I think tip, like, once teams feel like they're winning, it's sort of almost like a self perpetual like motion that they get into and, you know, it's like trust and everything, like, kinda comes together a little bit more. If you have a team that feels like they're losing all the time, then like, that it makes it a lot harder. So just how do you set that team up to win? I know these are like very high level, but that's sort ofHayley
Yeah.Brett
Some of the levers that I would look at if there was a that type of dynamic going on.Hayley
Yeah. The momentum.Brett
Yeah. **Hayley:** So at the beginning of now, today, you, Nini, and Scott are CTO, and Nini's our president and she runs Mission. The three of you run the company together. In the beginning, when it was just you and Nini initially co founding Vannevar Yeah. How did you make the distinction where you would kind of mostly oversee product and Nini would mostly oversee business development? **Brett:** I honestly have no idea. Think we just yeah. I I honestly think it's more like jazz, I guess, that and I think this is true even for today, like, sort of the best, like, leadership teams that I it's maybe, again, like, not, like, total expert in this, but I think the best leadership teams that I've seen in defense, people that I, like, admire most are generally cross functional. So you have a, like, a CTO that's also really good at BD for some reason, as Scott is. But also, Brian Schimpf, when he was at Palantir, he was he was that. He was a CTO that was really good at business development and and mission stuff. Or you have, like, a BD person that's also, like, cross functional in in other ways. So I think for Nini and I, when we just got started, it was just, alright, we're gonna try to make we're just gonna make this work. Whatever it takes to make, you know, Vannevar work, we just did that. And so it turned out that, yeah, I spent more time on like the product and engineering side and she spent more time, you know, lining up customer meetings in the early days. And so it just so happened that she was, you know, organizing like tons and tons of demos and running tons and tons of demos. Uniquely amazing at it.Brett
Yeah. Tapping into like her network to, like, make all that happen and then figuring out how to, like, grow beyond that and all that. And I was just iterating and making tons of mistakes on, like, the product side of, like, how do you, yeah, like, organizationally set the team up and then also, like, how do we think about product development? Yeah. So I'd say it was not like a we never sat down.Hayley
What's your advice to a new general manager or engineering leader who's trying to build that trust with the other side?Brett
It really just comes down to like winning together. I know it sounds like, I don't know, like, not very specific, but it really is like, go like, go to a customer site and, like, rush a customer meeting or a demo or something or, like, with or deployment with with that counterpart. The strongest relationships I think I've seen develop at Vannevar are from that. It's from just people that have worked together in usually like difficult circumstances and then one like succeeded. And so I think it's more about just, yeah, be like mission and user oriented, customer oriented and then just go do the thing. Yeah. That's been, yeah, I think the most useful. Yeah.
