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.
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.
Is Code For America working on any other projects with the IRS? Our family has personal experience with horrible customer service and the inability to resolve issues. The implementation of any technology would be very helpful.
To be clear, Direct File was all government employees. Code for America was not involved in the core federal product, though they did help a few of the states with their integrations. Credit to the IRS! Yes, the customer service can be horrible and people are getting stuck in terrible loops trying to resolve issues. Here's hoping that their experience shipping Direct File inspires new ways of approaching these persistent problems. I'm sorry for what your family is going through.
More substantive point, that I _think_ you would agree with: Some people may hear the emphasis on product management -- empowering somebody to make binding decisions about what to do, or at least what to do first -- as some kind of diss on project management. Obviously you _do_ still need people who actually get the stuff done, and the product manager should be able to take some major new feature that's been selected, and farm it out to a team to get the job done. But a lot of the time, "projects" should be small, discrete, in service of iterative improvement. In some cases the "project manager" might be the single developer working on something.
Minor note, the linked article has a typo in its headline. It says "How To Build Great a Digital Product". Clearly the "a" should be before the "Great".
The thing about limited launches is that often your choices are,
option 1: limited launch year 1, improvements year 2, full launch year 3
option 2: nothing year 1, nothing year 2, full launch year 3
People imagine, hey wouldn’t a full launch right now be better than a limited launch right now. But usually that’s just not on the table.
There are still pros and cons to the limited launch, sometimes it’ll slow you down to be supporting a half made product, but sometimes it’s better to build up your support operations gradually rather than suddenly. Etc etc
Yes... although sometimes option 1 looks like, "Since the launch year 1 went badly, the project is canceled." There's no formula that works for everything...
In general I'd rather there be individuals with responsibility, rather than applying a particular product management formula. So many government failures seem like "The contractor failed, but we don't blame the person who chose the contractor. Choosing a contractor who fails, our culture considers that to be totally acceptable behavior."
I agree that funding models haven't caught up with shifts IT approach to work in government. I have ideas on how we can improve that but only from a funder by funder perspective right now (tough).
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.
Is Code For America working on any other projects with the IRS? Our family has personal experience with horrible customer service and the inability to resolve issues. The implementation of any technology would be very helpful.
To be clear, Direct File was all government employees. Code for America was not involved in the core federal product, though they did help a few of the states with their integrations. Credit to the IRS! Yes, the customer service can be horrible and people are getting stuck in terrible loops trying to resolve issues. Here's hoping that their experience shipping Direct File inspires new ways of approaching these persistent problems. I'm sorry for what your family is going through.
Jennifer, thank you for your compassion and for leading Code For America's fantastic work.
More substantive point, that I _think_ you would agree with: Some people may hear the emphasis on product management -- empowering somebody to make binding decisions about what to do, or at least what to do first -- as some kind of diss on project management. Obviously you _do_ still need people who actually get the stuff done, and the product manager should be able to take some major new feature that's been selected, and farm it out to a team to get the job done. But a lot of the time, "projects" should be small, discrete, in service of iterative improvement. In some cases the "project manager" might be the single developer working on something.
As you say, yes, completely agree. I bow down to the amazing project managers. They're gold!
Minor note, the linked article has a typo in its headline. It says "How To Build Great a Digital Product". Clearly the "a" should be before the "Great".
Thanks. Have asked FAS to fix.
The thing about limited launches is that often your choices are,
option 1: limited launch year 1, improvements year 2, full launch year 3
option 2: nothing year 1, nothing year 2, full launch year 3
People imagine, hey wouldn’t a full launch right now be better than a limited launch right now. But usually that’s just not on the table.
There are still pros and cons to the limited launch, sometimes it’ll slow you down to be supporting a half made product, but sometimes it’s better to build up your support operations gradually rather than suddenly. Etc etc
And of course, Option 2 often looks like “full launch year 3... with significant problems when a flood a real users try using it all at once”!
Yes... although sometimes option 1 looks like, "Since the launch year 1 went badly, the project is canceled." There's no formula that works for everything...
In general I'd rather there be individuals with responsibility, rather than applying a particular product management formula. So many government failures seem like "The contractor failed, but we don't blame the person who chose the contractor. Choosing a contractor who fails, our culture considers that to be totally acceptable behavior."
Yes, great point—making sure the first thing that comes out doesn’t look bad can be critical for maintaining political support!
I agree that funding models haven't caught up with shifts IT approach to work in government. I have ideas on how we can improve that but only from a funder by funder perspective right now (tough).