Why DoD’s Biggest Software Programs Keep Failing Operators

By Andrew Park | 2025-08-01

How the Buyer-User Disconnect and Weak Product Management Put Mission Success at Risk

Throughout my career, I’ve heard countless DoD operators say the same thing about their software systems: they’re slow, hard to use, unreliable in the field, and rarely match how the mission is actually executed. These recurring problems stem from deep flaws in how DoD software is acquired, funded, and managed, starting with the fact that the people buying the software are rarely the ones who have to fight with it in real-world operations.

This structural disconnect blocks alignment between what gets funded, what gets built, and what operators truly need to accomplish their missions. Until this barrier is broken, no process reform or faster delivery cycle will change the outcome: operators will keep receiving software that fails them in real-world use.

This blind spot exists largely because traditional defense acquisition practices evolved around hardware programs, where the buyer-user gap is much smaller. For aircraft, ships, vehicles, and weapons systems, operators and test communities are embedded early in the requirements process and throughout development. Performance metrics are clearer and more stable, and operators can directly influence design decisions to ensure mission needs are met. While hardware programs have experienced cost overruns and delays, they rarely field products that operators can’t use to fight and win.

Software is different because the buyer-user gap is huge. The people funding and specifying DoD software are rarely the same people who depend on it in the field. Operators often have little to no voice during acquisition and development, leaving critical workflows and mission realities misunderstood or ignored. Complex, evolving missions cannot be fully captured in static requirements documents. This is why traditional Waterfall methodology proved disastrous for software development. It assumed requirements could be fully known, documented, and frozen upfront, which never matches reality for large, complex defense software systems where buyers and users are worlds apart.

Adopting Agile, SAFe, Lean, or DevSecOps has not solved this problem. Teams can “go Agile” or “implement Continuous Delivery” and still spend years building the wrong product if no one is continuously and competently validating what operators actually need.

The Cost of Failure

Every time operators reject or workaround bad software, missions slow down, training hours are wasted, and sustainment costs balloon. Programs spend tens or even hundreds of millions rewriting code that could have been right the first time if operator needs were validated early. These costs are measured not just in dollars but in missed mission outcomes and increased operational risk.

F-35 and the Future F-47 

The F-35 program is a high-profile example of this problem, and it’s still happening today. With over 8 million lines of onboard code, software underpins almost every aspect of the aircraft’s capabilities. As recently as 2024, GAO reports cited instability in the TR‑3 software upgrade, delaying deliveries and stalling deployment of critical Block 4 capabilities. Pilots flew missions with incomplete or unreliable software for years, creating operational risk and undermining confidence in the system. 

The next-generation fighter, the F‑47, will almost certainly involve an order of magnitude more software than the F‑35, including AI-enabled coordination with uncrewed “Collaborative Combat Aircraft.” I believe the F‑47 is destined for even worse problems than the F‑35—more delays, more instability, and greater operator frustration—simply because the size and complexity of its software will be exponentially larger unless this buyer-user gap is fixed and true Product Management expertise is brought into these programs.

What Commercial Tech Learned

 Silicon Valley discovered more than 15 years ago that software delivery process frameworks can only make you build the wrong thing faster if no one deeply understands the user. They faced the same complexity challenges DoD is now grappling with and solved them by investing heavily in Product Management. It became a core leadership discipline on every major software program because without it, development teams lacked direction and often delivered products that completely missed user needs.

Defense standouts like Palantir and Anduril are proof of the importance of this competency. Both companies exhibit exceptional strength in Product Management, relentlessly focusing on understanding operators and delivering solutions that fit real-world mission workflows. This is one of the biggest reasons they stand out so sharply compared to the typical software products produced by traditional defense primes. It is absolutely possible to achieve much better results across DoD software programs if other defense primes are required to acquire and develop stronger Product Management talent. O‑5 and O‑6 leaders have the authority to demand this from their contractors and should ensure that programs are staffed with true Product Management expertise, not just process managers with the title.

DoD continues to focus heavily on adopting Agile, SAFe, Lean, and DevSecOps practices, believing that faster pipelines and better process frameworks will fix their software problems. But this misses the real issue. The lack of strong Product Management is a problem at least ten times bigger than tooling or delivery speed. The companies that truly stand out in this space, like Palantir and Anduril, succeed because they treat Product Management as a core discipline on par with engineering, ensuring that what gets built actually meets operator needs.

The Critical Role of Product Management

