IQT GPA Webinar: Selling to Defense

Channel: IQT Published: 2026-01-29 9,598 words Source: auto_caption

Transcript

Okay. Well, good afternoon everyone. Uh, welcome to our latest um, IQT GPA webinar. My name is Barry Lefu. I lead IQT's government platform accelerator.

And, uh, today we have a very exciting uh, guest speaker with Dr. Dr. Jeff Decker. And, uh, we'll be introducing him in in just a moment. And, um, as we go through today, uh, just a reminder, we are recording this event.

uh we will be sharing a uh a link to the recording to everyone uh that's attending today and um as we go through the event today as you come we have a section at the end for Q&A uh feel free to put your questions as you think about them in in the chat uh in the chat option and then when we get to the Q&A we'll we'll go through your questions and one request would be in the chat if you wouldn't mind just uh providing your email and uh if we don't get to your chat uh to your question. Uh Jeff has has agreed to uh send you an email with uh some answers to your question. Okay. So, let's jump into this today. Um you know, the defense market, I think, as everyone knows, right, is is an area of growth and and opportunity.

Uh currently, the budget is about $1 trillion a year. Uh there's a presidential budget request to increase that budget to 1.5 trillion uh in the next year. So definitely rep represents a significant opportunity uh for startups in the InQel IQT ecosystem as well as others that are are targeting the uh Department of Defense, Department of War. Uh just as a note here as a disclaimer courtesy of IQT's legal department, uh today's event is meant to be educational. uh we really want to share best practices and ideas um to help our portfolio firms in their journey to build and grow their your government business.

I wanted to mention that no government funds uh were used to for this uh webinar today and then also we're not sharing any proprietary or non non-public uh types types of information as as we go through this today. Okay. And if anyone has additional questions about that feel free to reach out to me. Okay. So, on to our our guest speaker today.

Uh Dr. uh Jeff Decker has just a phenomenal background. He's currently the program director for Hacking for Defense at Stanford uh University. He's also the managing director of tech transfer for defense um and ha has done some work for the pre-court uh institute for energy and is also a research scholar at uh at Stanford. Um through Jeff's program um he's started his career as an army ranger and uh has really uh through the hacking for defense program he's helped launch over 70 startups uh which have created over 600 jobs and uh raised over 375 million in funding and uh the hacking for defense program is being used widely across across the country.

Um he's also the author of several books which we'll uh mention today. And uh with that um Jeff welcome. Um I as before we kind of get into the selling for defense uh Jeff I be great if you could share a bit about your career journey. Um you know you started your career Jeff as as an army ranger where you were deployed uh to various places including the Middle East um and then you you know moved into your role at at Stanford. So, you know, I think all of our startup firms would be very interested to hear about your career journey.

Um, so if you could talk us through that and Jeff, I also wanted to mention that, you know, thank you for your service for the time that you served in the army. Uh, it's such an an important thing to do. So, thank you Jeff. Over to you. >> Well, thanks Barry and and thanks everybody for joining.

really honored to be with Inktel uh today and to to share a little bit about my story and and some of the research that I've been engaged with um and experience that experiences that I've had over the the past few years. Uh yeah. So I mean I I I started out as a a ranger originally from Buffalo, joined the army, and I was only in for four years, but I I did four trips overseas, um three Iraq, one Afghanistan, and then after those four years, that that was enough. Uh my body told me it it was it was time to move on. And so what I did, I went on to grad school.

I have uh so my graduate work was all in international relations. Um my dream job at the time was to work at a a think tank. Um so I spent some time with Rand Corporation in DC and working with some of the smartest people I've ever worked with. Fantastic experience. Um, one thing one thing that left me wanting from that that role um with Rand was impact.

And I think that's probably something that resonates with all of you given that you're you're entrepreneurs andor in the government. Um, it's spending lots of time writing a policy paper or um some sort of guidance on how the government might think about a policy or strategy or program. uh was fantastic work. Uh the issue that that I ended up having was I really wanted to see impact and it wasn't clear whether anybody read my my work um in the government or if it just got put on a a shelf or in fact maybe maybe it was read and implemented but you know really seeing behind the curtain uh stopped me from from scratching that impact itch that I had. Um, and so having that itch and exploring it, I I ended up founding a a veteran mental health startup um time around 2014.

And I approached it the the startup process like a researcher. I went away did my business plan, you know, spent lots of time laboring in a dark room figuring out like the best way to to make this thing run. And when I went to selling it, it fell on deaf ears. Um, and so I couldn't figure out how to how to make it work. And I ended up reading some books and and finding this this person named Steve Blank, uh, who's written the startup owners manual, the steps to epiphany, uh, and realized all the ways that I was doing it wrong.

