Onboarding drop-off was concentrated in the verification steps of our card product, and the obvious read was a UX problem. That's almost always the first conclusion people reach when a funnel leaks at a step with forms and friction in it. Fix the copy, shorten the form, add a progress bar. We'd already done versions of all three before I started really looking at the data.
None of it moved the number in a way that mattered.
The data said something else
When I cut drop-off by user segment instead of looking at the funnel as one shape, the picture changed completely. New-to-credit and thin-file users were failing at different points than existing-credit users, and for different reasons. It wasn't one funnel with one leak. It was at least two different populations hitting two different walls, and we'd been trying to patch both with the same fix.
That reframed the problem. It wasn't friction in the abstract. It was a mismatch between a one-size-fits-all KYC flow and customers with very different risk profiles and very different tolerance for friction.
The fix was never going to be a UX patch. It had to be a different flow for a different user, and that meant a credit decision, not a design decision.
Two stakeholders, both right
Risk and our NBFC partner wanted more verification steps. Growth wanted fewer. Both had a real claim. Risk was accountable for fraud exposure on a regulated lending product. Growth was accountable for activation, and every extra step we added was visibly costing us conversion.
I couldn't resolve that by picking a side, and I couldn't resolve it with an opinion either. Whoever argued more persuasively in the room was going to win, and that's a bad way to make a decision that affects fraud exposure and revenue at the same time.
So I moved the argument onto data both sides would trust.
What I actually did
I instrumented the funnel to isolate, segment by segment, exactly where each group dropped and what each additional verification step was actually costing in activation versus what it was catching in fraud. That's a different question than "should we add this check." It's "what does this specific check cost, for this specific user, and is that cost worth it."
Once that was visible, the answer wasn't more checks or fewer checks. It was a step-up flow: lighter verification where the data showed risk was genuinely low, and stricter verification where it spiked. Match the intensity of the check to the user in front of you, instead of applying the same gate to everyone.
That's a small sentence for what took real instrumentation work to get right. We had to be able to see, per segment, the relationship between a specific check and a specific outcome, before we could make the call with any confidence.
What happened
Onboarding completion rose about 25% with zero increase in fraud or offer drop-offs. Risk got a stricter gate exactly where it was warranted instead of everywhere. Growth got their conversion back. And the conversation between the two teams changed from "what do we believe" to "what does the data show," which is a much easier room to be in.
The part I'd do differently
I'd instrument the segmentation earlier. We spent real time on UX-level fixes before the data told us the funnel wasn't one funnel. If I were starting this today, segment-level instrumentation would be the first thing I build, before a single copy change, because it's the only way to know whether you're solving a UX problem or a credit problem, and they need completely different fixes.
The instinct I keep coming back to: when two reasonable, well-informed people disagree about what to build, the fastest way through usually isn't more debate. It's a question neither side can argue with, because you're both looking at the same number.