One of the most critical disciplines in modern software development is Product Management. It is the function responsible for ensuring that what gets built truly solves operator problems and delivers mission value. Large, complex software efforts generate endless competing priorities, dependencies, and design trade-offs. Without dedicated product managers relentlessly advocating for operators, validating solutions early, and guiding development focus, engineering teams inevitably deliver poor user experiences. This is one of the biggest reasons why Product Management has exploded in Silicon Valley as the size and complexity of software products has increased by roughly 50 times since Agile and Scrum were first formulated. Every major tech company building complex software invests heavily in this discipline because they know that without highly competent product managers, even the best engineers and processes will fail to deliver software that users genuinely adopt and trust.

Over the past two decades, USG organizations have borrowed heavily from commercial software delivery frameworks like Agile, Scrum, SAFe, Lean, and DevSecOps. These frameworks focus on managing workflows and giving the appearance of faster delivery. They do not address the hardest and most important part of building successful software: discovering what operators truly need and shaping a product strategy to deliver it. While SAFe technically defines Product Manager roles, in practice, people are often assigned these titles without the competencies or experience to carry out the role effectively. This is a dangerous anti-pattern because it creates the illusion that the gap is filled when it is not, allowing programs to proceed under false confidence while operators remain unsupported.

Highly competent Product Managers are essential to fixing this. This is a demanding role that cannot be filled by title alone. It requires deliberate selection, rigorous training, and ongoing performance management. In a new product development effort, effective product managers must be able to:

1. Understand and Advocate for the Operator – Spend time with real users, learn their workflows and pain points firsthand, and ensure those needs drive every development decision.

2. Set a Clear Product Vision and Strategy – Define what success looks like and keep development focused on solving real operator problems while supporting mission priorities.

3. Validate Solutions Before Committing Resources – Test concepts and prototypes with operators early to confirm they solve the right problems before large amounts of time and money are spent.

4. Use Data to Measure and Improve Outcomes – Gather and interpret data on how well the software supports operators and adjust accordingly.

5. Lead Through Influence – Align stakeholders, contractors, engineers, and decision-makers to ensure solutions advance mission goals and earn operator trust.

Without these competencies in place, software programs will continue to build to spec but fail in practice. Features that matter most to operators will show up late or never. Systems will struggle with performance and reliability because the focus stays on contract milestones rather than mission value. Operators will be forced to patch around shortcomings, adding risk to every mission they execute.

Building Product Management Talent for DoD Programs

DoD needs to develop far stronger Product Management talent across both government and contractor teams if it wants to stop repeating the same software failures. While there are well-established training resources in the commercial sector, they were designed for Silicon Valley product environments, not for the unique constraints and realities of defense software programs.

Blindly adopting these commercial teachings will lead to the same disappointment that O‑5 and O‑6 leaders have already experienced with the blind adoption of Agile, Scrum, and SAFe. Defense acquisition programs have different funding mechanisms, longer decision cycles, complex contractor relationships, classified environments, and much higher stakes for operator success. Commercial best practices must be adapted, not copy-pasted.

Every large defense software program is unique, with its own constraints, culture, and available pool of performers. The path to building strong Product Management talent must be carefully tailored for each program. Leaders who want to see meaningful improvement in outcomes should seek specialized guidance to define the right approach for their teams and ensure their contractors acquire and develop the talent required to truly close the buyer-user gap.

Call to Action for DoD Leaders 

Commercial companies learned long ago that no software delivery framework can create great products on its own. They invest heavily in Product Management because it’s the only way to ensure teams are solving the right problems for real users. The same lesson applies in DoD programs. You cannot fix this problem with more process layers or additional frameworks at the PMO level.

O‑5s, O‑6s, and PMO leaders have the authority to change this, but it requires more than assigning titles. You must regularly measure the competencies of the individuals serving as Product Managers against the skills outlined above. Titles alone mean nothing if the people holding them cannot deliver results for operators. Programs must build mechanisms to evaluate whether these critical competencies are present and growing over time.

In addition, commercial teachings, trainings, and books on Product Management must be adapted to the unique constraints of defense acquisition programs and the available pool of performers on each program. Blind adoption will disappoint just as badly as the blind adoption of Agile, Scrum, and SAFe has disappointed many leaders in the past. PMOs need to demand clarity on how these learnings are tailored for their environments and ensure their contractors have a deliberate path for developing real Product Management talent—not just checking boxes on a framework chart.

If you are leading a program and want to explore how to adapt proven Product Management practices to the realities of defense acquisition, I’m open to connecting and sharing lessons learned from 19 years of delivering large, complex defense software. This experience comes from simultaneously serving as both Product Manager and Engineering Leader on multiple product lines, giving me a perspective on what it truly takes to close the buyer-user gap and deliver software operators can trust.