Norm or Policy: Susie Forbath on Building Public-Sector Software That Serves Everyone

Susie Forbath: How do you take those product insights and in turn use them to inform policy? Because I think that products that touch the public sphere are in a really unique place to get that real-time data and find out what's blocking users who are beneficiaries of these government programs in real time? And that's something that you don't get from traditional public policy research. So I think there's an opportunity to really merge those two disciplines to better serve beneficiaries. And earlier I talked about working within policy or advocating to change it. I've learned in this space, it's really important to distinguish between what is policy and what is a norm that's maybe disguised as policy. So that's when you really need to use the same skill sets that product people use in the private sector context and really asking the hard questions.

Jud Neer: Welcome to the podcast of the Future of Work Practice at Infosys Public Services. I'm Jud, and in my 25 years of building for governments, I've found the hardest part is rarely the technology. It's the people, the policy goals, and the judgment about what to create in the first place. All the stuff required to turn potential into results. My guest today is Susie Forbath, Director of Product and Design at Carina, a nonprofit platform connecting Medicaid-funded consumers who need home care with individual providers. Carina has helped deliver 19 million hours of care to people who want to remain living independently in their own homes. Susie has spent her career building technology at this intersection of public purpose and human need. She began her career in user experience design before moving into product management and delivery leadership at Pivotal Labs, where she worked as a vendor with both private sector and government clients before joining Carina. Susie, welcome.

Susie Forbath: Thanks for having me, Jud. Happy to be here.

Jud Neer: You've worked within the public sector from a variety of angles. Tell us how you got here and what drew you to this work in the first place.

Susie Forbath: Sure. So I've always been interested in the intersection between people and technology. And in undergrad, I studied information science, where I was introduced to the concept of sociotechnical systems. So basically saying that technology doesn't exist in a vacuum. And so one of my first projects at Pivotal was a client in government, and that's when I first got introduced to working in the public sector. So what we were trying to do with this large government organization was bring agile, lean, and user-centered practices, modern software development practices to how they worked. And I really saw the impact that my work could have in this space. Not only were we streamlining workflows, saving thousands of hours, but actually getting to hear from the government users who were using the product, saying things like, "This helps me sleep at night. This helps save lives." I really saw the impact of my work, which was really rewarding. So that's what brought me to Carina ultimately, and kept me coming back to public sector work. So at Carina, the problem space we're in is really important. We're in a healthcare crisis right now in this country. As our population ages, we're expecting to need 740,000 more home care workers in the next decade. But right now, turnover is at 80%. And home care workers gain only approximately $17 per hour on average. Meanwhile, people have a real need to stay in their homes. It can be really hard to find the right care when you need it. And so that's where Carina comes in, right? We facilitate people who need care with people who are looking to provide care. And we've had a really big impact in this space. An independent study of Carina found that 92% of people who use the platform to look for care said that it helped them stay in their homes. So this is possible for people to live the kind of life they want because this piece of software is working. So that's what brought me to this space, and that's what's keeping me at Carina.

Jud Neer: That's really cool. And I love what you said earlier about that moment when you saw the people that were working in government, those frontline workers, responding to the work that you had done. And I'm sure you see that at Carina also. That close collaboration with those stakeholders, not just the end users, but those people who their job day in and day out is serving those people. I've had a similar experience with my own work, with government customers as well, seeing the heart that they have for their own mission. Nobody goes into working for government to make a lot of money or make a name for themselves. They're there, as we call them, public servants, right? I love that notion. So tell me a little bit more, that collaboration that happens with you and your team and with those government customers that you're working with. What's different in that collaboration than what someone might experience as a product manager or designer in the private sector?

Susie Forbath: I think that private and public sector engagements are more similar than people might think, right? So, I've also worked in the private sector before with large enterprises, and there are a lot of similarities. There's a lot of approvals that need to happen before you can deliver value, a lot of understanding the political context, before you could actually make an impact, slow annual budget cycles. So I think those things are actually quite similar between teams working in the private and public sectors. And of course, you have to have a deep understanding of the ecosystem and the domain. And so, at Pivotal, we really took that to an extreme. We had our government counterparts, this was, of course, before COVID, but we had our government counterparts come to our office, work side by side with our consultants eight hours a day from one machine. So I was a product manager, and I had my government counterpart. We were sharing one computer, two monitors, two mice. Two keyboards.

