Doherty Threshold

The original IBM paper measured productivity of mainframe operators and found a cliff at around 400ms. Below that, users stayed engaged and their output went up faster than the speed improvement alone would explain. Above it, users disengaged, got distracted, and productivity collapsed.

Four decades later, the threshold has survived contact with mobile, the web, and now LLMs. The exact number varies (some research points to closer to 100ms for interactions and 1 second for page loads), but the shape of the curve is the same.

Performance isn't a nice-to-have. It's a UX feature that either the product team takes seriously on purpose, or it loses ground gradually to every competitor that does. Every PM has had the argument about whether to spend a sprint on performance instead of new features. The Doherty Threshold is the reason the answer is almost always 'performance' on a mature product.

A team A/B tests a new search implementation that returns results in 180ms vs the old one at 720ms. Features, UI, and ranking algorithm are identical.

The fast variant shows:

— +14% queries per session
— +6% result click-through rate
— +3% retention lift at 30 days

Nothing in the search experience was better except the latency. The product team had originally deprioritised the speed work because 'the search looks the same' — a reasonable-sounding mistake, because the benefit was invisible in screenshots and only showed up in behaviour.

Amazon and Google have both publicly stated that every 100ms of added latency costs them roughly 1% of revenue. The number is domain-specific; the direction is universal.