Product Management Talent: The Critical Gap Agile and DevSecOps Can't Fix

By Andrew Park | 2025-10-16

The F-35 Joint Program Office adopted Agile-based methods in 2018 and DevSecOps practices shortly thereafter, while Lockheed Martin began implementing Scaled Agile Framework in 2013 and stood up its Software Factory with DevSecOps methodology [Fli20, Dov18, Loc25]. Over a decade of methodology adoption later, the results tell a damning story.

In January 2025, the Pentagon's test office reported the F-35 program "has shown no improvement in meeting schedule and performance timelines for developing and testing software" [Def25]. Years earlier, Air Force Secretary Heather Wilson criticized the F-35's logistics system as so frustrating that maintainers were "wasting 10-15 hours a week fighting with it" [Tir19]. The software still fails operators.

This isn't an isolated failure. It's emblematic of a systemic problem across defense software development.

This article makes the case for why building product management expertise must become a top priority across the entire Defense Industrial Base in government program offices, research laboratories, prime contractors, and subcontractors alike. The DoD has the leverage to drive this change through contractual requirements and acquisition reform.

Bottom Line: Defense software keeps failing operators because the Department is solving the wrong problem. The biggest issue isn't delivery speed; it's the requirements gap. The DoD is constantly building the wrong things fast and then backtracking once requirements gaps are uncovered. This inflates costs, delays fielding, and delivers capabilities that frustrated operators must devise work-arounds to get their jobs done. Product management talent solves the requirements gap by validating requirements before committing the bulk of the engineering resources. Agile and DevSecOps can't fix this because they assume someone already figured out what to build. O-6 program managers have direct leverage through contract requirements and source selection to demand that contractors demonstrate real product management capability, not just retitled project managers, on every software-intensive effort.

The Requirements Gap Is Killing Defense Software

Defense software's biggest problem is the requirements gap, not software delivery. While the DoD does face delivery challenges, the far more critical issue is determining what products should be built and what their requirements are before the bulk of engineering resources are engaged in building software. Getting the wrong requirements to operators faster doesn't help them. It inflates acquisition costs and significantly slows modernization efforts.

Product management talent is the solution to the requirements gap. Product managers bridge the buyer-user disconnect, translate operator needs into buildable requirements, and own product success. Without sufficient product management talent, no amount of Agile sprints or DevSecOps pipelines will deliver software that operators actually need.

Agile, Scrum, and DevSecOps cannot solve the requirements gap because they assume requirements discovery is much more straightforward than it actually is. These methodologies focus on how to build and deploy software, operating on the premise that organizations can simply ask customers what they want and quickly validate it through iteration. This assumption breaks down catastrophically in defense software, where the buyer-user disconnect means requirements discovery is the hardest and most important problem [Par25].

The Department of Defense has spent two decades chasing commercial software methodologies (Agile, Scrum, Scaled Agile Framework (SAFe), DevSecOps) believing these frameworks would accelerate modernization. But this approach has failed to produce breakthroughs in defense platform software outcomes because it addresses delivery while ignoring the requirements gap.

Why Delivery Obsession Misses the Mark

These commercial methodologies all share a critical flaw: delivery obsession. Agile, Scrum, and DevSecOps are about how to build and deploy software rapidly, but they gloss over the fundamental question of what to build. They're execution frameworks designed for small teams in consumer software startups, where users can switch to competitors if something breaks and the cost of failure is measured in user churn, not mission failure or lives lost.

Defense software development operates under entirely different constraints. These are large, complex platforms with multi-decade lifespans, high consequences of failure, and demanding compliance obligations. For these systems, requirements discovery is paramount. Yet Agile, Scrum, SAFe, and DevOps all minimize requirements discovery, assuming the hard work of figuring out what to build has already been done.

The result is predictable: without proper product management to define what should be built, development efforts generate excessive waste through constant backtracking. Requirements appear unstable not because they're inherently volatile, but because the upfront product work was never adequately completed. High tech debt, fragile systems, long onboarding times, and expensive sustainment burdens can often be traced back to lack of product management. No amount of engineering excellence can overcome fundamentally flawed requirements.