Um and so started doing discovery and and quickly learned through several quotes to paraphrase that um remote mental health is the dumbest thing I've ever heard of. Um had I had I been able to to wait five and a half years with COVID I I think this conversation today would have been a little bit different. But in in the whole process of getting the startup to work, really beginning to understand um the startup mindset, Steve's methodology, the the lean methodology, um the business started to go. But one day I I went on to Steve's website and saw inaugural class 2016 Stanford hacking for defense and I thought, "Wow, um this class is about solving national security problems. involved in academia has startup uh source code and I I just knew that's where I had to be.

Um so I ended up packing up my stuff in Washington DC and and driving west to Stanford and I didn't have a job until St. Louis. So I've been allin with Stanford and hacking for defense for nine and a half years now. Um Barry shared some of the the organizations I work with at Stanford, but the three primary things that I do are one I I co-e the hacking for defense class where I'm honored to to um be involved with Steve Blank and Joe Felter and Pete Null and and Steve Weinstein, all titans of the defense technology um space. And then secondly, I I work to transition academic technologies and research into defense capability.

Um, and lastly, maybe most germaine to the conversation today is I spend as much time as I can researching the defense go to market strategy. So, what does it truly take for defense startups to penetrate and scale um the defense market? So, that's that's that's me. I'm excited to to chat a little bit more. And before Barry, you know, asks me some more questions, I just want to shine a light on Barry. Um, he he is a titan of the defense sector.

And if you don't know anything about Barry's background, MBA, PhD in in business, and he's got like nearly three decades of national security experience, um to include obviously Inqutel, but also doing public sector at at SAP and or SAP and Adobe and Oracle. So, fantastic resource, Barry. I'm glad to be here with you. >> Well, well, great. Well, thank you, Jeff.

Um it's it's a pleasure to uh to have you join our our event today. Thanks. So Jeff, that that's just a remarkable background and and thanks for walking our audience through it. Um, you know, Jeff, in in terms of, you know, your experience right when you were deployed in Afghanistan and as you did your research at Rand, what what was it that made you kind of decide that you really wanted to focus on bringing innovation into the Department of Defense? And did you have any kind of firsthand experience uh around how you know uh how you know how complicated and at times dysfunctional it is to uh to get programs moving forward. >> H it's a great question Barry.

Um, I mean, my time in the military, we we worked with an outfit called Blackwater um, sometimes. And I was intrigued by how much value they provide. And so, I know I knew these guys. I worked with these guys and I knew they were valuable, but on a macro scale, like what does it look like to outsource? And that that's what I did my my PhD on. um fundamentally can can uh private contractors augment or meaningfully supplement uh you know uniform personnel? Um so I've always had this fascination with the free market where the free market economy meets national security and and conflict.

And so what ended up happening for me was that morphed from private contractors and once I got the taste of startup life um you know into like how might we employ you know design thinking uh uh lean startup methodologies to the defense sector and that's what Steve Blank and Pete Null and Joe were already doing with hacking for defense but in terms of like my experience in the the government in in the army specifically. I think it just gave me an appreciation for how thick the bureaucracy is. You know, as a ranger, um I never got to choose which which boots I wore, which sunglasses I I wore, which rifles I used. And you know, this the things that we get aren't aren't always the the best solutions. Um let me let me give you an example.

So, uh, we had someone told us, my my leadership told us that we needed to use this this ball called the Remington Eye. Fantastic piece of tech. Um, and the whole purpose of it was, "All right, there's a ball. It's got a bunch of cameras on it. You're going to throw it into the building.

Someone's going to drive it around and we're going to find out if if there are bad guys in there and if they're armed and where in the building they are." Um and the purpose was so that we had complete or better understanding of what the threat was before we we entered the door. So sounded great. Well, let me tell you from an enduser perspective carrying a a suitcase um you know just standard one handle uh and you walking into the objective for a few kilometers arm going numb. you know, I'm carrying this thing, so I can't hold my rifle. Um, once we get in to the objective area, you know, it's it's under cover of of of darkness.

And so we we operated during night to have the element of surprise. But as this person's driving this this eye around for 20 minutes, dogs are barking, lights are turning on. And so, you know, the idea of, hey, this could save rangers lives because they know what the environment is before they go in was really great. But the reality was, you know, it actually made things, you know, not only more uncomfortable, um, but also put our our lives in danger. So that that always that resonated with me and and so you know that's kind of how I think about the defense market at a high level.

So what do end users need? What are decision makers hoping to achieve and how do we marry those together from an entrepreneurial perspective so we can can get the sale and that's what my selling to defense book is all about. >> That's great. Yeah, terrific answer Jeff. Thanks. And Jeeoff, as we go through the webinar today, obviously we're going to talk about like key things to be successful in in defense, but uh, you know, in selling to the Department of War, but you've seen lots of different startups.

