¿Cuándo descubriste que lo que creías que quería el usuario era otra cosa?

Lo que la gente dice, lo que hace y lo que necesita

El primer error nace de tratar como equivalentes tres cosas que casi nunca coinciden: lo que una persona dice que quiere, lo que hace en la práctica, y lo que en el fondo necesita.

La distancia entre lo que la gente declara y lo que luego hace está bien documentada en la investigación de usuarios. Las personas no mienten cuando responden una encuesta o una entrevista. Simplemente somos malos prediciendo nuestro comportamiento futuro, tendemos a dar la respuesta que creemos correcta o socialmente deseable, y racionalizamos después decisiones que tomamos por motivos que ni siquiera reconocemos. Por eso, preguntar directamente "¿usarías esto?" o "¿pagarías por aquello?" produce respuestas amables y poco fiables.

Steve Portigal, en Interviewing Users (2013), insiste en que el trabajo de investigación no consiste en recoger opiniones, sino en entender contextos y comportamientos. Cuando alguien pide una función concreta, esa petición es un dato, no una instrucción. Nuestro trabajo es preguntarnos qué intenta lograr esa persona cuando pide eso, porque la solución que propone rara vez es la mejor respuesta a su propia necesidad.

La petición no es la necesidad

Aquí está el corazón del malentendido. Cuando un usuario dice "necesito un botón para exportar a Excel", mezcla en una sola frase un objetivo, un problema y una solución que él mismo ha imaginado. Si tomamos la frase al pie de la letra y construimos el botón, es posible que hayamos resuelto lo que pidió sin tocar lo que necesitaba.

Quizá esa persona necesitaba compartir información con alguien que no tiene acceso al sistema. Quizá quería un informe que el producto no ofrece. Quizá no confiaba en los datos de la herramienta y quería revisarlos por su cuenta. Cada una de esas necesidades reales llevaría a una solución distinta, y probablemente mejor, que el botón que pidió. El botón era su hipótesis, no su necesidad.

El marco de los jobs to be done, desarrollado por Anthony Ulwick y popularizado por Clayton Christensen, ofrece una forma útil de mirar esto. La idea es que las personas "contratan" un producto para hacer un trabajo en su vida. Christensen lo resumía diciendo que nadie quiere un taladro, sino un agujero, y en realidad ni siquiera el agujero, sino aquello que el agujero le permite conseguir. Si nos quedamos en el taladro que el usuario pide, optimizamos la herramienta equivocada. Si entendemos el trabajo que intenta hacer, se abre un abanico de soluciones que antes no veíamos.

Por qué caemos una y otra vez

Si este desfase es tan conocido, ¿por qué seguimos tropezando con él? Hay varias razones, y ninguna tiene que ver con la falta de talento.

La primera es la comodidad. Interpretar literalmente lo que el usuario pide es rápido y evita el trabajo incómodo de investigar de verdad. Tomar la petición como instrucción nos libera de la responsabilidad de decidir, porque siempre podremos decir que hicimos lo que nos pidieron.

La segunda es el sesgo de confirmación. Cuando ya tenemos una idea de lo que queremos construir, escuchamos selectivamente. Damos peso a lo que confirma nuestra hipótesis y descartamos lo que la contradice. La investigación se convierte entonces en una búsqueda de justificación en lugar de una búsqueda de verdad.

La tercera es la presión por entregar. Detenerse a entender la necesidad real parece un lujo cuando hay un backlog que vaciar y unas fechas que cumplir. Marty Cagan lo describe con claridad en Inspired (2017): muchos equipos operan como fábricas que producen funcionalidades sin preguntarse si resuelven un problema real, porque la organización mide su éxito por lo que entregan y no por el valor que generan.

Don Norman, en The Design of Everyday Things (2013), añadía una dimensión importante. Los diseñadores expertos dedican un esfuerzo deliberado a determinar cuál es el problema real antes de resolverlo, y resisten la tentación de aceptar el primer enunciado que reciben. Esa resistencia es una competencia que se entrena, no un talento innato.

Cómo acercarse a la necesidad real

No hay una fórmula infalible, pero sí prácticas que reducen el desfase de forma significativa.

La primera es observar comportamiento en lugar de recoger opiniones. Ver a alguien usar un producto, o reconstruir con detalle cómo resolvió un problema la última vez que lo tuvo, dice mucho más que preguntarle qué haría en abstracto. El pasado concreto es mejor predictor que el futuro imaginado.