Why the Commercial Tech Industry Had to Solve This Outside the Agile Community

The product management field exploded in commercial tech over the past 10 to 15 years because Agile, Scrum, SAFe, and DevOps communities glossed over requirements discovery so severely that an entirely separate discipline had to emerge to fill the gap.

This neglect wasn't accidental. It stems from the fact that thought leaders in the Agile, Scrum, DevOps, and SAFe communities are heavily engineering-focused rather than business-focused. Their frameworks naturally prioritize what engineers care about: iteration speed, deployment frequency, technical practices, team dynamics. What gets short shrift is the business problem of determining what to build in the first place, a problem that requires different expertise and a different mindset.

When it became clear that Agile and Scrum weren't scaling beyond small teams, the engineering-focused community responded with SAFe, a framework that attempted to coordinate multiple Agile teams without fundamentally addressing requirements discovery. SAFe has been declining in popularity because it doubled down on delivery coordination while still assuming someone else had figured out what to build.

Meanwhile, a completely different discipline (product management) was quietly taking over the requirements problem. Product management emerged as the scaling approach that outperformed SAFe, Large-Scale Scrum (LeSS), and Scrum of Scrums, not by coordinating more delivery teams, but by tackling requirements discovery head-on with business-focused professionals who own product success.

The greatest evidence of this split is geographic: West Coast tech companies are dominated by product management practices while SAFe is scarcely found in those same companies. These companies still use Agile practices at the team level, but they scaled their organizations through product management hierarchies rather than through frameworks like SAFe, LeSS, or Scrum of Scrums. The engineering-focused delivery frameworks lost the scaling battle to a business-focused discipline because in complex software products, figuring out what to build is more fundamental than coordinating how to build it. Requirements discovery must be addressed first and addressed very well before committing substantial engineering resources to build something big. Getting delivery right doesn't matter if you're building the wrong thing.

The commercial tech industry's recognition of product management's primacy is now unambiguous. Marc Andreessen, co-founder of Andreessen Horowitz, stated: "If I don't have a great product manager, a great product originator... I'm not going to get a great product" [Gil25]. His partner Ben Horowitz wrote: "A good product manager takes full responsibility and measures themselves in terms of the success of the product" [Hor24].

The DoD has made the same mistake the Agile community made: assuming that engineering-focused delivery methodologies would somehow produce great products. They won't. The commercial tech industry learned this lesson over the past 15 years. The defense sector needs to learn it now.

The Proof: Defense Companies That Solve the Requirements Gap

Defense technology companies provide clear evidence of what happens when organizations prioritize product management talent. Companies like Anduril, Palantir, and Shield AI have delivered operationally successful products not because they follow Agile or DevSecOps methodologies better than traditional primes. They've succeeded because their founders and leadership teams possess deep product management expertise that enables them to solve the requirements gap.

What truly sets these defense technology companies apart from the vast majority of the traditional Defense Industrial Base is not their commercial pedigree or their software development processes. It's that they know how to discover and validate requirements, manage product risks, and own product success in ways that traditional defense contractors do not. This is a learnable, transferable skill set, not Silicon Valley magic.

The proof is in operational outcomes. Palantir's software is used by warfighters in combat zones because its product managers spent years embedded with operators, discovering actual requirements rather than gathering requirements from proxies. Anduril's autonomous systems are being fielded because its product management team validated feasibility, usability, and viability risks before committing to large-scale development. These companies didn't succeed by being faster at delivering software. They succeeded by being better at figuring out what to build.

This isn't accidental. The venture capital firms that back successful defense technology companies explicitly prioritize product vision and the ability to achieve product-market fit when evaluating founders. Andreessen Horowitz and Founders Fund understand that great defense products come from founders who can identify what to build and validate it with operators, not from simply adopting the latest development methodology [And25, Pal25].

The lesson for the Defense Industrial Base is clear: great software outcomes are not about importing commercial software practices like Agile and DevSecOps. It's about ensuring the people leading software efforts possess the skills to solve the requirements gap. Traditional defense contractors can develop this capability, but only if the DoD demands it contractually and holds them accountable for results.

