How Product Managers Guide Projects from Start to Finish

A lot of hands touch each product and service that gets built at Code for America. From client research to marketing, everything we create goes through a collaborative process full of feedback loops, iteration, and countless Zoom meetings. We want to hone in on one particular part of that process today: how product managers keep all our teams on track.

Recently, we sat down with three of our product managers: Yvonne Fong on the Tax Benefits team, Ryan Hatch on the GetCalFresh team, and Lauren Haynes on the Safety Net Innovation Lab team. We asked them a few questions to learn more about how product managers serve as translators between disciplines and ensure everyone is collaborating effectively.

For those of us who don’t know—what exactly is product management?

Lauren: Product management is making sure we’re building the right software at the right time for the right audience at the right size. It’s also a bit of playing translator between business, engineering, policy, and research. So to that end, it’s a lot of one-on-one relationship building to understand what each discipline needs and to lay out clear expectations for which problems we’re solving now and which we’re tabling for later. On my best days, it’s keeping the team moving forward on a shared vision to deliver client value, and all that invisible glue work to keep things running seamlessly.

What makes for a good product manager?

Ryan: There are two values critical to success in product management—curiosity and empathy. You have to be able to deeply understand the needs of clients, stakeholders, and your team to build a valuable product. This means listening deeply, asking a million questions to get to the root of a person’s problem, and fostering genuine interest in their answers. It’s so important to be respectful of the trust people put in you, and build at a pace that feels sustainable for everyone.

Lauren: A big part of this is navigating ambiguity. There’s never perfect information, so I try to figure out one to three questions we can answer right now to reduce ambiguity. Sometimes, rather than debating, we have to ask: where do we need to just try something to figure out if it’s the right thing to do?

Yvonne: A product manager is a sort of diplomat—it’s important to be measured as we guide everyone through their opinions to a decision that might not make everyone happy, but leads us all toward that north star goal.

It sounds like collaboration is a big part of the job. How do you make sure you’re striking the right balance between efficiency and getting everyone to feel heard?

Yvonne: On the Tax Benefits team, which I’ve seen grow from ten people to more than 25, we use “point people” for engineering, product, policy, and so on. When we do complex feature work on our products, each point person represents their discipline and brings their expertise and unique lens to the problem. We also have each point person update their discipline on the ongoing work so that the entire team has a shared understanding of the problem and our proposed solution. This also ensures a more efficient decision making process. Otherwise, we run into the problem of too many cooks in the kitchen, which can slow us down and make it harder to come to a solution. We’ve used this process to launch our case management system and complete major feature work for GetYourRefund and GetCTC.

Ryan: And the opposite of too many cooks in the kitchen is the frustration you feel in a meeting when you need input from someone who’s not there. You really have to think through facilitation dynamics, where you are in the process, and whether you need to go deep with a small group or broad with a big group. For example, if you’re kicking off a new project, you want to have research or government stakeholders in the room at the beginning to speak to the problem you’re trying to solve, along with a designer and engineer who can speak to the constraints for solving it. So they might say, “You can solve the problem in one of two ways. The first will be ready in two weeks, but will only solve the problem for 80% of people, the second will take much longer but will completely address the issue.” With everyone in the room you can make informed, shared decisions about what matters most. 

What’s different about working as a product manager at Code for America compared to other organizations?

Ryan: In the private sector, every decision had to be justified by how it could create a return on investment. Here at Code for America, the key stakeholders are clients and government partners. This changes what we choose to build and when. There’s this idea in government that there are no “edge cases”—the things we build have to serve everyone. It’s really empowering to build something with that goal at the forefront.  

Yvonne: I come from the private sector, too, and the biggest difference at Code for America is the decision making process. In my previous roles, it was very product-led, and now it’s more consensus-driven—which, like all things, has its pros and cons. We have a plethora of diverse ideas and creative solutions for addressing needs. Related to this is a sense of shared ownership. While some organizations tout that the product manager wholly owns their product, our products are truly owned by each member and discipline of the team. It is a product that reflects us all.

Lauren: What I really appreciate about working here is that we think about sustainability for our teams—like we don’t do a product release at 5 p.m. on a Friday. We have to always be asking, “Where is there urgency and where is there not?” There are undoubtedly going to be fire drills, but let’s not make them where they don’t have to be. 

You all sit on different teams—Ryan on GetCalFresh, Yvonne on Tax Benefits, and Lauren in the Safety Net Innovation Lab. Have you had the chance to learn from one another and other colleagues working across the organization?

Lauren: We do a lot of product management knowledge sharing across teams. Yvonne created a user pain score that has been adopted by other teams, which has taken insights from the Tax Benefits team into our work with MNBenefits. It helps us prioritize different features and bugs to fix, especially when we’re looking at clients who are not served well by the existing services. Can we fix something for someone who can’t get through the application at all? Can we help someone get food benefits sooner because we made it easier for a caseworker to make a determination? What percentage of users is this affecting?

Check out the client pain score to see how product managers prioritize fixes.

Yvonne: The user pain score was part of a bug triaging process we conducted at my last job, and it was an interesting exercise to translate its criteria to our problem space here. There, we had usual criteria that focused on revenue, user impact, whether it was client-facing, etc. With products like ours, however, it’s challenging to quantify those impacts—and if we focused on those metrics, it could lead to us missing our target population whose numbers may not, on paper, merit the central focus of our resources when fixing bugs. So we worked together as a team to add special weights to the score, including: if the users affected were part of our hard-to-reach populations, if our integrity as a service would be affected, and more. Now, if the users affected are in our hard-to-reach populations, we would give those bugs a higher priority.

Ryan: It’s also been very rewarding to partner with other Code for America teams to get benefits to clients who need them. For example, I recently collaborated with Yvonne and the Tax Benefits team on a messaging campaign to tell GetCalFresh clients that they might be eligible to receive money through the Child Tax Credit (CTC). Families who applied for the CTC through GetCalFresh claimed $710,347 in tax benefits through this experiment. It was awesome to connect folks who use our product with a fast and easy way to claim other benefits.

How would you like to see the field of product management evolve as a whole? 

Ryan: I’d like to see product managers consider the ethical consequences of our product choices more when we prioritize tasks. The best thing about working on a product team is the opportunity to build something at scale—something that helps thousands, if not millions of people. With that reach though comes a huge responsibility to do right by people. It can be tempting to release a feature that improves the bottom line or helps in the short term, but excludes or hurts people in the long run. As product managers, the most important role we play is to solve problems, not to create them.

Yvonne: I’d like to see product management as a whole, including at Code for America, evolve to become less risk-averse. As we tackle problems that don’t fall into a typical revenue-generating model, we’re in a unique position to redefine the product practice into one that may not look exactly like the traditional model, but is more elastic, creative, and dynamic. We’re already doing this, and it’s an ongoing process to put our values into practice. For us, the next stage is a clear mandate for fierce decision making. If we’re to tackle complex problems that impact clients in real and immediate ways, we need to realize that inaction may be more harmful than intentional, imperfect action. We have to do what we can to mitigate risk, but we can’t let it paralyze us into inaction—and we shouldn’t make a decision that actually increases the harm to our clients. And as we also implement changes required by policy, we’re in a position to measure and quantify those changes. We can reflect the harm, in real numbers, back to policy makers. Every product decision has the potential to either help or harm clients, but if we are swift to craft solutions that are flexible and ever-evolving, we will be best suited to effect urgent and meaningful change.