You just had a great example, right, of a of a technology that seemed very promising, but wasn't, you know, it sounds like that was not widely adopted. And so, let's kind of start with things that you've seen, Jeff. um you know when a company has a very technology you know has a great tech uh very innovative but yet they fail to get traction within defense like what are some of the key things uh that you've seen in terms of what not to do or what's led to companies not making their their technology successful >> I I don't know where to start Barry um you know the the old adage is there's thousand pads to failure and only a couple to success um seem to to apply here I think. Um >> okay so so three three come to mind. Um so the first way I think technologically strong companies fail to get traction is that they fail to recognize that the government buys solutions to problems.

They don't buy cutting edge tech or fancy f feature suites. So again, government buys solutions to problems. They don't buy sexy tech. Um and so when I and I failed to mention I also um talked to several startups and and coach them through this this process as well. And so what I've seen with coaching startups on campus, off-campus, um, is that many of them approach the the defense sector from a product first perspective and not a needs first perspective.

And so what that sounds like in in practice is entrepreneurs go into and prepare for conversations with potential government customers prepared to like deep dive on their tech and and so they're the entrepreneur ends up talking deeply about their tech and the defense person, the potential customer is really listening out for how the product can lead to organizational impact or how that product can solve a government problem or meet a a government need. And so there's this disconnect between entrepreneur talking tech tech and defense person listening for need need and you know many many technology companies because they're so techn technologically advance end up missing that and and so it sounds a little bit like I don't know um my my product is based on you know written in this code or uses these materials and it's the fastest thing available. it's x% faster than the the current state-of-the-art and they just expect the government person or listener to automatically translate like oh okay sexy tech that can fit into boom this use case or this we can we can morph this technology or product into this defense capability and it doesn't happen um and and it just leads to you know frankly it just leads leads to the the startup having to to do brute force sales. And so typically in in that conversation, the the defense person might say like, "Hey, Barry, I you you've got great tech. Um, you know, and they're thinking maybe I'm just not smart enough to to fully understand everything.

You should go talk to." And the hope is that if they make this introduction to their colleague or this other um government organization that that person will be able to figure out what the heck you're saying technologically and then get back to them. And what ends up happening is it's just like constantly like let me introduce you to let me you know explain this tech to this person or or that person. So, it's just this round and round um circle of lots of conversations with without much much meat. >> Yeah, I I I think you're you're you're totally spot on there, Jeff. You know, reflecting on on my experience, right, when I was managing sales teams, I would always talk to our our our sales and BD teams about not leading with speeds and feeds, right? From a software standpoint, don't talk about how how fast it is or how much data you can store, you know, all the cool whisbang features, right? It's it's really about solution, what I called solution selling, right? Where you're really aligning and and highlighting how a product can bring a solution to a problem.

And you know what I I think you it'd be great to get your perspective, Jeff, but I've always found it's so important, you know, before you go into a meeting with with the government with a Department of Defense executive or a program manager to really research and understand that organization's priorities and and what the the key things are that they're they're trying to accomplish. There's so much information especially about uh department of war less so about the in the IC but uh so much publicly available information that you can research ahead of time to really understand uh priorities but I guess Jeeoff it'd be great to get your perspective on on that and maybe your ideas around how how do you >> kind of frame and and understand uh or identify the problems before you go into the meeting. Right. So, uh, firms can, you know, fully position the, you know, their products as as a solution as as opposed to just tech. >> Yeah.

One thing I I wanted to add to what Barry said was if if you have a slide or in your talking points, there's some sort of chemistry or algorithm, like it's it's probably it's it's probably not the right thing. um unless you you know have it at the ready certainly like a backup slide or something if who you're talking to ends up being deeply technical then you can double click on on the chemistry or the computer science or whatever behind your your tech but if you're leading with that like eyes are going to to glaze over um 100%. Um and I think Barry what what you're talking about like that fundamentally is another way that that startups fail. Um companies fail because they trust the government to know what it needs. And so doing all this research is super important.

Um like the reality is that the government knows what it wants. It has a solicitation out or something like that. Um but it doesn't always know what it needs. and and so that's changing a little bit with the the commercial service um offering or the cso um that that DIU created. But fundamentally like the mindset is we we need this or we we want this and the expectation is from an entrepreneur like oh the government says it it wants this so therefore they need it.

Um I mean anybody in a relationship you know everybody on this call all 120 odd people have had a personal relationship you know in context matters. It's like you get asked by your your significant other hey could you pick up milk on the way home from work and and the wrong answer is like no I don't have time because by the time I get done commuting I've got to brush my teeth and and go to bed. Um but with the context, you know that it's you know what's being asked and proposed is is truly what that need is. Um maybe more of a a defense related example. I can't think of a better one than than Palunteer and and DIGsa.

Um so the the distributed ground common ground system basically like early like 2008 910 time frame. the the army said we want to fuse 600 streams of data and information from drones and sensors to you know different databases that we have into a common repository. And so they're saying we want this and the assumption was you know it was logical um that we we need more data so that intelligence analysts can better perform their job. So if intelligence analysts have more data then they'll be able to create better outputs. Um, but the interesting thing was that the the prime contractors that were contracted to build this thing and the the army like they didn't really incorporate any analyst feedback.

