For decades, the federal government has managed technology through the lens of projects — bounded by scope, schedule, and budget, measured by deliverables rather than outcomes. A project ends. A ribbon gets cut. A system goes live. And then, too often, a perfectly funded initiative quietly drifts away from the people it was meant to serve.
That model is changing. Across the federal landscape, forward-thinking agencies are embracing product management — a discipline that treats technology not as a one-time build, but as a living service that must continuously earn its value by meeting real user needs. It is a shift that is long overdue, and when done right, it transforms how government delivers on its mission.
The Problem With Project Thinking
The traditional project management model was built for predictability. Define requirements up front, lock in a contract, execute against a plan, and declare success when the deliverable ships. For building a bridge or procuring hardware, that logic holds. For developing digital services in a rapidly changing policy and technology environment, it often fails users before the first line of code is written.
Requirements gathered 18 months before a system launches rarely reflect the world users inhabit at go-live. Business owners are consulted at the beginning and then largely sidelined. End users — the employees, beneficiaries or partners who will live with the technology — are often an afterthought. The result is systems that technically meet contract requirements while functionally missing the mark.
Product management flips this equation. Instead of asking “did we deliver what we promised?” it asks “are we solving the right problem, for the right people, in the right way?” It centers the voice of the customer not as a check-the-box exercise, but as a continuous, disciplined practice woven into every sprint, every release decision, every prioritization conversation.
Building It at ARPA-H
When I had the opportunity to help introduce product management practices and formally establish Product Owner roles at the Advanced Research Projects Agency for Health (ARPA-H), the mission was clear — and the stakes were high. ARPA-H was stood up to drive transformational breakthroughs in health. The last thing it needed was an IT organization operating with an industrial-age playbook.
What we built wasn’t just a structural change. It was a cultural one. Product Owners were embedded not as intermediaries between business and IT, but as accountable stewards of outcomes. They were charged with deeply understanding the needs of the people ARPA-H serves — program managers accelerating breakthrough research, operational staff navigating complex administrative demands, and external partners bringing innovations to scale — and translating those needs into technology priorities that moved the mission forward.
Critically, we insisted that business owners stay engaged beyond the handshake at project kickoff. The Product Owner model created a durable, structured relationship between mission owners and the IT function — regular touchpoints, visible backlogs, and shared accountability for whether a system was working in practice, not just in theory.
Voice of the Customer as Operating Principle
One of the most important shifts was treating user feedback not as something gathered at the end of a project, but as oxygen that feeds every development cycle. At ARPA-H, this meant standing up structured mechanisms to hear from users continuously — validating assumptions early, catching misalignments before they became expensive, and building trust that the technology organization was listening.
When users feel heard, adoption goes up. When business owners see their priorities reflected in sprint reviews and release notes, they become advocates rather than skeptics. When Product Owners have the standing and authority to say, “this isn’t working for our users — we need to change direction,” teams are freed from the inertia of building to spec when the spec is wrong.
That is not a technology story. That is a governance story, and it is precisely the kind of governance reform that the federal government needs more of.
A Model Worth Replicating
The move from project to product management is not just about agile ceremonies and story points. It is about reorienting the entire relationship between technology, mission, and the people government serves. It requires leadership commitment, procurement flexibility, workforce development, and a willingness to measure success differently.
ARPA-H offered a compelling proving ground — a young, mission-driven agency with the operational latitude to build things right from the start. But the principles apply just as powerfully at larger, more established agencies navigating legacy system modernization, workforce technology transformation or health IT integration challenges.
The federal technology community is at an inflection point. The agencies that invest now in true product management capability — not just the vocabulary but the discipline, the structures, and the culture — will be better positioned to deliver on their missions, earn the trust of the public, and attract the next generation of public-sector technology talent.
The project is over. The product is the work, and it never stops.
Todd Hager is Vice President of Strategic Advisory for Alpha Omega, providing leadership in strategy, innovation, modernization, and team enablement. His work has been instrumental within HHS starting with the COVID response, working closely with the HHS, ACF, and ARPA-H CIOs to plan for and modernize the infrastructure and teams, while helping to develop agile, “service-forward” orientations within and between teams.
Todd is the Industry Chair for the ACT-IAC Emerging Technology Community of Interest (COI) and is a 2021 Federal 100 Award winner. He is a certified PMP, a Certified Scrum Master (CSM), ITIL v3 certified and CMMI v2 certified.
Leave a Reply
You must be logged in to post a comment.