What friction
actually costs.

Here is something I've learned from shipping payment features at national scale: the guests who don't complete a transaction are invisible. They don't leave a review. They don't send an email. They don't show up in your active user metrics. They just leave — quietly, at the moment of highest intent — and take their order somewhere else or not at all.

This invisibility is why friction is so consistently underestimated as a product problem. The signals are indirect. Conversion rates look like they're in a normal range. The checkout flow tests clean in QA. Nobody files a bug report that says "I would have ordered but you didn't have Apple Pay." They just don't order.

When we launched Apple Pay and Google Pay at Jack in the Box, the result was $94MM in payment volume that hadn't existed before. $81MM from Apple Pay. $13MM from Google Pay. Both net new — no prior baseline, no cannibalization of existing methods. That number is a measurement of what we had been losing, silently, every period before we shipped.

Friction compounds at every step

The mistake most teams make is treating friction as a checkout problem. It isn't. Friction lives at every transition point in the guest journey, and it compounds. A guest who has to reset their password before ordering is already carrying friction before they've seen a menu item. A guest who can't find the offer they came for adds frustration on top of that. By the time they reach checkout and discover their preferred payment method isn't available, the compounding has been running long enough that the abandonment isn't just about payment — it's about the whole experience feeling harder than it should be.

This is why fixing friction incrementally, systematically, across the full journey produces outsized results. Each individual fix might look modest in isolation. A 4% improvement to authentication success rates. A reduction of two taps in the offer flow. A new payment method that covers 40% of your mobile user base. Stack them across the journey and the conversion impact compounds in the same direction friction was compounding against you.

We cut ordering time by 50% at Jack in the Box through a series of targeted friction removals — no single dramatic intervention, just consistent work across every step of the journey over multiple release cycles. The cumulative outcome was a guest experience that was objectively twice as fast. That doesn't happen from one feature. It happens from treating every unnecessary second as a product bug.

The hardest friction to see is the friction you've normalized

There's a particular category of friction that's especially dangerous: the kind your team has stopped noticing because it's always been there. Multi-step checkout flows that made sense when the app launched and have never been revisited. Authentication requirements that were added for security reasons and were never evaluated for their conversion cost. Input fields that require more information than the transaction actually needs.

These become invisible through familiarity. Internal testing doesn't surface them because the people doing the testing know the product too well to experience it the way a first-time user does. A/B tests don't surface them because you'd have to think to test them — you can't run an experiment on something you've forgotten is optional.

The discipline I've developed is to walk through every guest-facing flow on a regular cadence and ask a single question at each step: why does this step exist? If the answer is "I'm not sure" or "it's always been this way," that step is a candidate for removal or consolidation. Most products have more of these than their teams realize, because nobody went back to audit the decisions made when the product was first built.

What the number tells you

$94MM is a striking number. But what it actually communicates is a methodology: find where guests are dropping off, understand why they're dropping off, remove the thing that's causing it, and measure the delta. The payment method example is the clearest version of this because the before and after are so clean. Before: those guests didn't complete. After: they did. The difference is a feature that removed a barrier at the moment of highest intent.

Every product has equivalent opportunities sitting in it. They don't always show up as dramatically because the cause and effect aren't always as direct as "guest doesn't have the payment method, guest doesn't complete the transaction." But they're there. In the authentication flow. In the offer redemption path. In the menu navigation. In the checkout sequence. In every place a guest has to do more work than should be required to accomplish what they came to do.

Finding them requires looking. Not at the guests who completed, but at the ones who didn't — and asking what was in the way.