What Real Product Management Looks Like

Before the DoD can contractually require product management excellence, it must understand what that excellence entails. This is the job of product management. Bona fide product managers are responsible for minimizing five critical product risks before committing substantial engineering resources.

These five risks are (1) Value Risk: Will this capability actually improve mission outcomes? (2) Viability Risk: Can this program deliver within constraints? (3) Usability Risk: Can operators employ this under operational conditions? (4) Feasibility Risk: Can this be built with available technology and workforce? (5) Sustainability Risk: Can this be maintained throughout the platform's life? [Cag17]

These five risks define what product managers must own. This is fundamentally different work from what project managers and systems engineers do.

#1 Value Risk: Will this capability actually improve mission outcomes? Product managers must validate that the proposed solution solves a real operational problem that warfighters face. For platform software like avionics systems, mission planning tools, or autonomous control systems, this means proving the software will enable the platform to execute its intended missions effectively. Product managers validate value through continuous engagement with operators and test pilots, testing prototypes in realistic conditions, and measuring whether proposed capabilities address genuine operational requirements rather than assumed needs.

Without proper value validation, programs fund capabilities that operators work around instead of rely on. Systems get delivered on time and on budget that don't solve the actual problem.

#2 Viability Risk: Can this program deliver within constraints? Product managers must ensure the solution is achievable within budget, complies with all applicable regulations and security requirements, satisfies legal and contractual obligations, and aligns with program office priorities. This includes understanding acquisition timelines, lifecycle costs, classification requirements, platform integration constraints, software licensing requirements, and how the capability fits within broader force structure and doctrine. A valuable capability that cannot be fielded due to cost, compliance, platform integration challenges, or programmatic constraints has failed.

Viability failures manifest as cost overruns and schedule delays. Product managers who properly assess viability risk prevent nasty surprises during Engineering and Manufacturing Development (EMD) and production.

#3 Usability Risk: Can operators effectively employ this under operational conditions? Product managers must ensure that pilots, mission commanders, and maintainers can actually use the software effectively in the field, often under high-stress combat or time-critical conditions, without excessive training burden. For platforms like the F-47, B-21, or Collaborative Combat Aircraft (CCA) autonomous drones, this means validating that cockpit interfaces are intuitive under combat stress, that mission planning systems don't create workload bottlenecks, and that maintenance diagnostic tools actually help maintainers troubleshoot problems quickly. Usability demands will skyrocket in the near future as the services transition to Multi-Capable Airmen, Sailors, Soldiers, and Marines who must operate multiple complex systems and perform multiple job roles that were previously handled by different specialized personnel. Software that requires extensive specialized training for each system or creates cognitive overload will fail in this operating environment. Usability is validated through testing with actual operators in realistic scenarios, not assumed because the software functions technically.

Poor usability forces operators to fight their own systems. These problems surface during operational testing, but by then programs have already committed years and millions to the wrong design.

#4 Feasibility Risk: Can this be built with available technology, workforce, and industrial base capacity? Product managers must work closely with engineering teams to validate that proposed solutions are technically achievable within program constraints. This includes assessing technical risk, understanding dependencies on platform hardware and other defense systems, evaluating dependencies on third-party libraries and commercial software, ensuring availability of required development tools and infrastructure, ensuring compatibility with existing platform architectures, and ensuring the engineering team has the clearances, skills, and access to development environments needed to deliver.

Critically, feasibility includes discovering and delivering on all necessary quality attributes. Product managers must work with engineers to define and validate requirements for quality attributes such as performance, security, scalability, availability, accuracy, and Size, Weight, and Power (SWaP) constraints for embedded platform systems. These are not afterthoughts but fundamental requirements that must be discovered early and validated throughout development. A mission planning system that produces perfect routes but takes too long to compute has failed. An avionics system that meets functional requirements but exceeds power budgets has failed. Product managers collaborate with technical leads and systems engineers to validate feasibility before committing to development.

