Main idea

A product question never arrives when you are free. It arrives because a customer is waiting for an answer, because a salesperson is in a meeting, because support has to reply before the end of the day. So it imposes its own moment, and that moment belongs to the sender.

What gets paid then isn't only the half hour in a test environment. It is leaving a subject you had entered, working through another one, then trying to come back. What you had in mind when you left — the connections you were holding, the hypothesis you were testing, the structure you were starting to see — isn't filed anywhere you could retrieve it from.

The two costs don't yield to the same remedies. Shortening the search attacks the first; only not being asked at all, or being able to send the question elsewhere, attacks the second. An answer obtained in two minutes instead of thirty leaves the interruption untouched.

Why it matters

This corrects a common evaluation error when tooling up: the gain is measured in search time, and the conclusion is that the problem is solved while the costliest part has stayed exactly where it was.

It also says what to aim at first for roles whose work is cumulative: move the question, rather than speed it up.

Nuances and limits

Not all interruptions destroy the same thing. A question that lands during a mechanical task costs its time and nothing else; the continuity cost is proportional to the depth of the work interrupted.

And the interruption sometimes brings what it destroys: a question from the field recalls a real use, and it happens that it reframes the very subject you were working on.

Open questions

• Under what conditions can a question that is urgent for a customer wait, without its sender going off to find somebody else?