When giving an ‘F’ is the right product decision

Friction is the 'F' word of product management. Say it in a room full of PMs and watch the reaction. It’s treated like a failure. A symptom of bad design. Something to be eliminated at all costs. The entire discipline has been built around this idea: remove steps, shorten flows, and make everything effortless. The data usually backs it up, so the belief gets stronger with every iteration.

The product community has spent years reinforcing this mindset. Reducing friction is consistently cited as a core driver of activation, retention, and conversion. It shows up in onboarding frameworks, optimization guides, and growth playbooks alike. The assumption is so deeply embedded that questioning it almost feels wrong. 

But here’s the thing nobody really talks about. Sometimes giving users an 'F' is exactly the right call, and knowing when to do it might be one of the most underrated skills in a product.

The problem we don’t account for

I ran into this while working at an e-commerce company, where I was handling both cybersecurity and customer identity and access management (CIAM).

On paper, those two roles should align, or at least that’s how it looks.

In practice, it didn’t feel that way. The roles seemed aligned on the surface, but once you got into it, the gap became clear. The CIAM side was focused on reducing friction: improving login success rates, simplifying onboarding, and removing unnecessary steps. Every extra click was treated as a potential drop-off.

At the same time, the cybersecurity side was dealing with an increasing number of account takeover attempts. At its peak, we were seeing over 100,000 account takeover attempts every week. And from the system's perspective, a significant number of them looked completely legitimate. 

These weren’t isolated cases. They were happening at scale, often coordinated rather than random. Attackers and hackers were launching constant account takeover attempts using stolen account details to breach real accounts. 

What made it more complicated was what happened after they got in, specifically during high-stakes moments in the journey like checkout, changing payment information, or resetting account recovery settings, where a lack of friction becomes a massive liability. 

From the system’s perspective, everything looked fine. Orders were placed, payment methods were used, and the behavior didn’t seem unusual. Which is exactly what made it a problem. From a product perspective, these were successful sessions. Users were moving through a flow that had been optimized.

Except they weren’t really the users we had in mind. Not exactly.

We thought we were making things easier for our customers, but we were actually making it effortless for intruders.

Where things start to break

If you look at this through a conventional product lens, the solution seems obvious: add more security.

Most platforms default to putting up traditional, blanket security walls across the whole product. Add OTP. Add MFA. Use CAPTCHA. Tighten validation. Most teams go in that direction, and to be fair, it makes sense on paper.

But there's an assumption buried in that approach that doesn't hold up. It assumes everyone should go through the same experience. That's where things start to break down. 

Real users feel it. Login becomes slower. Checkout gets interrupted. Drop-offs increase, not because intent is missing, but because the experience is getting interrupted at the wrong moments. 

Meanwhile, attackers and hackers don’t disappear. They adapt, learning where friction is lower and finding ways to work around the security checks you've put in place. You end up increasing friction for everyone without necessarily stopping the right people. 

This raises a more fundamental question: is friction the problem, or is misapplied friction the problem?

Rethinking friction

This is where the perspective started to shift.

It's not about adding more layers or removing them. It's about being selective. Adding OTP as a blanket rule hurts conversion. Not adding it increases risk. The limitation isn't in the tools themselves. It's in the absence of a system that can make decisions in context.

So the question changes. Instead of asking which friction patterns can stop bad actors, you start asking how to decide which visitor should experience which level of friction. Because most users behave in a fairly predictable way. A smaller group behaves very differently. And when both are treated the same, that's when things start to feel off.

Designing a framework for friction

Once you accept that not every visitor should have the same experience, your approach shifts toward building a dynamic framework. Here’s how we approached building ours.

The first thing we did was map where seamlessness was actually a liability – not across the whole journey, just the moments where a mistake was most costly, such as login, checkout, or changes to payment and account recovery settings. These were the places where getting it wrong had real consequences. Everything else could stay fast.

From there, as a second step, we started looking for specific clues that show when a session belongs to the right person or an intruder. These are things like a change in IP, a different location, logging in at an unusual time, repeated payment attempts, or behavior that doesn’t quite match previous patterns. Individually, these clues don’t mean much, but when you look at them together, patterns begin to emerge.

To sort these patterns, we mapped them onto a simple risk matrix that acts as a sliding scale. A known user on a known device sits at one end, while a spike of login attempts from different locations within ten minutes sits at the other. Most sessions fell somewhere in the middle, and that's where the interesting decisions happened. 

Applying friction more carefully

This is where the framework came to life in practice, with our Adaptive Fraud Detection service, a layer built to evaluate risk level instantly and assign a dynamic friction level.

Instead of a blanket approach, the goal became to apply the lightest friction possible that actually solved the problem.

• Low-risk users move through without interruptions. Everything feels smooth.
• Medium risk gets soft friction, a reCAPTCHA or an email notification – just enough to validate intent without breaking the flow. 
• High risk gets hard friction or a full stop. MFA, OTP, a temporary lock. Not as punishment, but because at that point the system no longer had enough confidence to let the session continue. Not in a dramatic way, just no trust, so no continuation. 

That’s where the idea of giving an “F” fits. Not every session should move forward, and that’s fine.

What changed

By using adaptive friction, we only triggered extra verification like MFA, OTP, or a hard block for fewer than 1% of our legitimate users. Things that used to go unnoticed were now being challenged at the right moment, and, maybe most importantly, we gained visibility. Instead of constantly choosing between security and conversion, we could observe both and adjust. 

For the vast majority of genuine users, nothing changed. The experience remained seamless. The system was running in the background, and they had no reason to know it existed. Yet behind the scenes, the results were significant because the service prevented almost 100,000 account takeover attempts weekly and reduced fraud chargebacks by 30%, potentially saving £3.5M annually. 

The number we kept coming back to was 1%. If fewer than 1% of genuine users were hitting a hard friction gate, the system was working. If that number climbed, it meant friction was becoming a blunt instrument again and needed recalibrating. 

The takeaway

This is the shift that conventional product thinking rarely prepares you for. Everything we learn pushes us in one direction. Reduce friction, simplify journeys, make things seamless. Those principles work, until they don't, because they rely on an assumption: that the person on the other side is someone you're trying to help.

That's not always the case.

So, the next time you're designing a product, it's worth pausing for a moment. What if the person on the other side is not your user? Because sometimes, the right product decision is not about removing friction. It's about knowing exactly when to give an 'F'.