Inventing products in the defense space ain’t easy: user problems are opaque, getting approval to test your product with users can take months, and you don’t really know if someone will pay for your thing until you’ve battled the bureaucracy for 6–12 months.
But alas, if you’re reading this, you’ve decided that getting better technology into the hands of the public servants that keep America safe is worth the struggle. This is part 1 on “how to start a defense company” with some lessons learned from defense tech companies Vannevar, Anduril, and Palantir.
Your 0 to 1 product objective—build something that gets people irrationally excited
In defense, your customers need to be irrationally excited by what you are selling. Unlike enterprise or consumer sales, your customers have to sign up for 6–12 months of pain to get their bureaucracy to buy your product. They will not do this unless they think your stuff is so useful that it will 10X their ability to do their job and / or get them promoted. So that’s the bar you need to hit.
This does not mean your v0 product needs to be perfect. But it does mean you need to be solving an urgent problem. The v0s of our first product at Vannevar— Decrypt, Anduril’s cUAS product – Anvil, and early Palantir Gotham were all launched with a limited set of features that solved narrow but important mission problems well. Because of the mission value, DoD customers went through the pain of deploying these initial prototypes and trusted the product to improve along the way. Your 0 to 1 product goal is to get here.
So, where do you start?
Get to the users
Job #1 for you if you’re trying to invent a new defense product is having a deep understanding of a top 3 mission problem for the government. This is because 1) you need extreme urgency to get any new technology deployed, and 2) you need to believe that each product you build can be sellable across DoD and get you $100M++ in ARR or $1B+ in enterprise value (if you’re a VC backed company).
Sounds tough. But fret not, there’s a tried and true method for figuring out where to bet: go meet people doing the mission. The fastest way to get this insight is to pick some problems and watch people do their jobs. Preferably on a military base. If you’re looking at UAVs, find DoD people that will let you watch them operate UAVs. If you’re looking at Space, go watch people analyze satellite imagery, etc. (See below if you don’t have a defense background — TLDR is you need to combine top tech talent with top military talent)
To stress — you need to watch them do their jobs. Sitting around a DoD conference table and asking them about their jobs doesn’t cut it. You’re going to understand 5% of what matters. You need to know more about what they do than they do. I’d trade one trip to a military base to watch a few users do their job for an hour over a hundred user interviews and months of smart people pontificating without contact with the mission. Do this, and you will begin to understand what problems are urgent in the area you’re targeting.
Pick an urgent problem
Urgency is everything. An urgent problem + a v0 prototype is infinitely better than a non urgent problem and a perfect solution. Here are some examples:
Anduril Anvil. By late 2016 / early 2017, ISIS started using cheap commercial UAVs (drones) to drop explosives on American and ally soldiers in Iraq and Syria. DoD had many solutions for countering large multi-million dollar aircraft (e.g., bombers), but could not counter a ~$200 DJI drone. This was a desperately urgent problem that Anduril decided to tackle.
Scott Sanders, one of the founding members of the Anvil team, describes early Anvil development:
When Anduril’s engineering team came up with the concept of Anvil — we were able to go from prototype to a full system test in less than 6 weeks with 45 Anvils at a Government Test Event. Anduril proved at that event that the 6 week, 60% solution, was more functional than competitors and was able to secure a prototyping contract with DoD. Three months later Anduril deployed a full end to end system to a combat zone and that started the road to scaling a counter UAS program of record.
(Scott’s now advising DoD tech startups on go to market strategy at A31 advisors)
Anduril’s Anvil work led them to win their first ~8 figure contract which led to their recent $1B contract ceiling award for SIP at SOCOM. If you pick an urgent problem, you can deploy a 60% solution, iterate, and win the space.
Vannevar Decrypt. After many months working on a non-urgent Arabic OCR (optical character recognition) problem, we invested a small amount of engineering to test a v0 intel platform called Decrypt for what we suspected was becoming a top 3 problem across DoD.
Decrypt v0 had only one primary feature — search — covering one small data source and was prototyped with a 2 person engineering team. However, Decrypt worked well enough on an urgent enough problem that there was demand to get it deployed quickly. People started interrupting demos to say things like “I need this on my deployment now”, “ How do I get this to my unit”, etc.
Our first Decrypt sale of a tiny~$25k, three month pilot with four users occurred shortly after we started demoing. To our great delight, these users started generating real intelligence wins that got briefed up to senior people in government despite it being a fairly limited prototype. As we improved Decrypt, we were able to take over more and more of their workflow, which let us convert that $25k pilot to a $1.3M contract in ~4 months.
If you can quickly deploy a 60% solution on an urgent problem, you’ve got a good chance of winning. Conversely, no amount of product optimization will save you if you’re targeting a non-urgent problem, e.g., pushing an over-optimized Arabic OCR product as the counter terrorism fight was winding down. If you sense a lack of urgency, move to the next problem.
Common mistakes for identifying urgent problems:
- Using program offices, industry days, or research / innovation groups as the source for what’s urgent. Because of how DoD requirements processes work, these groups are typically focused on problems that were urgent 2–5 years ago but are likely less relevant today. These groups are invaluable partners in getting your first contracts stood up, helping you navigate the procurement process, and getting your product in the door. But they are often multiple steps removed from your users.
- Spending time thinking and researching vs. being on base with mission users. Your initial approach is going to be wrong, and you spending months spinning on a bad idea in a vacuum isn’t going to get you closer to building a kick ass product. The only way to do that is to get in the trenches with the people doing the mission.
Pick a top 3 problem across DoD
If you’re a venture-backed company, you need to pick a problem big enough that will generate >$1B in enterprise value per product if you solve it. Translated to DoD contracting speak, this means you have to be confident that solving the problem will allow you to win multiple >$100m / year programs of record across multiple services in DoD. If you’re not sure that this will be true, you’re probably picking too small of a problem.
We think about new product development at Vannevar as placing bets in areas that we think might be top 3 problems across DoD. We launch v0s of products to get wedges into user groups so that we can understand these problems better than everyone else. This allows us to build the product that takes over the most workflow and ultimately lets us win. Starting small and launching quickly gets you the info you need here.
Once you’ve got a candidate for a good problem area, you can start the fun part:
Invent a thing that people want to buy
When you’re starting out (especially if you haven’t built a product from scratch before), you want to use iteration cycles to understand the problem better than anyone else. At this phase, you are iterating to become smarter on the problem, not to optimize a specific solution. When you start on a new problem, you know <20% of what’s necessary to build the right thing, and it’s very easy to get trapped iterating around a local maximum, meaning something that seems like the best answer but, in fact, is meh. You can think of iteration cycles as ways to identify the candidates for the global maximum.
Your focus should be doing the least amount of work necessary to validate or rule out product hypotheses to get you closer to seeing the global maximum solution. This may mean writing 0 lines of code. The less work you do, the faster you can iterate. Iteration speed matters because your first several product hypotheses will be wrong. Your goal is to be wrong for a shorter period of time.
Iterate and dogfood
There’s plenty of writing on building and iterating on MVPs, so I’m just going to address the components that are unique to defense.
In defense, it’s sometimes hard to get your product to users before you’re on a contract. You can create significant iteration speed advantages for yourself by using your product in the same way that DoD would use your product as a substitute for real DoD users. This is called “dogfooding”. Here are some examples.
Vannevar. Before we launched Decrypt, we had former intelligence officers on our team use Decrypt to perform intelligence analysis on the problems our future users were targeting. This gave us a better sense of where to take the roadmap but also made our first sales a whole lot easier as we could demonstrate immediate mission value to each groups we were pitched. We’re repeating this dogfooding process on our second product right now with success.
Anduril did live field tests of sending people and vehicles around their first sentry towers to see if their product would pick it up. They ran these tests almost every day with engineers involved. This allowed them to push code changes sometimes that day until they had a product that worked for the mission. Another benefit of this is they built an extremely compelling demo, which they ingeniously used to court VCs and potential customers by flying them out to the desert and strapping them into VR-goggles.
Dogfooding and customer pitches should be informing your iteration cycles. Repeat until people interrupt your demo to try to buy the thing. Once you have that, you’ve got your first candidate for a kick ass product.
Additional things to remember:
- You should be doing the least amount of work to test your hypotheses on each iteration. Don’t do what we did for Arabic OCR. We spent~6 months of engineering time optimizing OCR models for different customer demos before realizing 1) no one wants OCR enough to actually buy it, and 2) we could have come to this conclusion in the first month by using Figma or powerpoint mockups that show a demo of OCR without actually building it. Yikes. Use figma.
- Don’t fall into the trap of telling yourself “if we just had X feature, people would surely buy our product”. If people aren’t interested in the core functionality of your product, frilly features aren’t going to save you. You’re not at a global maximum. Stop optimizing a bad product and go back to the drawing board.
Product team composition for this stage
You don’t need a big team to get to product market fit in defense. It’s the combination of top tech talent and top military talent that allows you to win.
We got to initial “product market fit” with our first product with ~2 engineers and ~3 mission / use case people. For our second product, we launched v0 with 1 engineer and ~1 mission person. Anduril’s cUAS program was similarly started with ~1 engineer and ~1 mission person. A small team with quick engineering prototyping + deep domain expertise and access to users can get you the kernel of product market fit infinitely faster than a bigger team of the wrong composition focused on the wrong problem.
Plenty has been written about the product and engineering side of this, so let’s talk about the military talent / mission part of defense product development.
Having mission domain expertise on the product team is absolutely critical. The role of a mission person in DoD product development is to: 1) guide / prioritize iterations of the product with strong user intuition that may come from having direct problem experience and 2) provide access to users to test product iterations. Mission expert needs to have a say in product prioritization.
DoD and the IC are ripe with brilliant mission-driven jedi-level humans. You just have to find them. Some recruiting tips:
- Define the profile you want, which is probably someone with direct experience with the problem you’re targeting and probably ~5–10 years in government. You don’t want someone that’s too senior and therefore too removed from experiencing the problem as a user.
- Find them through all means possible. Start with your network — if you know talented veterans or former IC people, ask them for referrals for the best people they worked with. If you’re coming in cold, try Breakline (a group that connects DoD / IC talent with tech cos. highly recommend), veterans clubs at great schools, the Honor Foundation, etc.
- Select the jedi. Like PMs and engineers, a top performing mission teammate is 10X more productive than someone that’s good enough, so be rigorous. We use homework problems that try to match as closely as possible to what they’ll do on the job and typically only pass the top 10% from this round. If you haven’t recruited for a role like this before, get someone who has to be an interviewer. We have something like a 1–2% offer rate for these roles. Palantir has a similar recruiting philosophy.
Ship something
Once you’ve found something that people want to buy in, get it in their hands as fast as possible. Don’t worry about optimizing features. The biggest mistake people make is over optimizing the product before users have put their hands on it. Until you see how are using your product / what outputs they are generating for their jobs, you don’t know what to optimize. You can be creative with how you deploy to give you wiggle room with users — call it a beta, structure it as a one week access period when you sit on base with them, etc. Just get them something.
Once you’ve shipped, you’re now on the long journey of trying to make a product that people truly love. Irrationally. With passion. As per the above — irrational love is what will get your government counterparts to go through the pain to actually buy your stuff.
How to do this is a topic for another time, but one key difference with defense is to orient product development around increasing mission wins. In fact, your entire company should be oriented on generating mission wins for your users. When procurement time comes, you want dozens of people to be pinging their bosses and program offices on your behalf giving them amazing, specific examples of “I need this product. We accomplished Y awesome mission thing with it, and I’ll annoy you until you retire from the government if you take it away from me.”
Stay tuned for part 2, which is about how to sell your product in defense.
Godspeed, heroes.
p.s., if you’re thinking about started a defense tech company and need some help, ping me at bg@vannevarlabs.com.
