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.
An example from practice: an engineer added a search to the interface because "it's more convenient." Users didn't use it — they found what they needed through the sidebar menu, because the list was small and they remembered it. Two days of work, zero benefit. One five-minute call beforehand would have made it clear that search was solving a non-existent problem.
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. Finding the person is easier than it seems: reaching out directly with a short explanation ("I'm building a tool for X, I want to understand how you do this now — 15 minutes?") works better than waiting for "the right moment."
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.
Three conversations: what you actually learn
Imagine: you're building a shift-planning tool alone for a small delivery service. The initial hypothesis is that the main problem is the lack of a convenient calendar. You run three conversations in one day.
Conversation with the dispatcher. They describe switching every five minutes between a spreadsheet and a messenger to find out who came in for their shift. You ask: "Tell me about the last time a shift went badly — what happened?" — "Three couriers didn't check in. I found out only at the end of the day, when nothing could be done anymore." The problem is not the absence of a calendar — it's the absence of a signal about a no-show at the moment when you can still react and find a replacement.
Conversation with the manager. They say they want to see who is working on weekends. You ask them to show how they do it now. They open an Excel file with tabs by week — created three months ago, only the last two weeks filled in, everything else empty. You ask: "Why ask for a feature you already have?" Silence, then: "I guess that's not it. I just don't want to fill this in by hand every week." The real job: automatically generate the schedule based on rotation rules, not maintain a spreadsheet by hand.
Conversation with the courier. "How do you find out about your shift?" — "The manager posts in the group chat the day before, sometimes forgets." — "Has it happened that you came in for the wrong shift or found out too late?" — "That happened twice." A separate problem: the schedule doesn't reliably reach the person who needs to execute it.
After three conversations the picture is completely different: not "we need a better calendar" but three connected jobs — automatic schedule generation, real-time no-show notification, reliable schedule delivery to the courier. A beautiful interface is the last thing that matters here. Without these conversations you would have spent several weeks on UI for an imagined problem and wondered why the tool was barely used.
What to do with what you heard: don't try to tackle everything at once. Write down the three problems, pick the one that came up in two out of three conversations — that's a signal it's real. Note the rest and come back later. The first conversation with the dispatcher gave the sharpest job: a no-show with no signal. That's the one to take first — it's concrete, measurable, and clearly hurts.
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.
A useful rule for taking notes: record quotes, not conclusions. "I spend half the day on this every Friday" is worth more than "the user said it's inconvenient." A quote preserves the sharpness; a conclusion is already your interpretation, which may be wrong. When you later explain the task to an agent or prioritize work, the person's exact words keep the focus better than generalizations.
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.
In practice, "looking after" doesn't have to be a large study. Often it's enough to message the same dispatcher two weeks later: "How's the thing we launched working? Any situations where it doesn't help?" Five minutes of conversation after the release is worth more than fifty minutes of theorizing before it. And that second contact is usually what surfaces the next real job — not the one you imagined yourself.
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.
This also changes the quality of tasks for the agent. When you've just heard yourself how a person describes their work, you phrase the task more concretely and precisely — because you remember the details. The agent gets a better input and delivers a better output.
Contact is not a phase before development. It is an ongoing part of development itself.
What this means in practice
Contact with the user is not a one-time event before the start of a project — it's a work rhythm. Small, frequent touches are better than a large study once a quarter. Five minutes of conversation at the start of a task and five minutes of feedback after the release — that's the minimal working loop.
Mistakes that repeat most often:
- Telling the idea before questioning. As soon as you've explained your concept, the person switches from describing their own pain to evaluating your concept. Listen first, then talk. Always.
- Asking about future behavior. "Would you use this?" gets a polite "yes" that means nothing. Only questions about the past work: "Tell me how you did this last time."
- Talking to one person and thinking the picture is clear. One person is one angle. You need two or three contacts to understand what repeats and what's a coincidence. Three conversations fit in one workday.
- Skipping contact after the release. Talking before is good. But without looking after — it's only half the loop. Are you seeing how people use what you built? Did the pain go away or did people just find another workaround?
- Having contact and changing nothing in the task. A conversation must influence what you build. If after every contact the task remains exactly the same — you're hearing but not listening.
What's next
Contact gives you the picture of the problem — next you need to choose what to build first and agree with yourself on how you'll know it worked. That's what "The smallest valuable slice" and "Outcome metrics" are about. And for an overview of how the product engineer's role is structured — who they are, what they do, and why one person with an agent can do more than a team used to — see "Product engineer".