Comunicar resultados a partes interesadas sin experiencia en ML: cómo los Data Scientists IC dejan de enterrar el titular

La última vez que asistí a la presentación de un Data Scientist ante un CFO, la primera diapositiva era una matriz de confusión. El CFO preguntó, con amabilidad, qué estaba mirando. Doce minutos después, todavía no sabía qué hacer el lunes. El modelo era bueno. La presentación fue un pequeño desastre.

Este es el patrón del titular enterrado, y destruye más trabajo de DS que el código malo jamás lo hará. Usted pasó seis semanas en un modelo de abandono. El ejecutivo tiene ocho minutos en la agenda. Si su primera diapositiva no responde la pregunta con la que llegaron, la reunión termina con un amable "volvamos a hablar" y su modelo va al cajón con los demás.

Esta guía es el framework que uso, y el que practico con los Data Scientists IC junior de mi equipo. No se trata de simplificar. Se trata de respetar que el trabajo del ejecutivo es decidir, no aprender ML. Su diapositiva los ayuda a decidir o no los ayuda.

El titular "¿qué cambió?"

Toda presentación ejecutiva responde primero una pregunta: ¿qué es diferente ahora en comparación con el trimestre pasado?

No "así construimos el modelo". No "la curva ROC se ve genial". Qué cambió en el negocio y qué deberíamos hacer al respecto.

El titular es la primera oración que el ejecutivo escucha o lee. Si tiene que desplazarse para encontrarlo, ya lo perdió. Compare estas dos aperturas para el mismo análisis de abandono:

Enterrado: "Entrenamos un modelo de gradient boosting con 18 meses de telemetría de cuentas, logrando un AUC de 0.87 con validación cruzada de 5 iteraciones. La importancia de características sugiere que la velocidad de tickets de soporte es la señal más fuerte."

Claro: "$4.2M de ARR está en alto riesgo de abandono en Q2, frente a $2.8M el trimestre pasado. El incremento se concentra en 12 cuentas de más de $100K. Necesitamos decidir hoy a cuáles 5 llama el equipo de CSM esta semana."

El mismo modelo. Los mismos datos. La segunda inicia la reunión. La primera la termina.

Si no puede escribir la oración "qué cambió" en 30 segundos, el trabajo no está listo para presentar. Vuelva a su laptop. La presentación no puede arreglar una tesis que aún no ha nombrado.

Un ejercicio útil: antes de construir una sola diapositiva, escriba el asunto del correo que enviaría si el ejecutivo preguntara "¿qué encontró?". Si el asunto es "Actualización del análisis de abandono Q2", eso es un informe de estado, no un hallazgo. Si es "$4.2M de ARR expuesto en 47 cuentas; recomendamos actuar ahora en las 12 principales", eso es un hallazgo. Construya el deck alrededor del asunto.

La respuesta en 1 diapositiva

Asuma que la reunión se reduce a 90 segundos. Ocurre con más frecuencia de lo que cree. El CRO fue interrumpido por una llamada con un cliente. El CFO tiene la preparación del board a las 2pm. Tiene una diapositiva y un minuto y medio.

¿Qué aparece en ella?

Tres cosas, siempre:

1. El número titular. Una línea en negrita. El monto en dólares, el incremento, el cambio. No la metodología.
2. La decisión requerida. ¿Qué le pedimos al ejecutivo que apruebe, financie o cambie? Frasela como una oración con verbo: "Aprobar la incorporación de 2 CSMs al pod de alto riesgo" o "Pausar la prueba de precios para el segmento SMB hasta la semana que viene."
3. El responsable y la fecha. Quién hace qué y para cuándo. Sin esto, la reunión termina con buenas intenciones sin seguimiento.

Todo lo demás es apéndice. La ficha del modelo, la importancia de características, el rendimiento en el conjunto de retención, el análisis por segmento: eso va en las diapositivas 5 a 30, y solo las muestra si se lo piden.

Hago que mi equipo construya la respuesta en 1 diapositiva primero, antes de cualquier otra diapositiva. Si no puede escribirla, no tiene un hallazgo todavía. Tiene un estado del proyecto. Son artefactos distintos que van a salas distintas.

