Watch What People Do, Not Only What They Say
People often describe solutions using the vocabulary they already know. Behavior reveals the problem underneath.
Start With the Human — Do not begin with the product. Begin with the person.
People often ask for solutions, not describe problems
When someone says “I need feature X,” they are usually describing a solution they can imagine based on products they already know.
If a team treats that request as the final truth, it can copy the solution before understanding the need.
Request is an expression. Need is the underlying condition.
User vocabulary is limited by products they already know
People rarely describe a completely unfamiliar future. They remix familiar patterns: a button from another app, a dashboard from an old tool, a workflow that resembles what they already do.
Research therefore asks not only what they want, but why they want it.
People imagine solutions using the vocabulary of their past.
Behavior often tells the truth more clearly than preference
Someone may say they prefer a simple flow while repeatedly opening three tabs to verify information.
Someone may say they do not need reminders while keeping private notes so they do not forget.
Behavior shows where the current system is failing to support reality.
Behavior reveals where the current system fails to support reality.
Workarounds are valuable evidence
When users copy data into spreadsheets, create their own templates, take screenshots for memory, message themselves, or use another tool to finish a step, that is more than inconvenience.
A workaround is a trace of unmet need.
Every workaround is a clue.
Repetition reveals which problems matter
One inconvenience may be an edge case. When the same behavior repeats across people or moments, it becomes a pattern.
Repetition helps distinguish noise from meaningful friction.
Repeated behavior turns anecdote into product evidence.
Translate “I want feature X” into “What am I trying to do?”
This is a translation discipline for product teams.
A request is input. The team translates it back into intention, context, friction and desired outcome before thinking about solution.
Translate requests back into human intent.
Good research does not make users design the product for you
Users are experts in their problem, context and experience. They do not need to be expert system designers.
The product team must observe, synthesize, recognize patterns and take responsibility for design decisions.
Users should not have to become product designers to be understood.
To me when I start turning every request into roadmap
If my inbox fills with feature requests, I want to remember that each request is not automatically a roadmap item.
I want to ask: what behavior sits behind it? What workaround exists? What friction repeats? What outcome is the person truly trying to reach?
A good roadmap is not an archive of everything users ever asked for. It is where deeply understood human needs begin becoming product decisions.
Listen carefully. Observe more deeply. Build only after understanding.