La segunda es indagar en el porqué antes de aceptar el qué. Cuando llega una petición, la pregunta útil no es "¿lo construimos?", sino "¿qué intentabas conseguir cuando pensaste en esto?". Repetir esa pregunta con curiosidad genuina suele revelar una necesidad que la petición original ocultaba.

La tercera es mantener un contacto regular con usuarios reales, no puntual. Teresa Torres, en Continuous Discovery Habits (2021), defiende que los equipos de producto sostengan entrevistas frecuentes, idealmente semanales, para que la comprensión de las necesidades no dependa de un gran estudio anual que enseguida queda obsoleto. El descubrimiento continuo evita que construyamos durante meses sobre una imagen congelada del usuario.

La cuarta es validar con comportamiento comprometido antes de construir a lo grande. Cindy Alvarez, en Lean Customer Development (2017), recuerda que la mejor señal de que una necesidad es real no es que alguien diga que le interesa, sino que haga algo que le cueste: dedicar tiempo, poner dinero, cambiar su forma de trabajar. Diseñar pequeños experimentos que pidan ese tipo de compromiso da información mucho más fiable que cualquier declaración.

El contexto de la IA: síntesis veloz, comprensión frágil

La inteligencia artificial ha transformado la parte más laboriosa de este trabajo, y conviene mirar ese cambio con matices, porque tiene una cara luminosa y una trampa.

La cara luminosa es real. Hoy un equipo puede procesar en minutos cientos de reseñas, tickets de soporte y respuestas de encuestas, y obtener una agrupación temática razonable de lo que la gente dice. Esa síntesis, que antes consumía días, libera tiempo para lo que de verdad importa.

La trampa es sutil. Toda esa capacidad opera sobre lo que la gente dice, y ya sabemos que lo que la gente dice no es lo que la gente necesita. La IA es extraordinaria resumiendo declaraciones, y precisamente por eso puede reforzar el viejo error de confundir la petición con la necesidad, ahora a mayor escala y con apariencia de rigor. Un informe generado que dice "los usuarios piden X" suena tan solvente que invita a construir X sin más.

Hay un riesgo añadido. Está de moda pedir a la IA que genere "personas de usuario" o que simule cómo reaccionaría un cliente. Esos usuarios sintéticos pueden ser un punto de partida para ordenar ideas, pero no dejan de ser una conjetura estadística sobre cómo hablaría alguien, no evidencia de lo que una persona real necesita. Sustituir la conversación con usuarios de carne y hueso por su imitación generada es cambiar comprensión por comodidad. La IA acelera la recogida de lo que se dice, pero no nos exime de la tarea insustituible de entender lo que se necesita, que sigue requiriendo observar y hablar con personas reales.

Descubrir que lo que creías que quería el usuario era otra cosa es una de las experiencias más formativas del trabajo en producto, y también una de las más humillantes, porque suele llegar cuando ya hemos invertido esfuerzo en la solución equivocada. La buena noticia es que ese descubrimiento, si se produce pronto y barato, es exactamente lo que hace avanzar a un buen equipo.

La competencia que separa a quien construye lo que le piden de quien construye lo que hace falta no es la capacidad técnica, sino la disposición a dudar de la primera interpretación y a ir a buscar la necesidad real donde vive, que es en el comportamiento de las personas y no en sus declaraciones. En un momento en que la tecnología nos facilita más que nunca resumir lo que la gente dice, cultivar esa duda fértil se vuelve más valioso, no menos.

¿Cuál es tu historia? ¿Cuándo descubriste que lo que creías que quería el usuario era otra cosa, y qué señal se te había escapado por el camino?

Bibliografía

• Alvarez, C. (2017). Lean Customer Development: Building Products Your Customers Will Buy. O'Reilly Media.
• Cagan, M. (2017). Inspired: How to Create Tech Products Customers Love (2ª ed.). Wiley. I
• Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. HarperBusiness.
• Norman, D. A. (2013). The Design of Everyday Things (ed. revisada y ampliada). Basic Books.
• Perri, M. (2018). Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media.
• Portigal, S. (2013). Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media.
• Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.
• Ulwick, A. W. (2016). Jobs to Be Done: Theory to Practice. IDEA BITE PRESS.