LaunchGood
Four separate scheduled giving flows had grown apart over 10 years. Donors were confused, engineering was rebuilding from scratch every cycle, and every new campaign took 21 weeks to ship.
46%
increase in average donations from interval giving
37%
reduction in donation-related support tickets
21 wks → 2
campaign setup time reduction
$495K
surplus vs prior year's deficit
Platform
Responsive web app
My role
Product Manager
Team
Eng team, designer, data analyst
Timeline
3 months
LaunchGood had four separate scheduled giving flows: Ramadan, Friday giving, Dhul Hijjah, and general recurring. Each had different scheduling options, different interfaces, different rules. They'd grown organically over a decade with no unified design.
Donors couldn't understand why features available in one campaign weren't in another. Support was fielding questions like "Why can't I schedule this like I did for Ramadan?" Engineering was rebuilding the same infrastructure from scratch every cycle. The quote from the engineering team: "Every year we're rebuilding the same thing. We can't experiment or iterate. We just get it working in time."
The core insight
The donor experience problem and the operational problem were the same problem: nothing had been designed for reuse. Fixing one without fixing the other would have just created a new version of the same fragmentation.
I owned product strategy and vision for the unified giving system, cross-functional leadership across design, engineering, data, marketing, and CX, and mentored the junior designer on the project.
Discovery included process mapping, flow audits, historical data analysis, and donor behavior research to define the core problems and opportunities. I also wrote the internal documentation to formalize the new process, establish shared terminology, and get everyone on the same page.
For scoping: I defined the metrics framework (setup time, conversion, support tickets, referral performance) to enable self-service and track impact post-launch.
Instead of maintaining four separate giving experiences, I defined a single flexible giving system that worked across all campaign types: Ramadan, Friday giving, Dhul Hijjah, and general recurring. Donors stopped encountering inconsistencies between flows. Engineering stopped rebuilding the same infrastructure from scratch.
Replaced rigid campaign-specific duration requirements with custom patterns. Donors could give across specific nights (the last 10 nights of Ramadan, for example) instead of being forced into all-or-nothing options. This single change drove an 80% increase in average donation from interval givers.
Adapted tip prompts to donation size: flat-dollar suggestions for higher amounts, percentage-based for smaller ones. A small design decision that produced a 46% increase in average donation amounts from interval giving.
Built lightweight internal tooling so the team could configure and launch new campaigns without filing engineering tickets. Campaign setup time dropped from 21 weeks to 2 weeks, saving approximately 19 weeks of development time per cycle.
46% increase in average donations from interval giving
37% reduction in donation-related support tickets
Campaign setup time fell from 21 weeks to 2 weeks
$495K surplus compared to the prior year's deficit
New campaign types now launch in days instead of months, without growing more complicated as the system scales
Sometimes the most impactful design work isn't the interface. It's the architecture underneath it. By designing for reuse from the start, the donor experience problem and the operational problem were solved in the same move. Three months, one system, two problems fixed.