Últimamente estoy leyendo muchos posts que celebran lo mismo. Ahora podemos validar ideas con IA más rápido.
Y cuanto más lo veo, más me preocupa.
No porque la IA no sirva. Al contrario. Creo que puede ser una oportunidad enorme para hacer mejor producto. Mi preocupación es otra. Que este mensaje refuerce un problema que ya existe en la mayoría de equipos. Confundir validación con discovery. Tratar el prototipo y el test como sustituto de entender al usuario.
Mi preocupación no es la velocidad. Es el significado que le estamos dando. Si empezamos a tratar “validar” como si fuera “entender”, vamos a reforzar la confusión más peligrosa en producto. Y eso, con IA, se vuelve mucho más fácil de hacer sin darnos cuenta.
La escena que veo una y otra vez
En muchos equipos que “se supone que trabajan bien” hay un ritual que se repite al inicio del trimestre. Se asignan objetivos. Activación, retención, conversión. Se define el resultado que el equipo tiene que conseguir.
Hasta aquí, bien.
El problema aparece justo después. Casi como un acto reflejo, la conversación salta a iniciativas.
Y aquí es donde la IA vuelve el salto todavía más seductor.
La conversación suena moderna. Productiva. Rápida. Da la sensación de que el equipo está haciendo lo correcto porque está “validando”.
Pero muchas veces se está saltando lo esencial, que no es construir una versión para probarla, sino entender qué está ocurriendo realmente. Qué está viviendo el usuario. En qué contexto. Qué intenta conseguir. Qué le frena. Qué alternativas usa. Qué tensión hay entre lo que el negocio quiere y lo que el usuario necesita en ese momento.
Si no pasas por ahí, lo que estás probando no es si has entendido el problema. Estás probando si tu idea gusta, si convence, si parece funcionar.
Y ahí es donde el testeo se convierte en confirmación. No aprendes del usuario. Le pides que reaccione a tu marco, a tu solución, a tu manera de mirar el problema.
En el fondo es una creencia muy extendida. Se cree que hacer producto es tener ideas y ejecutarlas bien. La IA no crea esa creencia, pero la vuelve más cómoda, porque ahora puedes ejecutar y testear a una velocidad que hace todavía más difícil parar y preguntarte si estás entendiendo bien.
La distinción que ordena todo esto
Para mí la clave está en separar dos espacios.
Las oportunidades viven en el espacio del problema. Y se descubren haciendo discovery, no en una sesión de ideación. Nacen del entendimiento del usuario y su contexto. Fricciones, necesidades, deseos. Lo que intentan resolver hoy y cómo lo hacen. Y, por supuesto, conectadas con negocio, porque no hablamos de “hacer cosas que gusten”, hablamos de impacto.
Las iniciativas viven en el espacio de la solución. Son las ideas que propones para responder a esas oportunidades.
Esto parece semántico hasta que miras dónde nace tu roadmap.
Si partes de iniciativas sin discovery, partes de opiniones. Imaginas qué debería hacer el producto para cumplir un objetivo sin haber entendido bien qué está ocurriendo en la vida del usuario.
Si partes de oportunidades, cambias el juego. Porque entender el problema abre muchas soluciones posibles, y te da criterio para decidir qué merece la pena probar.
Y aquí está el punto incómodo.
La IA puede ayudarte a probar más rápido. Pero no puede darte criterio si no tienes comprensión.
La IA no debería empujarnos a saltarnos discovery. Debería ayudarnos a hacerlo mejor
Para mí, la IA es una oportunidad enorme para implementar producto mejor. Precisamente porque durante años una de las tensiones ha sido el coste de hacerlo bien.
Discovery no falla por falta de intención. Falla porque es exigente en dos frentes a la vez. Por un lado, genera una cantidad de información que hay que procesar. Notas, transcripciones, señales dispersas, documentación, síntesis. Eso ya exige tiempo y foco.
Pero la dificultad real empieza incluso antes. Discovery no es solo analizar. Es conseguir acceso a la realidad. Reclutar usuarios, agendar conversaciones, mantener una cadencia. Hablar con soporte, revisar tickets, escuchar a ventas, cruzar señales que están repartidas por herramientas y personas. Es un trabajo de coordinación y disciplina que no aparece en un sprint plan, pero que decide la calidad de todo lo que viene después.
Por eso muchos equipos no lo sostienen. No porque no crean en ello, sino porque es costoso en recursos y porque el sistema suele empujar en otra dirección. Si el equipo está gobernado por entregas, el discovery se vive como algo que “retrasa”, como una pausa que compite con cerrar tareas.
Y aquí es donde la IA puede ayudar de verdad, si la usamos bien. No sustituyendo el discovery, sino reduciendo fricción alrededor del discovery.
Puede ayudarte a procesar entrevistas, sintetizar, ordenar observaciones, documentar, preparar mejor conversaciones, e incluso idear con más amplitud cuando ya tienes comprensión. Y sí, también ayuda a validar asunciones sobre una solución, acelerando la experimentación cuando llega el momento.
Pero el orden importa. La IA no sustituye el discovery. Es una oportunidad enorme para que muchos equipos por fin puedan sostenerlo, porque reduce el coste real de hacerlo bien. Y esa diferencia es enorme.
La regla que uso para evitar la trampa
En mi libro Haz Producto lo planteo de una forma muy simple, porque en producto se repite mucho lo de “hay que hacerse buenas preguntas”, pero muchas veces no se nos dan marcos claros para hacerlo o se nos pasa por alto en el día a día.
Para mí, en este contexto, las preguntas cumplen dos funciones muy concretas. Primero, te anclan en el problema, porque son preguntas sobre el problema y sobre la oportunidad, no sobre la solución. Segundo, te ayudan a descubrir qué partes de esa oportunidad todavía no entiendes bien.
Y aquí está la clave del proceso.
A través de las preguntas puedes ver qué sabes realmente, pero sobre todo aparece algo mucho más valioso. La lista de lo que no sabes. No lo que sospechas ni lo que intuyes, sino lo que de verdad te falta para comprender el problema que hay detrás de esa oportunidad.
Esa lista se convierte en una herramienta muy poderosa para el equipo, porque transforma una sensación difusa de “nos falta información” en algo accionable. De pronto es evidente qué necesitas entender, qué preguntas tienes que responder y qué huecos hay que completar antes de idear.
Como no puedes investigarlo todo a la vez, esa lista también te permite ordenar el trabajo. Decidir qué es lo más importante entender primero para no construir desde opinión y qué puede esperar.
A partir de ahí, investigar deja de ser un gesto genérico. Se convierte en tareas concretas para responder esas preguntas y completar la comprensión que falta.
Y cuando llegas a ideación, llegas de forma distinta. No estás intentando inventar una solución desde una sala. Estás diseñando desde una comprensión mucho más sólida del problema, del usuario y del contexto, para idear mejores soluciones, no solo más soluciones.
Afinar lo equivocado
La IA ha hecho más barato validar ideas.
Pero sigue habiendo algo que no se puede acelerar sin pagar un precio. Entender el problema.
Si conviertes la validación en sustituto del discovery, la IA no te ayuda a aprender más rápido. Te ayuda a confirmar más rápido tu idea.
Y el riesgo es claro. Puedes sentir que avanzas y, aun así, estar afinando una solución que no era la correcta para el usuario ni para el negocio.
