Presentar a no-técnicos sin traicionar los datos

Tienes el análisis terminado. Cuatro días de trabajo, tres hipótesis descartadas, una conclusión sólida con los datos que la respaldan. Incluso has escrito un one-pager impecable: pregunta, respuesta, dato, contexto, recomendación. Lo mandas por correo el domingo por la noche. El lunes a las nueve te llega un mensaje de la directora de operaciones: "Oye, ¿puedes venir un momento a la reunión de las 9:30? Quiero que nos cuentes lo que encontraste, cinco minutitos". Y de repente todo cambia. Ya no es un documento que alguien lee a su ritmo. Es una sala con seis personas mirándote, un proyector que no funciona, y una directora que quiere la respuesta antes de que termines la primera frase.

Este es el momento en el que muchos analistas buenos se convierten en analistas invisibles. Saben encontrar la respuesta pero no saben DECIRLA en voz alta, delante de personas que no hablan su idioma técnico, en un contexto donde la paciencia se mide en segundos y no en páginas. Y como no la saben decir, su trabajo no genera acción. El análisis se queda en un fichero (archivo) que nadie vuelve a abrir, la decisión se toma "por intuición" o "por lo que dijo Finanzas", y el analista sale de la reunión pensando "no me han escuchado" — cuando la realidad es que no le han entendido, que es distinto.

Esta lección cierra un círculo. Has aprendido a reformular la pregunta, a elegir el formato, a curar los datos que entregas, y a escribir un one-pager que cualquiera puede leer en noventa segundos. Todo eso es necesario. Pero comunicar de forma escrita y comunicar de forma oral son dos habilidades distintas, y la segunda tiene reglas propias que nadie te enseña en un curso de SQL. Aquí las vas a aprender.

### Por qué comunicar es parte del trabajo, no un extra

Hay una escena que se repite en todas las empresas de datos del mundo. Un analista pasa una semana entera investigando por qué ha caído la retención (la proporción de usuarios que siguen usando el producto mes a mes). Encuentra la causa. Escribe un informe brillante. Lo manda. Nadie lo lee. En la siguiente reunión de dirección, el CEO dice "creo que la retención ha bajado por el cambio de precios" — una hipótesis incorrecta — y todo el equipo asiente. El analista está sentado en la sala, sabe que los datos dicen otra cosa, pero no dice nada. O dice algo tan técnico que nadie lo entiende. O empieza por "bueno, es que depende de cómo definas retención…" y pierde la sala en la segunda frase.

Este no es un problema de timidez ni de falta de confianza. Es un problema de habilidad. Comunicar un resultado técnico a una audiencia no técnica es una habilidad que se aprende, se practica y se mejora — exactamente igual que escribir SQL o limpiar datos. La diferencia es que nadie la enseña explícitamente. Se asume que "si sabes el dato, sabrás explicarlo". Y esa suposición es falsa. McKinsey factura millones al año no solo por la calidad de sus análisis, sino porque saben PRESENTARLOS de una forma que genera acción. Lo que venden no es el dato: es la capacidad de que alguien haga algo con él. La presentación no es la guinda del pastel: es la mitad del pastel.

### BLUF: Bottom Line Up Front — la conclusión primero

En el ejército estadounidense hay un formato de comunicación que se llama BLUF: Bottom Line Up Front, es decir, la conclusión al principio. Cuando un oficial escribe un informe a su superior, la primera frase es la conclusión o la petición. No el contexto, no los antecedentes, no la metodología: la respuesta. "Recomiendo cancelar la operación porque el clima no lo permite". Después viene todo lo demás — el análisis meteorológico, las alternativas evaluadas, los riesgos — pero la primera frase ya contiene lo que el superior necesita saber para decidir.

Este patrón militar se ha convertido en la norma de todas las consultoras estratégicas — McKinsey, BCG, Bain — y de todas las empresas de datos que funcionan bien. La razón es simple: los directivos viven en un estado permanente de sobrecarga informativa. Reciben cientos de mensajes al día, entran y salen de reuniones cada media hora, y su cerebro está entrenado para buscar la conclusión lo antes posible. Si empiezas tu presentación por la metodología ("primero segmenté a los usuarios por cohortes de antigüedad, luego calculé la tasa de abandono por segmento, después crucé con…"), el directivo deja de escucharte en la segunda frase. No porque sea maleducado: porque su cerebro está gritando "¿Y EL RESULTADO? ¿CUÁL ES EL RESULTADO?".

