Experimentation-Driven Product Development

Hola a todos. Soy Graham, y estoy muy emocionado de darles esta charla relámpago hoy sobre el desarrollo impulsado por la experimentación.

Así que, soy Graham McNicol, soy el cofundador de GrowthBook. GrowthBook es la plataforma de código abierto más popular para feature flagging y pruebas A-B. Y el objetivo de la charla de hoy es ayudarles a entender los fundamentos de lo que llamamos desarrollo impulsado por la experimentación.

Así que, vamos a echar un vistazo a cómo desarrollamos productos hoy en día, y luego vamos a echar un vistazo a las pruebas A-B y luego algunas formas en que podemos combinarlas para hacer mejores productos. Esta es una presentación basada en animales. Ese es mi perro Nellie, y así que si no les gusta de lo que estoy hablando, al menos obtendrán algunas fotos de animales bonitos.

Así que, echemos un vistazo a cómo construimos productos actualmente. Así que, si son como yo, usan algún tipo de sistema ágil. Esto es Scrum. Si tienen mala suerte, les toca usar algún proceso como este. Me siento muy apenado por ustedes si lo hacen. Pero si miran todo el panorama de diferentes procesos ágiles, todos están perdiendo una cosa, que es, ¿qué significa hecho?, ¿verdad? Así que, para algunos procesos, podrían tener algo como, ya saben, hecho significa que está libre de defectos, o aceptamos las historias de usuario, o ¿le gusta al propietario del producto? Y así, típicamente, lo que queremos decir con hecho es, como, enviado, ¿verdad? Lo enviamos a producción, y hemos terminado. Pero, ¿cómo sabemos que lo que enviamos realmente funcionó, verdad? O en un panorama más amplio, como, ¿y si estábamos equivocados al construirlo en primer lugar? Como, ¿y si el producto que enviamos realmente perjudicó nuestro negocio?

Bien, con eso en mente, echemos un vistazo a las pruebas A-B. Entonces, la definición de pruebas A-B que realmente me gusta es una forma controlada de medir el impacto de los cambios en usuarios reales. Y así, desde un nivel alto, lo que eso parece es, primero, comienzas con una hipótesis, alguna idea que deseas probar. Y luego, asignas, generalmente al azar, a los usuarios en diferentes grupos. Luego expones esos grupos a las diferentes variantes. Luego, rastreas cómo se comportaron en tu aplicación o producto. Y luego, usas estadísticas para averiguar si ese cambio que detectamos fue estadísticamente significativo o no.

Así que, con eso en mente, echemos un vistazo a algunos ejemplos de pruebas A-B en el mundo real. Ahora, estos son basados en la web, pero puedes hacer pruebas A-B en cualquier producto que sea digital. Así que, esto es de Airbnb, y querían aumentar las tasas de conversión y disminuir las tasas de cancelación siendo más claros sobre las políticas de cancelación mostrando esta línea de tiempo. Así que, tómate un momento para pensar si crees que este cambio fue exitoso o no en mejorar esas métricas. Bueno, resulta que esta prueba falló. Así que, echemos otro vistazo a otro ejemplo. Así que, esto es de Netflix, y la versión de control tiene solo un botón que dice probar ahora, y luego prueban una nueva variante que tiene una dirección de correo electrónico y luego el botón. Así que, ve a una página de registro después de eso. Así que, tómate un momento para pensar si eso ganó, y ese realmente lo hizo. Y eso va un poco en contra de algunos de los principios de la UI donde pensamos que no deberías mostrar campos de formulario siempre que sea posible.

