Si “poner al usuario en el centro” fuera solo una decisión, ya lo habríamos resuelto hace tiempo.
La mayoría de equipos lo dice con convicción, y en muchos casos lo cree de verdad. El problema es que entender el concepto es fácil. Lo difícil es convertirlo en una práctica que se sostenga en el tiempo.
Cuando un equipo está realmente en contacto con usuarios de forma habitual, lo notas enseguida. No por lo que dice, sino por lo que le cuesta. Hablar con usuarios no es una declaración de intenciones. Es un trabajo real que implica logística, coordinación, insistencia y una disciplina que no se parece a “hacer una entrevista de vez en cuando”.
Por eso, cuando hablo con un equipo y nadie menciona las fricciones típicas de esta práctica, suelo entender que el contacto con usuarios es, como mucho, esporádico. No lo digo como crítica. Lo digo como observación. Si el hábito existiera, esas fricciones estarían en la conversación, porque forman parte del día a día, sobre todo al principio.
La fricción suele aparecer de formas muy concretas. Por ejemplo:
- Conseguir usuarios dispuestos a hablar y que no siempre sean los mismos perfiles.
- Coordinar agendas sin que sea un infierno para el equipo y para el usuario.
- Evitar que cada entrevista sea un evento extraordinario que se cae en cuanto hay una urgencia.
- Hacer que el aprendizaje no se quede en una conversación aislada, sino que se acumule y se convierta en decisiones.
- Mantener una cadencia mínima para que el usuario no sea un recuerdo, sino una referencia presente.
Si esto no aparece en el relato de un equipo, es muy probable que el usuario esté “en el centro” solo como idea.
Por qué hablar con usuarios de forma habitual es tan complicado
Aquí es donde se suele simplificar demasiado el problema. Se dice “hablad con usuarios” como si fuera una tarea más del backlog. Pero hablar con usuarios de forma habitual no es una tarea aislada, es un proceso que tienes que diseñar. Y diseñar procesos cuesta, porque implica tomar decisiones, simplificar, automatizar y sostener el esfuerzo hasta que se convierte en hábito.
Además, no se trata de hablar con usuarios una vez. Se trata de poder hacerlo de forma recurrente. Ahí cambia todo.
La dificultad no está en hacer una entrevista. La dificultad está en hacer que esa entrevista no sea una excepción.
En la práctica, aparecen obstáculos típicos que explican por qué muchos equipos ni siquiera llegan a empezar:
- No hay un canal claro para reclutar usuarios de forma continua.
- La responsabilidad queda difusa y al final nadie la lidera.
- Cada entrevista requiere empezar desde cero con contacto, coordinación y contexto.
- La agenda del equipo se llena de urgencias y la conversación con usuarios se percibe como “algo que ya haremos”.
- No hay una forma sencilla de capturar y compartir aprendizaje, así que el esfuerzo se siente poco rentable.
- Se repite el mismo patrón con perfiles de usuario demasiado parecidos, lo cual da una falsa sensación de validación.
- La organización asocia “hablar con usuarios” a “investigación larga”, y eso añade resistencia.
Cuando un equipo no tiene un sistema mínimo, la práctica se vuelve frágil. Un mes se hacen entrevistas, el siguiente no. Una persona empuja, luego cambia de prioridades. Se logra hablar con tres usuarios, se aprende algo, y después pasan semanas sin volver a hacerlo.
El problema no es falta de intención. El problema es falta de mecanismo.
El atajo que parece user centric y no lo es
En este punto suele aparecer un atajo muy común, especialmente en equipos que están intentando “hacer las cosas bien” pero no tienen todavía un hábito sólido de discovery.
He visto a muchos equipos hacer una lista de funcionalidades que creen que podría estar bien desarrollar y preguntarlo a sus usuarios para validar un posible roadmap. Lo plantean como si fuera una forma de escuchar. A veces incluso lo sienten como una práctica centrada en el usuario, porque hay usuarios implicados y porque se recoge feedback.
El problema es que esa dinámica cambia completamente el tipo de información que obtienes.
Cuando preguntas por funcionalidades, llevas al usuario al terreno de la solución. Lo invitas a opinar sobre algo que todavía no existe, en un contexto artificial, sin la presión real de su día a día. Y además, le obligas a reaccionar a tu marco, no a contarte su realidad.
No es que esa información sea inútil, pero tiene un riesgo enorme. Puede darte una sensación de validación que no es comprensión.
Este es uno de los motivos por los que muchos equipos creen que “ponen al usuario en el centro” cuando en realidad solo lo están usando como confirmación.
Recogida de requisitos no es product discovery
Aquí es donde conviene hacer una distinción que parece semántica, pero no lo es.
La recogida de requisitos, en su versión tradicional, parte de una lógica. Preguntar al usuario qué necesita para convertirlo en una lista de cosas a desarrollar.
El product discovery, cuando se hace bien, parte de otra lógica. Entender qué está viviendo el usuario, qué intenta conseguir, qué le preocupa, qué le frustra, qué desea, qué le limita, qué alternativa utiliza, qué trade-offs acepta y cómo resuelve hoy su situación.
La diferencia es importante porque cambia la conversación y cambia el resultado.
Si preguntas “qué funcionalidad te gustaría”, es probable que el usuario te conteste con ideas, preferencias o deseos generales. A veces incluso con “soluciones” que reflejan más su imaginación que su contexto real.
Si preguntas “qué estás intentando resolver” y “qué ocurrió la última vez que lo intentaste”, la conversación va a otro lugar. Deja de ser una opinión y se convierte en un relato. Y en ese relato es donde suele aparecer la realidad del usuario.
El discovery, tal y como lo entiendo y como lo planteo en Haz Producto, se centra en el espacio del problema. No porque desprecie las soluciones, sino porque sé que una solución buena nace de una comprensión profunda. Si te saltas esa comprensión, lo que haces después es apuntar con poca información.
En el espacio del problema aparecen cosas que no salen cuando preguntas por funcionalidades:
- Momentos concretos en los que el usuario se frustra o abandona.
- Expectativas que el producto genera y luego no cumple.
- Limitaciones del contexto que el equipo no había considerado.
- Soluciones alternativas que el usuario ya utiliza y que compiten con tu producto.
- Motivaciones reales, no solo declaraciones de intención.
- Pequeños detalles operativos que hacen que una “buena idea” sea irrelevante en la práctica.
Esto no se obtiene preguntando “qué te gustaría tener”. Se obtiene entendiendo la vida del usuario lo suficiente como para que tus decisiones no sean una suposición.
El sesgo del yo ideal y la falsa sensación de cercanía
Hay otro problema que he visto repetirse mucho y que es especialmente traicionero. Cuando un equipo habla con usuarios de forma esporádica, tiende a interpretar que ese contacto es más continuo de lo que realmente es.
Es como si el equipo se contara una historia de sí mismo. Una versión ideal. “Hablamos con usuarios”, “estamos cerca”, “los tenemos en cuenta”.
Y es verdad que han hablado, pero la realidad es que han hablado poco. O han hablado con perfiles muy parecidos. O han hablado solo en ciertos momentos, por ejemplo cuando hay que validar una solución. El sesgo del yo ideal rellena los huecos y crea una sensación de seguridad que no corresponde con el nivel real de comprensión.
Esto tiene un efecto práctico muy claro. Reduce la urgencia de montar un sistema. Si crees que ya estás cerca, no sientes que necesites cambiar nada.
Y ahí el usuario deja de ser una referencia presente. Se convierte en un recuerdo.
Qué significa realmente poner al usuario en el centro
Llegados a este punto, la idea se vuelve más concreta.
Poner al usuario en el centro significa que su realidad influye de forma consistente en cómo decides.
Y para que su realidad influya de forma consistente, necesitas acceso recurrente. Necesitas poder hablar con usuarios con una frecuencia suficiente como para que el aprendizaje se acumule, se compare, se contraste y se convierta en criterio.
Aquí aparece una idea que suele incomodar porque es muy simple. Si no hablas de forma habitual con usuarios, es muy difícil que el usuario esté en el centro. Puede estar en tu intención. Puede estar en tu discurso. Pero no está en tu proceso.
Cómo se convierte en un sistema y por qué Continuous Discovery encaja
Una de las propuestas más prácticas que conozco para convertir esto en un hábito es el enfoque de Continuous Discovery Habits, de Teresa Torres. No porque sea la única forma, sino porque plantea algo que muchos equipos no se atreven a hacer. Diseñar el contacto con usuarios como un sistema recurrente.
En su enfoque, el punto de partida es sencillo y, por eso, exigente. Hablar con usuarios todas las semanas.
No como evento. Como costumbre.
Teresa Torres propone que estas conversaciones no sean entrevistas de una hora, sino encuentros breves, de unos 20 minutos. Si sabes lo que buscas, no necesitas más. Es mejor sostener conversaciones cortas y frecuentes que hacer una entrevista larga cada tres meses.
También habla de un objetivo habitual de dos o tres conversaciones por semana. Pero lo importante no es el número exacto, sino entender que esto funciona como un hábito que se construye con progresión, porque empezar cuesta.
Una forma realista de empezar, siguiendo el enfoque de Teresa Torres, es:
- Empezar con una conversación semanal y mantener esa cadencia varias semanas para crear el hábito, con usuarios distintos siempre que sea posible.
- Convertirlo en una cita recurrente, no en una tarea que se decide cada vez.
- Reducir fricción con procesos simples de reclutamiento y agenda.
- Automatizar todo lo posible para que el sistema sea fácil de mantener.
- Capturar el aprendizaje de forma ligera para que no se pierda y para que pueda compartirse.
Cuando ese sistema existe, el usuario deja de ser una actividad aislada y empieza a integrarse en el proceso de producto. No solo sirve para discovery. Sirve para tests, para obtener feedback después de un lanzamiento, para aclarar dudas sobre un flujo, para explorar un comportamiento observado en datos, para entender por qué algo no se usa.
La diferencia no es cuantitativa. Es cualitativa. Cambia la relación del equipo con la realidad del usuario.
Por qué se nota tanto quién lo ha hecho
Montar un sistema así no es fácil. Reclutar usuarios no es fácil. Agendar de forma recurrente no es fácil. Sostener la cadencia cuando hay trabajo, urgencias y dependencias no es fácil. Y por eso es tan reconocible quién lo ha hecho y quién no.
El equipo que lo ha puesto en marcha suele estar orgulloso. No por ego, sino porque sabe el esfuerzo que hay detrás. Y porque cuando funciona, cambia la calidad del trabajo. Las decisiones tienen otra base. Las discusiones son distintas. La priorización se vuelve más sólida. El equipo deja de inventarse al usuario y empieza a convivir con él.
Poner al usuario en el centro no es un eslogan. Es una práctica. Y como todas las prácticas serias, se nota en lo que cuesta y en lo que transforma.