La analogía es una película de suspense frente a un telediario. En una película de suspense, el director te mantiene sin saber quién es el asesino durante dos horas: el suspense es el producto. En un telediario, el presentador te dice en la primera frase "se ha producido un terremoto en Turquía de magnitud 7.1" y después te cuenta los detalles. El directivo no quiere ver una película de suspense: quiere el telediario. Quiere saber qué ha pasado, y solo después, si le interesa, quiere saber cómo lo has averiguado.

El BLUF en la práctica funciona así: entras en la sala, te dan la palabra, y tu primera frase es la conclusión. "El churn ha subido porque los usuarios del plan básico no están adoptando la funcionalidad clave del producto". Ya está. En una frase, el directivo sabe de qué va la reunión, cuál es la respuesta, y puede decidir cuánto detalle quiere. Si quiere más, te pregunta. Si no quiere más, ya tiene lo que necesita. En ambos casos, tu análisis ha llegado.

Lo que le pasa a la mayoría de los analistas es que sienten que están "haciendo trampa" si empiezan por la conclusión. Sienten que necesitan JUSTIFICAR la respuesta antes de darla, porque si no, "¿cómo van a confiar en mí?". Pero la confianza no se gana explicando la metodología: se gana dando respuestas correctas una y otra vez. Un médico no te explica la bioquímica de un antibiótico antes de recetártelo. Te dice "tienes una infección, toma esto". Si le preguntas "¿por qué?", te lo explica. Pero no empieza por ahí. Tú tampoco deberías.

### Adaptar el mensaje a la audiencia: tres versiones del mismo hallazgo

Un hallazgo no tiene una sola forma de expresarse. Tiene tantas formas como audiencias. El mismo dato — "los usuarios del plan básico con 3-6 meses de antigüedad abandonan a un ritmo tres veces mayor porque no adoptan la funcionalidad de automatizaciones" — se dice de tres formas distintas según quién esté escuchando. No cambias el contenido: cambias las palabras, el nivel de detalle y el encuadre (frame), es decir, desde qué ángulo presentas la información para que conecte con lo que esa persona necesita decidir.

• ▹Para un director o CEO (le importa "¿qué hago?"): "Estamos perdiendo el 11% de los usuarios básicos en su primer semestre porque no descubren la funcionalidad que nos diferencia. Propongo un programa de onboarding guiado que puede bajar ese 11% al 4% —la media del resto de usuarios— y ahorrarnos 180.000 euros anuales en usuarios perdidos."
• ▹Para un product manager (le importa "¿cómo afecta al producto?"): "Los usuarios que no activan automatizaciones en sus primeras 4 semanas tienen un churn del 11% frente al 2% de los que sí lo hacen. Necesitamos un flujo de activación más agresivo en la semana 3-4 del onboarding del plan básico. Te paso los datos del segmento para que lo priorices."
• ▹Para un ingeniero (le importa "¿qué tengo que construir?"): "Necesitamos un trigger que detecte usuarios del plan básico que llevan 21 días sin crear una automatización y les envíe una secuencia de 3 correos con plantillas prediseñadas. Te paso el segmento SQL y la lógica de exclusión. ¿Cuánto tardarías en montarlo?"

Fíjate en lo que cambia y lo que no. El dato subyacente es el mismo en los tres casos: segmento concreto, métrica concreta, causa identificada. Lo que cambia es el encuadre: al director le hablas en euros y en acción estratégica; al product manager le hablas en flujos y priorización; al ingeniero le hablas en triggers y tablas. Ninguno de los tres necesita saber cómo hiciste el análisis. Los tres necesitan saber qué implica para SU trabajo.

Esto no es manipulación ni es "simplificar para tontos". Es traducción. Cuando un intérprete traduce del español al inglés, no está simplificando ni engañando: está diciendo lo mismo en un idioma que el receptor entiende. Tú haces lo mismo: traduces del idioma de los datos al idioma de quien decide. Y cada persona decide en un idioma distinto: euros, usuarios, sprints, plazos, riesgo.

### El storytelling con datos: un arco narrativo, no decoración