Bien. Así que, con eso en mente, ¿con qué frecuencia creemos que las pruebas A-B ganan? Como, en promedio, en toda la industria. Así que, lo que quiero decir con ganar es como con qué frecuencia una prueba A-B que lanzamos, con qué frecuencia tiene éxito en mover las métricas que fue diseñada para mejorar. Y resulta que en realidad solo un tercio de las pruebas que realizamos tienen éxito en mover una métrica que queríamos que moviera. Eso significa que dos tercios del tiempo en realidad no tiene éxito o perjudica nuestro producto, ¿verdad? Y es un poco peor que eso porque ese tercio es en realidad una estimación alta. Resulta que en toda la industria, generalmente es un poco más bajo, y dependiendo de cuán optimizado esté tu producto, se vuelve cada vez más difícil mejorarlo. Una cosa interesante para llevar de esto es que nadie lanza un producto o construye un producto que no cree que ganará, ¿verdad? Así que, esa tasa de éxito de un tercio es nuestro mejor esfuerzo. Estamos construyendo cosas que creemos que funcionarán y aún así no tenemos éxito dos tercios del tiempo. Simplemente resulta que realmente no somos buenos prediciendo lo que nuestros usuarios quieren.

Y la otra conclusión de aquí es que sin pruebas, estás adivinando, porque realmente no hay una manera causal de averiguar el impacto de lo que estás haciendo sin realizar un experimento controlado. Ahora, escucho algunas objeciones comunes todo el tiempo sobre por qué las empresas no realizan experimentos. Así que, echemos un vistazo rápido a algunas de ellas ahora. La primera es, ¿qué hacemos? Miramos los datos de antes y después y simplemente los entrecerramos. Así que, demos un hipotético de cómo podría verse esto.

Así que, tenemos alguna tasa de conversión a lo largo del tiempo y lanzamos una nueva característica aquí y luego rastreamos su rendimiento a lo largo del tiempo. Vemos este gráfico, ¿verdad? Entonces, ¿creemos que esto es exitoso? ¿Movió la métrica? Bueno, la métrica subió y hacia la derecha. Así que, tal vez, pero la respuesta real es que no tenemos idea porque no puedes saber a menos que realices un experimento controlado porque no tienes contrafactuales, ¿verdad? Así que, como si no hubiéramos realizado esa prueba, el gráfico podría haber lucido así. Y aquí hay un ejemplo real de Airbnb donde lanzaron una nueva característica y luego terminaron retirándola. Pero si solo miras el agregado, es realmente difícil decir causalmente qué pasó porque hay tanto ruido en tu señal. La gente está desplegando otras características todo el tiempo. Tienes cambios en el tráfico y vacaciones y todo tipo de cosas que lo afectan. Y las pruebas A-B están realmente diseñadas para controlar esas variantes.

El otro ejemplo que escuchamos sobre por qué no realizan experimentación es, bueno, no necesitamos porque hicimos pruebas de usuario. Bueno, si estás familiarizado con las pruebas de usuario, generalmente, están probando con cinco, tal vez incluso 10 si tienes suerte, pruebas. Es solo un tamaño de muestra realmente pequeño para tratar de averiguar lo que quieres y hay todo tipo de otros sesgos que no tendré tiempo de abordar. Y generalmente, si estás de acuerdo en realizar pruebas de usuario para empezar, estás de acuerdo en realizar pruebas más grandes con más personas después. Así que, deberías estar de acuerdo con eso.

Muy bien. Así que, echemos un vistazo a la mejor manera de construir productos. No obtienes puntos por adivinar que creemos que integrar las pruebas A-B en tu proceso es cómo lo haces. Y así, cada producto debería definir cómo se ve el éxito antes de comenzar a construirlo. Y así, el proceso que nos gusta hacer es, básicamente, antes de comenzar a construir cualquier cosa, te sientas y decides, ¿cuál es la hipótesis? ¿Por qué estamos construyendo esta cosa? ¿Qué esperamos que haga? Y luego, ¿qué acciones o comportamientos demostrarían que la hipótesis es correcta? Y luego, ¿qué métricas necesitaríamos rastrear para eso? Así que, podría ser una tasa de registro o evento de compra. Y luego, el paso final aquí es, ¿cuál es la cosa más pequeña que podemos construir para probar esta hipótesis y ver si es correcta? Porque quieres llegar a la señal lo más rápido posible para no perder tiempo construyendo cosas que no funcionan. Llamamos a esto HAM. Hay Jonham. Y luego, si tienes el tráfico para realizar ese experimento, entonces deberías hacerlo. Y así, cómo podría lucir el proceso ajustado es, básicamente, en tu planificación de tus proyectos, como que se te ocurre la hipótesis, los criterios de éxito, y luego lo reduces al mínimo posible. Y luego, haces tu proceso de producto regular. Pero luego, en lugar de simplemente enviarlo a producción al 100% de todos, lo envías como una prueba A-B. Y luego, decides, basado en los resultados de esa prueba, una vez que llegas a un poder significativo, si deberías desplegarlo o retirarlo. Y luego, haces una revisión, como presentar los experimentos a tu equipo y como iterar desde allí. Y la buena noticia es que esto es súper fácil, particularmente si estás usando feature flags, ¿verdad? Así que, como desarrolladores, cuando enviamos algo a producción, como, el objetivo principal, al menos inicialmente, es asegurarnos de que no rompimos nada, ¿verdad? Ese es el mínimo para lo que acabamos de enviar. Y los feature flags son realmente útiles con eso porque puedes realmente envolver tu cambio en solo un poco de lógica condicional.