Jud Neer: Wow.

Susie Forbath: And so yeah, we were really taking it to a degree.

Jud Neer: That's really close collaboration.

Susie Forbath: Exactly. That's pretty much as close as you can get. But there was a lot of value because I was an expert in delivering modern software that drove real outcomes. And they were an expert in not only the program that we were working on, but also understanding how government worked. So they were able to open the doors when we had questions, when we needed to reach the right people. And so, exactly. That was really, really tight collaboration between government and between the contractor. And you don't get that when you simply, as a consultant, provide a recommendation and then leave. And so we had to do that also, that same kind of close collaboration with our users as well. So one constraint that we found in this government context was that because of the security posture, we couldn't do traditional remote user testing. So if we created a prototype, we couldn't see what the user was doing on the other side, clicking live. And we also didn't have an approved analytics tool for web analytics. So we had to be creative in those constraints. And so what we did was we actually went to the environment in which our users were operating, not just for a meeting, but this was actually living in their world for a week. We spent a week living alongside them in their context, understanding their entire environment, and building that trust with them. And we were really successful. And so that government work requires that kind of creative problem-solving that you might not see in a private sector context.

Jud Neer: Governments also then have to work within the boundaries of, one, what is legislated or statutorily mandated, and also realities of politics. I'm curious if you have a story where you've run into those kind of boundaries as well, and how you worked through that as a product manager or designer.

Susie Forbath: I like to think of product managers almost akin to product scientists. Because a lot of what we use in product management is the scientific method. You have a hypothesis of how your product is going to solve the problem, and you essentially deploy experiments. Just like a scientist, you don't want any confounding variables. You want to know if your intervention is actually having the intended impact. And so that's really at odds with the way that government procures software. Government procurement was not designed with this kind of product scientist method in mind. Government procurement, often a government project is successful for software if you're meeting the requirements that are defined upfront, if you meet the scope under budget and under time. And so that's really at odds about what we know now in the year 2026 about building successful software. But I also think there's a constraint that is even higher level than that, beyond procurement, which is policy. So in the private sector, if you're coming up against a ceiling, you can change your revenue model. You can decide to work on a different problem. But when working with government, you're dealing with a policy that's been written by a legislator who's never seen your product before. And so you have to figure out, do you work within that policy, or do you advocate for it to be changed using those traditional channels? And at Carina, I feel this very acutely because working in Medicaid, there's a saying that we say, once you know how Medicaid works in one state, you know how Medicaid works in one state. So every state can make a lot of choices about how they actually administer the program. So it means that you can't just copy-paste what works in Washington and put it in the Oregon context without doing your policy homework. And I've seen this play out in the real world. So just to give you an example, in Washington state, parent providers, so parents who care for a child who qualifies for Medicaid and home care, they are granted a certain number of hours for respite. This is paid time off so that they can take a break from caregiving. But it can be really hard to find a caregiver to take those hours. And so we ran some product experiments to see can we move the needle on providers filling that gap and filling those hours that the state gives us as part of its program. And we moved the needle, but we kept running up against the ceiling. And when we dug into it, we realized that it wasn't a product problem at all, but was actually a policy problem. We found that because these respite jobs were for a short duration of time, it could be a few hours at a time, those care providers found that the reimbursement rates didn't justify the work it would take for the complexity to learn a new client, to just be there for a short time, and the cost of transportation didn't justify the work and what it would require. And so that, I think, opens the door for something that I think is really underserved in this work. That is, how do you take those product insights and in turn use them to inform policy? Because I think that products that touch the public sphere are in a really unique place to get that real-time data and find out what's blocking users who are beneficiaries of these government programs in real time? And that's something that you don't get from traditional public policy research. So I think there's an opportunity to really merge those two disciplines to better serve beneficiaries. And earlier I talked about working within policy or advocating to change it. And I've learned in this space, it's really important to distinguish between what is policy and what is a norm that's maybe disguised as policy. So that's when you really need to use the same skill sets that product people use when in the private sector context and really asking the hard questions. Because I found that sometimes something that seems like policy is really like, we've always done it this way, or, we implemented it this way once and we've never questioned it before. And so that's when you can make real change in government products by questioning what's norm and what's policy.

