Relief at scale
Emergency aid software during COVID. The platform moved close to $1.5 billion, and it's where I learned to be a product manager.
The stakes
When COVID hit, the government stood up emergency relief programs almost overnight: rent, mortgage, and utility assistance for people who'd lost their income. The software was how you applied for the relief. People submitted through these apps, and on the other end a check either went out or it didn't. Get it wrong and someone loses their home.
It started in San Antonio and spread from there. The pattern we built for the city got rebuilt for Michigan and reused again after that, and across the whole lineage it moved close to $1.5 billion, half a million households, a million people, and a couple million sensitive documents.
San Antonio
San Antonio came in three passes. First the city's utility assistance app. Then, when COVID hit, a housing version, and our CEO did most of that rework in two brutal weeks to handle the new questions and the volume about to land. Day one it took a thousand applications, then a thousand a day for months.
The third pass was mine. The intake was workable but rough, so I rebuilt it: a cleaner flow, plus a secure link so people could leave halfway through and come back instead of starting over, before that was a common thing. This third version is where I found out I was a product manager. I worked with two teammates (one was more technical and the other was more UI/UX savvy), translated the vision into the build, and directed it more than I wrote it.
The Homeowner App for Michigan
The Homeowner App was my baby, and the one I built myself. The state's staff had to work with creditors, the banks and tax offices that actually receive the money, and the creditors only touched the app once a month or so, so they were always a little lost in it. Instead of building the staff their own separate screen, I re-architected the creditor view so it didn't need a duplicate. One page served both. So when a staffer helped a creditor, they were looking at the exact screen the creditor saw and could walk them straight to the right files. One view, no duplication, and a better design for it.
None of this came with much formal training, and that was the point: no-training-required was our north star, because the public side has to be intuitive for people who are stressed and seeing it for the first time. Where we did support it, we kept it light, short videos on a YouTube channel and an email blast when a new feature shipped so people could watch and pick it up. Over a thousand case managers used the internal side, and the same bar held: get oriented and start working, no manual required.
CERA
The first Michigan app, the big one, was CERA, and I feel a real sense of parental responsibility for it even though I wasn't there at the start. It was built on the pattern I designed in San Antonio. Other people spun up the Michigan version and ran it while I was heads-down elsewhere. It moved close to a billion dollars and took over 300,000 applications.
Late in its run it wobbled and I got called in. I knew the app, and I was the one they trusted when something had to get fixed. The real reason was the reporting: it was a reconciliation problem, I come from a financial background, and nobody else on the team did. On a billion-dollar program, I was the only one who could make the numbers tie out.
The pattern was sound enough to scale to a billion dollars, but getting it that big surfaced real performance problems that had to be solved along the way. It always worked for users. It just had to be taught to work at that size.
Working with them
None of this happens without great people on the other side. On the Homeowner App I had a tester who was exceptional, the kind who actually puts herself in the shoes of the person who'll use it. We met twice a week, plus ad-hoc whenever, and during testing I'd push updates to the acceptance environment multiple times a day. She'd give specific feedback, I'd turn it around fast, and most of the time we hit it on the first try. The times we didn't, we corrected quickly. That's how we built trust, and a great counterpart on the user's side is what makes a great product possible.
I run support
Here's the engine under all of it: I'm the support lead. I'm the one users come to when something's confusing or broken, so I get every data point about what's clunky straight from the people living in the app. That's an unfair advantage for making it better, because I'm not guessing at the friction, I'm fielding it. I've done it for years across these apps, and I still run support today, with a great teammate handling most of the grunt work now, though I get my hands dirty when it counts. It's the closest seat to the user there is, and I've never wanted to give it up.
What I'm good at
Nobody's ever accused me of being the most technical person on the team. I'm not the best designer either, my stuff can be a little clunky. What I'm excellent at is understanding the user: what naturally belongs together, what they'll want next, the lens they're looking through, and the stakeholders they have to answer to. Someone checking a single application is doing a different job than someone watching the whole batch that pays out today, and I build for that difference.
A lot of people hand someone a database and a list of steps and call it done. I build for the person. That's why product management fits: good enough to be dangerous on the technical side, good enough to be dangerous on design, and excellent at user empathy.
I describe my role now as something like the COO of our Public Sector and Nonprofit vertical. On a given day I might be the product owner, running a demo for a prospective client, writing the technical response to an RFP, refereeing between an engineer and a client to keep an escalation from blowing up, building the schedule for an engagement, or working support. I also run the finances for the whole company, which is exactly why I was the one who could untangle a billion-dollar reconciliation. Wearing all those hats is how I like it.
I went from heads-down, build-as-fast-as-I-can agile to planning and seeing the whole board, and I learned that leading isn't handing people freedom, it's getting in there with them and giving them the scaffolding to do their best work. Most people never get to try on this many hats, or find out which one they're actually built for. Nine years in, having worn all of them, this is the one I'm meant to do.