Charitable Allowance foundation / Account model

Separating identity from transactions so one person could hold multiple giving accounts.

I co-led the product requirements for restructuring a legacy single-account model into an identity account and separate transactional accounts, creating the foundation for multiple giving contexts under one person.

Role
Product Manager / Technical Product Manager
Timeframe
Charitable Impact giving platform
Scope
Identity split, transactional accounts, and multi-account enablement
Status
Foundation shipped; public evidence is sanitized for confidentiality.

The legacy model made a person and their giving activity the same thing.

That assumption worked for a simpler account experience, but it became a constraint as the platform prepared for family and youth giving. A person needed a stable identity while participating in more than one transactional context, and those contexts needed clear ownership and access rules.

This account work formed part of a year-long sequence of four foundational infrastructure releases behind Charitable Allowance.

Change the model without losing clarity across product surfaces and data flows.

  • Define the identity account as the durable representation of the person.
  • Define transactional accounts around giving and money movement.
  • Allow multiple transactional accounts beneath one identity account.
  • Identify the customer, backend, and data dependencies touched by the new relationships.
  • Give engineering and QA acceptance criteria that described behavior, not only a proposed interface.

Start with entities and relationships, then walk the journeys that rely on them.

  1. Clarify the vocabulary. The split between identity and transactional accounts needed language that product, engineering, design, QA, and internal teams could use consistently.
  2. Model cardinality and lifecycle. Requirements described how one identity could connect to multiple transactional accounts and where state or ownership decisions surfaced.
  3. Trace downstream behavior. I worked with engineering to identify how the model affected customer journeys, backend management, and data flows.
  4. Sequence the backlog. Stories and acceptance criteria translated the model into testable increments within the broader foundational-release arc.

Ownership boundary

I co-led this foundational work with product and engineering partners. The detailed architecture and implementation belonged to the engineering team; my ownership centered on product modeling, requirements, prioritization, and delivery readiness.

Public evidence boundary.

The source materials behind this work include entity maps, user journeys, dependency views, and acceptance criteria. The public version explains the product model and the evidence boundary without exposing confidential implementation detail.

Evidence note

Before-and-after entity map

The public case study explains the legacy account assumption and the separated identity / transaction model; the original entity map remains confidential.

Evidence note

Multi-account journey

The public case study describes how one identity reaches and manages more than one transactional account without publishing internal journey materials.

Evidence note

Dependency map

The public case study names the affected customer, internal, and data surfaces while keeping the detailed dependency map private.

Evidence note

Requirement excerpt

The public case study summarizes a model rule as acceptance-criteria style product detail without publishing internal tickets.

The model shipped as infrastructure and unlocked later feature development.

The account restructure and multi-account enablement formed part of the four-release foundation behind the 2025 Charitable Allowance launch. The defensible result is that the platform could represent an identity separately from multiple transactional accounts and use that structure for downstream work.

Measurement boundary

No adoption, account-growth, retention, or revenue metric is attached to this story. The available evidence establishes delivered platform capability and scope, not a quantified customer outcome.

A data-model decision is also a product-language decision.

Teams move faster when they share precise words for the entities a system represents. This story focuses on the trade-offs behind the chosen model and the moments where a concrete diagram changed the conversation.