Um, and what that meant was, you know, six 600 streams of information, you know, lots of complexity, lots of cost, and and significant development time. And so like D6A, the government spent I I don't know um north of 10 billion dollars um it was projected to be north of10 billion and ended up spending almost $10 billion for a system that never worked. And so that's like building to a government want. And then Palanteer took a completely different perspective and their perspective was okay um government we we know what you want these but let's let's better understand what you need and so Palanteer got it start by talking to intelligence analysts doing that research that that Barry just mentioned and what they found was well these intelligence analysts they don't need 600 streams or whatever the number was um what they need is fusion and aggregation pertaining only to Iraq and Afghanistan during this time period. And so it went from like 600 or hundreds hundreds and hundreds to like 40 like dozens of different um different sensors that needed to be integrated.

And so that reduced complexity, it reduced cost, it reduced time. And talent here, you know, before 2016 spent less than $500 million. And so six billion less than 500 million. Like there's a big delta there. Um DIA failed.

Palanteer has we all know the Palanteer story. Um and I think that the takeaway here is you succeed when the government succeeds. And so help your customer be su successful. Do the research to understand what their needs truly are and disagregate them from what their their wants are and then build that. >> Yep.

That's excellent advice, Jeeoff. And you know what's interesting is actually Palunteer was an early um IQT in investment and uh they benefited also from uh an IQT work program to better understand the uh the requirements of intelligence analysts and yeah it's just been remarkable the the growth trajectory that they've seen and and that they continue to be on. So, so Jeeoff, let's let's shift a little bit, right? So, you've spent, you know, quite a few years, right, focused on hacking for defense, kind of bringing tech in, you know, in into government, helping do tech transfer. You you've now uh you're going to be shortly publishing a book uh and a whole new framework that's called selling uh to selling to defense, right? And I guess it'd be great for you if you could explain a little bit about what's different about selling for defense and then what what are some of the kind of key uh themes and and takeaways uh that you'll be delivering in your selling to defense framework. >> Yeah, certainly.

Um so so first you hacking for defense for those of you who aren't familiar with it as I mentioned 2016 Steve Blank, Joe Felter and and Pete Newell uh created this course at Stanford called Hacking for Defense. And I personally have been involved for this will be my 10th year um since 2017. And the premise of the class is let's let's take the the lean methodology that C blank built and instead of levering it for creating companies to generate revenue, excuse me, let's lever that method methodology to solve missiondriven problems. And so solving a mission need and as the primary and not generating revenue. And so what we do with this class is we take government problems, real world government problems, we bring them into the class and then teams of students work on on these problems.

We and Inqutell has been a fantastic supporter um specifically Mark Brier and and Steve Bower. And so couple Inqutel problems that I can think of that we've had over the years. So, one of them was in 2019 um how do we solve how do we recognize what a deep fake is and and what when it's a real media and this is the time around when there's that fake news deep fake of Nancy Pelosi slurring her speech um you know anything from like really frontier technology and and bleeding edge um national security threats to like how how might we the the Air Force better better better design um instruction for pilots? So varied across um different different problem spaces and different uh users within the government or different problem sponsors. And so the students just apply the lean methodology to getting out of the building, having lots of conversations to truly understand what the problem is, understand the difference between government wants and and government needs, and then ultimately to to solve the root cause of the problem, not to create a a band-aid solution. And so that the hacking for defense book was was all about that.

Um and and when I published it in 20 late 2024, I was blown away. So this was just meant for students um students taking the class at Stanford and the 70 odd schools also teaching it across the country. And I was blown away that that startup entrepreneurs um Devtech entrepreneurs were were picking this book up and and reading it. And the questions that I got were like, "Oh, like how do I use this outside of the class?" like what if I don't begin with a problem? How do I find a a problem? And so selling to defense is a a natural outgrowth of that. It answers those questions.

And the way I framed the book is, you know, to go beyond discovery. The hacking for defense class is largely discovering what the needs are, what the perspectives are, which problem are we going to solve. Um and there are three parts of the the selling to defense book. um discover, iterate and sell. So what that means is discover needs.

government needs. Um, iterate and refine your product so that you can earn trust in your product with war fighters as well as gain credibility compliance-wise with the the bureaucracy and then sell only when you know that you have value to return um or value to offer um the defense department. So that's, you know, again, discover, iterate, sell is is how I break that up. >> Excellent. That that sounds like a terrific uh methodology.

And Jeff, will you be you're going to be publishing a book? Um approximately when will the the selling the defense book uh be be published? >> Oh, that's very I think that's the hardest question you could possibly ask me today. >> Okay. Sorry about that. >> Yeah. No, no, no.