Es como, si está activado, muestra este código. Si no, no ejecutes ese código. Y así, añade mucha seguridad. Aquí hay un ejemplo de Growthbook. Este es el de arriba mostrando JavaScript y el de abajo mostrando React. Y así, los feature flags añaden mucha seguridad. Porque te permite separar el despliegue de tu código de la liberación de esa característica. Y luego, si algo sale mal, puedes simplemente apagar el flag muy rápidamente. Solo pulsa el interruptor y se apaga en milisegundos.

Lo genial es que ahora que estás liberando condicionalmente esa característica a tus usuarios, una de las formas en que puedes liberarla condicionalmente es a través de una prueba A-B. Aquí está ese mismo flag al que acabamos de añadir dos reglas diferentes. La primera dice, si son un usuario beta, actívalo para ellos. Y la segunda dice, si estás fuera de ese grupo, entonces vamos a ejecutar esta prueba A-B al 50% de nuestra audiencia. Y dentro de ese 50%, hay la mitad de cada uno dentro, ¿verdad? Y así, básicamente, para esa línea de código, ahora tenemos una prueba A-B completa en ejecución. Y eso nos permite obtener resultados como este. Así que, esto es, en el lado izquierdo, nuestras métricas que elegimos para este experimento. Y tenemos la columna que muestra la versión de control, y la nueva versión variante, y luego todas las estadísticas a la derecha. Es bastante complicado, pero básicamente, declaramos un ganador en esta prueba porque es significativo.

Así que, lo genial de las pruebas A-B es que reemplazan muchas diferencias de opinión, ¿verdad? Porque decidiste esos criterios de éxito de antemano, tienes un marco para decidir el destino del proyecto que no depende de tus sesgos u opiniones personales. La otra cosa que hace es que fallar no es un fracaso, ¿verdad? Así que, si lanzas algo y aprendes que no funcionó, puedes realmente celebrar eso, ¿verdad? Porque no enviar algo negativo es bueno, ¿verdad? Ahorraste a tu negocio algo de dinero y aprendiste rápido.

Muy bien. Así que, en conclusión, lo que quiero que te lleves de esta charla es que hecho no debería ser enviado, ¿verdad? Enviar algo no significa que funcionó o fue exitoso. Y que realmente necesitas hacer una hipótesis y probarla para ver si realmente fue exitosa en hacer lo que se suponía que debía hacer. Y realmente, deberías estar haciendo esto en cada proyecto si tienes el tráfico para hacerlo. Porque si no estás probando, realmente estás adivinando. Y el desarrollo impulsado por la experimentación es más fácil de lo que piensas. Hay muchas herramientas por ahí que hacen esto realmente, realmente fácil. Y realmente debería añadir cero esfuerzo adicional y cero tiempo adicional a cómo estás enviando y construyendo productos hoy. Bueno, eso es todo el tiempo que tenemos. Muchas gracias por escuchar. Si tienes alguna pregunta, no dudes en comunicarte. Mi información está ahí. Muchas gracias.