Project Resolve
Project Resolve was Microsoft Research's multi-year initiative on civic tech for community health workers — the frontline workforce that connects people to health, housing, and food resources in underserved communities. CHWs are some of the most effective and least-resourced practitioners I've worked with and I learned so much from them on this project. Mary Gray's team at MSR convened the engineers and other researchers. I was the PM, user researcher and co-design lead from early 2021 through fall 2022.
When COVID hit, a coalition of 14 Community Based Organizations (CBOs) in North Carolina received state funding to run vaccine equity drives and needed shared digital infrastructure to coordinate across organizations. We built the Healthy Community Hub with them. By mid‑2022 we had 42 frontline staff active in the tool with over 1,883 client records on file.
Project Resolve had a second goal though, beyond the software itself. That was to pioneer a new methodology for building software, one that would fix some of the underling reasons big tech products leave non-profits out. We were exploring a model where small non-profits could co-own software and drive its development, with engineers and designers taking a purely supportive posture.
Designing for different priorities
Software for small CBOs is a different beast from software built by and for startups. The clients may not have housing, they may be in domestic‑violence situations or undocumented immigrants with ICE exposure — and they are slow to trust, sometimes for very good reasons. The staff are stretched thin and lean semi‑tech‑phobic. They leverage many volunteers, which means there's no institutional memory to carry you through a rough onboarding. The work happens in the field, not at a desk, on patchy connectivity. And these organizations feel burned: by big tech changing the product out from under them, by funders constraining how dollars can be spent. None of those constraints are exotic — they just aren't the defaults a Silicon Valley PM is taught to optimize for. Listening hard, then building from there, was the only way to land something they'd trust enough to actually use.
I organized research, with a team that included CHWs, to understand how many of the organizations currently worked so we could truly mold the software to the CBO and not the other way around. Intake, office work, events, field visits, ongoing services. This helped us outline a very different set of priorities.
The first thing you'll notice if you work with CBOs is that everything runs on spreadsheets! They are amazingly flexible but quickly proliferate in a way that makes them hard to track. We designed this platform to be extremely customizable. CBOs could mold it to their mental model of their offerings and just the data they needed, and dial in permissions for staff and volunteers.
We treated data ownership as crucial from day one, with multi‑tenant isolation and export features early on. We also prioritized multi-language and offline support much higher than I ever have before on a project.
Participatory Agile
We attempted to run the engagement as "Participatory Agile" — a deliberate attempt to cede the roadmap to the people who would use the tool. In practice that meant including a team of CHWs, who had never been a part of software development before, in every product and engineering meeting. We also established a train-the-trainer model, called the Community Tech team, in which I would help them feel confident in on the platform so that they could in turn help CHWs at their organizations be successful.
We actively and iteratively worked on creating a culture where technical expertise yielded to lived expertise. It's not straightforward. It's hard to speak up when you don't recognize tech jargon and hard to stay quiet as an engineer when you think you've seen something a thousand times. The model had wins and also setbacks. My colleague's analysis of the collaboration is now a CHI 2026 paper by Liang, Tseng, Fetterolf, and Gray. I take their critiques as direct input on how I work now.
Paper 2.0
One feature that brings it all together was something we called Paper 2.0. Community health workers and community members were not looking to get away from paper forms anytime soon. Rather than push organizations to digitize, we embraced this. The mobile app (actually a PWA) would let you quickly snap photos of documents which were immediately available for review on a desktop, where OCR had recognized the particular form and extracted fields.
Some engineers pushed back. We already supported capturing data on a tablet and OCR is hard (this was before great multi-modal AI models). We kept working on it anyways, though the project pivoted before it went live. To me, it's a wonderful example of an innovative feature that emerged only because of our co-design process.