Probably late summer. Late summer, early fall. >> Okay, great. We'll we'll uh we'll we'll be looking looking forward to it. And Jeeoff, you you just kind of describe like the key kind of three steps to um you know, your selling to defense framework um with you know, things that you've seen with other startups, right? Like where in that process do startups typically get stuck and and like what's kind of the biggest kind of area to kind of kind of that you see that they have the most uh difficulty with, right? Uh is it is it that early kind of problem discovery or is it more uh getting their technology, you know, to have all the bells and whistles and you know compliance capabilities that are needed to to sell into uh the Department of War.

>> Great. Another great question, Barry. Um, a as you were asking it, I was scanning through the the participant list and and I see um who I I believe is Dr. Rich Carlin, formerly from ONR. Um, Rich was instrumental in in standing up hacking for defense at Stanford and and across the country.

So, I just wanted to give a a shout out to to Dr. Carlin there. Um, but back to your your question, Barry. Um so the the question was where where do startups get stuck and and what are the common problems? >> Yes that's right it it in in terms of relative to your the steps in the uh selling for defense framework. Yeah.

I So what many startups do is they have this this sexy tech and they immediately go to sales. Um and they don't learn about government needs, government problems, government use cases. The expectation is again you as I said before um sexy tech equals contracts and and dollars and discovery isn't done. Um, so that's that's one. Um, and then the second one, and I think you know, iteration is is one of these things that's really not appreciated.

Um, so you're a new company. Uh, we all know that the the government does business with prime contractors because prime contractors have been existence for, you know, over a hundred years, many of them. Um, and so they know that Boeing or Lheed isn't going out of business. there's not much risk in in awarding a contract to them. There is an inherent risk in awarding a contract to brand new shiny startup even if it's five years old because we don't know if they'll they'll be in business or the government doesn't know they'll be in business.

So the whole thing with iteration is this this magical thing where companies go out and they they engage in pilots, they engage in demonstrations or exercises and they they gain credibility and they they gain trust. So what I mean by that is if you're triing your solution in an exercise, like you're working shouldertoshoulder, sometimes in the mud or in a steer environments with war fighters, actively getting their feedback on how your product can be made better, doing quick sprints to turn that over and then providing it to them. And so the the impact is is twofold. One, your product gets better and and war fighters are happy. Um, but also you you show that your company is is resilient and and willing to work through difficult things rapidly, which prime contractors arguably aren't aren't great at, um, to to meet their needs.

And so that that's one. And then two, you also have this this level of bureaucratic credibility in and iterating and and quickly delivering better capability or different capability from what your product can offer. Um, which tells the the government that oh you engaged in this exercise, you had to integrate with war fighter workflows. you had to integrate with technology, legacy technologies that were currently being used. And so when you get out, when you finish these exercises and you finish your iterations, your product is better, you have data um in terms of evidence, you know, statistics for how it performed.

Um you have testimonials from, I don't know, Colonel So and so saying like, "No kidding, this thing works and we want more of it." as well as network. Um, and and network's another big one. You know, many different people with across the Department of War who would be interested in buying your things, who might have budget and who have a specific need to to help you um and procure your solution. And so, you know, that was a a long- winded answer, Barry, but really going from technology to sales not preferred. Um but go taking an iterative approach to gaining an understanding of the needs, iterating to to refine your product, gather evidence that you can then marshall evidence, data and network to to land contracts is the the proven way to go.

Um and so that that was that was pretty abstract. Um you know, one one example I can think of is Pico Grid. uh great case study in and how to do this in the in the wild. Um, Pico Grid is is a company that integrates sensors, platforms, and and people. And you know they they were involved in a an army pilot and they had this bright shiny prototype and it left soldiers wanting like great sensor fusion integrations wonderful but dot dot dot you know soldiers were uniformly giving feedback that we need this thing to be portable and we need it to be capable of of doing AI targeting.

Um, and so rapid rapid iteration, um, Pico Grid ended up tweaking what they had, creating a a backpack sized unit, not something that went on the back of a a truck bed. Um, so manportable and it ended up being the it's called portal, but it ended up being the company's it's currently the company's bread and butter product. And so, you know, example of a company listening for feedback, testing, listening for feedback and and iterating. >> Great. Excellent.

I I think that's a a very important insight. So, you know, Jeeoff, um, a book that I've always been a fan of and an author is is Jeffrey Moore, right, with his book Crossing the Chasm. And what you know I think what I see is a common challenge with uh IQT portfolio firms as well as um you know other firms kind of working to enter the DoD market is they'll initially you know they'll get a an IQT work program or they'll get a cber award right to kind of build a pro a prototype allow them to kind of iterate and you know get some government funding for uh essentially R&D to enhance or or modify their that product, right? But there's the whole famous, you know, chasm, right? That I think companies run into uh that's also in the defense world sort of is sometimes called the valley of death. And it'd be really terrific to get your perspective on on that and some strategies and thoughts that you have to help make, you know, crossing that chasm or the the valley of death, right? it make that a very short window as opposed to something that could stretch out for years which really makes it very very difficult for startups to u you know to survive and and thrive uh with with that type of uh challenge. >> That's a great point.

