How to land and convert your first defense pilots
Published by Nini Hamrick, President at Vannevar Labs
Part Two in our series, “How to Build a Defense Company,” focuses on getting your first defense pilots and securing meaningful revenue. You can read Part One here on inventing new defense products. Much has been said about how hard it is for new startups to get their technology funded by the government. We agree. It’s hard. But it can be done — if you partner with the right Department of Defense (DoD) teams, generate operationally relevant mission wins, and align to DoD program office objectives.
I co-founded Vannevar and lead our government-facing team. My first experience trying to win defense pilots was in 2020 after leaving government as a GS-13 intelligence analyst with no private sector experience. I learned many lessons the hard way about how to bring together mission, budget, and contract into a deployment that I want to share here.
For the Vannevar timeline, we founded the company in 2019. By 2021, we reached $3.5M in annual contract value (ACV) with the DoD. By 2022, we reached $25M in ACV. By 2023, we reached $49M in ACV. The first couple of years of Vannevar were about figuring out how to win and convert our first pilots and how to build initial relationships with program offices. By no means do we know everything here, and much of what we’ve learned also came from friends and colleagues at places like Palantir and Anduril. We still have a lot to learn but wanted to share what has gotten us this far.
The Theory of Winning and Running Pilots
I. PLANNING PHASE
Mapping end users and program offices
Arguably the most important work you need to do before pitching is to develop a theory about which program offices and which end users you’re trying to deploy your technology with.
Program offices are incredibly important, and if you’re new to the defense space, they are the most critical component for you to understand. Program offices own the lion’s share of the DoD’s budget for technology through large, well-funded programs to build and deploy new capabilities. You need a hypothesis before starting a pilot about how you will partner with the end user group to secure the group’s commitment to expose pilot wins to program managers (PMs) in this program office to establish how these outputs might fit in the PM’s portfolio and secure a path to deploy your products long-term.
If you are not developing and refining your program office hypothesis while running the pilot and are only focused on the end users, you are setting yourself up for failure on the conversion. Typically end users and mission groups will not be able to buy and sustain the deployment after it ends without a program office partner.
Your program office strategy should inform your choice of end users. To engage PMs — and create the foothold and visibility needed to secure a follow-on deployment — your end user group needs to have relative importance to PMs that would sponsor this deployment. We’ve found two sets of DoD mission groups are more likely to get visibility for their pilots with program offices:
1) Service components of the geographic combatant command that are executing real-world missions with ties into their parent services,
2) New force design units exercising new authorities or operational concepts that often incubate future requirements and capabilities for program offices.
To demonstrate how this planning process works in practice — in June 2021, we started mapping out program office and users within a conventional DoD service. Will Golinkin — a highly motivated intern at the time coming out of business school who was previously a USMC communications officer — ran this process. He started with his network and led dozens of conversations and demos to map out the program offices with emerging or existing requirements relevant for our product and groups of users that those PMs might support.
This part of the process can feel like a grind because, well, it is. When we are in this stage, we are asking for introductions to literally anyone willing to talk to us and mapping out the org chart in a tool like LucidChart.
Pitching mission
Once you’ve mapped out the end user groups and PMs you think make sense for your product(s), it’s time to start approaching them. The most important part of landing defense deployments is building a product that people actually want to buy. See our “How to invent defense products” blog for some things to think about here.
It’s so painful for your government counterpart to go through the procurement process that they have to be irrationally excited about what you are selling. It’s a small miracle every time a government customer successfully navigates procurement to buy from you.
To create this level of excitement, we “pitch” the mission — not products, widgets, or features. Our goal is to show in the first 10 minutes of the meeting real examples of how we can (or already are) impacting the group’s mission. If we show up and list out features or talk about what our buttons do, we’ve failed. No one cares about your product until you’ve proven it is worth their time on the mission nor should they.
Doing this well requires serious preparation.
Before meeting with a new group, we talk to as many people as possible to try to understand their mission. Once we have some understanding, we “dogfood,” meaning we use our products ourselves until we understand and can demonstrate how we can impact their mission today. Often this takes us a week of prep and 15+ hours of product prep time. But it’s worth it. At the very least, it ensures that the DoD group we’re meeting with gets something useful out of the meeting.
The pilot triad
Who you bring to the meeting is equally important as what you present. It should not be a traditional salesperson. At Vannevar, we developed a ‘deployment triad’ concept: a growth person, a product-oriented mission strategist or product manager, and a senior engineer — all of whom are mission focused.
The mission strategist’s job is to deeply understand the group’s mission and demonstrate how what we build supports that mission with compelling demos and mission examples. The engineer’s job is to bring technical credibility and answers to questions about security, integration, and architecture. The growth person’s job is to align our team to the DoD group’s mission priorities, ensure we’re talking to the right people on the government side, and develop a strategy for working with the group on procurement if they are interested in deploying with us.
If you already have some DoD deployments, your most effective pitches will not be from you but rather from your DoD users who pitch the missions they’ve accomplished with your product either with you in the room or separately government-to-government. Insight from forward deployed users can be especially helpful for headquarters units if you’re able to link them up, even if they don’t end up wanting to do a deployment with you.
For the conventional service mentioned above, after a month or so of pitches, we identified a highly motivated Major in a forward deployed unit. His team was forward deployed with few capabilities developed for the new intelligence mission they were being asked to achieve. We pulled together several demos on that mission and showed it to several people in his unit and started having regular conversations about how we could help him and where we needed to improve the product to support his users.
After another couple of weeks, he became excited enough to run a pilot.
In parallel to the user track, we identified a Lieutenant Colonel in an innovation unit that had the authority to run capability experiments for this service. We then paired up the Major with the intelligence capabilities problem with the Lieutenant Colonel with the authority to sign a 3-month vendor demonstration agreement (aka an unpaid pilot). In the early days, this is a big win.
II. RUNNING THE PILOT
Once you’ve created pull from the mission group to test and deploy your product, the next step is running a pilot. Don’t worry if the group you’re working with doesn’t have access to funding for a pilot. You’re solving for speed to get the pilot started to capitalize on this pull and make an immediate dent on their mission, and often, tactical or operational groups that own mission have limited funding. If this is the case, running a no-cost pilot through a Vendor Demonstration Agreement (VDA) for speed can be the way to go with the blessing of the group’s acquisition and/or requirements team. These are common agreements that your DoD group or your own lawyers can help you draft.
Generating mission outcomes and building champions
Once you’ve launched the pilot, you need to deliver mission outcomes within days or weeks in mission areas that get briefed to senior leaders and drive operational decision-making. Our board member John Doyle — founder at Cape, formerly Palantir — told us the goal of a pilot is to “teach your users to produce outputs that realize the vision of strategic decision-makers.”
Erin Biggers, senior director of mission success at Vannevar and a former US Air Force intelligence officer, reminds our teams before a pilot launch that the timelines for generating mission outcomes can be punishing. If your pilot hasn’t produced operational impact within the first month, users and their bosses will understandably start to move on.
Erin recommends tying your pilot to a high-visibility, high-operational period for the DoD group, such as a large force exercise, where the group brings concentrated attention and clear mission objectives that help drive a tempo of outcomes, including briefings to decision-makers.
As an example of generating mission outcomes, Aubrey Manes — senior mission success lead at Vannevar and a former naval intelligence officer — was working with a group of users on one of our first pilots, and she noticed the analysts using our first product Decrypt to measure the effectiveness of their high-profile operations and manage the signature of their low-visibility operations in the physical and digital environments. Specifically, the users detected foreign actors publicly reporting on operations that they did not intend to be visible.
These users were irrationally excited about this outcome — they were charged with these missions but had never been able to produce these outputs before. They started incorporating data from our product into their pre-mission planning, briefing their senior commanders on the impact in post-mission storyboards, and recommending changes to their unit’s tactics, techniques, and procedures based on what they were learning from this experimentation.
Operational leaders in this group began to take notice of the enhanced pre- and post-mission insights they were getting from their analysts on missions they cared about. As the proof points piled up, these Colonels became champions that this pilot was filling an unmet mission requirement for their group.
Deploying forward
We also frequently deploy our pilot triads overseas to Europe and Asia with our users to build mission wins and credibility quickly, especially if it’s a new mission domain or user group.
Anduril and Palantir do this really well. Talk to enough people in DoD, and you’ll hear stories from the early days of Palantir when they sent engineers and deployment strategists to forward operating bases in Afghanistan to support the mission. Anduril frequently deploys their product teams to austere locations to test new products in similar ways.
For the conventional service pilot, Will — who is now a growth director at Vannevar — working with Aubrey on the user engagement side traveled to four bases in the US and overseas. Embedding forward made it a lot easier for them to deploy over a hundred user accounts in a short amount of time and was the only way they could ensure our product was driving real value for the pilot group. They also figured out our product wasn’t working well in forward environments, prompting our engineering team to optimize how we rendered our product over low bandwidth.
This pilot created significant user demand at the Major level and below. Will and Aubrey then channeled this demand up the chain of command to the Colonel level. Building relationships at the Colonel level led us to spending time in person with one particular Colonel talking about his vision for intelligence missions in this service and developing new capabilities based on his vision. We also brought in the Colonel’s users so he could hear from them about the wins they were generating.
iii. CONVERTING THE PILOT INTO A PROGRAM PORTFOLIO
The outputs you demonstrate through the pilot must resonate not only with senior operational leaders, but also with PMs advancing the goals of large, well-funded DoD programs.
I learned this the hard way. In one of our first pilots, I over-indexed on generating user traction as the signal of whether we were on track to convert the pilot into a deployment. We propelled this user excitement into a pilot outbrief with the 2-star chief of staff of the organization who was equally excited by the pilot’s novel outputs. At the end of the brief, he turned to the PM in the room and asked him to figure out what came next for the pilot (This is a typical outcome of a meeting with a general officer — they do not take on acquisition or programmatic funding decisions).
It turned out the outputs we’d generated with the users in the pilot had no relationship to the PM’s objectives. The PM was charged with building a large-scale government-owned software system through a multi-year, well-resourced program, and I had made no effort during the pilot to define how our work with the users fit into this vision. The PM understandably opted not to convert the pilot. He didn’t take this decision because he was callous to the end user feedback; the PM’s job was to support specific DoD requirements and his investments needed to directly support these codified objectives.
Fortunately, we were able to find a different PM with the incentives to convert this pilot, but the experience taught us that we needed to align pilot outputs to a program and involve PMs in the pilot as much as possible. User traction and operational leader buy-in is necessary but insufficient if you’re aiming to build a long-term deployment, not just a series of pilots and experiments.
Kyle Erickson — Mission Operations at Anduril Industries, formerly Palantir — told me he thinks of his job as “developing a rich and sophisticated model of a PM’s inner life. What motivates them? What do they see as the upside of working with you? What do they perceive as risks? Why are they doing what they do? Without that — you can’t understand how to direct activities on a pilot.”
PM takes a bet on your pilot
Converting your pilot into an annual deployment is the culmination of the roadshow with users and O5 or O6-level champions to find the right PM who has the program objectives to care about the pilot’s new capabilities and working with the users to fit the pilot outputs into the PM’s vision. This roadshow may include the users attending the PMs’ working groups on requirements and documenting their unmet needs for the PM through capability needs statements or other requirements documentation.
DoD PMs have very little flexibility with their in-year execution funds to take bets on interesting new concepts they want to prove out because of the DoD budget structure. That means when they do take a bet within this limited radius of action, it’s a vote of confidence.
To do this, they need to believe that what you’re building with the user group has the potential to significantly advance the future capabilities of their program. As Scott Philips (Vannevar CTO, formerly STR and Palantir) points out, “Most DoD PMs don’t wake up in the morning excited to go buy more software licenses. They are motivated by building large-scale, future-looking capabilities that will significantly advance national security.”
For the conventional service pilot, Will and Aubrey demonstrated the pilot wins to PMs in this service alongside the users and expanded our relationships with different program offices over a three-month period. Eventually, they identified a program office with the budget and mandate to deploy capabilities in this area and channeled the end user demand and O6-level advocacy we had to this program office, which led to an initial $2.7M deal. The following year, we expanded this to a $13.5M deployment by generating more mission outcomes and building stronger relationships with that program office.
The important part here was not the initial funding size, but the champions and PMs that embedded the pilot in the requirements and budget process for these groups and secured a foothold for a longer-term deployment.
Landing the deployment on contract
Once the PM has decided to take a bet on you, mold yourself to whatever contracting route the PM tells you creates the least friction for their program. There are advantages to using an OTA, SBIR Phase III, or some pathway that you can prime to land the deployment. If you have one of these in place already, then it’s just about convincing the PM and their acquisition counterparts that it’s the best value for the government to use it. But if they have a clear preference for a contract vehicle, happily use it, even if you’re subcontracting to a prime.
We learned early on not to let using the “right contract” become an obstacle to working with a PM who is taking a bet on you inside a large, well-funded program. You can shift contract pathways for future spending once you’ve established a relationship with that PM and the acquisition officers they work with. For instance, our first pilot conversion was as a subcontractor to a large systems integrator, and it still created the foothold we needed to develop several other deployments on our own OTA.
The next part of this series will focus on how to grow these deployments once you’ve landed them. Until then — godspeed, and reach out to us if we can help.