Feasibility failures surface as technical risks that blow up schedules. Contractors report late in development that solutions don't meet performance requirements or exceed SWaP constraints. Product managers who properly assess feasibility prevent these program-killing discoveries.

#5 Sustainability Risk: Can this capability be maintained and supported over its operational lifetime? Product managers must ensure that long-term maintenance and support are achievable with realistic workforce and funding commitments. This includes validating that the codebase is written, organized, and documented in ways that new engineers can understand and modify, that technical knowledge isn't lost when people leave, that development tools and dependencies remain available, that the architecture remains adaptable as technology evolves, and that lifecycle costs beyond initial fielding are accurately projected and affordable. For defense platforms that operate for decades, a capability that cannot be sustained becomes a liability. Product managers must work with software architects, DevOps engineers, and sustainment teams to validate that the solution can be maintained effectively throughout its expected service life.

Sustainability failures create future unfunded requirements. Programs build platforms meant to operate for 30+ years, but if the software can't be maintained, they've created a future budget problem that consumes resources meant for other priorities.

This is the job. Real product managers address all five risks during requirements discovery, before large-scale engineering efforts begin. They don't deliver requirements documents and disappear. They remain embedded with engineering teams throughout development, continuously validating that the capability will succeed on all five dimensions.

These responsibilities require a fundamentally different skill set from project management or systems engineering. Product managers own the strategic question of what to build and validate that it will succeed across all five risk dimensions. Many project managers and systems engineers cannot transition to product management because the work requires different aptitudes, different experience, and a different mindset.

Contractors who cannot demonstrate this capability, who cannot show their product managers actively managing these five risks, do not have real product management talent. They have project coordinators with different titles. The DoD must establish clear qualification standards for product management roles to prevent contractors from simply retitling existing staff without ensuring they possess the requisite skills. What matters is that sufficient talent with genuine product management capability is acquired and retained to perform this critical work on all complex DoD software development efforts.

Defense's Structural Challenge: The Buyer-User Disconnect

One critical reason the requirements gap is so large in defense is the structural buyer-user disconnect. The people funding and specifying DoD software are rarely the same people who depend on it in the field [Par25]. Unlike hardware programs where operators are embedded throughout development, software acquisition allows this gap to persist, resulting in systems that are non-performant, hard to use, and rarely match how missions are actually executed.

Without strong product management to bridge this gap, Program Management Offices devote their attention to day-to-day management of software delivery teams instead of realizing the requirements gap is the glaring problem and that they don't have the talent in place to address it. The result is technically delivered systems that fail to meet operator needs, require extensive retraining, and generate workarounds in the field. Organizations cannot engineer their way out of poor product strategy, no matter how fast they sprint.

Beyond User Feedback: The Need for Deep Domain Expertise

Continuous operator engagement is only the beginning. True product management excellence in defense requires professionals who commit to the field long enough to develop domain expertise that exceeds that of typical end-user operators.

Most operators serve only a few years and can only express immediate pain points and feature tweaks within their siloed roles. Great product managers absorb the domain over many years, eventually understanding the full scope of what's needed more deeply than the operators they serve. This depth of understanding enables genuine innovation.

As Henry Ford reportedly said, "If I had asked people what they wanted, they would have said faster horses." Operators typically describe incremental improvements to existing workflows rather than envision transformational capabilities. Only product managers with deep, accumulated domain knowledge and awareness of what's possible with emerging technologies can recognize opportunities for breakthrough solutions that operators cannot yet imagine.

This buyer-user gap is precisely why the government must insist that Defense Industrial Base companies recruit, grow, and retain product management talent in everything they produce for the DoD. Product managers are the critical bridge between what gets funded and what operators actually need to accomplish their missions.

The Cost of Continuing Without Product Management Talent

The requirements gap is not a static problem. Every year the DoD delays addressing it, the cost compounds and programs commit to building the wrong capabilities.

