Ten years ago, when Pete Newell, Steve Blank, and Joe Felter launched the Hacking for Defense (H4D) course at Stanford, “defense” was still a dirty word in Silicon Valley. Investors were reluctant to put their money into defense tech, engineers were uninterested in the military, and tech companies kept their distance from the DoD. As veterans steeped in the tech world, they sought to change that.
Enter: H4D. They took Blank’s Lean Startup methodology and worked with students to apply it to national security. Could the Pentagon define its problems clearly enough for nontraditional founders and developers? Could students and technologists rapidly prototype solutions that made a difference? And could the Pentagon—finally—change the way it builds and acquires technology? The answer—proven now by ten years, dozens of universities, and over 70 startups—it turns out, was yes.
In this conversation, Pete Newell, now the CEO of BMNT and co-founder of the Common Mission Project, reflects on the accidental origins of H4D, the painful realities of defense acquisition, and what it takes to be a successful defense founder.
Note: This interview has been edited for length and clarity.
Tectonic: Could you start off by just telling me a little bit more about the genesis and launch of Hacking for Defense? Why is this something that you’ve dedicated so much of your career to?
Pete Newell: Hacking for Defense started by accident.
About a year after BMNT started, around 2014 or 2015, we were approached by somebody in DoD who said they were writing a document to blueprint the future of technology acquisition for 2025. They were told by Congress specifically to include things about nontraditional technologies. They were past the deadline. They had extended it twice, they were coming up to crunch time, they had to report something to Congress—and they could not get anybody in Silicon Valley to talk to them.
The ask of us was, “Can you prove it’s possible to get Silicon Valley engaged in a conversation with the DoD about something that’s important to the DoD?” And my answer was yes. They told us we had two weeks to get it done, and they would send us a contract afterward.
I had been in and out of the Stanford campus and the area as the REF director for years, and I knew that when I took problems to campus, I got all kinds of people to talk to me. So, with that in mind, I was like I’ll just come up with a problem that DoD cares about that also exists in the commercial world. Believe it or not, it was about supply chain and logistics in the Pacific. Twelve years later, and we’re still talking about that problem. If I pulled out the original, you’d look at it and say, yep, they’re still talking about the same things.
We decided to take that problem and break it up into pieces. And then, we recruited some students from Stanford and put them on teams, each with a part of the problem. It was spring break, so there were some military people who were fellows and students available. We told the teams, “It’s your job to rewrite this problem so that it is understandable by people with no defense background, and then go talk to people in Silicon Valley about it. Then come back with a rewritten problem from their perspective. And then, if that works, you’re going to recruit them to sit down and really write it out a one-page explanation of the problem and the conditions it exists in. At the end of this, you’re going to give it to one of the managing partners from the private equity firms on Sand Hill and see how they respond to it.”
It worked beautifully. We had people coming out of the woodwork to talk to the teams. Incidentally, this is when I met Steve Blank. One of the students was taking his Lean LaunchPad class and went to him and said, “Hey, these BMNT people kind of sound like you.” DIUx was also standing up at the same time. So we had early members like Enrique Oti and Steve Butow and others from DIU sitting in the room with us most of the time.
Steve Blank and I met over coffee in the midst of this and did a mind meld over lean methodology and problem sourcing and curation from Afghanistan. What the two of us realized is that when we drew a diagram of how customer discovery in Lean, it was identical to what I was doing with REF in Afghanistan in 2012. We were both surprised, but credit to Steve for seeing the big idea. As he walked out of the door he said, “You and I are going to work together, and we’re going to do something to help the government.”
Flash forward to the outbrief for the [Pacific logistics] problem. We were sitting in a room with Bill Perry, Steve Blank, Anya Manuel, who was the managing partner of Rice, Hadley Gates, Sharon Burke, who was a former assistant SecDef for Operational Energy, Chris Zember, who was the government client, and a bunch of the students. We walked through the supply chain exercise and what we learned. At the end, we told Bill, “This worked perfectly. But in the end, unfortunately, it’s not scalable, because we’re using students, and students, when they’re going to school, don’t have the time to do this.” Then one of the students, a civilian who had never touched the military, stood up and said, “Hey, wait a minute. Had this been a class at Stanford, I would have taken it.” We all sat still for a second, then Bill Perry looked at Steve and said, “You guys need to make this a class at Stanford.”
That was in April of 2014. By August, we had rewritten the educator’s guide for the Lean Methodology, changed the language for Hacking for Defense, and had a curriculum for students. We were able to recruit Tom Byers, who was the head of Stanford’s venture technology program, to be the academic sponsor of the course. Then, we worked with Alex Osterwalder to change the business model canvas, which is at the heart of Lean, and created the mission model canvas.
We got all that done by January, but we didn’t know whether students would actually sign up for the class, because it was competitive. You had to sign up as a team with a problem. We didn’t know if we’d be able to get problems, and we didn’t know up until the last minute whether Stanford was actually going to let us teach the course.
At one point, I was talking to Jon Young, the J8 of the Joint Improvised Threat Defeat Agency, about finding problems for the course. He looked at me and said, “Listen, you’re nagging me. Solving one problem a year for me is just not interesting. I literally have so many problems in the building that I have zombie problems that nobody will touch—they’ve been there so long that nobody owns them anymore. My problem is getting rid of problems. It’s gotten to the point where my program managers, who used to manage five programs, now have 25 and they’re not getting anything done other than just moving paperwork. I need the ability to kill things off, solve them, or get them out of the building to someone else.”
He then said, “I’ll cut you a deal. I will give you problems for the course if you will build this process for me inside my agency and do the same thing.” Jon was the first donor of problems for the course.
During one of the student information sessions, Steve Butow—who runs the space portfolio at DIU—and I were sitting on either side of a student and just chatting. We asked him why he came to the session. He said, “Yeah, you know, I’m really interested in this technology around low Earth orbit satellites and imagery, and things like that.” He was fascinating to listen to and really understood the tech. While we didn’t have a problem that was related to the tech, Steve and I told him we’d come up with one if he took the course.
Turns out, that student was Payam Banazadeh, the future founder and CEO of Capella Space. So a lot of early H4D was circumstance, serendipity, a little bit of luck, and just a lot of hard work. That was before we ever taught the first class.
We had other universities who were teaching Lean LaunchPad and heard about what we were going to do. They came to us and said, “We heard you’re doing this thing for defense, and we want to do it too.” And we said, “Listen, we’re going to teach the first class in the spring of 2015, and, if we are successful, in 2016 we’ll have it ready for others.”
There was room for eight teams on the course, 32 students. We had over 150 students show up for the info sessions, and I think we had 16 teams apply.
So, just to break it down—what are the actual steps you teach in H4D?
First thing—before we ever teach the students—we go out and source problems. BMNT teams go all over the world gathering problems. And then we curate them. That means we vet them: is this a real problem, or is it just research disguised as a problem? Is it something students can work on
Once we hand the problem to the students, the process starts.
Step one is identifying the beneficiary. That’s almost never spelled out in the problem statement. And often it’s the hardest part—figuring out who really benefits from solving this.
Sometimes there are multiple beneficiaries, and they don’t all agree on what success looks like. Eventually, the team has to choose who they’re going to prioritize.
Then it’s about understanding the value proposition: what’s the mission the beneficiary is trying to complete, and how does solving this problem help with that? You might have a great technical solution—but if it doesn’t improve the mission, it’s not useful.
Half the course is just that: understanding the mission and value equation.
Then we move into understanding the solution space: what’s the pathway by which we could deliver a solution? Who do we need to engage in the government? Where’s the money coming from? What programs or contracting offices are relevant?
And finally—can we do it? Is it financially feasible? Is it scalable? Can you deliver the solution at a cost that makes sense?
That’s the arc of the course, start to finish—10 to 14 weeks.
What kind of successes have you seen come out of the course? And how many of these solutions were adopted?
Let me back up and talk about success. Building a course like this is really a multi-sided value proposition. You’re trying to build something that has value for four different sets of people.
One is the students. And the students will tell you—this is a quote—that this is the hardest course they take in their professional career, but it’s the only course that allows them to work on a real problem with real people that gives them real experience that leads to real jobs. That was straight from a Stanford student who’d been there for six years. Students are looking for real experience. They’re not looking for more lectures, more theory, and more reading. They want to get their hands dirty working on something real.
The second group is the universities. They’re being pushed to not just do research but to actually turn out real outcomes. And they’re being pushed to graduate students who are more capable of operating in a different kind of world. So, in many cases, universities are looking for a different type of classroom—one that’s more experiential, or one that actually meets the demand of industry, or the government, or society.
The third group is the government. The government has tons and tons and tons of problems, and they’re looking for people to help them clear those problems. People to either tell them, “Your problem is wrong,” or, “Your problem’s right, and here’s a way to solve it,” or, “That’s a bad idea,” or even, “That’s already been solved.” The government doesn’t have time to do the kind of research it needs, and, frankly, it doesn’t have ready access to the outside world to get the feedback it needs.
And finally, industry. You’d be surprised—we always thought industry would just want to know what the government’s problems are, but what they tell us is, “We do this because we want to hire the students that come through this course.” That’s why Lockheed Martin is such a big supporter of H4D—they want access to the talent.
So the course is centered around those four groups, and making sure we deliver equally to all four. I always say the first output of the course is people. We are producing students who are familiar with DoD, familiar with the national security ecosystem, familiar with the kinds of problems the government faces, and who are actually excited to work on those types of problems. We frame it as a form of national public service, and students will tell you that their mindset shifted—from one end of the spectrum to the other—in terms of their willingness to work with the government, their understanding of the pain points, and their appreciation for the value they can bring.
So, the number one output is talent—young men and women who actually want to help solve the government’s problems. Sometimes they join the military. We’ve had plenty who say, “Hey, I’m going to become a reservist,” or, “I’m going to sign up for active duty,” or something like that. A lot of them say, “I’m going to go work in the defense tech field, because I’ve got this calling now and I understand it.” So talent has always been the most important output.
The second output is helping the government understand its problems better. Ninety-nine percent of the problems that come into the course end up changing during the quarter, which tells you that the government didn’t fully understand the problem to begin with. Sometimes, even the requirements are wrong—because they haven’t done the discovery work needed to understand how fast technology is changing versus how fast the problem is changing, or how the context around the problem is evolving.
Could you give me an example of that?
Yes. I’ll give you the JIDA problem—the Joint Improvised-Threat Defeat Agency. They were working on a system to help foreign partners do IED interrogation, which basically means you’ve got to go up, tear apart the device, and figure out how it works. There’s a lot of tech involved.
The students found plenty of ways to solve the problem but were stymied by JIDA’s processes. Eventually, they deciphered the entire system that JIDA used to deliver and use tech. They knew it so well that when at one point, they put a slide up on the wall that mapped out all of JIDA’s systems, and someone had a panic attack because they were convinced it was a classified slide. But it wasn’t—the students had built it based on open-source intelligence.
The students then said, “Listen, your problem isn’t the tech. It’s you. You are physically unable to run this system through your own processes because your processes are broken.” So they were fighting themselves, not the problem.
To JIDA’s credit, they said, “You’re right. New problem: fix our process.” And the students spent the rest of the course mapping out JIDA’s internal workflows. Eventually, JIDA spent another six months completely building on the teams’ analysis and fixing their own system. That’s a great example of how things evolve.
Another example is Capella. We gave them an initial, unclassified problem that basically said, “We need a way to track illegal fishing operations in bad weather.” That means we need satellite imagery—SAR imagery—of Chinese commercial fishing vessels going out in rough weather, because that’s when people do a lot of illegal stuff. But the real, underlying problem was tracking mobile North Korean missile launchers in bad weather. One is a proxy for the other.
So, sometimes we use a kind of decoy problem to represent the real one. And we eventually move toward the right answer. We track how the students revise the problem each week. They learn more, they engage with stakeholders, and they literally start changing the language in the problem statement to be more specific to what the problem really is. And that’s what opens up the opportunity to actually make headway.
Over the course of a decade teaching this course, have you seen a willingness within the DoD to adopt the solutions that the students come up with?
Yes, if you look at adoption in one of two or three ways:
At the lowest level of impact, the problem sponsor says, “Thank you. I’m going to take your material, I’m going to rewrite the problem, and I’m going to give it to the requirement writers or the capabilities folks, and we’re going to change direction based on what you gave us.”
The second level is when the government comes back and asks the students to continue working on the problem because there’s more work to be done. And eventually, sometimes, the government builds a team around it. That could be a policy issue, a deeper tech issue, or something else entirely.
And then the third is when the team launches a company. Or a company gets formed to carry out the solution. And the government steps in and actually supports it—sometimes with money, sometimes with a pilot program, and sometimes with a real acquisition.
Across ten years of the course, there have been 72 companies started by students based on problems the government gave them. Of those, I’d say probably 20 or 25 have been really effective at navigating the dual-use space—meaning they’ve built a commercial entity to do business with both the government and commercial customers, but are still focused on solving the problem.
What lessons do you think this holds for people who are trying to launch defense tech companies? What have you learned about what makes something successful?
I tell everybody: I don’t care what the government tells you. If they’re describing a problem, it’s probably wrong.
If that problem hasn’t gone through a rigorous discovery process, whatever you’re being told is probably not accurate—and it’s not the thing you actually need to solve. So be really careful about saying, “I heard this from a government rep, and now I’m going to go build a solution,” because you probably don’t understand the problem, you don’t understand the context it exists in, and you definitely don’t understand the stakeholders that are wrapped around it—the ones you need to recruit or the government needs to recruit for you in order to actually move forward.
That’s a mouthful, but without that discovery work, it’s really easy to get led down a rabbit hole, only to find yourself sitting at a dead end. And yes, maybe you got some research money—but there was never a scalable program on the other end of that. You were just doing research for the sake of research.
That’s the biggest one.
The second one is understanding the nature of dual-use financing. And this is really about their ability to take an idea—an understanding of a government problem—and match that up with a commercial problem, get a sense of where they’re similar, where they’re not. Then get government R&D dollars—non-dilutive capital—that allows them to do more discovery work while conserving the equity in their company to build the company and scale the product.
That work helps you build a better pitch deck, which you then take to the venture capital world to scale what you’re doing. And when you do that, you’re scaling off the government’s books. That allows you to come back to the government with a better, more usable solution that they’re more likely to give you money for—to do a demonstration or proof of principle.
And I can give you example after example. Even companies like Palantir were built on this premise—building things using government R&D dollars that helped them develop a better product, which they eventually sold back to the government.
So that’s the second biggest lesson I can give to folks approaching this: you’ve got to be able to ping-pong back and forth and use the dollars and the engagements in both spaces to your advantage.
What’s the biggest mistake you see founders making? What are the mistakes you teach students in the course to avoid or look out for?
I don’t know if I’d say “the” biggest mistake, but one of the most common ones is mistaking R&D dollars for a pathway to a program.
Like, “I got an SBIR Phase I,” or “I got a Phase II—so the next thing should be a big contract, right?”
No. In fact, that’s not how it works.
There’s been a lot of effort—really good effort—put into widening the top of the funnel, to get more R&D dollars into startups and emerging companies. But the tight, structured pathway that leads from R&D into actual acquisition programs? That part still hasn’t been solved.
And most emerging companies just don’t understand how government money works. They don’t understand the contract structures. They don’t understand the legislative process—how long it takes for money to move from Point A to Point B, and what it actually takes to get something into a program of record.
People give lobbyists a hard time, but lobbyists are phenomenal at educating folks on how this works: how you get something into the National Defense Authorization Act versus the Appropriations Act, how money flows across to the Pentagon and into actual programs, and how those programs can use the money.
If you don’t understand that flow—how money works in the government—you’re going to be at the mercy of whatever someone tells you. And a lot of times, what they’re telling you just isn’t true.
What’s the number one piece of advice you’ve given to students over the past ten years in Hacking for Defense?
The repetitive piece of advice is: it’s all about the problem. [I say it] over and over and over again.
And the problem is more than just a problem statement. You’ve got to understand first who the beneficiary of the solution is. And in the government space, the beneficiary of a solution is not the customer. The beneficiary is the person at the end who gets issued the thing—or has to use the thing—and actually has a mission to execute.
If you don’t understand the job that person is trying to do, you have no idea what you’re actually building for.
Also, the buyer is not the beneficiary. The buyer is someone in a program office. So you have to understand all the stakeholders—the people who have a positive or negative influence on the problem and its potential solution.
We talk about the “problem owner”—that’s the person with a seat closest to the issue, the one who cares most about getting it solved. Then there’s the “champion”—that’s someone with budget and authority who can actually do something if they see a good solution. Then you’ve got “supporters” and “advocates”—the ones who’ll help you navigate or connect the dots, but they’re not the buyer, the champion, or the end user.
And then there are “saboteurs.” These are the people who’ll body-check you—not because they’re bad people, but because your solution might take something away from them or make their job harder. It’s a zero-sum game sometimes. You don’t gain something without taking it from someone else.
The most powerful advocate you can have is a saboteur you’ve turned into a supporter. But you don’t get there without getting out of the building, talking to people, doing discovery. And I’m channeling my inner Steve Blank here—but you need to engage with people, with MVPs, and listen to feedback.
That’s not the same thing as pitching a solution. In fact, in the first few weeks of the course, we spend a lot of time politely—then less politely—telling students to stop pitching and start listening. Stop talking about solutions and talk to us about what you’ve learned about the problem.
When you reach the point of what we call “product-mission fit”—you understand the beneficiary, you understand the value proposition to them, and you understand how it impacts their mission—that’s when you’re ready to pursue a solution.
Without that? You’ve got no business building anything yet.
Do you see enough companies doing this kind of discovery? This work of product-mission fit? Are they thinking about the warfighter before launching?
It’s becoming more and more common. I’ll start with this: we at BMNT have spent ten years inside government organizations, helping them change how they talk about problems—and also how they engage with companies.
So now you’re seeing the language change. They’re using our words. “Mission model canvas.” “Problem curation.” “Beneficiary versus customer.” These things are mainstream now.
There are still plenty of companies that don’t get it—or they try to do it without any external feedback. And I think that’s one of the hardest things for a startup: getting someone to talk to them honestly.
Not just, “Hey, that’s cool.” But, “Your MVP sucks. Your analysis is crap. Try again.”
That kind of feedback is what young companies need. It’s what helps them build the right thing. And former H4D students will tell you—they still use the same process. They do discovery. They talk to users. They interview people. That’s the legacy of the program.
How have you seen Silicon Valley’s culture shift toward the government and defense over the past decade?
It’s changed a lot.
We don’t have to recruit from Silicon Valley to get people to come to the course anymore. We teach the course in a classroom that seats over 100 people. There are 32 students, six instructors—and the rest of the seats are full of people flying in from D.C., from venture firms, from tech companies. They just want to sit in, help the teams, be part of it.
And when a student from any H4D program reaches out to someone in Silicon Valley? They get answers fast. Faster than I do. I tell them, “If you want to talk to the Chief of Staff of the Army, you’ll get there before I will.”
It’s the same with tech companies. Senior people are engaging directly with students. They’re opening doors. They’re donating their time.
I wouldn’t say it’s a cultural shift—it’s a lean-in. People now feel like, “Yeah, I’m part of this. I’m part of the H4D nexus.”
Also, the number of instructors at universities raising their hands to teach these courses? That’s a big deal. It’s not easy work.
What about inside the Pentagon? Have you seen more willingness to adopt creative or nontraditional solutions?
Yes, definitely. In 2015, it was, “We’ll talk about nontraditional stuff because we have to.” Then it became, “We need this, but we’re not going to disrupt anything.” And now it’s, “We’ll actually disrupt the system if it means getting better outcomes.”
Steve Blank and I have always said: don’t put a Band-Aid on acquisition. Build a parallel pathway. Something that’s permeable—you can cross between it and the traditional system.
The way we work is: start with a problem, not a requirement. Break it down. Build and test prototypes. Scale what works. Requirements writing comes after you know what you’re building.
That’s an inverted process compared to how the DoD usually works.
Right now, the system doesn’t let you stay in that discovery zone very long. You have to move from R&D to a program of record. There’s no “limited deployment” phase in between.
But things are changing. OTAs, CSOs, and congressional mandates have helped. Take the Commercial Solutions Opening—DIU built that with us in 2016. Congress authorized it in 2017. But it took six years before a SecDef said, “You can use this.” And another year before they said, “You will use this.”
So it’s taken 10 years to move the needle—but it’s accelerating now.
And that brings me to my last question. Trump has signed several executive orders aimed at overhauling acquisition—how the government buys software, hardware, even builds ships. Do you think change is finally happening?
I’m hopeful. I think something could fall out of this that’s closer to what we’ve been pushing for.
What’s encouraging is that it’s not just one entity—it’s the White House, DoD senior leadership, and Congress all pulling in the same direction. Not perfectly in sync, but they’re talking. We’ve been in conversations with all three.
The real question is: are they going to move a chunk of the budget into a new system? Are they going to touch the requirement system? Will they offer a real alternative?
Because what we don’t need is just another “rapid something” that’s a band-aid on the existing system.
Honestly? I’d love to see the requirement writers, capability directors, program managers, and warfighters all locked in a room together for six months—working on one mission-focused outcome. Not siloed. Not sequential. Just building something real.
So yes—I’m hopeful. I’ll quote Rep. Wittman: “Congress can give them all the authority they want. The Pentagon just has to use it.”
They’ve already got the tools. They just need to act.
Let’s see what happens. It’s going to be an interesting year.