How I Stay Close to Users Without Chasing Every Request

I still believe a product should not hide behind cold, anonymous communication. Users need to know where to ask for help, who owns the problem, and what happens after they report it.

Being close to users is not the same as posting constantly on social media. It means listening to real problems, making decisions, and returning with a clear answer.

I Start With Evidence That Already Exists

Before sending a survey, I read support requests, failed searches, error reports, cancellation notes, and questions that appear more than once. These signals show where the product creates confusion.

I then speak with the people affected. I do not begin with “What feature would you like?” I ask what they were trying to achieve, what they do now, where the process becomes difficult, and what a useful result looks like.

The GOV.UK user research guide makes a useful distinction: opinions that do not come from users are assumptions to test. I apply the same rule to my own ideas.

I Keep the Feedback Loop Short

My loop is simple:

1. Choose one question that affects a product decision.
2. Speak with people who have faced that situation.
3. Watch the real task, not only a presentation of it.
4. Compare the conversation with product and support evidence.
5. Decide what to change or what not to change.
6. Tell participants what happened next.

The final step matters. Someone may spend an hour explaining a problem and never hear from the team again. Even when I reject the requested solution, I can explain the constraint, the decision, or the experiment that will follow.

That response proves that the conversation was not a polite collection exercise.

A Request Is Not Always the Need

A feature request usually describes the solution a user has imagined. My job is to find the need underneath it.

If several people ask for another export button, the actual problem may be the current file format, a missing filter, or a report that arrives too late. Adding more buttons could make the interface worse without fixing the task.

I combine different forms of evidence:

• interviews explain context and language;
• usability tests expose hesitation;
• support reveals repeated pain;
• product data shows where a path stops;
• colleagues working with users add operational context.

No single source tells the whole story. Agreement across several sources gives me more confidence than a loud request from one channel.

Showing the People Behind the Product

The original French article recommended publishing many team photos. I no longer see that as a requirement. People should decide what parts of their lives become public.

There are more useful ways to make a team visible: a clear ownership page, readable release notes, a support address that works, and replies signed by a person. I also state product limits instead of pretending every request is possible.

Honesty can include saying that a problem is understood but not yet scheduled. A specific answer is more respectful than a vague promise.

Contact Must Respect Time and Consent

A research invitation is not permission to send offers later. I separate research, service communication, and marketing. I explain why I am contacting someone, what I want to learn, and how the notes will be used.

I also avoid asking for feedback that the team cannot act on. Research without room for a decision wastes the participant’s time and creates a queue of ignored findings.

Staying close does not mean contacting everyone every week. It means being available at the moment of need, asking better questions, and closing the loop after a decision.

Trust grows from that continuity. Users can see that the team listened and took responsibility for what followed.