When programs build capabilities based on poorly discovered requirements, the cost doesn't stop at initial development. Rework during development happens when engineering teams discover mid-stream that requirements don't match operator needs. Programs burn months and millions redesigning. Changes during testing occur when Operational Test and Evaluation (OT&E) reveals usability problems or performance shortfalls. Program offices negotiate with contractors about whether fixes are in scope. Post-deployment modifications become necessary when operators find workarounds because the software doesn't actually support their workflows. Eventually programs fund "capability improvements" that should have been in the original design. Sustainment cost growth happens because software that didn't consider maintainability during development drives up Operations and Support (O&S) costs every year.

For a major platform, poor requirements discovery adds hundreds of millions to lifecycle costs. That's money that could have funded additional capability or other programs.

Poor requirements discovery is why software efforts slip schedules. Requirements churn forces repeated design iterations. Late discovery of feasibility issues requires architectural changes. Usability problems found during testing force interface redesigns. Integration issues surface because no one validated dependencies upfront.

Program offices report schedule delays to leadership. But the root cause is that no one managed product risks before committing to development.

Systems built without proper requirements discovery create hidden readiness problems. Operators train on systems that don't match how they'll actually execute missions. Work-arounds become standard operating procedures. Mission planning takes longer because the software fights the operators. Maintainers struggle because software wasn't designed for field maintenance.

Platforms might meet technical specifications but fail to deliver the intended warfighting capability. That's a requirements failure, not a delivery failure.

Every year the DoD doesn't demand product management capability, the problem persists. Contractors have no incentive to invest in product management talent because the DoD hasn't required it. The Defense Industrial Base will not build this capability on its own. Without explicit contractual requirements, prime contractors and their subcontractors will continue assigning project managers and systems engineers to coordinate software delivery without addressing the requirements gap.

The solution is straightforward: the DoD must lead by demanding product management excellence in contracts, and the Defense Industrial Base will respond by acquiring and developing this talent. Contractors will invest in what the customer requires. If the DoD makes product management capability a decisive factor in source selection, the DIB will quickly build the necessary expertise. The DIB cannot produce the modernization outcomes the DoD needs without getting this talent on board and engaged in all its efforts. But the impetus must come from the customer.

Programs are in requirements definition or early development right now. This is when product management matters most. If programs commit to full-scale development without proper requirements discovery, they lock in years of problems.

By the time programs reach Initial Operating Capability (IOC), the requirements failures will be baked in. The cost to fix them will exceed program budgets. Schedule impacts will push programs years to the right. Capability gaps will be operational realities.

The platforms being developed today will operate for 30+ years. The software being built now will define how thousands of warfighters execute their missions. Getting the requirements wrong now locks in decades of problems.

The Path Forward: How O-6 Program Managers Can Drive Change

O-6 program managers have direct leverage to fix the requirements gap. They don't need to wait for policy changes from above. They can demand product management excellence in their contracts through source selection criteria and contract requirements.

This applies equally to acquisition program managers and to research laboratory leaders funding technology development. For research organizations, demanding product management excellence in technology development contracts ensures promising technologies solve real operational problems and can successfully transition to acquisition programs.

For organizations like Kessel Run, Platform One, and the Army Software Factory that build software internally rather than through traditional contractors, the product management imperative remains the same. These organizations must ensure their product managers possess the skills to manage all five product risks and remain deeply embedded with operators. The advantage these organizations have is direct control over hiring and developing product management talent, rather than relying on contractors to provide it. However, building this capability internally still requires the same rigorous approach to requirements discovery and the same commitment to addressing value, viability, usability, feasibility, and sustainability risks that external contractors need.

The next software-intensive contract awarded should explicitly evaluate product management capability. Program offices should not accept proposals that simply list "product manager" on an org chart. They should demand evidence that these individuals can address all five product risks.

In Requests for Proposal (RFPs), program offices should require resumes demonstrating product management experience, not just project management. They should ask for case studies showing how proposed product managers discovered and validated requirements before development. They should include interview questions that test whether proposed product managers understand the five risks. They should score this as heavily as technical approach and past performance.

Program offices should not let contractors claim their systems engineers or project managers will "also do product management." That's how programs end up building the wrong thing.

Product managers who can address all five risks are as critical as lead systems engineers and should be compensated accordingly. If contractors are billing product managers at project coordinator rates, programs are not getting product management talent.