I I love the the book and and so those of you who who aren't familiar with it, it's like this this bell curve and it it's looking at how how different people or segments adopt new technologies. And so again, bell curve really small section of early adopters truly visionaries. Those that are are forwardleaning um and but they're they're not as tech forward as the visionaries. And then th there are those people who who adopt it once it becomes mainstream. And then those there there are those that like don't have a a a cell phone until until you know their their house phone is just basically obsolete.

Um and so they only adopt when when obsolescence happens with the the current product. And I think that model is super important and applicable to the defense market not only in terms of of adoption but also market and bureaucratic penetration. And so you'll you know as a startup trying to sell into the defense department 2.2ish twoish million people um department of war um you are going to need to find these early adopters these champions and yes absolutely for for product adoption per um Jeffrey Moore but also because these people will these champions these early adopters will serve as sherpas for you to understand the morass of the bureaucracy and so what I mean by that is um one champions can can help you to understand which programs are are being set up or which which needs your product might be best suited for. They are also really valuable at getting you introductions to key people within the organization that you not having a.gov or mill email address, you you might not be able to get their attention. And so in the way I think about this and and selling to defense is if you're working initially on learning not selling learning about what the the government needs are learning about where they're spending their money.

Um so it's need plus budget. That's that's what you're you're toggling for. Um, you're then creating products and iterating on products that are are going against those needs while simultaneously picking up champions as you go along and and really building that bell curve of penetration so that you could fully and truly scale. >> Great. Yeah, I I think that's really really important, Jeff.

And and I think also right is um we've I think you talked spoke earlier right about the whole reducing the risk for the government and one thing that I've seen is very important right is to have is to have a successful kind of pilot and use case and uh ideally have that customer be willing to you know talk to other parts of the of the department of war or other agencies about their uh their insight. I mean that that is incredibly important, right? Because um no one ever wants to be first sometimes, right? Sometimes there are it is some people really lean forward and uh which is fantastic, but you really want to then uh find other early adopters um which hopefully will give you additional funding um and and not just depending on one uh one customer, right? who then may have a 12 18month budget cycle until they can fund uh deployments for it. So I think that that's that's really key is uh is doing that and then it's also understanding how you know that particular solution that's been built right to solve a mission problem find out other parts of the government that have similar or you know corollary uh problems as as well right and then really hopefully get that the network effect going to uh to scale that so terrific >> that's wonderful advice >> yeah yeah so Um, so Jeeoff, we're we're coming up here. We want to save some time for questions. So, I'm going to uh leave leave you with one one last question and then we'll go to audience Q&A.

And as a reminder, you can use the the chat feature to enter your question. We ask that you also uh provide your email in the event we don't get to it today. And we'll uh Jeff will uh we'll follow up with you with uh answers. So, Jeff, um we have a great turnout today. a lot uh a lot of our portfolio firms participating.

Um what would your kind of like one key takeaway uh be for our audience of like one thing that they should do say in the next 30 days to help position their company to be uh better enabled and and better prepared to um to target the the defense tech and the department of war. This is a thoroughly unsexy answer, but I I promise it'll it'll help if if you could in the next week, two weeks, work with your team, go through all of your notes, and map out in an organizational chart all of the different government organizations that play in your space. And it might look a little bit like Department of Navy initially and then like, oh wow, Department of Navy consists of Navy and Marines and then like on down into the the individual Marine Corps and the Navy to really identify the operational units that address day-to-day a problem or need that you solve is such a powerful exercise. Um, and having this map and starting to cross out organizations and circle those that that are most relevant to your technology is a forcing function to to do mind meldding with your team. And it also provides a roadmap for understanding where the needs exist within the department of war.

Um, again that align with your product. Then also gives you a platform to start looking into funding data. So like this organization says they care about a specific need, but are they spending against that need? Um so that will really help you to doing this or chart will help you to to qualify you know who potential customers are and then you'll be able to to leverage the data that you have from pilots and sivers and and exercises to have conversations with them and once you verify or validate that the the need is what they say it is leverage data so you're not having the conversation of you should buy my tech because it's great tech. It's fundamentally like you should buy this tech because this is your need. This is this product addresses your need in XYZ and we've proven that it addresses your need in this cber or in this pilot and here's the here are the data and the testimonials and the people who who are behind it.

Um, so in short form, really don't trust the that the government knows exactly what it wants. Like do the digging, map it out in an org chart. Learn the needs, iterate with them on on ideas on on how to develop and deliver the best product to meet those needs, and then then you're off to the races with selling. >> Great, Jeff. That's that's great advice.

