Si tu equipo hizo una ronda de entrevistas a usuarios el mes pasado, te hago una pregunta incómoda: ¿alguien volvió a abrir esas transcripciones? En la mayoría de los equipos con los que trabajo, la respuesta honesta es no. Diez conversaciones de 45 minutos, transcritas, guardadas en una carpeta de Drive que nadie vuelve a tocar después de la segunda semana. Y las decisiones del trimestre se terminan tomando sobre lo que alguien recuerda haber escuchado — no sobre lo que los usuarios realmente dijeron.
El cuello de botella nunca fue hacer las entrevistas. Hacerlas es la parte fácil y la parte que se siente productiva. El cuello de botella es la síntesis: convertir diez conversaciones dispersas en algo que un equipo pueda usar para decidir. Y como la síntesis es cara, casi nadie la hace bien.
Llevo meses iterando un pipeline con IA que comprime ese proceso a 30 minutos. No es magia, no reemplaza el criterio humano, y no produce un informe perfecto sin revisión. Pero convierte un trabajo que nadie quiere hacer en uno que el equipo puede ejecutar de forma consistente después de cada ronda de research.
Por qué la síntesis manual se rompe en la práctica
Sintetizar diez entrevistas cualitativas con rigor es un trabajo cognitivamente agotador. Hay que leer con atención, identificar patrones que cruzan varias conversaciones, separar lo anecdótico de lo recurrente, y traducir todo eso en una decisión. Un investigador experimentado tarda entre 15 y 25 horas en hacerlo bien. La mayoría de los equipos medianos no tienen ese tiempo ni ese perfil disponible.
Entonces pasa una de dos cosas, y ambas son malas. La primera: alguien hace un resumen apurado, sesgado por las dos o tres últimas entrevistas que tiene frescas en la memoria. La segunda: se pescan las citas que confirman lo que el equipo ya quería hacer, y las entrevistas se vuelven decoración para una decisión que ya estaba tomada.
En los dos casos, el research no informó nada. Costó semanas de coordinación y horas de la gente entrevistada, para terminar validando un sesgo. El problema no es la falta de datos — es que los datos nunca se procesaron de forma que pudieran contradecirnos.
El pipeline: tres fases, un insight
Lo que voy a describir no requiere infraestructura sofisticada. Necesitas un LLM con ventana de contexto grande (uso Claude, pero GPT también funciona), las transcripciones en texto plano, y media hora. Lo dividí en tres fases porque cada una tiene un objetivo distinto y un prompt distinto.
La clave está en lo que no hago: nunca le pido al modelo "resume estas diez entrevistas". Ese prompt produce papilla genérica — un promedio que aplana exactamente lo que importa. El truco es estructurar antes de sintetizar.
Antes de buscar patrones, convierto cada transcripción cruda en un documento estructurado con las mismas categorías. No un resumen — una extracción. Le paso cada entrevista por separado con un prompt fijo, y al final tengo diez documentos comparables entre sí.
Eres un investigador de UX senior analizando una entrevista con un usuario. A partir de la siguiente transcripción, extrae en formato estructurado: 1. PERFIL: rol, contexto y antigüedad usando el producto. 2. JOBS-TO-BE-DONE: ¿qué intenta lograr esta persona? (máx. 3, en sus propias palabras cuando se pueda). 3. FRUSTRACIONES: problemas concretos que menciona, cada uno con una cita textual breve de respaldo. 4. WORKAROUNDS: soluciones que se inventó por su cuenta. 5. MOMENTOS DE VALOR: qué sí le funciona bien. 6. CONTRADICCIONES: dónde dice una cosa pero describe hacer otra. 7. SEÑALES DÉBILES: comentarios al margen que podrían importar. No infieras lo que no está en la transcripción. Si una categoría no aplica, escribe "sin datos". [PEGAR TRANSCRIPCIÓN]
Ahora sí le doy al modelo los diez extractos juntos, y le pido lo único que la síntesis manual hace mal: contar. Qué frustración aparece en cuántas entrevistas, qué jobs se repiten, dónde hay contradicciones entre lo que la gente dice y lo que hace. Le exijo evidencia explícita — "aparece en 7 de 10, ver citas" — para poder distinguir lo recurrente de lo que solo dijo la persona más elocuente.
Un patrón no es un insight. "7 de 10 usuarios se quejan de X" es un hallazgo; el insight es la tensión que conecta ese hallazgo con una decisión. Para los tres patrones más fuertes, le pido al modelo que formule el insight en una frase, la evidencia que lo respalda, la implicación de producto, y qué tan sólida es la evidencia. Después yo elijo cuál mueve la aguja. Esa última decisión no se delega.
El error más común no es usar IA para esto — es pedirle "resume estas entrevistas". Un resumen promedia, y al promediar borra la diferencia entre lo que se repite y lo que dijo una sola persona. Estructura primero, cuenta después, sintetiza al final.
Dónde la IA falla (y dónde no puedes fallar tú)
Este pipeline funciona, pero tiene fallas predecibles. Conocerlas es lo que separa usarlo bien de tomar malas decisiones más rápido.
Inventa patrones cuando le pides patrones. Si la señal es débil, el modelo igual te entrega cinco "hallazgos" con tono de certeza. Por eso la Fase 2 exige conteo y citas: para que cada afirmación se pueda verificar contra la transcripción original. Si un patrón no tiene citas que lo respalden, no es un patrón.
Pierde el matiz emocional. Una transcripción tiene tono, duda, frustración real. El modelo extrae bien el qué, pero no siempre capta cuánto le importa al usuario. Ese peso lo tienes que poner tú, leyendo las citas que el modelo marcó.
No tiene contexto de negocio para priorizar. El modelo sabe que 7 de 10 mencionan un problema; no sabe que resolverlo cuesta seis meses de roadmap, ni que ese segmento es el 5% de tus ingresos. La priorización es una decisión de negocio, y sigue siendo tuya.
Trata el output como el trabajo de un analista junior brillante pero sin contexto: rápido, estructurado y exhaustivo — y que necesita que un senior valide antes de presentarlo. Nunca lleves el resultado crudo a una decisión sin leer las citas de respaldo.
Lo que cambia cuando la síntesis deja de ser el cuello de botella
Cuando sintetizar pasa de veinte horas a treinta minutos, lo importante no es que ahorras diecinueve horas y media. Es que la síntesis deja de ser un evento raro y costoso, y se vuelve algo que haces por defecto después de cada ronda de entrevistas.
Ese cambio de costo cambia el comportamiento. Entrevistas más seguido, porque ya no le temes al backlog de análisis que se acumula. Las decisiones se anclan en evidencia fresca y verificable, no en lo que alguien recuerda de una reunión de hace dos meses. El research deja de ser un proyecto especial y se vuelve una práctica continua.
Para una empresa mediana en LATAM que no tiene un equipo de research dedicado, esa es toda la diferencia. No necesitas contratar un perfil senior de investigación para empezar a tomar decisiones de producto basadas en lo que tus usuarios realmente dicen. Necesitas tus transcripciones, treinta minutos y la disciplina de no saltarte la Fase 1.
La próxima ronda de entrevistas que hagas, no la dejes morir en una carpeta. Antes de archivar las transcripciones, dedícale media hora a las tres fases. Empieza por una sola entrevista y el prompt de extracción — si el documento estructurado que sale te resulta útil, ya tienes el 80% del pipeline andando.
La pregunta no es si tienes tiempo para sintetizar tus entrevistas. Es si puedes seguir tomando decisiones de producto sobre lo que alguien cree recordar haber escuchado.
¿Quieres montar este pipeline con tu equipo?
En Saphia Labs ayudamos a equipos de producto y operaciones a integrar la IA en su trabajo diario — desde síntesis de research hasta automatizaciones. Agenda una llamada y vemos cómo aplicarlo en tu contexto.
Agendar llamada gratuita