Una buena respuesta en 1 diapositiva suena a un memorando de decisión, no a un resumen de investigación. El CFO puede llevársela a su jefe. El CRO puede reenviarla a sus VPs. Si su diapositiva no puede extraerse de contexto y seguir teniendo sentido, no está terminada.

Cuándo usar intervalos de confianza (y cuándo omitirlos)

Aquí va la herejía: la mayoría de las veces, los intervalos de confianza no pertenecen a la diapositiva.

Lo sé. Nos entrenaron para mostrar siempre la incertidumbre. Y en una revisión entre pares de DS, debe hacerlo. Así se somete el trabajo a presión. Pero en una sala ejecutiva, un intervalo de confianza a menudo hace lo contrario de lo que usted pretendía. Usted quiso decir "soy riguroso". Ellos escucharon "no sabe realmente". La decisión se congela. Nadie actúa. El modelo no cambió nada.

La regla que uso: muestre el intervalo cuando la decisión cambia con el límite inferior. Ocúltelo cuando no lo hace.

Dos ejemplos.

Muéstrelo. Una prueba de precios muestra un incremento de ingresos del 4%, IC del 95% [-1%, 9%]. El límite inferior es negativo. La decisión absolutamente cambia con eso. Si el efecto real es -1%, no despliega. El IC es todo el punto. Liderece con él.

Ocúltelo. Un modelo de abandono dice que 47 cuentas están en alto riesgo, con un intervalo de calibración que dice "entre 41 y 53 abandonarán realmente en los próximos 90 días". La decisión (llamarlas esta semana) no cambia si el número es 41 o 53. El intervalo distrae. Póngalo en el apéndice, menciónelo una vez si se lo preguntan: "la banda es más o menos 6 cuentas con un 90% de confianza, no cambia la acción."

El impuesto de la falsa precisión es real, pero el impuesto de la falsa incertidumbre lo es igual. Un IC de [-1%, 9%] presentado junto a una recomendación direccional le da al ejecutivo exactamente la señal equivocada: que usted está cubriendo sus espaldas porque no cree en su propio número. Si cree en la llamada direccional, haga la llamada direccional. El IC vive en el apéndice donde los pares de DS pueden analizarlo.

En caso de duda, pregúntese: "si el límite inferior fuera un 20% peor, ¿cambiaría la recomendación?". Si sí, muestre el intervalo. Si no, lo está mostrando para usted, no para la sala.

La tensión entre "el modelo dice X pero el negocio sabe Y"

Este es el momento que quiebra a los Data Scientists IC junior. El modelo dice una cosa. El director de ventas objeta: "eso no es lo que estoy viendo en el campo". La sala se voltea hacia usted. ¿Ahora qué?

No luche en la diapositiva. Perderá, y debería perder. El director de ventas tiene contexto que el modelo no tenía.

En cambio, haga tres cosas, en orden:

1. Nombre el conflicto, en voz alta. "El modelo predice que los deals mid-market de más de $50K cierran un 30% más rápido cuando lideramos con la demo de integraciones. Mike, usted dice que eso no coincide con lo que ve en el campo. Profundicemos. Es importante."

Suena simple. De hecho, es la parte más difícil. La mayoría de los Data Scientists IC se quedan en silencio, o peor, se ponen a la defensiva. Nombrar el conflicto dice: confío en mi modelo, confío en su intuición, y uno de los dos se está perdiendo algo. Busquemos qué es.

2. Muestre los datos que vio el modelo. No el algoritmo. Los datos. "Aquí están los 340 deals de los últimos 12 meses que alimentaron este modelo." Esto suele resolver el conflicto al instante. El director de ventas mira los datos y dice "ah, esos son principalmente deals inbound; mi objeción era sobre outbound, que el modelo no vio". Ahora tiene un hallazgo real: el modelo es correcto para inbound, la intuición es correcta para outbound, y la hoja de ruta es construir un modelo separado para outbound o delimitar este a inbound únicamente.

3. Pregunte qué sabe el negocio que los datos no. "Mike, ¿qué tendría que ver en el campo para que la recomendación del modelo le pareciera razonable?" Esto invierte la conversación de defensa a colaboración. Ya no está argumentando en favor de su modelo. Está recopilando características.

