At Missguided, the request kept arriving through every channel we had. Why is there no phone number? Put a phone number on the site. I just want to ring someone. Taken literally, the ask was clear: staff a call centre. Price it up, plan the rota, put the number in the footer. A business that prides itself on listening to customers does what it’s told.
Except the literal complaint is rarely the brief. Customers describe what they need in the language of solutions they already know, and in that language a phone number is simply the shape trust takes when you’re worried about an order. Nobody wants to sit in a hold queue. They want to know where their parcel is, whether the return landed, whether a human will take responsibility if something has gone wrong. The phone number was the only word they had for that.
Take the request seriously. Don’t take it literally.
Those are different disciplines. Taking it literally means building what was asked for. Taking it seriously means asking what job the request is doing, and then watching what people actually do, because stated intent and behaviour part company constantly. The worry behind the calls lived at specific moments: after dispatch, around returns, when an order went quiet. Solve the certainty problem at those moments, where the customer already is, and the demand for the phone number falls away. The request was real. The phone number wasn’t.
The same shape turns up in almost every roadmap conversation I sit in now. “We need an app” usually means reordering takes too many taps for the people who buy most. “We need live chat” often means answers arrive slower than stock sells out. “Customers want more choice” regularly means they can’t find the thing they came for. Each request is a torch pointed at a real problem, held by someone who can only describe solutions they’ve seen elsewhere. Build the torch and you’ve bought the shape of the answer without the job it was doing.
The counterargument deserves its due: sometimes the literal request is exactly right, and a customer asking for a phone number occasionally just wants a phone number, particularly at higher price points where the call is part of the service. The point is not that requests are wrong. It’s that they are evidence to be tested, not instructions to be executed, and the test is nearly always cheaper than the build.
Customers are excellent at telling you something is wrong, and unreliable at telling you what to build. Both signals arrive in the same sentence.
The craft is splitting them. Log every request, but file it as a symptom. Find the moment it comes from, watch what people do there, and build for the job. Done well, the requests don’t get fulfilled. They quietly stop arriving, which is the only sign-off that matters.