Cómo experimentar sin generar caos en el equipo
El problema de testear sin hipótesis
Un test A/B sin una hipótesis clara de por qué debería funcionar no enseña nada, incluso si "gana" una variante. Sin hipótesis, ganar un test solo dice qué pasó, nunca por qué — y sin ese porqué, el aprendizaje no se puede aplicar a la siguiente decisión de diseño o mensaje.
Un experimento a la vez, por canal
Correr múltiples experimentos superpuestos en el mismo canal contamina los resultados. Prefiero un experimento activo por canal con una ventana mínima de significancia. Esta disciplina cuesta paciencia — es tentador lanzar tres ideas a la vez cuando hay presión por resultados— pero los datos contaminados terminan costando más tiempo del que ahorran.
Documentar aprendizajes, no solo resultados
Un experimento que "pierde" enseña tanto como uno que gana, siempre que quede documentado el porqué. Mantengo un registro simple de hipótesis y aprendizaje para que el equipo no repita el mismo test disfrazado de idea nueva seis meses después. Ese registro también sirve para nuevos integrantes del equipo: leerlo evita que repitan, sin saberlo, un experimento que ya se corrió y ya dio una respuesta.
Qué hacer esta semana
Crea un documento simple de una columna: hipótesis, resultado, aprendizaje. Empieza registrando ahí el último experimento que corriste, aunque haya sido hace meses. Comparte ese documento con todo el equipo, no solo con quien lo escribió — su valor crece cuando todos pueden consultarlo antes de proponer un nuevo test.
Cómo decido cuándo detener un test
Defino de antemano el tamaño de muestra o el tiempo mínimo necesario antes de lanzar el experimento, no después. Revisar resultados a mitad de camino y detener el test en cuanto "se ve ganador" es la forma más común de engañarse con ruido estadístico. Escribir ese criterio de parada antes de empezar también protege al equipo de la presión de detener el test apenas hay buenas noticias parciales — la disciplina se decide antes, no en caliente.
