CASE STUDY · PAYPAL CONSUMER · 2019–2024
Asking Less to Get More
How progressive onboarding replaced a data-collection gauntlet with a trust-first system that actually activated users.
A reverse firehose.
Before a user could do anything useful, the product demanded everything: identity, verification, financial instruments, regulatory acknowledgments, and a collection of asks that individual teams had inserted over time — each locally defensible, none accountable for the total.
The original compliance-driven floor was legitimate. What accumulated on top of it was organizational sediment.
The Signup flow accumulation (core compliance steps plus team-inserted additions):
12 steps before any value is delivered
What made it worse: research made the problem look smaller than it was. Survey data and brand recognition scores were fine. Put those same users in front of actual tasks and features they could name, features visible on screen, simply failed to register as available and relevant to them.
Users weren't confused about what PayPal is. They were confused about what PayPal could do for them right now, in this moment, with this account.
The onboarding flow was optimized for completion, not understanding. It produced compliant users, not capable ones. Any mental model customers had of the system quickly decayed, and they rarely stepped into another product.
Only ask for info when you're giving something in return.
A bank account link means something completely different when it unlocks a specific capability the user has already decided they want, versus appearing as step five of eight in a setup sequence. The same data collection, in a different context, produces a different user.
Before
After
Intent detection early in the flow (P2P vs. commerce vs. mixed-use) shaped what came next. Users who received a path matching their apparent intent were significantly more likely to complete a second meaningful action within their first month.
Platform constraint: The signup system was a monolith — global regulatory requirements across hundreds of locales, high engineering risk on any change. Progressive onboarding had to happen downstream, on the surfaces where there was room to move.
Push Notifications as an Object Lesson
Push notification opt-in was the most valuable way we could get a customer’s attention, and this was a rock solid example of how asking for too much, too soon, with no concrete benefit or trust basis was a miss. At signup, no relationship had been established, no value delivered, so users had little reason to opt-in to this potentially invasive permission. Even worse, once that request was declined, the conversation was effectively over: iOS only allows you to invoke Push Notification permissions directly once. After that, we had to give the user a tedious explanation how to navigate through Settings to opt-in, which is obviously not likely.
Our hypothesis was that if we gave customers an unambiguously useful reason to grant us permission to their attention window, they would be more likely to take the leap. Furthermore, by giving them a proxy ask instead of invoking the permission request directly (with a high likelihood of success) we preserved the simple path, which further increased our chances. Effectively, we changed the conversation from “Welcome to PayPal newbie. Let me blast you with info, we will tell you why later” to “Hey return customer, it’s your friend PayPal here. THe thing you already said you want to do is much better with notifications. Can we ask you to turn those on? You can change your mind later.”
your packages
User asked for this.