CASE STUDY · PAYPAL · 2019-2024
The Notification Overload Problem
How I made a diffuse, ownerless trust problem visible, then built the governance that kept it solved after I left.
A platform-wide trust issue nobody owned.
PayPal's consumer product had dozens of teams talking to customers at once: push notifications, in-app messages, email, badge dots, lifecycle marketing, credit alerts, fraud alerts, promotional offers. Each team owned a single channel and answered for a single set of metrics. No one was watching what one customer received across all of them.
The effect was easy to predict and hard to see. Customers in early life, the window where trust is still forming, were getting overlapping outreach from sources that never coordinated, at a volume no single team felt responsible for.
THIS WAS A SHARED SURFACE WITH NO OWNER
This was no single screen to redesign or flow to optimize. This was an organizational challenge, with fragmented ownership was adding up to real harm against the one thing every team shared, which was customer trust. You can't argue against a problem nobody can see. We needed to make it visible, put it in terms that asked for a structural answer, and find an caretaker
The problem was never a single notification.
It was that no one owned the sum of them, and no process could see the total or decide against it. That gap was where I focused. The work came together in two parts, evidence first and structure second.
1 · The audit
I worked a little outside my lane. I pulled a modest budget together from what was already around, with no dedicated headcount and no approved initiative, and brought in an outside research firm to run a secret shopper audit of PayPal's full blended communication footprint. They moved through the product the way a new customer would and logged every notification, every email, and every in-app prompt across onboarding and early life.
That report did the thing a design intuition never could on its own. Once the evidence came from outside and sat on paper, it stopped reading as a design preference and started reading as a shared risk that leadership across functions had to answer for.
2 · The routing engine
The fix was never a person choosing what each customer received. A committee can't decide any single customer's messages, and shouldn't try. What it could do was govern how types of message were handled, and let a rules engine do the routing.
Every notification entered one intake and was typed along a few axes: urgent or not, regulatory or not, important or not, actionable or informational. From that type the engine chose an output channel, push, SMS, email, or an app badge, with a fallback if the first channel was blocked, since a customer who had declined push still needed a regulatory notice to reach them somehow. It also set timing. Most messages waited in a per-customer queue and were released gradually, but a higher-priority type could jump the queue and go out sooner.
3 · The oversight committee
Marketing, product, and legal sat together to own the rules the engine ran on, normalizing how each type was treated rather than ruling on individual sends. They could also sample a single anonymized customer's stream to see how the system felt in practice. No PII, but enough account context to judge it: balance positive or owed, account age, number of products in active use, login frequency.
The recommendation was that once the capability existed, the routing should run on its own through AI, with the committee moving fully into oversight. Until then, the humans held the loop.
The most useful output wasn't a screen.
It was a structure for deciding, and it outlasted the project. The framework held because it lived in process rather than in any one person. After I moved on, the intake funnel and the committee kept running.
Centralized intake
One process for every notification request across the platform, built from nothing.
Centralized Cross-functional reviews
A committee that weighed each request against the customer's total communication load, with no team approving its own channel alone.
Customer attention and trust
Qualitative research evaluating how PayPal communicated with it's customers showed almost 30% improvemement. This translated into fewer unsubscribes and notification opt-outs.
The structure worked as long as the attention behind it held. Its reach depended on continued cross-team investment, and where that investment thinned, so did the coverage. The model was sound. Keeping it staffed and current was the harder, ongoing part.
Build the structure. Also keep the evidence fresh.
A committee can calcify or get quietly routed around once the original urgency fades. If I ran this again I'd schedule a regular re-audit so the evidence stays current, instead of leaning on the first report to carry weight forever.
THE LESSON
Building the governance was the right move. Pairing it with a standing re-audit would have made it more durable, because external evidence is what gave it authority in the first place.
WHAT THIS PROVED
Credibly surfacing a diffuse, ownerless problem enough for an organization to restructure and engineer around it is doable, but not easy. Unorthodox methods work well when deployed with precision.