Yes, Virginia, there really are products in government
"Don't fight paper with paper," and other reminders that plenty of folks are doing it right in government
Since my product vs project funding post, I’ve gotten a lot of questions, but one in particular that I feel I need to address. “Are there any IT investments that would count as products by your definition?” “Are products in government even possible?”
The answer is, of course, yes. The point of the post was to highlight how hard it is to build in a product model when your funding comes in one big chunk, on the condition that you’ve planned every feature and requirement ahead of time. But teams don’t always have the option of going for that big chunk of funding, often because they just don’t have the time to develop requirements, write a plan, get approval, engage procurement, issue an RFP, and select a vendor.
Imagine you’re at the Department of Transportation and the pandemic shutdown causes a supply chain crisis, for instance. You can start to see how aggregating data from ocean carriers, trucking companies, ports, railroads, retailers, and others would provide enormous value to the entire ecosystem. Each player could adjust their plans based on the insights from a data platform, if it existed. But a traditional IT project would take several years just to get started, much less deliver working software. In the meantime, the impact on the supply of goods is driving up prices and hurting the economy. What do you do?
If you’re Andrew Petrisin, Deputy Assistant Secretary for Multimodal Freight, you scrape together the change in the couch cushions (so to speak), find some internal developers, and recruit a small subset of your ecosystem partners, who will be both the data providers and the users of this platform. You set everyone’s expectations for a true minimum viable product (MVP) and get going. You start delivering value to your early users in small increments, enough to earn and keep their trust, so that more and more of them want to provide their data, and so that every subsequent release is better and better because it’s been co-created with and tested by users. You do all this without most of the trappings of a government IT project.
This is how the team at DoT built FLOW (Freight Logistics Optimization Works). It’s absolutely a product, and a good one. There’s a lot more to the story of FLOW, and Allie Harris and I have written up more of it (by no means all of it) on the Federation of American Scientists blog. Give it a read here
FLOW is probably a better product than it would have been if it had all the “advantages” of planning and funding that come with traditional IT projects in government. But even without the benefit of having to dig through the couch cushions for budget, and all that unintentionally unlocks, teams still pull off incredible products that are built iteratively with constant user feedback and learning. Take, say, Direct File, the IRS’s new (free!) tool for low-income filers.
Direct File’s coup was not lack of funding. I exactly don’t know how they budgeted or planned for it. I know there was $15M in the Inflation Reduction Act for a study, which the IRS brilliantly used to do a prototype. That prototype created much the same kind of momentum the FLOW team saw from just making stuff and sharing it with their community. Andrew’s line about FLOW that really got me was “you can’t fight paper with paper.” The Direct File team knew that instinctively, which is why they showed what a product would look like instead of gathering requirements and writing an RFP. You fight paper with product, even very early, bare bones, not-even-really-working-just-showing-how-it-would-work product.
Fight paper with product
But their real coup wasn’t the prototype. It was a limited launch. (You can call it a staged roll out, an MVP, or whatever you want…it’s all about not trying to do everything from day one.) Direct File launched this tax season, but was only available to residents of 12 pilot states, and only to people in certain circumstances. It didn’t work for gig workers, for instance; only W2 wage earners could use it for the 2023 tax year.
This raised huge alarms in DC. Former IRS commissioner Mark Everson told the Washington Post: “You’ve got to develop this so it’s comprehensive. If it’s just treating the more simplified [tax returns], what about the more complex sets of circumstances?” Members of Congress hostile to the IRS generally and supportive of Intuit’s specious and self-interested attacks on the project used the limited launch as a punching bag of course, but lefty members weren’t entirely supportive either; they were constantly pushing for a broader roll out, and worried that these limited ambitions were somehow a sign of failure before the team had even started. Even IRS-friendly outlets like Vox covered the idea of a Direct File product positively, but bemoaned the lack of reach to all possible users. I personally took a handful of calls from journalists with the same basic take: Great idea, but how sad that it’s offered to such a limited population? Why can’t we do this right?
Here's what I said to those journalists. You all complain that government doesn’t use best practices from the consumer Internet. THIS IS A BEST PRACTICE. This is how every app you like started. Take Yelp. It first served just San Francisco customers and businesses. When it had figured out what really worked for its users, it expanded to New York, and then Los Angeles, and later Chicago. Over time, the company honed both its technology and processes so that it could expand more rapidly across the nation, and the world. Starting in every region at the same time would have deprived it of the opportunity to build the product that has succeeded at the scale it has.
Facebook, now with more than three billion users, started with college students, in fact, at first, with just Harvard students. Back then, it was designed just for them, to serve a relatively small subset of their needs. Over the years it expanded to serve the general population and to provide more and more services. Say what you want about Facebook, but if scale is what you want, they have it.
Have you ever tried to get an invitation to a new social network like Bluesky or a new AI tool? The company takes your email and lets you know when they’ll let you onboard on their schedule. That’s them managing the rollout to work out the inevitable bugs in the system with a smaller number of users, adding more people as the reliability and usability of the system increases. It’s a well-known and well-tested recipe for happier developers, happier users, and ultimately, for sustainable and bigger growth. Why does anyone expect government technology to succeed without similar starting small approaches? DC’s worries about a limited launch are perplexing to people who’ve made software that millions – even hundreds of millions – of people use.
Direct File pulled this off despite so much hand-wringing about this strategy. They stuck to their guns and to their product strategy. How’d it work out? When surveyed, 90% of respondents who’d used it ranked their experience as excellent or above average, citing ease of use and trustworthiness as reasons for their satisfaction; 86% of them said that their experience with Direct File increased their trust in the IRS. Attention: every other federal government leader! Want results like that?
FLOW and Direct File are both recent examples, but there have been products in government for decades. I tell the story of CMS’s Quality Payment Program of Recoding America. It’s not the story of a staged roll-out, it’s the story of a team fighting to product manage in the sense of making actual tradeoffs in the service of usability and stability. I say this a lot but I’ll say it again:
Project management is the art of getting things done.
Product management is the art of deciding what to do.
The number of ways the QPP team had to fight to decide to do the important things, to push back against policy choices that would have doomed the product, take up all of Chapter 11, so it’s best to just read it there, but I bring up an almost ten year old example to prove these practices didn’t arrive in government yesterday. And to remind everyone to fight trade-off denial like your product depends on it.
One thing all these products have in common is speed. It’s months, not years, to have something to show, even if it’s not the whole tamale. I’m so sick of people in government telling me they’re going slow in order to do it right. Going slow keeps them from learning what they need to know til it’s too late. And once again, this is by no means limited to digital products. The need for speed is starting to get more play. Listen to Sen Brian Schatz on the Ezra Klein show earlier this week:
And I’ve got to say, boy, fast really works. It works on policy. It works for people. And the politics works. I think we should have the kind of impatience that regular people have, which is like, “What the hell? I thought you did this thing. Where’s my stuff?” And I don’t think we have that impatience. I think we have this sense that we enact, and then we take credit.
Actually, listen to that whole episode. It’s gold. He’s spot on. I have a feeling Sen Schatz would be a fan of the product model. Let’s tell him about it, shall we?
Beautiful. I work with folks everyday trying to identify “how to make MVP work in government”. While it feels complex and overwhelming because of all of the funding constraints, it really is so similar to the development process of many of our favorite apps. But the fear of failure and criticism keeps folks from getting creative and figuring out how to interactively roll out meaningful chunks of work bit by bit. Mentally managing loud voices asking how government can’t move fast to build products that work for every single possible user in the entire United States of America is also a feat of patience.
Thank you so much for your voice in this space.
These are fantastic examples that illustrate a good strategy for breaking down the work with small, end-to-end value driven chunks. Doing this well is rare. It's much more common to see approaches that break down the work by module or system...and calling it an MVP.