17 de octubre de 2026 · Martina Pérez
¿Y si el conocimiento de tu producto se actualizara solo?
Estás en una llamada con product managers presentando un diseño y empiezan a cuestionar cada parte. Estás en una llamada con ingeniería y no entienden por qué estás trabajando en eso. Trabajas con otra persona de diseño y no deja de cuestionar el razonamiento detrás de tus diseños.
Supongamos que estás siguiendo bien el proceso. El problema está claro. Has hecho el trabajo de discovery. Has explorado distintas soluciones. El diseño es sólido.
¿Entonces qué está pasando?
Creo que a veces el problema no es el diseño. Es que cada persona mira el problema desde un sitio distinto.
La investigación está en un sitio. Las métricas de producto, en otro. El feedback de clientes, en otro. Las decisiones anteriores están enterradas en documentos o en Slack. Y cada persona llega a la conversación con una versión ligeramente distinta de lo que cree que es verdad.
Tienes el problema claro y de repente recibes diez opiniones distintas sobre él. ¿Afecta de verdad al journey? ¿Cuánto? ¿Le pasa a muchos usuarios o solo a unos pocos? ¿Está empeorando? ¿Hay evidencias en otro sitio? ¿Lo resuelve otro producto de otra manera? Cada persona tiene una hipótesis distinta, y no hay un terreno común.
Muchos desacuerdos de producto no son desacuerdos sobre la solución. Son desacuerdos sobre el problema, la evidencia y el contexto que hay detrás.
El problema no es que los equipos de producto no tengan suficiente información.
Nuestra comprensión de un producto cambia cada semana. Nuestros artefactos de producto, normalmente no.
Una nueva sesión de investigación revela una fricción. La analítica muestra una caída en un embudo. Alguien del equipo ve que un competidor hace algo diferente. Aparece un patrón nuevo en otro sitio.
Pero el journey map se actualiza cada pocos meses, y poco a poco se va separando de todo lo demás.
Eso es lo que me hizo empezar a usar la IA de otra manera: no para generar más investigación, sino para mantener conectado lo que ya hemos aprendido.
Así que empecé a preguntarme: ¿y si el journey del usuario pudiera convertirse en un artefacto vivo?
¿Y si cada semana pudiéramos revisar la información que ya tenemos y mapearla sobre nuestro journey actual? Hallazgos de investigación. Datos del embudo. Feedback de clientes. Observaciones internas. Patrones de la competencia.
La idea no es del todo nueva. Herramientas como TheyDo, Smaply, UXPressia y Dovetail ya ayudan a los equipos a conectar partes de esta imagen. Pero la mayoría de los equipos que conozco siguen teniendo las piezas repartidas entre un repositorio de investigación, una herramienta de analítica, una bandeja de feedback y documentos internos.
Así que quise ver hasta dónde se puede llegar conectando lo que ya existe, sin añadir otro producto.
Ya he creado algunas automatizaciones en n8n para explorarlo. Trabajo en n8n, así que es la herramienta que tengo más a mano, pero la idea no depende de ella. Serviría cualquier herramienta capaz de conectar tu repositorio de investigación, tu analítica y tu bandeja de feedback.
Una sesión de investigación menciona que alguien nunca recibió el email de verificación. Se etiqueta en el paso de Registro y aparece junto a tres sesiones anteriores que describen el mismo momento. Una queja es una anécdota. Cuatro son un patrón.
El embudo muestra que casi la mitad de las personas que descubren el producto nunca llegan a registrarse. Esa caída está ahora en la misma columna que esas cuatro sesiones, así que el número y las citas describen el mismo momento.
Un producto similar empieza a dejar probar una plantilla antes de crear una cuenta. Ese patrón se asigna a Registro como posible oportunidad. La nueva página de precios de otro producto no, porque no toca este journey.
Y hay otra en la que estoy trabajando: investigar las hipótesis que hay detrás de los problemas que vemos.
Juntas, no crean otro dashboard. Crean algo más parecido a un mapa de producto vivo.
Pero hay una distinción importante.
Ese journey no representa tu opinión. Representa lo que muestran los distintos datos cualitativos y cuantitativos. Las opiniones del equipo también están ahí, como una fuente más entre las demás, no como el marco.
Con esto, puedes empezar a formar opiniones firmes sobre la mejor solución. Pero ahora tenéis una comprensión compartida. Podéis comunicaros de verdad y hablar el mismo idioma.
Y tienes opiniones informadas, en lugar de opiniones sin fundamento.
Para mí, eso es lo interesante.
La IA no debería sustituir el pensamiento de producto. Debería reducir el coste de mantener vivo el conocimiento del producto.
Este enfoque tiene un riesgo evidente: puede parecer objetivo cuando está lleno de decisiones.
¿Cómo se resumen las sesiones de investigación, y con qué modelo? ¿Qué entra en un resumen y qué se queda fuera? ¿Quién decidió que este embudo importa más que otro? ¿Qué alimenta una oportunidad, y quién decide cuánto pesa?
Cada una de esas preguntas necesita una persona detrás. Según la empresa, puede ser alguien de producto, de diseño, de datos o de investigación, o varias personas para distintas partes del journey.
Importa menos quién hace qué que el hecho de que alguien lo haga. Cada parte del journey necesita una persona responsable con nombre propio, que compruebe que la automatización funciona y que lo que trae es fiable. Eso no es opcional. Cada actualización enlaza además a su fuente, para que cualquiera pueda comprobar de dónde sale una afirmación y cuestionarla.
La IA recopila, no edita. Reúne lo que el equipo ya sabe. Las personas que conocen cada área deciden qué significa.
En lugar de preguntar «¿Qué sabemos de esta parte del journey?», el equipo puede empezar con una imagen siempre actualizada.
Y una regla sencilla:
Si llevas más de tres minutos debatiendo cuál es el problema, con qué tienen dificultades los usuarios o cómo afecta a las métricas, para y mira el journey.
Si la respuesta está ahí, la conversación pasa a qué hacer al respecto. Si no está, has encontrado un hueco en lo que sabe el equipo, y eso se convierte en lo siguiente que hay que aprender.
Los equipos dejan de dedicar su tiempo a ponerse de acuerdo sobre lo que es verdad, y empiezan a dedicarlo a decidir lo que importa.
Voy a compartir cada automatización por separado: qué funcionó, qué no y qué cambiaría.