Not All Friction Is a Conversion Problem

Product teams are trained to see friction as something to remove. Fewer fields, fewer clicks and fewer reasons to pause usually mean higher conversion. That logic is useful, but incomplete.

When it becomes easier to buy something directly from the content you are watching, the intended outcome is obvious. Shorten the distance between interest and purchase. But when an AI agent can submit hundreds of requests to a public service, the same reduction in effort creates a very different result. Demand rises, while the organization receiving that demand still has limited people, systems and time.

The recent examples of AI services limiting access when demand exceeds available capacity make the point from another direction. Access is not only a user experience question. It is also a capacity decision.

I think product teams need to stop treating all friction as a defect. Some friction is accidental. Some is protective.

Accidental friction is a repeated login, an unclear price, a broken payment flow or a form asking for information the company already has. It adds effort without improving the outcome. Remove it.

Protective friction helps the product understand intent, prevents low-quality demand or gives the operation time to deliver what was promised. A confirmation step before an expensive action, qualification before a specialist consultation, or a limit on how many automated requests one account can submit may slightly reduce conversion. It can still improve the product as a whole.

This distinction matters more now because AI changes the cost of expressing demand. A person previously had to write one support request, complete one application or research one purchase. An agent can perform these actions repeatedly. The effort on the requesting side approaches zero, but the receiving side may still need human review, inventory, compute capacity or regulatory checks.

A team looking only at the funnel will celebrate. More submissions. More trials. More orders. A team looking at the full system may see longer response times, lower fulfilment quality and growing service costs.

I have seen the simpler version of this in growth work. A campaign improves lead volume, but sales receives more poorly qualified conversations. A free trial gets easier to start, but support demand rises from people who were never likely to buy. A new self-service option increases account creation, while manual verification becomes the hidden queue behind it.

None of these outcomes means the team should add random obstacles. It means the team should measure beyond the point where its interface ends.

Before removing a step, I want to know what that step currently filters, signals or protects. Then I want to understand the downstream constraint. How many requests can operations handle? Which actions create variable costs? Where does human judgement remain necessary? What happens to existing customers if demand doubles?

This should also change how teams run experiments. A test is not successful because one conversion metric moves. It is successful when the additional demand produces a worthwhile business outcome without damaging delivery. That requires a small set of connected measures: conversion, quality of demand, cost to serve, fulfilment time and customer outcome. Adding all of them to a giant dashboard is not the answer. Choosing the few that expose the trade-off is.

Roadmaps should reflect this as well. If a feature makes an action dramatically easier, the roadmap needs the capacity, controls and service changes required to absorb the result. Shipping the entry point while leaving the receiving operation unchanged is not growth. It is transferring work to another team.

The product leader’s job is therefore not to remove the most friction. It is to remove the friction that serves no purpose, while keeping or redesigning the friction that makes the system sustainable.

A smooth customer journey is valuable. A smooth journey into a queue, a rejection or a degraded service is not.