I think one thing I would add to that that I think that research you describe can also enable right is to help identify like what is the TAM what's the the total addressable market in the DoD for a given project um which is obviously very important as firms look to raise additional capital is being able to highlight what what is that addressable market and that can come out of that research. I think another point to add is, you know, there's been so dramatic advances with with AI tools, right? Google Gemini, uh, Notebook LM, Chat, GPT, and, um, the unique thing is a lot of DoD and Department of War requirements, uh, are are publicly available. And there's a tremendous amount that you can do um you know to to do research without having to have some subscription or or hiring you know uh an an experienced consultant that you can really do by uh curating data with deep research mode with some of these research tools kind of building them in into like I said a a curated uh notebook LM to really kind of capture that that information. Um uh and then hopefully as a firm, right, you also have someone that knows the Department of Defense, knows how the government operates and can help you with that that journey as well. So terrific.

Well, thanks for that answer, Jeff. So, we'd like to shift to uh audience Q&A uh here and um I'll go through some of these uh the questions. The first one is from Andrew and uh Jeff the question is what are your thoughts around innovation and deep tech? I work for a D tech semic company which is much harder to describe than an innovative company. >> Is Barry is it possible for Andrew to come off mute and maybe unpack his question a little bit? >> Uh if I can find him in this list of the audience. uh that or Andrew if you can uh maybe add some additional clarifications to it and it's Andrew and you know well I'll take a stab at it while we're we're trying to to get more context.

Andrew, the the question that I I think you're asking is um you've got a a deep tech semi. Is that a a trucking? I'm thinking >> probably semiconductor. Uh Jeff. >> Oh, semi semiconductors. All right.

I went I was thinking autonomous. Um >> Okay. >> Okay. Um >> All right. I thought Andrew added here.

Um, >> yep. >> I I'm I'm sorry, Andrew, if you could provide a little bit more background. So, semiconductors. Um, and what did you what do you mean by harder to describe than an innovative company? Um, my initial reaction is what what do your semiconductors unlock? like what value fundamentally do do your semiconductors unlock and and which use cases do they apply to? Is does it unlock value in terms of computer vision or autonomy? Is it compute? And so those are all great things, but who ultimately cares about those things? Um so which decision makers and which organizations need more compute? Um and then how do you translate that to defense? is the application ISR or intelligence surveillance reconnaissance. Um if if your your semiconductor is is faster at processing, how does that translate to >> Yep.

Can you hear me? >> Yes, Andrew. Yes, you should. >> Yeah. So I I don't want to make it a long I was trying to build a a sort of universal question rather than to be specific to us but yes it's a semiconductor company but we provide a universal provider with an unfair advantage. So basically we can change all electronics not just not just one thing.

Uh but we're deep tech. So if we start explaining the physics right we we lose the people but if we can't explain the physics then we can't explain you know we can well we could explain behaviorally how how what the advantages are but it it's tricky right it's you got to understand things it's you know you know new very advanced technology is is more like magic than it is like trying to take people down a line And you you sort of hit you sort of touched on the points at the beginning actually but but it it's a hard it's a hard world to be in right that that's really that's really what what I'm saying. >> Yeah certainly Andrew. So um thanks for for expanding. I I get this question a lot especially on the academic side.

Um and so what I what I typically suggest to people is it's not how you do the magic. It's not what's under the hood of the magic. It's why is the magic? Why is the output valuable to the defense department? And then who, what, when, where, the descriptive properties of the value like how does that how do they intersect with with the defense department? Does that make sense? >> Yeah, abs. >> Absolutely. Um uh yeah you know you have a set of physicists right and one thing they want to do is describe the physics right and you know you have very few of the business people because the company is focused on the physics right so exactly right >> one 100% and then it also comes down to which color of money you're you're going after >> like if you're having if if you're going after um RDT& so then you may end up having more of a conversation about the physics.

But if it's a procurement or or operations and maintenance contract that you're you're shooting for, then like the tech and the the equations like they matter far less. It's all about output. How could how does this move the needle for war fighter? But bottom line, if you end up moving just leading the narrative arc with this is valuable to war fighter based on X, Y, and Z in these situations, then a highly technical person in the conversation could then say, Andrew, well, talk to me about the physics. Are you doing X or are you doing Y? What makes you different? >> Great. Thank Thanks, Jeff.

And Andrew, thanks for your clarification and question. So we'll go to the next question which is from uh Stephen uh Saltzman and the question is does the DoD get involved in spec specifying components in a new system or device or do they rely on the system or device vendors to design in the right the right components. Um, so, uh, I think that's that's the, uh, the the question there. And that and that does come up frequently, right, where companies are maybe designing like a really cool new LAR chip, right, that does amazing things compared to the status quo, but then they're searching for how do they get that, you know, in into plugged into a a program of record or into a larger system. >> Yeah.