Program offices should watch for contractors trying to fill product management roles by retitling existing project managers without salary changes. They should watch for product management positions billed at rates significantly below systems engineering leads. They should watch for proposals that treat product management as an overhead function rather than a critical technical role.

Programs should fight for the budget to pay for real talent. A single requirements failure that forces a major redesign will cost more than paying properly for product management upfront.

Program managers need to build their own literacy in product management so they can evaluate whether contractors actually have this capability. They should attend product management training. Defense Acquisition University (DAU) should offer this; if they don't, program managers should demand it. They should talk to program managers at defense tech companies like Anduril or Palantir about how their product managers work. They should review current contracts and ask whether their "product managers" are just coordinating backlogs or actively managing the five risks. They should hold quarterly reviews where product managers brief how they're addressing each of the five risks.

If a contractor's "product manager" can't articulate how they're managing value, viability, usability, feasibility, and sustainability risks, the program doesn't have product management.

Programs that implement these changes will see more stable requirements because they were properly discovered upfront. They'll catch usability and feasibility problems before committing to full-scale development. Operators will be involved throughout, not just shown the finished product during OT&E. Cost and schedule will be more predictable because product risks were validated early. Software will actually work for operators the way they need it to work.

Programs without product management already know what happens. Requirements churn throughout development as engineers discover what operators actually need. Major design changes late in the program when technical feasibility issues surface. Delivered systems that meet specifications but don't solve operators' problems. Expensive post-delivery modifications to make unusable software usable. Sustainment nightmares because maintainability wasn't considered during development.

Every software-intensive program that has struggled likely suffered from the same root cause: no one was managing the five product risks upfront.

O-6 program managers control source selection. They write RFPs. They evaluate proposals. They hold contractors accountable.

The question isn't whether the Pentagon will mandate product management excellence from above. The question is whether program managers will demand it on their programs right now. They don't need permission to make product management capability a source selection criterion. They need the will to do it and the knowledge to evaluate it.

The F-35 program spent a decade on Agile and DevSecOps without addressing the requirements gap. Programs should not repeat that mistake. Demanding product management talent will result in capabilities that work for the operators who depend on them.

Scaling Product Management Excellence Across Defense

While O-6 program managers can drive immediate change through source selection, broader institutional changes could accelerate progress across the entire DoD.

One promising approach would be making demonstrated excellence in product management a contractual requirement across all software-intensive programs to ensure consistent standards. Source selections could assess whether contractors have senior product management talent with deep domain expertise leading their software efforts. This would need to be measured, evaluated, and tied to contract awards. Contractors who cannot demonstrate real product management capability would be less competitive for software contracts.

The Under Secretary of Defense for Acquisition and Sustainment (USD(A&S)) could consider issuing acquisition guidance requiring all software-intensive programs to include specific product management qualifications in their source selection criteria. Given the scarcity of this talent, proposals could demonstrate product management capability through formal training credentials from recognized product management training organizations, evidence of domain expertise development, and concrete plans for building and retaining product management talent within their organization.

Another important step would be paying for senior product talent the way the DoD pays for systems engineers. Product managers who can capably address all five product risks need to be recognized as critical technical contributors, not program administrators. Compensation and career progression should reflect this reality. The DoD should be wary of DIB companies that fill these roles by simply retitling existing project managers and systems engineers. That approach will not solve the requirements gap. This requires people with real, proven product management skills and knowledge. The DIB will not attract and retain world-class product management talent capable of managing these five risks if they treat these roles as glorified project coordinators.

The DoD could establish General Schedule (GS)-2210 product management career tracks in government with compensation parity to systems engineers. Program offices could budget for senior product management positions at salary levels competitive with systems engineering leads. Evaluation criteria could prevent contractors from claiming product management capability without demonstrated expertise.

Developing technical literacy in government program offices would enable proper evaluation and accountability. Program managers need to understand what great product management looks like and demand it. Without this literacy, the DoD cannot effectively evaluate contractor proposals or hold them accountable for product management excellence.