La palabra storytelling (contar historias con datos) se ha puesto de moda y se ha vaciado de significado. En muchos sitios se usa para decir "pon un título bonito al gráfico" o "empieza con una anécdota". No es eso. El storytelling con datos es la habilidad de construir un hilo lógico que lleve al oyente desde la pregunta hasta la acción sin perderle por el camino. Es un arco narrativo con tres actos, exactamente igual que una película: tensión, investigación y resolución.

Acto 1: la tensión. Presentas el problema de forma que el oyente sienta que le importa. No "el churn ha subido un 1.6 puntos porcentuales": eso es un dato frío. Sino "estamos perdiendo 1.200 usuarios más al trimestre que el anterior, y si sigue así, en seis meses habremos perdido suficientes para que los ingresos recurrentes caigan por debajo del umbral de rentabilidad". Ahora sí importa. Ahora el directivo está escuchando, porque has conectado el dato con una consecuencia que le afecta.

Acto 2: la investigación. Cuentas qué encontraste, pero como un detective que resuelve un caso, no como un científico que presenta un paper. "Lo primero que hice fue mirar si el problema es general o está concentrado. No es general: el 80% del churn extra viene de un solo segmento. Usuarios del plan básico, entre 3 y 6 meses. ¿Por qué ellos? Porque nunca descubrieron la funcionalidad que hace que quedarse merezca la pena." Cada frase avanza la historia. No hay rodeos, no hay callejones sin salida, no hay "también miré esto otro pero no salió nada".

Acto 3: la resolución. Propones una acción concreta y cuantificas su impacto esperado. "Si conseguimos que ese segmento active automatizaciones en su primer mes — y sabemos que solo el 8% lo hace hoy — podemos reducir su abandono del 11% al 4%, que es la media del resto. Eso son 900 usuarios recuperados al trimestre, unos 180.000 euros anuales. Propongo un programa de onboarding guiado que podemos probar en cuatro semanas." El oyente termina con una decisión clara en la cabeza: sí o no, ahora o después, con este presupuesto o sin él.

### La pregunta incómoda: cómo gestionar el desafío sin perder el suelo

Has terminado tu presentación BLUF perfecta, con tu arco narrativo de tres actos. Y entonces el director financiero levanta la mano y dice: "Eso no cuadra con lo que me dijo Finanzas la semana pasada". O la directora de marketing dice: "¿Estás seguro de ese número? Porque yo tengo otro". O el peor de todos: "Sí, pero el año pasado pasó lo mismo y no hicimos nada y se arregló solo". Bienvenido a la pregunta incómoda. Es el momento más importante de toda la presentación, porque es donde se decide si tu análisis genera acción o se archiva.

La reacción natural del analista ante la pregunta incómoda es una de dos: o se pone a la defensiva ("no, mis datos están bien, mira, aquí está la query…") o cede el terreno ("bueno, puede ser, déjame revisarlo…"). Las dos reacciones son fatales. La primera te convierte en alguien con quien es desagradable discutir — y la próxima vez no te invitarán a la reunión. La segunda te convierte en alguien en quien no se puede confiar — porque si cedes a la primera objeción, ¿cómo de seguro estabas realmente?

La respuesta correcta tiene tres pasos, siempre en este orden: validar, anclar, ofrecer.

1. 01.Validar. Reconoce que la pregunta es legítima. "Es una buena pregunta" o "Entiendo la discrepancia". No estás diciendo que el otro tiene razón: estás diciendo que su preocupación merece atención. Esto desarma la tensión y evita que la conversación se convierta en un debate de egos.
2. 02.Anclar. Vuelve a tu dato concreto. "Lo que yo he medido es X, en el período Y, con la fuente Z". No discutas sobre percepciones ni sobre lo que "parece". Discute sobre números concretos con definiciones claras. Si el otro tiene un número distinto, la conversación productiva es "¿estamos midiendo lo mismo?" — no "¿quién tiene razón?".
3. 03.Ofrecer. Propón un paso siguiente que resuelva la discrepancia. "Puedo cruzar mi dato con el de Finanzas esta tarde y te mando la reconciliación mañana a primera hora". Esto hace dos cosas: demuestra que no tienes miedo de que te comprueben, y da al directivo una salida que no es "creerme o no creerme" sino "esperemos al dato".

