The Portfolio Manager Is New and It Changes How Software Vendors Must Scale Inside DoW
Harvey Morrison: Co-Founder/CEO, Marion Square
This post is Part Two of a Marion Square blog series examining the Department of War’s shift to the Warfighting Acquisition System and what it means for commercial technology vendors.
In the first post, The Warfighting Acquisition System: What the Biggest Shift in DoD Buying Means for Technology Companies, we outlined why the Department is fundamentally redesigning how it acquires and fields technology—prioritizing speed, modularity, and mission impact over legacy process.
This article goes deeper into one of the most consequential structural changes introduced in that strategy: the creation of portfolio-level acquisition leadership, and why this new role materially changes how software vendors should think about scaling inside DoW.
The Department of War’s new acquisition strategy makes a quiet but consequential admission: the way DoW has historically acquired software no longer works at scale.
For years, software capabilities entered the department program by program. Teams bought tools to solve local problems analytics here, workflow there, an AI model somewhere else. Many of these decisions made sense in isolation. Collectively, they created fragmentation, duplication, and systems that were difficult to integrate or extend.
The new acquisition strategy responds to this reality by introducing something DoW did not previously have in a formal, empowered way: portfolio level ownership of digital and software capabilities.
That is where the new Portfolio Manager role comes in.
This role is not an evolution of existing acquisition jobs. It is a structural change designed to fix how software scales or fails to scale inside DoW.
What Changed in the New Acquisition Strategy
The acquisition strategy is explicit in its intent to move away from isolated, program specific technology decisions and toward enterprise and portfolio based management of capabilities, particularly in software intensive domains.
The new strategy document emphasizes outcomes such as:
Reducing duplicative software investments
Improving interoperability and reuse
Enabling continuous delivery and upgrade of digital capabilities
Making deliberate decisions about which tools become enduring, enterprise relevant solutions
Those objectives cannot be achieved if every software decision is made independently at the program level. They require a layer of governance that looks across programs and over time.
The Portfolio Manager role is the mechanism DoW is introducing to provide that governance.
What a Portfolio Manager Does in a Software Context
For software vendors, it is critical to understand what this role actually exists to do.
Portfolio Managers are not writing requirements and they are not awarding contracts. Their job is to decide which software capabilities should persist, expand, or consolidate across the department.
In practice, that means they are asking questions like:
Is this capability solving a problem that exists in multiple parts of the organization?
Does it integrate cleanly with existing platforms, data environments, and workflows?
Is it duplicative of tools already in use elsewhere?
If this works in one place, should it be reused broadly—or constrained deliberately?
These questions were previously answered implicitly, inconsistently, or not at all. The new strategy makes them explicit and assigns ownership for answering them.
How This Differs from the Old Model for Software Vendors
Under the prior acquisition model, a software vendor could scale by successively selling into adjacent programs. Expansion was often opportunistic, relationship driven, and slow. Each deployment stood largely on its own.
The new strategy changes the logic.
Scaling is no longer just about selling the same software multiple times. It is about being recognized as a portfolio relevant capability.
That recognition does not happen during source selection. It happens after software is deployed, when DoW evaluates whether the capability should become shared, standardized, or expanded across missions or organizations.
This is the key shift software vendors must internalize.
What “Scaling” Now Actually Means for Software
Under the new acquisition approach, a software capability scales when a Portfolio Manager determines that it:
Addresses a recurring need across the organization
Reduces complexity rather than adding to it
Fits into the broader digital architecture
Justifies continued and expanded investment over time
A vendor can deliver a successful pilot, meet all performance requirements, and still not scale if their software is viewed as narrowly useful or difficult to integrate.
Conversely, a focused deployment that demonstrates reuse potential and architectural alignment can become a foundation for broader adoption.
Why This Matters to Software Vendors Right Now
The Portfolio Manager role is new, and DoW is still operationalizing it. That creates a transition period where old assumptions and new decision making structures coexist.
Software vendors that continue to treat each engagement as a standalone sale may find that interest does not translate into expansion. Vendors that understand the portfolio lens early can shape how their software is evaluated from the start.
This does not replace the need to understand acquisition rules or contract vehicles. It adds a new layer that did not previously exist in a formal way.
Ignoring that layer does not break compliance but it does limit scale.
The Marion Square Perspective
Marion Square works with software vendors navigating this exact shift.
Our focus is helping companies:
Understand how DoW’s acquisition strategy changes post-award decision-making
Position software as a reusable, portfolio-relevant capability
Align early deployments with how DoW now thinks about scale
The Portfolio Manager role is new because the problem it addresses is now unavoidable.
For software vendors, adapting to this model is not about learning a new buzzword. It is about understanding where DoW now decides which software becomes enduring infrastructure and which remains a one off tool.
Next in the series: a closer look at how OTAs, CSOs, and rapid pilots are used by DoW to evaluate software capabilities before making portfolio-level scale decisions.