Contestaré la pregunta, pero también afirmo que está redactada de manera demasiado restringida. Suponiendo que las pruebas A / B son aplicables al dominio, y la organización confía en las pruebas A / B, entonces debe A / B probar todo lo que se está desarrollando . Por lo tanto, la pregunta debería ser: ¿Cómo se construye una hoja de ruta del producto cuando se pueden utilizar las pruebas A / B?
¿Se pueden utilizar las pruebas A / B? Para ejecutar las pruebas A / B, se deben cumplir varios ingredientes necesarios. Estos se resumieron en http://exp-platform.com/expMicro…, y supongo que se cumplen.
Un par de supuestos críticos deberían ser válidos, que se indican en http://bit.ly/ExPScale:
- ¿Cuándo explotará la burbuja de ciencia de datos?
- Cómo entender los diferentes tipos de curtosis
- ¿Vale la pena aprender habilidades de análisis de datos después de tener 5 años de experiencia en la industria de TI?
- ¿Cuál de los siguientes cursos debería elegir, big data y Hadoop o data science? ¿Cuál de los cursos anteriores tiene más alcance en el futuro? Tengo 1,5 años de experiencia como desarrollador de Java.
- ¿Qué proyectos interesantes de análisis de datos se han completado utilizando herramientas de redes sociales?
- La Organización quiere tomar decisiones basadas en datos y ha formalizado el Criterio de evaluación general (OEC)
- Se pueden ejecutar experimentos controlados y sus resultados son confiables.
Si la organización apenas comienza a usar experimentos controlados en línea, entonces generar confianza en el sistema es mucho más crítico que la hoja de ruta. Concéntrese en las pruebas A / A y las pruebas A / B con efectos conocidos, como un experimento de desaceleración (http://bit.ly/expRulesOfThumb Rule # 4), y aprenda su impacto en las métricas, que es mucho más importante que establecer una hoja de ruta .
Finalmente, supondré que la organización tiene una plataforma de prueba A / B que es fácil de usar. Idealmente, está estrechamente integrado con los sistemas de implementación y configuración. Si es difícil o propenso a errores ejecutar experimentos controlados, entonces la organización encontrará razones para evitar ejecutarlos.
Entonces, dada la pregunta más amplia: ¿Cómo se construye una hoja de ruta del producto cuando se pueden utilizar las pruebas A / B?
Aquí hay algunas observaciones.
- El recurso limitante crítico es el desarrollo de características. Para que la organización de desarrollo diseñe, codifique y pruebe una idea (al nivel en el que se puede lanzar a producción) se necesitan recursos. Ejemplo: en 2010, Bing se integró con Facebook y Twitter (http://blogs.bing.com/search/201…, http://blogs.bing.com/search/201…) e hizo una apuesta audaz que las redes sociales Las señales serán útiles. El desarrollo de tales características a la escala requerida es una inversión de ingeniería masiva, probablemente de más de 100 personas años. Sin embargo, es difícil cortar esquinas ingiriendo señales parciales: para probar la idea, la característica tuvo que implementarse.
Un corolario de lo anterior es que si una idea es fácil de probar A / B, detenga los debates y simplemente ejecute la prueba.
Ejemplo: en 2013, Bing realizó una serie de experimentos sobre colores de fuente. La variante ganadora se muestra a la derecha a continuación, en comparación con el control de la izquierda.
- Las diferencias son tan sutiles que deben destacarse. Los tres cambios de color que se realizaron se muestran a continuación
- ¿El costo de hacer tal cambio? Trivial: todo lo que se necesita es cambiar varios colores en el archivo de hoja de estilo en cascada (CSS). Los resultados mostraron que los usuarios tuvieron más éxito al completar las tareas, mejoró su tiempo de éxito y la monetización mejoró con una suma de más de $ 10 millones anuales. Debido a que estos resultados sorprendentes generalmente se ven (con razón) con escepticismo, este experimento inicial se repitió con una muestra mucho más grande de 32 millones de usuarios, y los resultados se mantuvieron. En otro ejemplo en Bing, un cambio en el color de fondo del anuncio tuvo un impacto en los ingresos del 12% (más de $ 150 millones en ingresos anuales). Ver http://bit.ly/expRulesOfThumb para más detalles.
Douglas Bowman dejó Google porque sintió que probar 41 tonos de azul o decidir el ancho del borde no es un entorno en el que pueda operar (http://stopdesign.com/archive/20…), sino algunas de esas decisiones “minúsculas” puede valer decenas a cientos de millones de dólares (https://www.theguardian.com/tech…). Al mirar el ROI, el retorno en muchos casos no está correlacionado con la inversión.
2. Una organización ágil debería priorizar en función de los nuevos datos. Si un experimento tiene un gran éxito, tiene mucho sentido asignar más recursos para explorar variaciones.
Ejemplo: Greg Linden implementó las recomendaciones del carrito de compras en Amazon (http://glinden.blogspot.com/2006…). La idea, que inicialmente tenía una prioridad baja por parte de HiPPO (http://bitly.com/HIPPOExplained), mostró resultados increíblemente sólidos. Greg luego escribe: “No solo ganó, sino que la función ganó por un margen tan amplio que no tenerla en vivo le estaba costando a Amazon una parte notable de cambio. Con una nueva urgencia, se lanzaron recomendaciones de carrito de compras ”.
Por el contrario, fallar rápido es importante si hay pruebas sólidas de que algo es malo.
El problema difícil, por supuesto, es que rara vez está claro si la idea es mala, especialmente cuando se intentan nuevas direcciones. ¿Es la implementación? ¿Deberíamos iterar? Renunciar es difícil, especialmente después de una inversión significativa considerada estratégica.
Ejemplo: cuando Bing implementó características sociales y las pruebas A / B no mostraron valor, la pregunta era si necesitamos repetir más o “fallar rápido”. Dada la inversión masiva y la dirección estratégica, se necesitaron cientos de experimentos para darse cuenta de que esto Es poco probable que sea tan útil como se esperaba.
3. Probar una forma limitada de una idea puede proporcionar un valor significativo.
Colin McFarland ha dicho: “Diseñe como si tuviera razón, pruebe como si estuviera equivocado” (http://codevoyagers.com/2016/03/…).
Ejemplo: para implementar un cambio de UX que involucra JavaScript complicado, puede ahorrar recursos significativos para implementarlo y probarlo solo para un par de navegadores, dicen las versiones recientes de Edge y Chrome. Si la idea falla para un gran porcentaje de sus usuarios, y decide fallar rápidamente, guardó una gran cantidad de implementación y pruebas para todas las demás versiones del navegador.
4. Los usuarios finales son un recurso limitante, pero con un sistema diseñado correctamente de experimentos superpuestos (los usuarios están en múltiples experimentos), no es muy limitante. Consulte http://research.google.com/pubs/… y http://bit.ly/ExPScale.
Bing hoy ejecuta cientos de experimentos simultáneos en un día determinado. Es muy raro que los desarrolladores deban esperar para ejecutar un experimento. Solo cuando se detectan o se sospechan interacciones fuertes se secuencian los experimentos.
La priorización del desarrollo de funciones es, en última instancia, una cuestión de ROI: retorno de la inversión. Cuál es el costo de desarrollo y cuál es el rendimiento (mejoras al Criterio de evaluación general).
Alex compartió varias metodologías, como PIE e ICE en http://conversionxl.com/ab-testi…, y básicamente representan diferentes formas de estimar el ROI. El problema clave con todos los marcos que dependen del “rendimiento esperado” es que nuestra capacidad de predecir el valor es baja en muchos casos, especialmente con ideas novedosas.
Ejemplo: El experimento más exitoso en la historia de Bing valió más de $ 100 millones anuales (en ese momento, ahora más del doble), simplemente no recibió una prioridad alta y se retrasó 6 meses porque había ideas mejor clasificadas. Cuando finalmente se implementó (durante un fin de semana, lo que indica una inversión sorprendentemente baja), se dispararon múltiples alarmas el lunes por la mañana de que Bing estaba haciendo demasiado dinero y que algo estaba claramente mal 🙂
En http://bit.ly/ExPScale, compartimos el siguiente principio: Somos pobres para evaluar el valor de las ideas
Las características se crean porque los equipos creen que son útiles, pero en muchos dominios la mayoría de las ideas no logran mejorar las métricas clave. Solo un tercio de las ideas probadas en Microsoft mejoraron las métricas para las que fueron diseñadas. El éxito es aún más difícil de encontrar en dominios bien optimizados como Bing. Jim Manzi escribió que en Google, solo “aproximadamente el 10 por ciento de estos [experimentos controlados, estaban] conduciendo a cambios en el negocio”. Avinash Kaushik escribió en su manual de Experimentación y Pruebas que “80% del tiempo usted / nosotros estamos equivocados acerca de qué el cliente quiere “. Mike Moran escribió que Netflix considera que el 90% de lo que intentan es incorrecto. Regis Hadiaris de Quicken Loans escribió que “en los cinco años que llevo haciendo pruebas, estoy tan acertado al adivinar los resultados como un jugador de béisbol de las grandes ligas al golpear la pelota. Así es, ¡he estado haciendo esto durante 5 años, y solo puedo “adivinar” el resultado de una prueba aproximadamente el 33% del tiempo! ”. Dan McKinley en Etsy escribió “casi todo falla” y “ha sido humilde darse cuenta de lo raro que es para ellos [las características] tener éxito en el primer intento. Sospecho firmemente que esta experiencia es universal, pero no es universalmente reconocida o reconocida ”. Finalmente, Colin McFarland escribió en el libro Experiment! “No importa cuánto creas que es obvio, cuánta investigación has hecho o cuántos competidores lo están haciendo, a veces, con más frecuencia de lo que piensas, las ideas experimentales simplemente fallan”.
La clave para mejorar los éxitos (ya que es la suma de las mejoras de la OEC lo que importa) se puede lograr de dos maneras:
1. Mejorar las ideas que salen de la evaluación.
Si el costo de implementación es alto, puede revisar bocetos, maquetas y construir prototipos; puede realizar encuestas y hacer estudios de laboratorio de usabilidad; y puedes probar con datos históricos. Estos métodos de evaluación varían tanto en el costo para ejecutarlos como en el valor y la confiabilidad de la información obtenida a través de ellos. En Cómo medir cualquier cosa: encontrar el valor de los intangibles en los negocios, Doug Hubbard usó el término EVI, Valor esperado de la información, para definir el beneficio esperado obtenido al obtener información adicional. Un experimento controlado proporciona información muy cercana a la perfecta (hasta la incertidumbre del valor p y otros factores de diseño experimentales), pero puede ser más costoso que otros métodos de evaluación de nuevas ideas. Consulte http://bit.ly/ExPScale para obtener más detalles sobre el embudo de ideas.
2. Prueba más ideas. Thomas Edison dijo: “Para tener una gran idea, tener muchas de ellas”.
La capacidad de crear infraestructura que le permite probar más ideas rápidamente se conoce como capital iterativo, un término acuñado por Michael Schrage (http: //www.strategy-business.com…).
Para resumir, la pregunta inicial fue “¿Cómo se construye y mantiene una hoja de ruta de prueba A / B?” Si cree que todo debería ser probado A / B, la pregunta debería ser: “¿Cómo se construye una hoja de ruta de producto cuando A / ¿Se pueden utilizar las pruebas B? ”. La respuesta es bastante estándar: priorizar por ROI, pero darse cuenta de que estimar el retorno es realmente un proceso inexacto. Por lo tanto, asegúrese de aumentar el número de pruebas haciéndolas más baratas de ejecutar. En palabras de Mike Moran (https://www.amazon.com/Do-Wrong-…), “si tienes que besar muchas ranas para encontrar un príncipe, encuentra más ranas y bésalas más rápido y más rápido”.