Hay una técnica específica para la objeción más difícil: "Sí, pero no hicimos nada y se arregló solo". La respuesta no es discutir si se arregló solo o no. La respuesta es cuantificar el coste de esperar. "Puede ser. Pero mientras esperamos, estamos perdiendo 400 usuarios al mes. Si tarda tres meses en arreglarse solo como la última vez, habremos perdido 1.200 usuarios que costará 240.000 euros recuperar. ¿Es un riesgo que queremos asumir?". El directivo ya no está decidiendo entre "hacer algo" y "no hacer nada": está decidiendo entre "hacer algo que cuesta X" y "esperar y asumir un coste de Y". Esa es una decisión de negocio, no una discusión sobre datos.

### Los tres errores fatales del analista que presenta

Después de asistir a cientos de presentaciones de analistas — las mías propias y las de equipos que he dirigido — hay tres errores que aparecen una y otra vez. No son errores de contenido: son errores de ACTITUD que convierten una presentación buena en una presentación que no genera nada. Los tres son fáciles de reconocer y, una vez que los ves, fáciles de evitar.

1. 01.Leer el gráfico en voz alta. "Como podéis ver, en el eje X tenemos los meses y en el eje Y la tasa de churn, y la línea azul muestra que en julio subió del 4.2% al 5.8%…". El directivo sabe leer un gráfico. Lo que no sabe — y lo que tú deberías estar diciendo — es QUÉ SIGNIFICA ese gráfico para el negocio. No describas lo que se ve: interpreta lo que implica. "Este gráfico muestra que estamos perdiendo dinero desde julio y la tendencia no se revierte sola."
2. 02.Pedir perdón por el dato. "Bueno, esto es un análisis preliminar, no sé si los datos son del todo fiables, habría que verificar con Finanzas…". Si no confías en tu propio dato, ¿por qué debería confiar el directivo? Si el dato no está listo, no lo presentes. Si está listo, preséntalo con convicción. La duda legítima se expresa como nivel de confianza ("esto explica el 70% de la caída; el otro 30% requiere más investigación"), no como disculpa.
3. 03.No tener preparada la respuesta a "¿Y qué hacemos?". Has presentado el problema de forma brillante. El directivo está convencido. Y dice: "Vale, ¿qué propones?". Y tú dices: "Bueno, eso ya es más de producto, yo solo hago el análisis…". Acabas de tirar a la basura todo tu trabajo. El análisis sin recomendación es un diagnóstico sin tratamiento. El directivo necesita la siguiente frase, y esa frase es tu responsabilidad, no la de otro.

### La técnica del "titular de periódico"

Un ejercicio que hago con todos los analistas de mis equipos: antes de presentar cualquier cosa, escribe un titular de periódico. No un título de informe ("Análisis de retención Q3 2024"). Un titular de periódico: una frase que, si la leyeras en la portada del periódico económico, entenderías de qué va sin abrir el artículo. "TaskFlow pierde 1.200 usuarios al trimestre por un fallo en su onboarding". Eso es un titular. Tiene un sujeto (quién), un verbo (qué pasa), y un porqué. Si no puedes escribir ese titular, tu análisis no está listo para presentarse.

El titular de periódico es la prueba ácida de que has destilado tu hallazgo hasta su esencia. Si necesitas dos frases, probablemente estás mezclando dos hallazgos distintos. Si necesitas un adverbio ("posiblemente", "parcialmente", "en ciertos casos"), probablemente no tienes la conclusión clara. Y si no puedes escribirlo sin jerga técnica ("El LEFT JOIN entre fact_subscriptions y dim_users muestra un decay rate…"), probablemente todavía estás pensando como analista en vez de como comunicador.

1# La técnica del titular: ejemplos buenos y malos
2
3titulares_malos = [
4    "Análisis de retención Q3 2024",                    # <- es un título, no un titular
5    "Hemos encontrado insights interesantes en churn",  # <- no dice cuáles
6    "Posible correlación entre onboarding y retención", # <- "posible" mata la fuerza
7    "Hay que investigar más el segmento básico",        # <- no es un hallazgo, es una tarea
8]
9
10titulares_buenos = [
11    "El 80% del churn extra viene de usuarios que nunca activaron automatizaciones",
12    "Perder 4 semanas de onboarding nos cuesta 180k euros al año",
13    "Los usuarios que completan el tutorial retienen 3x mejor que los que no",
14    "El plan básico pierde un 11% de usuarios entre el mes 3 y el 6",
15]
16
17# La estructura: QUIÉN + QUÉ PASA + POR QUÉ/CUÁNTO
18# Si falta alguno de los tres, el titular no está listo.
19for i, t in enumerate(titulares_buenos):
20    print(f"Titular {i+1}: {t}")

