Hay una situación que aparece con bastante frecuencia.
Una organización decide que determinado producto es estratégico. Define objetivos, asigna presupuesto, arma un equipo y empieza a ejecutarlo.
Después aparecen los datos.
Y muestran algo diferente.
Quizás otro producto convierte mejor. Quizás los clientes no valoran una funcionalidad como esperábamos. Quizás una modificación que parecía evidente termina empeorando el resultado.
Entonces ocurre algo interesante: en lugar de revisar la decisión, empezamos a buscar otra métrica.
Cambiamos el período. Miramos otro segmento. Encontramos una explicación.
Hasta encontrar un número que confirme lo que ya habíamos decidido.
La empresa tiene datos. Tiene dashboards. Probablemente tenga un equipo de Data.
Pero eso no significa que sea data-driven.
Hay una diferencia enorme entre utilizar datos para tomar una decisión y utilizarlos para justificar una decisión que ya tomamos.
Para mí, ser data-driven tiene mucho menos que ver con cuántos datos tenemos y mucho más con el método que utilizamos para decidir.
Y, sobre todo, con nuestra capacidad para descubrir rápidamente cuándo estamos equivocados.
El valor de los datos no es darnos siempre la razón
Durante mucho tiempo asociamos una organización data-driven con determinadas capacidades: data warehouses, dashboards, KPIs, analistas, científicos de datos y reportes distribuidos por toda la compañía.
Todas pueden ser extremadamente valiosas.
Pero son infraestructura.
Una empresa puede tener todo eso y seguir tomando decisiones exactamente igual que antes.
Para mí, la lógica debería parecerse bastante más al método científico:
Hipótesis → Prueba → Medición → Decisión → Aprendizaje
Tenemos una idea sobre lo que puede ocurrir. Buscamos una forma de ponerla a prueba. Definimos qué resultado esperamos y qué evidencia nos haría cambiar de opinión. Ejecutamos, medimos y aprendemos.
Hay un dato que me parece particularmente ilustrativo.
En un trabajo sobre experimentación a gran escala, Ron Kohavi y otros investigadores reportaron que solo alrededor de un tercio de las ideas testeadas en Microsoft mejoraban las métricas que originalmente buscaban mejorar.
Es un dato bastante incómodo.
Porque si incluso organizaciones con enorme capacidad tecnológica y de experimentación se equivocan frecuentemente al anticipar qué ideas van a funcionar, quizás el objetivo no debería ser volvernos extraordinariamente buenos prediciendo.
Quizás deberíamos volvernos extraordinariamente buenos descubriendo rápido cuándo nuestra predicción era incorrecta.
Una de las mayores ventajas de trabajar con datos no es aumentar nuestra capacidad de tener razón. Es reducir el costo de estar equivocados.
Una opinión puede convertirse en una hipótesis
Esto aparece todo el tiempo en decisiones de producto.
Supongamos que creemos que bajar la tasa de determinado producto va a aumentar suficientemente la conversión como para compensar la reducción de margen.
Alguien puede estar convencido de que va a funcionar. Otra persona, con la misma experiencia, puede pensar exactamente lo contrario.
Podemos discutir durante semanas.
O podemos transformar la discusión en algo que pueda ponerse a prueba:
Si reducimos la tasa de X a Y, esperamos que la conversión aumente Z, manteniendo determinados niveles de rentabilidad y riesgo.
La diferencia parece pequeña, pero cambia completamente la conversación.
Ya no estamos discutiendo quién tiene razón.
Estamos diseñando una forma de descubrirlo.
Esto también cambia cómo pienso la intuición.
Una persona que lleva quince años trabajando en un negocio probablemente tenga conocimiento que ningún dashboard captura completamente. Reconoce patrones, entiende excepciones y puede detectar cambios antes de que aparezcan claramente en una métrica.
No descartaría nunca esa intuición.
La usaría para generar hipótesis.
Si alguien me dice: “Por mi experiencia, creo que si hacemos X va a ocurrir Y”, mi respuesta no debería ser “los datos dicen otra cosa”.
Debería ser:
¿Cómo podemos probarlo?
La experiencia genera hipótesis. La evidencia ayuda a evaluarlas. Y el resultado mejora nuestra experiencia para la próxima decisión.
Una métrica debería tener una decisión detrás
Otra situación que encuentro con frecuencia empieza así:
“Necesitamos medir esto.”
Antes de construir la métrica, me gusta hacer tres preguntas:
¿Qué acción vas a ejecutar con ella?
¿Contra qué la vas a comparar?
¿Qué significa que esté bien o mal?
Supongamos que construimos un dashboard que muestra:
Conversión: 18%.
¿Es buena?
No lo sabemos.
Quizás ayer era 12%. Quizás nuestro objetivo era 25%. Quizás un segmento convierte 30% y otro 4%. Quizás la conversión aumentó porque estamos aceptando clientes con mucho más riesgo.
O quizás lleva seis meses en 18% y nadie piensa hacer nada diferente si mañana pasa a 15% o a 21%.
En ese caso hay una pregunta incómoda:
¿Para qué estamos mirando esa métrica?
Una métrica sin una decisión asociada corre el riesgo de convertirse simplemente en información.
Y acumular información no es lo mismo que construir conocimiento.
Mejorar una métrica puede empeorar el negocio
Este punto es particularmente importante porque los experimentos rara vez tienen una sola consecuencia.
Supongamos que bajamos una tasa y la conversión mejora.
¿Ganamos?
Todavía no lo sabemos.
Podríamos haber aumentado la conversión a costa de reducir demasiado el margen. O haber incorporado clientes con un nivel de riesgo mucho mayor.
Por eso, además de una métrica principal, necesitamos definir qué cosas no estamos dispuestos a deteriorar mientras intentamos mejorarla.
En experimentación suelen llamarse guardrail metrics. Prefiero pensarlas simplemente como métricas de protección.
Si nuestro objetivo es aumentar conversión, por ejemplo, rentabilidad y riesgo podrían funcionar como métricas de protección.
La regla es sencilla:
si el experimento mejora la métrica principal pero rompe una métrica de protección relevante, el experimento no ganó.
Esto es particularmente importante cuando los resultados aparecen en momentos diferentes.
En crédito, por ejemplo, podemos observar cambios en conversión prácticamente de inmediato. Pero algunas consecuencias sobre el comportamiento de una cartera necesitan meses para materializarse.
Una decisión puede parecer extraordinaria durante las primeras semanas y bastante menos atractiva varios meses después.
Medir rápido no significa necesariamente aprender rápido si estamos midiendo solamente la parte del resultado que aparece primero.
No todo puede —ni debería— experimentarse
También hay que reconocer los límites del método.
No todas las decisiones pueden convertirse en un A/B test.
Hay organizaciones o productos con volúmenes tan bajos que esperar significancia estadística puede ser poco realista. En esos casos tendremos que utilizar otras herramientas: comparaciones temporales, evidencia cualitativa, análisis histórico o simplemente la mejor información disponible.
También existen decisiones difíciles de revertir.
Una arquitectura, una contratación importante o determinadas decisiones regulatorias no siempre admiten un experimento pequeño antes de avanzar.
Ahí la pregunta cambia.
No es “¿cómo hacemos un A/B test?”, sino “¿qué evidencia podemos conseguir antes de tomar una decisión cuyo costo de reversión es alto?”
Y están los ciclos de feedback largos.
Podemos modificar algo hoy y observar rápidamente una mejora en una métrica, mientras que el costo aparece tres o seis meses después.
Por eso no creo que ser data-driven signifique experimentar absolutamente todo.
Eso también puede convertirse en burocracia.
Significa elegir el instrumento correcto según la decisión que tenemos adelante.
Cuanto más reversible sea una decisión, más barato debería ser probar y aprender.
Cuanto menos reversible sea, más importante se vuelve entender los supuestos antes de avanzar.
El problema no es solamente cultural: también son los incentivos
Hay algo que me parece necesario reconocer.
Decir que una organización tiene que estar “dispuesta a cambiar de opinión” suena bien.
Pero no siempre es tan sencillo.
Imaginemos que alguien propuso una iniciativa, consiguió presupuesto, convenció a la dirección, armó un equipo y dedicó seis meses a ejecutarla.
Ahora los datos muestran que la hipótesis era incorrecta.
Aceptar el resultado no implica solamente decir “me equivoqué”.
Puede significar cancelar un proyecto, reasignar personas, explicar por qué se gastó determinado presupuesto y quizás poner en riesgo el financiamiento de la próxima iniciativa.
Hay incentivos reales para seguir adelante.
Por eso no alcanza con pedir objetividad.
Hay que diseñar mecanismos que la hagan más probable.
Uno bastante simple es escribir antes de ejecutar cuál es la hipótesis, cuál es la métrica principal, qué métricas queremos proteger y qué resultado nos haría detenernos o cambiar.
También ayuda poner fechas explícitas de revisión. Continuar una iniciativa no debería ser siempre la opción automática mientras cancelarla requiere una decisión extraordinaria.
Y probablemente haya algo todavía más importante:
una organización debería poder reconocer como un buen resultado haber detenido temprano una iniciativa que la evidencia mostró que no funcionaba.
Si cancelar siempre se interpreta como fracaso, los equipos aprenderán rápidamente a encontrar argumentos para continuar.
Podemos tener toda la infraestructura de datos del mundo y seguir teniendo ese problema.
Aprender también requiere memoria
Supongamos que probamos una hipótesis y no funciona.
Gastamos poco, medimos correctamente y aprendimos que, bajo determinadas condiciones, nuestra idea era incorrecta.
Eso puede ser un resultado extraordinariamente valioso.
El desperdicio aparece si seis meses después otro equipo propone exactamente lo mismo porque nadie sabe que ya lo habíamos probado.
Por eso creo que una organización orientada a datos debería conservar algo más que tablas y dashboards.
Debería poder responder:
¿Qué hipótesis probamos?
¿Qué esperábamos que ocurriera?
¿Qué ocurrió realmente?
¿Qué decidimos?
¿Y qué aprendimos?
Además, una prueba exitosa tampoco debería convertirse automáticamente en una verdad permanente.
Cambian los clientes. Cambia el mix. Cambia la competencia. Cambia el producto.
Algo que funcionó hace un año puede no producir hoy el mismo resultado.
Experimentar también implica volver a observar si el efecto sobrevivió cuando cambió el contexto.
Visto así, los datos dejan de ser solamente un activo analítico.
Se convierten en memoria organizacional.
Cinco preguntas antes de construir otro dashboard
Intentaría resumir todo esto en cinco preguntas:
¿Qué creemos que va a ocurrir?
¿Cuál es la forma más barata de descubrir que estamos equivocados?
¿Qué resultado nos haría cambiar de decisión, y lo definimos antes de mirar los datos?
¿Qué no queremos romper mientras intentamos mejorar esto?
¿Dónde va a quedar registrado lo que aprendimos?
No hace falta tener una plataforma sofisticada de experimentación para empezar a trabajar así.
Hace falta construir el hábito de convertir opiniones en hipótesis, hipótesis en evidencia y evidencia en aprendizaje.
Entonces, ¿qué significa realmente ser data-driven?
No creo que sea tener más dashboards.
Ni un data lake, un warehouse o un lakehouse.
Ni contratar más científicos de datos.
Ni medir absolutamente todo.
Todas esas cosas pueden ser necesarias.
Pero son herramientas.
En el artículo anterior planteaba que una buena decisión tecnológica empieza preguntando:
¿Qué problema queremos resolver?
Los datos agregan una segunda pregunta:
¿Cómo vamos a saber si realmente lo resolvimos?
Ahí dejan de ser algo que miramos después de tomar una decisión y empiezan a formar parte del mecanismo mediante el cual decidimos.
Por eso, si tuviera que definir una organización data-driven de una manera simple, diría:
No es una organización que tiene una respuesta para todo. Es una organización que construyó un método para descubrir rápidamente cuándo está equivocada.
El objetivo no debería ser tener razón todo el tiempo.
Debería ser aprender suficientemente rápido como para tomar una mejor decisión la próxima vez.
Fuente
Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. & Pohlmann, N. (2013). Online Controlled Experiments at Large Scale. Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining.