You can name the problem at your desk, out of your own head — but it will be your problem, not the user's. Between "it seems to me he has a hard time loading a catalog" and "I watched him do it" lies a chasm, and most unnecessary features fall into it. It closes one way only: by contact with the person you're building for.
It sounds banal, and that's exactly why this step gets skipped most often. It feels like everything is already clear. A product engineer treats that feeling with suspicion: "it's already clear" is a signal that you're leaning on a guess you never checked.
You are not the user
The main reason to talk to people is that you're not like them. You know the product from the inside, you're technically literate, you remember where every button is. The user doesn't. What's obvious to you stops them; what seems important to you they don't even notice. You unconsciously project your own habits onto them — and you design for an imagined person who resembles yourself.
This isn't cured by intelligence and experience. Even strong intuition is just compressed past contact; when the contact goes stale or never happened, intuition lies with confidence. So the question isn't whether you're smart, but how long it's been since you watched a real person do their work.
Three forms of contact
Contact doesn't have to be a month-long study. Three simple forms are enough, and all of them are within reach of a single person.
The first is a short conversation. Ten or fifteen minutes with someone who has that very job. Not a pitch of your idea, but questions about their work: how they do it now, what went wrong the last time, how long it took.
The second, and the strongest, is observation. Ask the person to show you how they do the task right now, on their own data, and stay quiet while they do it. Five minutes of watching reveals more than an hour of telling: where they stumble, what they route around, what workaround they've already invented. People don't talk about their workarounds — they just do them, not seeing them as anything worth mentioning.
The third is a quick hypothesis check. Without waiting for a finished product, show a sketch, a rough screen, even a text description of the flow, and watch the reaction. The goal is not to please but to find where the person got confused, or where it solves someone else's job rather than theirs.
What to ask about, and what's pointless
There's a reliable rule: ask about past behavior, not future wishes. "Would you use feature X?" is a question almost everyone politely answers "yes" to, and that "yes" is worth nothing. People predict themselves poorly and want to make you happy. But "tell me how you did this last time" is about a fact that happened; you can't embellish that so easily.
From this come the main traps too. A leading question ("handy, isn't it?") extracts the confirmation you planted yourself. Telling your idea before you've questioned the person nudges them into evaluating your concept instead of describing their own pain. Averaging — "usually I…" — hides the real cases; you have to pull toward specifics: "when exactly was the last time, what happened then." A product engineer listens far more than they speak, and keeps their own solutions to themselves until they've heard the problem.
Closing the loop when working alone
On a large team, contact with the user is often handed to a separate role, and what reaches the engineer is already a retelling — drained of color, missing the very details that decide things. When one person carries the whole path, this turns from a problem into an advantage: whoever builds it has seen for themselves how it breaks. Nothing is lost in the retelling.
But the responsibility is the same — no one will close the feedback loop for you. To close it means not only asking before but also looking after: how people use what you shipped, whether they do what you counted on, whether the pain is gone. That "after" is already about the outcome metric: contact tells you what to fix, the metric tells you whether it got fixed. Without both, you're rowing blind, however fast you row.
The minimum worth making a habit: don't start any notable task until you've talked to or watched at least one real person with that job. One live contact almost always changes the framing — and saves weeks of work in the wrong direction.