Uh and and I think Barry, I'd be curious to get your your um response to this question, too. Um I I think in my experience, it's been a little bit of both. Um but fundamentally, one of fundamentally, you know, products are designed to fit platforms. Platforms are not designed to fit products. So again, you've got this great product.

they will not the the government will not change their submarine to fit your product. And so if they're specifying like, hey, it's it's got a maybe it's for a UV and or under unmanned underwater vehicle. Um the spec is this UUV needs to fit through a torpedo tube. And so if if you're designing a new battery, like the battery has to fit the specs of of what the the the UV size is. Um and so they can specify some some broader constraints.

Sometimes it's it's very specific so that it allows integration. But the bottom line is you know indicating even if you go outside of the box that your product plays with legacy systems you know which systems they are how to integrate not only with those systems but human workflows for operating those systems is exactly what they're looking for. And if you can communicate that, I'm not saying that every time, you'll you'll allow them to to change their spec. Um, but you can at least begin having a conversation of how you might be able to approach the the problem or develop a solution that adds the value that they're looking for, but could potentially be outside of their their spec or requirement. Barry, curious to hear you.

>> Yeah, spot on. What what I'd add to that um Jeff is you know really target the prime contractors that are you know developing the platform uh the government has something called you know with these long-term contracts something called technology insertion right a tech a tech upgrade a tech insertion and I think really um combining you know targeting the government to understand why this new capability could add value uh at a lower cost to the to the platform is important as well as than making um developing a relationship with the prime contractor or contractors that are also part of it, right? Prime contractors are also very riskaverse, but what they are motivated by is the ability for them to grow their contracts and to provide additional value to the government. And so you'll you'll want to frame it uh in in that respect. Okay. Um so we have time for one more question.

This is an interesting one from Christian K. Uh Christian says, "As a UWF uh hacking for defense alumnist applying rapid customer discovery to solve mission sets, I see a clear tension between custom defense needs and commercial scalability. In your view, is the forward deployed engineering model more successful when adapting a commercial product to the war fighter or should non-traditionals embrace a defense first path from the start?" So there a lot of components to that, right? commercial versus custom uh leveraging uh you know dual use things like that but we'll we'll end with your answers to to this question Jeff. >> Yeah Christian um nice to to meet another H4D uh veteran. So thanks thanks for the question.

Um I think I'm gonna I'm gonna target the the last part part first. Um, in my my opinion, Barry would love would love it if you disagree. Um, but in my opinion, Defense First is most successful when the government is either the largest customer or the only customer. And so we we'll think back to to Palunteer um early early 2000s mid there there really wasn't a commercial market for data mining um the government was the only only customer defense sector was the only one in town basically um similar with SpaceX uh and so defense first works again when the government is the only or largest customer and I fundamentally believe that doing both as a a young startup penetrating and trying to scale the commercial side while simultaneously trying to penetrate and scale the defense side is incredibly difficult largely because you've got two different sales cycles. You have two different sets of requirements.

You know almost always the government um regulations are more stringent than commercial. um you'll essentially need two different engineering teams um in some cases to design two different types of products. And to do all of this and then sell to completely different ecosystems, it you'll essentially need to have two parallel or um bifrocate your organization into you know your public team and your commercial team which is really tough for early startups to do. Um and so the tension by by definition with how to even engage commercial in the commercial space and the defense space like that it's created as attention. Um, and so when you do discovery, like Barry just got done talking about total available market.

the total available market on the commercial side is substantially larger or or even this close to being the same size as the defense sector. like you'll probably get more bang for your buck selling commercially, developing that track record of delivering product and then using that commercial product as a prototype later um when the company's ready and has commercial traction and product market fit to penetrate the defense side with that commercial product serving as the prototype that you can then tweak. >> Great. Thanks. Thanks, Jeff.

That's that's a a great answer. So, um folks, we're we're about we are out of time here. I'd like to just share here uh my thanks to uh to Jeff uh for his sharing his great insights today. U also thank all of you for for attending. We wanted to share Jeff's contact info.

Uh we have his email there which is jm deckerstanford.edu. Uh Jeff also regularly publishes uh via Substack uh which you can uh access there at stanford h4dhacking fordefense.substack.com. substack.com. Um, I will mention that Jeff actually just published a really insightful article this morning on that Substack that I I found very interesting in terms of uh some key uh things to be aware of in in selling to the defense market. And then finally, uh Jeff's uh hacking for defense manual uh which really encompasses his uh the work that he's done for the course at at Stanford.

uh that's available publicly if you just go to Amazon and you search for hacking for defense manual it'll take you to a page where you can get a get a copy of Jeff's book there. So uh with that again we'll be sharing the slides in a in a recording in in a few days and then also for the questions that we did not get to which there are uh actually there's quite a few uh we'll uh we'll get those to Jeff and Jeff will work to to answer those for you via email. Okay, thanks again. Have a great afternoon and rest of your day. Bye.

>> Thank you everyone. >> Thanks.