Taproot+ didn't exist when I joined. Two and a half years later, it had 30,000 users and had delivered $10 million in pro bono services to nonprofits, using a lean, assumption-driven approach that prioritized outcomes over features from day one.
The Taproot Foundation had spent years connecting skilled volunteers with nonprofits who needed their expertise, lawyers, designers, marketers, strategists. It worked, but it was slow, staff-intensive, and hard to scale. Each match required human coordination. The model couldn't grow.
The hypothesis was that a self-service marketplace could change that. If volunteers and nonprofits could find each other directly, browse, connect, and start a project without a Taproot staffer in the middle, the same mission could reach far more people. My job was to test that hypothesis and build the thing that proved it.
Early in the project, I conducted extensive user interviews with both sides of the marketplace. What we found reshaped everything. Nonprofits, accustomed to Taproot's high-touch model, expected to post a need and wait. Volunteers, on the other hand, wanted to browse, to find a project that fit their skills, their interests, and their availability.
The implication was clear: the marketplace had to be built for volunteers first. They were the ones doing the shopping. If we made it easy for volunteers to find compelling projects, nonprofits would get matched. If we optimized for nonprofits, nothing would move. This single insight determined nearly every product decision that followed.
"We weren't building a platform. We were building a habit, getting skilled professionals to see pro bono work as something they actually wanted to do."
We didn't start by building software. We started by simulating the marketplace manually, creating project pages, connecting volunteers to nonprofits by hand, and watching what happened. This was the minimum viable product: static pages, email notifications, and a lot of staff effort behind the scenes to make it look automated.
Every time we manually responded to a user need, we asked: is this common enough to automate? We built a simple scheduling tool that reminded users to check in on their projects, and an automatic check-in system that flagged projects needing attention. Each automation replaced staff time with product, but only after we'd confirmed the need was real.
Working closely with a developer and a design shop, we kept the team tiny and the feedback loops short. We ran regular interviews throughout the build, and used surveys embedded in the product to gather ongoing signal. Nothing got built that wasn't measurably adding value.
Taproot's existing programs had a solid set of ground rules for what good pro bono work looked like, but they'd been built for a staff-run model. Translating those rules into a self-service product meant constantly asking: what's the outcome we're actually trying to produce? Not "we need a project listing page," but "we need 10 nonprofits matched with a volunteer each week."
That outcomes-first mindset kept us from over-building. Every feature had to justify itself against a specific goal. When a feature didn't move the metric, we cut it. When something worked, we doubled down. The result was a lean, functional marketplace that actually converted, not a sprawling product that impressed in demos but failed in use.
In 2.5 years, Taproot+ grew to 30,000 users and delivered $10 million in pro bono services to nonprofits that couldn't have afforded them otherwise. The product was lean enough to sustain itself with a small team, and the approach was disciplined enough that it earned a Harvard Business Review case study. The thing I'm proudest of isn't the numbers. It's that we built something that actually worked for the people who used it.