Why Defense Software Fails: The Critical Product Management Gap
Without world-class product managers, the Pentagon’s $2+ trillion modernization effort is already lost
The Department of Defense faces an uncomfortable truth: in war game simulations against China, America loses every single time. Not because of insufficient hardware or brave personnel, but because the software systems connecting platforms, processing intelligence, and enabling decision-making were designed for yesterday’s conflicts. While Defense Secretary Pete Hegseth pushes urgent modernization initiatives and the DoD Software Modernization Implementation Plan promises to deliver capabilities at the speed of relevance, a silent killer threatens to undermine these efforts before they begin: the near total absence of product management expertise across the defense industrial base.
In a recent Facing Disruption webcast, I sat down with Andrew Park, founder of Edensoft Labs and a product leader with over two decades bridging engineering and user needs in defense software. His message was stark: the defense industry’s traditional approach to software development, heavy on project management and light on product discovery, is fundamentally incompatible with the complex, rapidly evolving systems modern warfare demands. More troubling, the Pentagon and its prime contractors remain largely unaware of what they’re missing.
The Requirements Gap That No One Is Measuring
The defense acquisition system has long prided itself on rigorous requirements definition. Detailed specifications run to thousands of pages. Review boards scrutinize every capability. Yet a paradox sits at the heart of this process: believing everything end users say and implementing it directly leads to crappy products.
This is the requirements gap, the chasm between stated requirements and actual user needs. 1Research from Sonar examining over 200 software projects found that technical debt costs $306,000 per year for projects with one million lines of code, equivalent to 5,500 developer hours spent on remediation rather than innovation. Much of this debt stems from building the wrong things in the first place.
Andrew shared a painful early career lesson. He spent nine months leading the miniaturization of a tactical radio into a cigarette pack sized device, only to discover operators had no interest. The engineering was flawless. The product discovery was non-existent. When operators finally saw the device, they rejected it immediately because it didn’t meet their requirements for running missions.
Henry Ford’s famous observation captures the essence of skilled product management: if he’d asked people what they wanted, they would have told him faster horses. Users articulate needs through the lens of existing solutions. Product managers must excavate the underlying problem. When an operator requests a faster, stealthier aircraft, the product manager asks: what mission outcome are you unable to achieve today? What constraints are you operating under? What emerging technologies might enable entirely different solutions?
This level of discovery requires far more than gathering requirements in conference rooms. It demands deep customer engagement, technological awareness, and the ability to validate assumptions rapidly before committing millions to development. As the DoD’s own guidance acknowledges, product management creates benefits throughout the product lifecycle by tying the end to end value stream of development and delivery, aligning products directly to business and mission requirements, and establishing continuous user feedback to prioritize capabilities and features.
Yet across the defense industrial base, this capability remains vanishingly rare. When military leaders at the O5 and O6 levels talk about Anduril, they’re blown away. The company is doing it right, and there’s a simple reason why: their major investors, Silicon Valley venture capitalists, would never fund a company without confirming strong product management capabilities are in place.
The Silicon Valley Standard That Defense Ignores
In 2024, Silicon Valley secured over $65 billion in venture capital investment, with investors now demanding clear signals of product market fit, monetization, and efficient user acquisition, especially for complex enterprise solutions. Behind these investments lies a simple calculus: VCs won’t fund companies lacking exceptional product managers and technical architects, regardless of how promising the technology appears.
Mark Andreessen’s investment criteria are instructive: he seeks start-ups with a great product manager as a non-negotiable requirement. If the company also has a great software architect, he might invest even before the product idea fully matures. These investors understand that talent precedes execution, and execution precedes results.
The pattern repeats across successful defense tech start-ups. Palantir, Shield AI, and Rise8 all emerged from environments where product management was non-negotiable. Their founders either came from Silicon Valley or deliberately imported its product culture. Traditional defense contractors, by contrast, have spent decades optimizing around project management methodologies that work brilliantly for predictable, well-understood engineering challenges like building bridges or manufacturing aircraft. These same methodologies break down catastrophically for complex software systems.
The distinction matters enormously. Project management excels at coordinating the execution of known work. Product management excels at discovering what work should exist in the first place. 2The DoD Software Modernization Implementation Plan explicitly acknowledges this gap, identifying the need to scale an enterprise-level software cadre and develop and track software engineering talent as critical priorities. Yet even as the Pentagon recognizes the problem, the defense industrial base lacks the talent pipeline to address it.
Andrew has been trying to get this message out to defense leaders. Any O6 or O5 running a complex development project with multiple teams is probably experiencing tons of pain. There are many things to fix, of course, but product management is the number one thing to look into.
The Five Product Risks Defense Teams Ignore
Drawing on the framework developed by product management thought leader Marty Kagan and adding his own refinement for defense contexts, Andrew outlined five critical risks that product teams must actively manage and that defense programs routinely ignore.
Value risk asks whether customers will actually use this. Andrew’s miniaturized radio failed this test spectacularly. So do countless defense software systems that look impressive in demonstrations but languish unused on operators’ laptops.
Viability risk questions whether something can be sustained within business constraints. Budget, schedule, and policy realities constrain what’s feasible. Products that ignore these constraints never reach production.
Usability risk examines whether users can figure it out. Defense software notoriously suffers from interfaces designed by engineers for engineers. If a system requires weeks of training or forces unnatural workflows, it fails the usability test.
Feasibility risk determines whether engineering can actually build this. Overcommitment to impossible timelines or underestimation of technical complexity guarantees failure.
Sustainability risk, Andrew’s addition, asks whether code can be maintained and evolved over decades. Unlike commercial software with three to five year lifecycles, defense systems must function for 20 to 30 years. 3McKinsey research found that technical debt accounts for about 40 percent of IT balance sheets, with companies paying an additional 10 to 20 percent to address tech debt on top of the costs of any project. For defense systems with extended lifecycles, unmaintainable code becomes catastrophic.
Sustainability deserves special attention in defense contexts. Anyone at the commander, captain, colonel, admiral, or general level talks about sustainability constantly. It’s top of mind at those levels, and it needs to be top of mind for DoD product managers.
The traditional acquisition process manages feasibility and viability reasonably well through extensive reviews and oversight. It systematically neglects value, usability, and sustainability. The result? Systems that meet stated requirements but fail in operational contexts, or succeed initially but become unmaintainable cost sinks within years.
Why Agile Failed Defense (And What Actually Works)
The defense software community embraced Agile methodologies enthusiastically over the past two decades, hoping rapid iteration would solve the slow, bureaucratic waterfall approach. 4The Air Force led with software factories like Kessel Run, created in 2017, with other services following. The Army Software Factory and Marine Corps Software Factory were established in March 2023. Yet many of these initiatives disappointed, delivering incrementally faster versions of fundamentally misconceived products.
The flaw stems from a misunderstanding about complexity. There’s a real commitment in the defense community to the idea that all software, whether big or small, should be built through quick iterations. That assumption underlies what Agile and Scrum and DevSecOps have been built upon. But that assumption is often flawed.
Agile apostles assumed all software development operates in what the Cynefin framework calls the complex domain, unpredictable territory requiring constant experimentation. But when teams have strong product managers who’ve done thorough discovery and strong software architects who understand the problem space, much of the work shifts into the complicated or even obvious domains where upfront design dramatically outperforms blind iteration.
Andrew illustrated this with a practical example. If he took some of the best engineers in his company and put them on new product development, typically maybe 20% would be in the complex domain, 30% in the complicated domain, and 30% in the obvious domain. But if he took new hires and put them on the same work, then yes, it would all be in the complex domain, and they should do Agile, Scrum, and DevOps.
This insight exposes why Agile often produces what product managers derisively call feature factories: organizations that efficiently build features without creating coherent, valuable products. The bottom up, iteration heavy approach works brilliantly when teams are learning entirely new territory. It produces architectural technical debt and wasted effort when applied to problems that skilled practitioners could solve through upfront design.
Defense programs compound this problem by combining weak product discovery with excessive risk aversion. If you have an extreme risk reduction type of mentality, you cannot innovate. It is completely incompatible. The result is programs that adopt Agile’s terminology and ceremonies while maintaining waterfall’s risk avoidance culture. The worst of both worlds.
What works? A talent first approach. Invest heavily in cultivating product managers who can do genuine discovery, reducing uncertainty about what to build. Simultaneously develop software architects and engineers with deep craftsmanship skills who can design maintainable systems at scale. With these capabilities in place, teams can apply the right methodology for each component: agile exploration where needed, disciplined engineering where appropriate.
The AI Amplifier: Making Talent More Critical Than Ever
As artificial intelligence tools transform software development, many organizations see an opportunity to reduce their dependence on expensive senior talent. Andrew sees precisely the opposite. AI allows every person on the product team, whether they’re a product manager or a designer or an engineer or a QA person, to expand their impact and add contributions in other roles too.
This is the promise of AI: enabling humans to become multi-capable. But there’s a dangerous trap. In the hands of novices, AI coding tools produce technical debt at unprecedented speed. Tools like Bolt or Lovable can generate applications through successive prompts, but each iteration likely compounds architectural problems that AI lacks the expertise to recognize, much less fix.
5Research shows that 71% of developers spend at least 25% of their time dealing with technical debt, while 91% of CTOs identify it as a major challenge. AI threatens to multiply this problem exponentially if organizations respond by hiring less experienced developers and assuming AI will compensate.
The solution isn’t to avoid AI. Andrew’s teams use Cursor and other tools extensively. Rather, AI makes senior engineering and product talent more valuable, not less. What he’s seeing now will be common knowledge within two years, but people aren’t raising the alarm because they don’t have enough experience to have figured this out yet.
I recently coined a term for the phenomenon: slop at scale. AI enables rapid development, but without strong architectural thinking and product discipline, organizations will generate vast codebases of unmaintainable, misconceived software faster than ever before.
For defense contexts with 20 to 30 year system lifecycles, this is existential. Code documentation is more important than ever. The human skills of how to create great documentation and code are more important than ever in the age of AI. Organizations are going to have so much more code, and if they want to use AI to help in the future, that AI will not have all the context it needs if humans aren’t putting all that hidden context into the code.
Building the Capability That Doesn’t Exist
The defense industrial base faces a chicken and egg problem. Programs need product managers to succeed. But product managers capable of operating in defense contexts are extraordinarily rare because defense contractors haven’t been looking for, measuring, or rewarding product management skills.
The prescription starts with education. Andrew repeatedly referenced thought leaders whose books should be required reading for defense software leaders. Marty Kagan’s Inspired is the foundational text on modern product management, articulating the core responsibilities and mindset. When Andrew read it after many years of doing product management, he realized Kagan was describing many of the things that through experience, he’d come to do himself, things he knew worked.
Teresa Torres’ Continuous Discovery Habits is particularly relevant for DoD contexts where continuous user engagement is possible and necessary. Roman Pichler’s frameworks are useful for large defense developments with worksheets and artifacts that can be shared across multiple teams and stakeholder groups.
Beyond reading, organizations need to create career paths that value product management skills equally with technical and project management capabilities. This means measurement frameworks that assess how well teams are managing the five product risks, incentive structures that reward validated learning over feature velocity, and hiring practices that prioritize product thinking.
Edensoft Labs addresses the engineering side of this equation, helping teams develop the software craftsmanship skills necessary to build maintainable systems at scale. But engineering excellence alone isn’t sufficient. Andrew learned this the hard way. All his efforts to become a great engineer and a great computer scientist were not enough. He could do his job perfectly, design code great, write great code, but it still wouldn’t impact the world without strong product management.
For defense programs, the path forward requires coordinated action across multiple fronts.
Program executives and acquisition professionals must recognize that product management is a distinct discipline requiring specific expertise. They need to stop assuming that project managers, systems engineers, or technical leads can perform product management duties without training and support.
Prime contractors need to build product management capabilities comparable to their project management depth. This means creating product management career tracks, investing in training, and structuring programs to give product managers the authority their role requires.
Congress and oversight bodies should measure programs on product outcomes like user adoption, mission impact, and sustainability, not just on schedule adherence and requirements verification. Current incentive structures reward delivering what was promised, not discovering what should have been built.
Defense startups and innovative contractors should resist the gravitational pull toward traditional defense contractor norms. They need to maintain the product centric culture that enabled initial success as they scale.
The Modernization That Won’t Happen Without This
Christian Brose’s book The Kill Chain crystallized a strategic reality: American platforms and systems optimized for counterterrorism are catastrophically mismatched for great power competition. The response, modernization efforts spanning multiple services and combatant commands, represents a multi trillion dollar transformation over the next two decades.
The global military aerospace and defense lifecycle management market reflects this urgency, with product lifecycle management solutions playing a critical role in managing complex defense systems from design to disposal. But all the investment dollars and reform initiatives cannot overcome a fundamental capability gap.
Modernization doesn’t have a hope of happening without really great product management talent being cultivated and acquired within the defense industrial base.
My conversation with Andrew revealed an industry at an inflection point. The traditional defense industrial base excels at predictable engineering challenges governed by clear requirements. Modern software systems, distributed, interconnected, rapidly evolving, demand a fundamentally different approach centered on continuous discovery and sustainable design.
Some organizations get this. Anduril, Palantir, and Shield AI built product centric cultures from inception. Companies like Rise8 are helping traditional organizations adopt these practices. But the broader defense industrial base remains organized around 20th century assumptions about software development.
The opportunity cost of inaction compounds daily. 6Stripe estimates technical debt alone has a $3 trillion impact on global GDP, with engineers spending 33% of their time dealing with technical debt rather than innovation. For defense, the cost isn’t just financial. It’s strategic competitiveness measured in decades of advantage ceded to adversaries.
The most encouraging aspect is that solutions exist. The body of knowledge around product management is mature and accessible. Organizations that commit to building this capability see transformational results. But commitment requires acknowledging the problem first.
Defense leaders reading conference room demos, attending software factory showcases, and hearing Agile success stories should ask harder questions: How did you discover these requirements? How do you know users will adopt this? What’s your technical debt strategy? Who owns the product risks? These questions will be uncomfortable because honest answers often reveal gaps. But asking them is the first step toward building the capability that modern defense demands.
The alternative is continuing to fund development efforts that deliver technically impressive systems operators don’t use, or use reluctantly because no better alternative exists. In war games against peer competitors, technically impressive but operationally inadequate is indistinguishable from failure.
Our platforms, whether Army, Navy, Air Force, or Marines, whether air, sea, or land, are not well suited for the great power competition they need to be prepared for. The whole process is too slow. It starts with bureaucracy. Hegseth is trying to change that. From the top down, they understand that America is way behind on modernization strategies.
The bureaucracy can change. The regulations can evolve. The acquisition pathways can accelerate. But none of it matters without the people who can discover what needs to be built, ensure it serves actual user needs, and architect it for sustainable evolution. Product management isn’t nice to have supporting capability. It’s the foundational requirement that makes everything else possible.
Defense leaders who understand this and act on it will build the capabilities that win future conflicts. Those who don’t will continue funding expensive demonstrations of what failure at scale looks like.
U.S. Department of Defense, “DoD Software Modernization Implementation Plan,” approved by DoD CIO John Sherman on March 30, 2023. The plan describes the flexible oversight foundation for continuous planning and management of software modernization, with the stated goal of delivering “resilient software capability at the speed of relevance.”
Tech debt: Reclaiming tech equity,” October 2020, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity
Red Hat, “Modernizing defense software factories,” https://www.redhat.com/en/topics/cloud-computing/modernize-defense-software-factories. Kessel Run, established in 2017, pioneered the software factory approach for the Air Force. The Army and Marine Corps followed with their own software factories in March 2023.
https://www.sciencedirect.com/science/article/pii/S0167642318301035
Stripe, “The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP,” September 2018, https://stripe.com/files/reports/the-developer-coefficient.pdf. The study surveyed developers across multiple countries and found they spend an average of 13.4 hours per week (33% of a 41.1-hour work week) on technical debt and bad code.
Resources
Product Management Talent: The Critical Gap Agile and DevSecOps can’t fix https://www.linkedin.com/pulse/product-management-talent-critical-gap-agile-devsecops-andrew-park-i7the
Code Documentation Standards Debunking the AI Documentation Myth https://www.linkedin.com/pulse/debunking-ai-documentation-myth-what-engineering-leaders-andrew-park-feyye
Operator-User Disconnect in DoD Why DoD Software Keeps Failing Operators https://www.linkedin.com/pulse/why-dods-biggest-software-programs-keep-failing-operators-andrew-park-ghgme