top of page
Search

American Government Needs More Product Managers

Updated: 2 days ago

Project managers deliver what you asked for. Product managers deliver what users want. 


The US has amassed trillions of dollars in technical debt, across all levels of government, and is decades removed from being a global leader in digital public services. How did this happen? In large part by saddling projects with too many cooks, too many requirements, and the wrong overall playbook.


America’s best technology firms have long ago moved to some version of the Directly Responsible Individual model. In Silicon Valley today this individual is usually styled a product manager. Where a traditional project manager is in charge of wrangling updates and making sure that the train is still rumbling forwards, product managers have a more specific goal: making sure that the right things, and only the right things, are being done. 


Rather than dispersing this responsibility widely, the product manager model forces all collaboration and decision-making through a single person, who then owns the results. 


There are three reasons this works:


1. Product managers want to be judged by outcomes, not checkboxes


Jennifer Pahlka, a former deputy CTO in the Obama administration, reflected on her government experience in Recoding America. It’s become a bible of sorts on how the public sector should think about software and digital services, and the ways in which they’ve historically gotten it backwards. 


A telling anecdote, from page 63:

“I’ve spent my entire career training my team not to have an opinion on business requirements,” he told me. “If they ask us to build a concrete boat, we’ll build a concrete boat.” Why? I asked. “Because that way, when it goes wrong, it’s not our fault.” 

The classic danger of too many stakeholders is that project teams will ultimately deliver what makes the most people in the hierarchy happy—often at the expense of real users. This approach pushes builders towards safety, even when the outcome is a concrete boat.


It’s not that hierarchies shouldn’t exist. Product managers should never decide unilaterally on their instincts alone. But their job is to be relentless at chasing and incorporating feedback in service of one singular goal: building the software that real end users actually want. 


How do I make sure vendors offer this type of product manager?


2. Product managers create real feedback loops


Few organizations work well in a pure top-down fashion. The most useful information in any project comes from the front, and any decision made without that data will be worse for it. 


Real users don’t have our context. They navigate interfaces as if they’d never seen them before, because usually they haven’t. They don’t know what they don’t know, and will mostly remain forever ignorant of how their problem is covered in detail on page 74 of an unwieldy guide that only a dozen people have ever read in full. They just want stuff to work.


A great product manager is a pitbull advocate for end users as they actually exist, and ensures that every design and engineering decision factors real-world usage patterns. 


How does this apply to internal users on the government side?


3. Product managers resolve tensions by leaning into them


Healthy collaboration should never be combative. But it should be a bit frictional, in that it should surface and directly address tensions that will always exist when multiple parties are asking for different things. 


A good product manager respects chains of command, and works hard to understand the Chesterton’s Fence aspect of why requirements exist. But they’ll also push to ensure that any compromises to usability and simplicity are truly necessary. If a given requirement isn't actually mandated by legislation but is just, say, a committee interpretation, they’ll see it as their job to consult with developers and users to draw up better alternatives.


The payoffs for this are tangible. When a taxpayer logs on to a digital government service, they’ll notice if it feels designed around their needs and technical knowhow. When it does, good things follow. 


What if our requirements are set in stone and there’s little room for discretion?




 
 

Related Posts

See All
Our Working Principles

The seven principles that keep us grounded to the only end goal: using tax dollars well.

 
 
bottom of page