### El ensayo general: preparar las tres preguntas que te van a hacer

Ningún analista senior se presenta a una reunión sin haber preparado las objeciones. Antes de entrar en la sala, te haces tres preguntas: "¿Cuál es la primera pregunta que me van a hacer?", "¿Cuál es la objeción más dura que pueden ponerme?", y "¿Cuál es el dato que no tengo y que podrían pedirme?". Si tienes respuesta preparada para las tres, entras seguro. Si no la tienes para alguna, al menos sabes dónde está tu punto débil y puedes adelantarte: "Sé que vais a preguntar por X; no tengo ese dato todavía, pero puedo tenerlo el jueves".

En la práctica, las preguntas incómodas se agrupan en cinco tipos, y una vez que los conoces, puedes prepararlas todas:

1. 01.La duda sobre el dato. "¿De dónde sale ese número?" / "¿Estás seguro?". Respuesta preparada: la fuente, el período, la definición exacta de la métrica. Tenla escrita en una nota por si la necesitas.
2. 02.La contradicción con otro dato. "Finanzas me dijo otra cosa". Respuesta preparada: las posibles diferencias de definición (período distinto, segmento distinto, fuente distinta). Ofrece reconciliar.
3. 03.La minimización. "Eso siempre ha pasado" / "No es para tanto". Respuesta preparada: la tendencia (antes era X, ahora es Y) o el coste de no hacer nada (si seguimos así, en 6 meses pasa Z).
4. 04.La pregunta de implementación. "¿Y eso cuánto cuesta?" / "¿Cuánto se tarda?". Respuesta preparada: una estimación de orden de magnitud, no un presupuesto exacto. "Estamos hablando de semanas, no de meses" o "Entre 5.000 y 15.000 euros, depende del alcance".
5. 05.La derivación. "Interesante, pero yo necesito saber otra cosa…". Respuesta preparada: anota la nueva pregunta, confirma que la investigarás, y redirige al tema original. "Perfecto, lo miro. Para la decisión de hoy, lo que importa es X".

### La regla de los 30 segundos: si no engancha al principio, no engancha

Hay una verdad incómoda sobre las presentaciones a directivos: los primeros treinta segundos determinan si te van a escuchar o no. No es justo, no es ideal, pero es real. Un directivo que lleva ocho reuniones seguidas está evaluando inconscientemente en los primeros segundos: "¿Esto me afecta? ¿Esto es urgente? ¿Esta persona sabe de qué habla?". Si tus primeras dos frases no pasan ese filtro, el directivo entra en modo piloto automático — asiente, mira la pantalla, pero está pensando en la reunión siguiente.

Por eso la primera frase de tu presentación es la más importante. Y esa primera frase NUNCA debería ser: "Buenos días, voy a presentaros un análisis que hice sobre…" (aburrido), ni "Antes de empezar, dejadme dar un poco de contexto…" (el contexto puede esperar), ni "Esto es un análisis preliminar, así que…" (acabas de pedir perdón antes de empezar). La primera frase debería ser tu titular de periódico: "Estamos perdiendo 180.000 euros al año por un problema de onboarding que podemos resolver en cuatro semanas". Ahora todos están escuchando.

### Resumen: el checklist antes de presentar

1. 01.Escribe tu titular de periódico. Si no puedes, no estás listo.
2. 02.Prepara tu BLUF: la primera frase que dirás es la conclusión, no el contexto.
3. 03.Adapta el lenguaje a tu audiencia: ¿le hablas en euros, en usuarios, o en sprints?
4. 04.Construye tu arco en tres actos: tensión → investigación → resolución. Máximo 5 minutos.
5. 05.Prepara las tres preguntas que te van a hacer y ten la respuesta lista.
6. 06.Ensaya en voz alta al menos una vez. Lo que suena bien en tu cabeza no siempre suena bien en la sala.
7. 07.Ten preparada la respuesta a "¿y qué hacemos?". Siempre. Sin excepción.