Mira lo que la gente hace, no solo lo que dice
La gente suele describir solutions con el vocabulary que ya conoce. Behavior revela el problem que hay debajo.
Start With the Human — No empieces por el producto. Empieza por la persona.
Los users suelen pedir solutions, no describir problems
Cuando alguien dice “necesito feature X”, suele describir una solution imaginable desde products conocidos.
Request no es lo mismo que need.
Request is an expression. Need is the underlying condition.
El vocabulary del user está limitado por products que ya conoce
La gente imagina el future recombinando patterns familiares.
Research debe preguntar por qué, no solo qué.
People imagine solutions using the vocabulary of their past.
Behavior suele decir más verdad que preference
Lo que alguien dice puede diferir de su behavior.
Behavior muestra dónde el system no sostiene la reality.
Behavior reveals where the current system fails to support reality.
Los workarounds son evidence muy valiosa
Spreadsheet, template, screenshot, private note o tool alternativo son clues.
Workaround es una huella de unmet need.
Every workaround is a clue.
Repetition muestra qué problems importan
Un inconvenience aislado puede ser edge case; repetition crea pattern.
Eso separa noise de friction real.
Repeated behavior turns anecdote into product evidence.
Traduce “quiero feature X” a “¿qué intento hacer?”
Request es input, no decision.
Hay que traducirlo a intention, context, friction y outcome.
Translate requests back into human intent.
Buen research no obliga al user a diseñar el product
El user es expert en su problem y experience.
El product team debe sintetizar y asumir design decisions.
Users should not have to become product designers to be understood.
A mí cuando empiezo a convertir cada request en roadmap
No todo feature request merece ser roadmap item.
Busca behavior, workaround, friction y outcome detrás.
Listen carefully. Observe more deeply. Build only after understanding.