Turning a feature factory into a platform with a purpose

A motivated team with no strategic thread

Microsoft’s Tech for Social Impact division had an inspirational vision to become the preferred platform for nonprofits of any size, anywhere in the world. It was well-funded, growing, and drawing serious partner interest. But when I joined, the product team was in a familiar and uncomfortable place.

The roadmap was a sprawling list of features designed to serve every possible nonprofit persona, fundraisers, marketers, grant writers, program managers, and gift processors. The team was shipping steadily, but no one could clearly articulate why they were building what they were building. The connective tissue between the work and the strategy simply wasn’t there.

Underneath that, there was a more structural problem. The CRM at the heart of the platform had been acquired rather than built, a sound early decision to get to market quickly that also introduced real rigidity into the system. Customers faced long, complex implementations. And some of the most critical product decisions were drifting in directions that I wasn’t convinced served our customers well.

Microsoft Cloud for Nonprofit: Platform Vision

The division’s six capability areas organized around the central mission of knowing donors and supporters, accelerating mission outcomes, and delivering effective programming. This was the strategic context I was building toward.

Reversing a decision that would have abandoned our customers

One of the most consequential initiatives I led at Microsoft wasn’t on the roadmap when I arrived. It was a decision I had to reverse.

My predecessor and director had landed on a strategy to cut payments functionality from the product altogether, offloading the complexity to third-party providers and letting implementation partners carry the burden. On paper it made sense. Payment integrations are resource-intensive, difficult to maintain, and not obviously a competitive differentiator.

But something felt wrong to me, so I did the research. I talked to customers and partners. I studied the market. Two major findings emerged: recurring monthly donations are the financial lifeblood of most nonprofits especially in the global fundraising market. Forcing an organization to migrate payment providers and reauthorize their entire donor base is not a minor inconvenience, it’s an organizational crisis that disrupts revenue streams. Second, implementation partners needed the flexibility to build complex, automated donation processing workflows and integrations for their specific markets.

Cutting payments wouldn’t just be a product decision. It would have created serious risks for our customers.

I made the case internally. I worked with engineers, architects, and designers to develop a new extensible architecture, one that allowed customers to integrate their existing payment provider’s API directly, eliminating the need to migrate donors while giving partners a flexible foundation to build bespoke workflows. The design created clear integration points for any financial technology that might emerge in the future.

The pitch wasn’t immediately popular. It contradicted an already-decided strategy and required significant rearchitecture investment. But I came prepared with a concrete architecture plan, an achievable partner success story, and a reimagined roadmap tied to measurable outcomes. Leadership agreed to pursue the initiative.

From feature list to outcomes-based roadmap

In parallel, I set out to rebuild the product roadmap from first principles. The existing approach organized everything by product line, fundraising features here, marketing features there, with the implicit goal of matching competitors feature-for-feature ahead of RFP cycles. Each list was well considered, but it was hard to imagine when the product gaps would be closed, for our customers and the team alike.

I worked with the team to rebuild the roadmap based on themes and driven by our five core ambitions for our customers. Each theme was connected to long-term outcome metrics, I defined high-level success measures for each and worked closely with fellow product managers to help them translate that thinking into measurable targets for their own initiatives.

The new roadmap did double duty. Internally it reorganized how engineering pods were structured and how we reported progress to divisional leadership. Externally the themes gave prospects and existing customers a coherent picture of where the platform was heading, framing our vision beyond just fundraising features.

Driving this change required patience and political judgment. My director initially wanted to present the roadmap in the familiar feature-silo format to senior leadership, so I gave her that view first. Then in every subsequent conversation I talked about outcomes. I let the new framing take hold through example rather than mandate. Eventually the outcomes-based language became how the whole team operated.

Coaching the team to think in outcomes

Changing the roadmap was only half the work. My fellow product managers struggled to define how they could measure their own initiatives and tie them to the aspirational outcomes. I coached them through it, providing high-level metrics for each long-term outcome and working with them to define measurable targets for their specific initiatives.

This went all the way down to design. My designer and I established success metrics that determined when a design was considered validated by user testing, removing ambiguity from a part of the process that is often treated as subjective. By putting a stake in the ground on what we really wanted to enable for customers, it became easier for the whole team to apply that kind of thinking to their own work.

Microsoft’s Tech for Social Impact division was restructured into a broader Microsoft Philanthropies organization in late 2024.