Nueve de cada diez veces, la intuición tiene razón sobre algo que los datos no capturaron: un cambio de estrategia reciente, un competidor entrando al segmento, un cambio en el plan de compensación hace tres meses que los datos aún no absorbieron completamente. Trate la objeción como señal gratuita. Escríbala. Es su próxima característica.

El único caso en el que debe mantener su posición: cuando la objeción del director de ventas es "simplemente no lo creo". Eso no es una señal contraria. Es incomodidad ante ser medido. Mantenga la calma, entréguele los datos y déjelo procesarlos.

Traducir la probabilidad del modelo en acción para el negocio

Un propensity score de 0.73 no le dice nada a un CFO. Deje de poner probabilidades en diapositivas ejecutivas a menos que las haya traducido.

Traduzca a una de tres cosas, según la audiencia:

• Dólares (para CFOs, CEOs, socios de finanzas)
• Deals o cuentas (para directores de ventas, CROs)
• Headcount u horas (para COOs, líderes de operaciones)

Un modelo de abandono que dice "el 23% de las cuentas está en riesgo" se convierte en:

$4.2M de ARR expuesto en 47 cuentas. 12 de ellas superan los $100K. Si salvamos 5 de las 12 principales, recuperamos $1.7M.

Un modelo de lead scoring que dice "este lead tiene propensión 0.84" se convierte en:

Los leads del primer decil cierran al 31%. Si los enrutamos a AEs senior, proyectamos 14 deals adicionales ganados por trimestre al ASP actual, aproximadamente $980K en ARR incremental.

Un pronóstico de demanda que dice "la demanda de Q3 estará un 12% por encima del plan" se convierte en:

Necesitamos contratar 6 CSMs adicionales antes del final de Q2 o incumpliremos el SLA en el 18% de las nuevas cuentas.

La regla de traducción: si su número no termina en dólares, deals o personas, tradúzcalo otra vez. El cerebro del ejecutivo funciona con esas tres unidades. Los propensity scores, los porcentajes de lift y la ganancia de información no desencadenan conversaciones sobre presupuesto. Los dólares sí.

Una hoja de trabajo útil que hago llenar a mi equipo antes de cualquier presentación ejecutiva:

Si no puede completar las columnas de la derecha, no tiene un hallazgo ejecutivo. Tiene un resultado de investigación. No son lo mismo.

Lecturas previas para partes interesadas

El hábito de mayor apalancamiento que he adoptado en cinco años de trabajo en DS: enviar una página de lectura previa 24 horas antes de la reunión.

No el deck. Una página. Tres viñetas. La decisión que está solicitando.

El formato que uso:

Asunto: [Decisión requerida] Riesgo de abandono Q2: recomendamos actuar en las 12 cuentas principales esta semana

Qué cambió:
- $4.2M de ARR en alto riesgo de abandono en Q2, frente a $2.8M el trimestre pasado
- 12 cuentas de más de $100K, concentradas en 5 clientes
- Impulsor principal: velocidad de tickets de soporte (incremento 3x en los últimos 30 días)

Lo que solicito:
- Aprobar el alcance de retención por parte del CSM a las 12 cuentas principales esta semana
- Aprobar presupuesto de $40K para paquete de descuento de retención en las 5 principales
- Decisión antes del EOD del miércoles para que el alcance comience el jueves

Lo que llevaré a la reunión:
- Las 12 cuentas, puntuadas
- El borrador del playbook de retención
- El resultado proyectado a 90 días con y sin acción

Tres cosas que esto hace:

1. El ejecutivo entra a la reunión ya al 80% de una decisión. Tuvo tiempo para pensar, consultar con su equipo y volver con una pregunta más precisa.
2. Usted descubre objeciones por escrito, de forma asíncrona, donde puede abordarlas con calma. No en el acto, donde tropezará.
3. Si la reunión se cancela (y en mi experiencia una de cada tres reuniones ejecutivas lo hace), la decisión igual se toma. La lectura previa es el artefacto. La reunión es solo la ratificación.

El error que veo cometer a los Data Scientists IC: envían el deck como lectura previa. El ejecutivo abre la diapositiva 1, ve una matriz de confusión y cierra el correo. No envíe el deck. Envíe la página. El deck es el apéndice.