Defense Acquisition University (DAU) could develop a product management assessment course for program managers on software-intensive programs. This course could train government personnel to evaluate whether contractors possess genuine product management capability versus rebranded project management. This kind of training would help Program Executive Officers, laboratory directors, and acquisition leaders make better source selection decisions.

Consider the scale of what's at stake: the F-35 fleet is expected to operate until 2070 with over 2,400 aircraft planned for the U.S. services alone. Virginia-class submarines will be acquired through 2043 and remain in service into the 2070s. The B-21 Raider won't reach full operating capability until the early 2030s, with at least 100 aircraft planned. The Army's Future Long-Range Assault Aircraft is targeting initial fielding in 2030 with up to 334 aircraft by 2040.

These programs represent hundreds of billions in acquisition costs and trillions in lifecycle sustainment. Modern platforms are defined more by software than hardware with each passing year, and with the rise of autonomy, this shift is accelerating. The longer the DoD waits to address the root causes of poor requirements definition, the worse the problem becomes.

The stakes couldn't be higher. In an era where software defines more and more of warfighting capability, future modernization efforts will grind to a halt under the weight of building the wrong capabilities if the DoD doesn't fix this talent gap.

To build the future, the Department must abandon the delivery obsession that has dominated defense software thinking for two decades. It must start growing the product management talent inside its own walls, both in government and across the entire Defense Industrial Base. The DoD has the acquisition leverage to make this happen. It's time to use it.

References

[And25] "Anduril Industries." Wikipedia. https://en.wikipedia.org/wiki/Anduril_Industries

[Cag17] Cagan, Marty. "Inspired: How to Create Tech Products Customers Love." 2nd ed., Wiley, 2017. The framework of value risk, viability risk, usability risk, and feasibility risk is adapted from Cagan's work. Sustainability risk has been added to address the unique challenges of defense platforms that operate for decades.

[Def25] "The F-35 program's software development isn't getting any better, Pentagon report finds." Defense One, February 4, 2025. https://www.defenseone.com/technology/2025/02/f-35-programs-software-development-isnt-getting-any-better-pentagon-report-finds/402725/

[Dov18] Dove, Rick, William Schindel, and Lockheed Martin Corporation. "Case Study: Agile Systems Engineering at Lockheed Martin Aeronautics Integrated Fighter Group." Conference on Systems Engineering Research, 2018. https://www.researchgate.net/publication/327072122

[Fli20] "'Agile' strategy fails to deliver as F-35 upgrade two years late and cost rise $1.5bn." Flight Global, May 14, 2020. https://www.flightglobal.com/fixed-wing/agile-strategy-fails-to-deliver-as-f-35-upgrade-two-years-late-and-cost-rise-15bn/138345.article

[Gil25] Gil, Elad. "An Interview with Marc Andreessen." High Growth Handbook. https://growth.eladgil.com/book/introduction/where-to-go-after-product-market-fit-an-interview-with-marc-andreessen/

[Hor24] Horowitz, Ben. "Good Product Manager/Bad Product Manager." Andreessen Horowitz, May 9, 2024. https://a16z.com/good-product-manager-bad-product-manager/

[Loc25] "Software Factory." Lockheed Martin. https://www.lockheedmartin.com/en-us/capabilities/digital-transformation/software-factory.html

[Pal25] "Palantir Technologies." Wikipedia. https://en.wikipedia.org/wiki/Palantir_Technologies

[Par25] Park, Andrew. "Why DoD's Biggest Software Programs Keep Failing Operators: How the Buyer-User Disconnect and Weak Product Management Put Mission Success at Risk." LinkedIn, August 1, 2025. https://www.linkedin.com/pulse/why-dods-biggest-software-programs-keep-failing-operators-andrew-park-ghgme/

[Tir19] Tirpak, John A. "Air Force Tries To Fix F-35's ALIS: From A Big, Broken Box To the Cloud." Breaking Defense, March 29, 2019. https://breakingdefense.com/2019/03/air-force-moving-f-35s-alis-from-a-big-broken-box-to-the-cloud/