Enabled Charitable Allowance through four foundational platform releases.

A new giving experience depended on rules deeper in the platform.

Charitable Allowance would bring family and youth giving onto a platform whose legacy account model treated a person and their giving activity as one account. That structure limited the ability to represent multiple transactional accounts, assign responsibilities, and make changes traceable.

This was not a single feature build. It was a sequence of connected platform decisions across product, engineering, QA, design, data, and internal operations. I worked as the only India-based product professional, bridging Canadian product leadership and an engineering organization of more than 50 people across two continents.

The experience could only be as clear as the account and permission model underneath it.

• Identity and money movement were coupled. The platform needed to distinguish who a person was from the transactional accounts they used to give.
• One person needed more than one giving context. Multiple transactional accounts had to sit under a single identity without creating ambiguity in ownership or access.
• New roles needed product-wide definitions. Owner and Administrator permissions affected customer surfaces, backend management, and the data moving between them.
• Sensitive changes needed a record. Role and permission changes required an audit foundation that could later expand across the product.

Make the system explicit, then give each release a testable boundary.

Because Charitable Allowance was an entry point for young users, I also reviewed requirements and data flows with awareness of North American youth-data-protection constraints. Formal legal or compliance sign-off sat outside my ownership.

1. Model the core entities. I co-led requirements for separating the identity account from transactional accounts and for enabling more than one transactional account beneath a single identity.
2. Trace roles across every surface. I led requirements for Impact Account Owner and Impact Account Administrator permissions, including how roles appeared to customers, backend users, and downstream data flows.
3. Turn rules into delivery detail. I managed backlog, user stories, acceptance criteria, sprint ceremonies, UAT, and release-readiness work around the broader program.
4. Build observability into the model. I co-built an audit system and change-data-capture pipeline, starting with role and permission changes before the system expanded to other product areas.

Public evidence boundary.

The source materials behind this work include account models, permission rules, release dependencies, and acceptance criteria. The public version names the evidence boundary without exposing confidential product or architecture detail.

The measurable statement is the scope delivered, not an invented adoption story.

The work spanned four foundational infrastructure releases over more than a year. Together, they re-architected the core account model, enabled multiple transactional accounts under one identity, and established RBAC and audit foundations behind the 2025 Charitable Allowance launch.

Platform work earns leverage by making future decisions safer.

The strongest product contribution here was not a visible screen. It was making accounts, roles, permissions, and change history explicit enough that teams could build new experiences on a more dependable model.