Conectar la IA al contexto de producto (sin filtrar nada)
El contexto de producto vive en tres lugares distintos, el backlog, el analytics y la investigación, y cada uno pide un camino técnico distinto. Conectar mal mezcla los tres; conectar sin revisión de seguridad filtra datos de usuarios reales.
Le preguntas a la IA por qué la activación de tu feature nueva está baja, esperando que cruce el tablero de bugs reportados con el embudo de analytics y con lo que los usuarios dijeron en la última investigación. Devuelve una respuesta segura, pero mezcló todo: trató el tablero como si fuera texto para buscar por significado, el embudo como si necesitara búsqueda semántica, y la transcripción de la investigación como planilla. El motivo real de la baja activación estaba en una frase específica de una entrevista, que nunca leyó como texto de verdad.
Le preguntas a la IA cuál fue tu margen de contribución en el último trimestre. Responde con un análisis impecable, lleno de término bonito de finanzas. E inventado. La IA nunca abrió tu ERP ni tu cierre, así que adivina un número plausible.
Le pides a la IA que revise la cláusula de multa de un contrato de prestación de servicios. Devuelve "la multa del dos por ciento está dentro del límite legal", segura, redonda, lista para el cliente. El límite de tu caso era otro, la IA adivinó el número y nadie lo confirmó en la fuente.
Le pides a la IA que diga qué campaña tuvo el mejor ROI, cruzando el panel de medios pagos, que es estructurado, con las respuestas de la investigación de marca, que es texto corrido. Devuelve un número lindo, pero trató el panel como texto para buscar por significado y la investigación como planilla, perdiendo el patrón real que solo aparecía en las respuestas abiertas.
Le pides a la IA que cruce el índice de rotación, que vive estructurado en el sistema de nómina, con la política de desvinculación, que es texto corrido en PDF. Devuelve una respuesta con jerga de gestión de personas, pero trató la política como si fuera planilla y la nómina como si necesitara búsqueda por significado.
Quieres entender por qué la activación de la feature nueva está por debajo de lo esperado, y le pides a la IA que cruce tres fuentes en una sola pasada: el tablero de tickets en Linear, el embudo de activación en Amplitude y las transcripciones de la última ronda de entrevistas en Dovetail. Devuelve una respuesta segura y bien escrita, pero mezcló las tres: trató el embudo estructurado como si necesitara búsqueda semántica, trató el tablero de tickets como texto suelto perdiendo el status y el label de cada uno, y trató la transcripción de la entrevista, texto corrido lleno de matices, como si fuera una planilla de números. El motivo real de la baja activación estaba en una frase específica que una usuaria dijo en la entrevista, "no sabía que existía ese botón", y la IA nunca llegó cerca de leer eso como texto de verdad. Formato equivocado, causa raíz equivocada: el embudo pide razonamiento sobre schema, el backlog pide lectura estructurada de ticket, la entrevista pide búsqueda por significado.
Le pides a la IA que explique dónde se traba más el pipeline, cruzando el export del CRM, que es fila y columna, con el informe de win-loss en PDF que el equipo de ventas arma cada trimestre. Devuelve una respuesta de consultor, pero trató el CRM como texto para buscar por significado y el PDF como planilla simple, perdiendo la tabla de conversión por etapa.
Le pides a la IA que encuentre dónde se rompe más el SLA, cruzando el sistema de tiempo por etapa, que es dato estructurado, con el informe de calidad en PDF lleno de gráficos. Devuelve una respuesta con jerga de eficiencia, pero trató el PDF como texto corrido, perdiendo la tabla de tiempos.
Le pides a la IA que liste qué controles internos están más expuestos, cruzando la matriz de riesgo, que es fila y columna, con la política de tratamiento de datos, que es texto corrido. Devuelve una lista genérica, pero mezcló las dos fuentes, tratando la matriz como texto y la política como planilla.
Le pides a la IA que encuentre qué servicio causa más incidentes, cruzando el log estructurado del monitoreo con el informe de postmortem en PDF lleno de gráficos de latencia. Devuelve una suposición con aire de quien entiende de infra, pero trató el log como texto para buscar por significado y el PDF como planilla, perdiendo el gráfico.
Le pides a la IA que encuentre dónde abandona más el usuario el flujo, cruzando los datos de embudo, que son estructurados, con el informe de investigación en PDF lleno de mapa de calor. Devuelve un cliché de UX, pero trató el embudo como texto corrido y el PDF como planilla, perdiendo el mapa de calor que mostraba el punto real de fricción.
Le preguntas a la IA qué competidor gana participación de mercado más rápido, juntando el informe de win-loss en PDF, lleno de gráficos, con la planilla de ventas por trimestre en una sola pasada. Devuelve una respuesta linda, pero mezcló los dos: trató el PDF con gráficos como texto corrido y perdió la tabla, y trató la planilla como si necesitara búsqueda por significado, no al revés.
Ok, fíjate en algo: el problema casi nunca es que la IA sea mala analizando. El problema es que está respondiendo de memoria, sin haber abierto nunca tu producto de verdad. Es como contratar al mejor PM del mercado, sentarlo en tu escritorio y nunca darle acceso a tu Linear, a tu Amplitude, a tu Dovetail. Va a hablar bonito y se va a equivocar feo, porque está adivinando. Conectar la IA al contexto de tu producto es exactamente lo que la saca de lo genérico. Solo que conectar mal es peor: o mezcla los formatos y falla el diagnóstico, o filtra datos de usuario que no podían salir.
La idea central de esta lección. El contexto de tu producto vive en tres naturalezas distintas, y cada una pide un camino técnico propio. El backlog (Linear, Jira) es estructurado pero lleno de texto corto y status: la IA razona sobre los campos, no necesita búsqueda vectorial pesada. El analytics (Amplitude y similares) es dato estructurado de eventos: la IA razona sobre el schema, el embudo, las estadísticas. La investigación (Dovetail y similares) es transcripción de texto corrido: pide búsqueda por significado, RAG de verdad. Mezclar los tres caminos es el error número uno. Y antes de conectar cualquiera de ellos, viene la pregunta de seguridad: ¿ese dato de usuario puede salir de la empresa, o necesita anonimización primero?
01El contexto de producto vive en tres lugares, y cada uno tiene una naturaleza
La primera cosa que cambia todo es dejar de tratar "el contexto de mi producto" como una sola cosa. Lo que existe son tres fuentes de naturaleza distinta, y la naturaleza dicta el camino.
El backlog vive en Linear o en Jira: cada ticket tiene campos estructurados (status, prioridad, label, responsable) y un cuerpo de texto corto que describe el problema. El analytics vive en Amplitude o equivalente: eventos, embudos, cohortes, todo en fila y columna, puro dato estructurado. La investigación vive en Dovetail o equivalente: transcripción de entrevista, nota de campo, texto corrido lleno de matices, el habla real de una persona real. Tres naturalezas, tres caminos.
02Analytics: la IA razona sobre el schema, casi nunca necesita vectorial
El panel de Amplitude es dato estructurado: eventos con nombre, propiedad, timestamp, usuario. Para responder "dónde abandona más el usuario el embudo de activación", la IA no necesita transformar cada evento en coordenada de significado. Necesita entender la ESTRUCTURA: cuáles son los eventos, qué significa cada uno, cómo calcular la tasa de conversión entre dos pasos, qué cohorte comparar con cuál.
En vez de buscar fragmentos parecidos, razona sobre el schema, sobre la estadística (tasa de conversión, tamaño de cohorte, mediana de tiempo entre eventos) y sobre una muestra representativa. Es más barato en tokens, más exacto y sin el riesgo de que la búsqueda semántica traiga el evento equivocado. Antes de armar algo más sofisticado sobre el analytics, pregunta si el dato ya no está lo bastante estructurado para que la IA simplemente calcule.
03Backlog: ticket estructurado, no texto suelto
Linear o Jira parecen, a primera vista, un montón de texto. Pero cada ticket carga estructura: status, label, prioridad, sprint, responsable, y solo después el cuerpo descriptivo. El error común es tirar todo eso a una búsqueda por significado y perder justo la estructura que responde la pregunta más útil: "¿cuántos tickets de bug están abiertos hace más de treinta días en el label de checkout?".
Esa pregunta es conteo y filtro sobre campo estructurado, no búsqueda semántica. La IA que lee el backlog directo desde la API de Linear o de Jira, respetando los campos, responde eso con exactitud. La que trata todo como texto corrido puede hasta acertar por suerte, pero pierde la precisión que el tablero de verdad tiene para ofrecer.
04Investigación: aquí sí, RAG de verdad
La transcripción de entrevista de Dovetail es el territorio natural del RAG, el mismo territorio de cualquier documento de texto corrido. La pregunta "¿los usuarios mencionan dificultad para encontrar el botón de exportar?" no se resuelve contando ningún campo: se resuelve buscando por significado dentro de lo que la gente dijo, incluso cuando el usuario dijo "no pude sacar el informe" en vez de la palabra "exportar".
Aquí es donde vive la trampa más cara de producto: tratar la transcripción como si fuera dato estructurado, resumiendo demasiado rápido y perdiendo la frase específica que cargaba el insight. La investigación existe justamente para capturar la divergencia y el matiz que ningún promedio resume bien. Si dejas que la IA resuma la entrevista entera en un párrafo genérico sin dejarte volver al testimonio original, perdiste el motivo de haber hecho la investigación.
05Seguridad: el dato de usuario real pide revisión antes de salir
Todo hasta aquí fue sobre acertar. Ahora el punto que, en producto, te puede derribar: lo que sale de la empresa. La transcripción de entrevista carga habla de gente real, a veces con nombre, correo, detalle de cuenta que identifica a la persona. Enviar eso sin pensar a un modelo en la nube no es optimización, es filtración.
La capa de protección que aplicas antes de conectar cualquier cosa es simple: anonimizar lo que identifica (cambiar nombre por código, quitar correo y dato de cuenta), decidir dónde corre el análisis (modelo en ambiente de la empresa versus nube pública, según la sensibilidad), y mantener el registro de qué fuente entró en qué análisis. No es burocracia. Es la diferencia entre "conecté la IA a mi investigación" y "filtré el habla de un usuario real a un tercero sin darme cuenta".
Sabe más: por qué resumir demasiado pronto mata el insight
Un error sutil y común: pedirle a la IA que resuma la transcripción entera antes incluso de que formules la pregunta. Eso parece eficiente y es lo opuesto. El resumen ya decidió, por ti, qué era importante, y frecuentemente descarta la frase rara que no encajaba en el patrón, que es justo donde vive el insight raro. El camino más seguro es mantener la transcripción como fuente viva de búsqueda (RAG) y solo resumir DESPUÉS de que ya hayas hecho la pregunta correcta y visto las declaraciones originales que la sostienen. Resume al final de la investigación, nunca al principio.
Hazlo ahora
Toma un caso real de tu producto donde necesitaste una respuesta que dependía de más de una fuente, tu tarea real u otro (por qué una feature no prendió, dónde se traba el usuario, qué priorizar).
- Lista las fuentes que tendrían la respuesta: el tablero de tickets, el panel de analytics, la transcripción de investigación.
- Para cada fuente, clasifica la naturaleza: estructurado (backlog, analytics) o texto corrido (investigación).
- Marca el camino de cada una: backlog y analytics llevan a razonamiento sobre campo y schema; investigación lleva a búsqueda por significado.
- Haz la revisión de seguridad: ¿esa fuente tiene dato que identifica a un usuario real? ¿Necesita anonimizarse antes de que cualquier análisis salga de la empresa?
Acabas de diseñar la conexión de tu contexto de producto con la IA por el camino correcto, y con el cuidado de seguridad en su lugar.
Practica
1. Quieres saber 'dónde abandona más el usuario el embudo de activación' a partir del panel de Amplitude. ¿Cuál es el camino más indicado?
2. ¿Por qué tratar la transcripción de una entrevista de investigación como si fuera dato estructurado suele hacer perder el insight más valioso?
Para la pizarra
Sobre los tres lugaresanalytics, backlog e investigación tienen naturalezas distintas. Tratar a los tres igual es el error común.
Sobre analyticsel embudo ya es estructurado. La IA razona sobre los eventos, no necesita búsqueda vectorial.
Sobre la investigaciónla entrevista existe para capturar la excepción que el promedio no resume. Resumir demasiado pronto tira a la basura el motivo de haberla hecho.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.