Jud Neer: Great. The remainder of our time, I want to talk, as many people are doing these days, I suppose, about AI and how that's affecting the workplace in general. But for you, I'm curious how that is affecting product management and design work. AI is beginning to empower more people than just your traditional software engineers to be able to build at least prototypes if not full on production software. I'm curious how you're thinking about using AI within your own team to serve ultimately your customers.

Susie Forbath: So as you said, AI is really facilitating non-traditional builders to create prototypes really quickly, or even create working software really quickly. And so, I think the conclusion that a lot of people draw from that is that we're going to need fewer people, right? Because the work is now sped up. But I don't think that's fully what's happening with AI. I see this with my team, right? We use AI to synthesize user research. We use AI to create prototypes really quickly to communicate ideas. But anyone could do that now. So what's really more important is that product mindset, right? So knowing the right question to do research on, right? And now that maybe it's easy to do that synthesis. Or knowing what a solution might be for this problem and that prototype that you create is just an artifact to communicate that idea, but it's really important to have the right idea in the first place. And so, I think as these artifacts become cheaper and cheaper and easier to make, what's really going to be more important is the ownership of those artifacts. And so, you still need that human touch to know, okay, do I really stand behind this prototype? Do I really stand behind this particular solution for this user group? So that's when storytelling and a lot of the other techniques within product management are going to become more and more important. And another thing that I think is more salient is that stakeholder management. So, I think, we at Carina work in a really complex multi-stakeholder space. We work with unions, we work with state agencies, we work with program administrators as well. So knowing what's the right artifact to bring to the right stakeholder at the right time is still something that requires a lot of human judgment. So AI can provide some suggestions, but really you as a product person own that human relationship. And so, I think with that, maybe a little antithetical to what we've been hearing in the tech space for the last little bit, but I actually think we're going to see a big revaluation of liberal arts degrees in building tech and product and design in particular.

Jud Neer: So Infosys has done some research into future of work related to AI, and they've found that teams really are looking for regular training around AI to help be successful. Given the perspective that you've shared, what kind of training do you think really makes sense to help teams be able to do the kind of thing that you're talking about with AI and be able to tell it well, not just the how, but also that what?

Susie Forbath: Yeah, just as we talked about, it's really easy to create these prototypes now. And I think we've seen just in the past few years how quickly these AI systems are changing and facilitating work. So I think that if you were to do training for like here's how to work with this particular model to create this particular output, it's going to get dated very, very soon definitively. So I think it's actually useful for managers to get training in how to facilitate the AI use of their team, what's acceptable and what's not. I think where teams falter is that they're not sure whether they're truly doing the work if they're using AI tools, and different organizations have different postures around this. So I think the organizations that are going to be really successful aren't the ones that are going to be afraid of AI, but the ones that are going to lean into it. And I think it's on leaders to really model what that looks like, right, and to encourage that AI use, and encourage also for their teams to still be those product thinkers and not have just because the AI tells you a certain thing, that that is truth. You still need to have those strong opinions and know when is the output meeting my needs versus when do I not agree with the AI, and shape these tools to get to the outcome that you want as a product team.

Jud Neer: So our last question, what sort of advice would you give to somebody who is interested in doing what it is that you do?

Susie Forbath: I know I keep leaning into this, but I'd really say study the liberal arts, or hire people who have studied the liberal arts, because as quickly as these AI tools and systems change, the liberal arts training is going to teach you how to think, regardless of how the world evolves and how this domain evolves in the next few years. And if you really want your work to matter, go into this field. I get stories in my inbox from consumers every day, testimonials saying things like, because of Carina, my daughter, who has special needs, is able to stay at home. Or, I'm able to stay in my apartment because I have the help from caregivers, or, I no longer have to rely on my neighbors for help. So getting that feedback loop between the work you do and the impact it has on people and living their lives, that's huge, and I think it's a really great benefit of being in this space.

Jud Neer: If you're in the business of turning capability into results for the public sector, we'd love to hear from you. This podcast is brought to you by the Infosys Knowledge Institute. You can find show notes and a transcript in the podcast section at infosys.com/IKI. The show is produced by Christine Calhoun and Yulia De Bari. Audio engineering by Dode Bigley. I'm your host, Jud Neer. Thanks for listening.