Qué omitir

Cosas que no deberían estar en la diapositiva para una audiencia ejecutiva:

• Curvas ROC
• Matrices de confusión
• Gráficos de importancia de características (a menos que una característica sea toda la historia y la esté nombrando)
• Tablas de hiperparámetros
• Cualquier cosa con "log-loss", "perplejidad", "divergencia KL" o "MAP" en el título
• Desgloses de iteraciones de validación cruzada
• Curvas de pérdida
• El diagrama de arquitectura de su modelo
• Una lista de las librerías que utilizó

Si el ejecutivo pregunta, tiene todo esto en el apéndice. Debería poder ir a la diapositiva 18 y responder "sí, el AUC es 0.87, calibrado en un holdout de 5 iteraciones". No lo ofrezca voluntariamente.

El criterio es brutal pero justo: si una diapositiva no ayuda al ejecutivo a decidir, no va al frente del deck. Los artefactos del modelo van a la revisión entre pares de DS, que es una reunión diferente con una audiencia diferente. Confundir esas audiencias es como se construyen decks de 30 diapositivas que nadie lee.

Voy más lejos: si se encuentra queriendo mostrar la curva ROC, pregúntese por qué. Generalmente es porque está orgulloso del modelo. Es justo, debería estarlo. Pero el orgullo no impulsa decisiones. El número titular sí. Muestre el titular. La curva ROC es para su DS lead.

La trampa del "construimos un modelo que no cambia nada"

El peor resultado en el trabajo de DS no es un modelo incorrecto. Es un modelo correcto en el que nadie actúa.

He visto equipos entregar hermosos modelos de abandono que permanecen en un dashboard de Looker durante un año porque nadie definió jamás qué debería hacer el equipo de CSM con ellos. He visto modelos de lead scoring con AUC de 0.91 que producen cero deals adicionales ganados, porque la lógica de enrutamiento nunca cambió. El modelo era correcto. El bucle de acción faltaba.

Esta trampa se tiende antes de escribir la primera línea de código.

La solución es anterior a la comunicación. Antes de empezar el proyecto, escriba la respuesta a esta pregunta: "si el modelo funcionara perfectamente, ¿qué cambiaría en el negocio el lunes?"

Si no puede responder eso en una oración, no empiece el proyecto. Vuelva a la parte interesada. Pregúntele. Si tampoco puede responderlo, el proyecto no está listo.

Una buena respuesta: "El equipo de CSM tendría una lista clasificada de cuentas en riesgo cada lunes y llamaría a las 10 principales esa semana."

Una mala respuesta: "Entenderíamos mejor el abandono."

Entender no es una acción. Es un sentimiento. Nadie fue promovido por entender mejor el abandono. Las personas son promovidas por retener $4M de ARR llamando a 12 cuentas.

Una vez que tiene la respuesta, el resto del proyecto se vuelve más fácil:

• El formato de salida lo dicta la acción ("una lista clasificada de cuentas")
• La cadencia la dicta el flujo de trabajo ("cada lunes")
• La métrica de éxito la dicta el resultado del negocio ("ARR retenido vs control")
• La estrategia de comunicación la dicta quién actúa sobre ella ("el equipo de CSM, semanalmente, en su revisión de Pipeline existente")

Si el bucle de acción es real, la comunicación se escribe sola. La diapositiva dice: "aquí está la lista. Llame a las 10 principales. Mediremos la retención en 90 días."

Si el bucle de acción falta, ningún pulido en las diapositivas lo salvará. El modelo va al cajón. El ejecutivo deja de asistir a sus reuniones. La próxima contratación de DS hereda el mismo modelo y el mismo dashboard, y el ciclo se repite.

Esta es la disciplina más difícil en el trabajo de DS como IC. Casi nadie la enseña en la universidad. El nivel técnico es la barra fácil. La barra del bucle de acción es lo que separa a los Data Scientists IC que son promovidos de los que no lo son.

Más información

• Plantilla de descripción de puesto de Data Scientist
• Gestión de partes interesadas para ICs
• Reportes de A/B test que no se re-debaten
• Cuándo rechazar un brief deficiente