Como sabrás el Lean Startup se basa en el aprendizaje validado, en lo importante que es partir de un producto mínimo viable y poco a poco ir iterando a una versión más completa, mejor adaptada y más friendly-user.
Esas iteraciones, desde un mvp a versiones superiores se hacen a través del aprendizaje validado, de las entrevistas y de los experimentos.
Para mejorar nuestro producto (que puede ser cualquier cosa) es muy importante que cada nueva funcionalidad, cada nueva actualización y cada iteración tenga un fundamento sólido.
Suena obvio asegurarse de que ese nuevo desarrollo o iteración del producto realmente aporta valor y los usuarios lo quieren o les agrada mucho la idea de ello. Pero la realidad es que es algo que no se suele hacer.
Muchas empresas y emprendedores suelen tener “las cosas muy claras” y por dónde se debe tirar, el roadmap, las iteraciones, todo muy preparadito. Y luego pasa lo que pasa…
Como decíamos una buena manera de asegurarse de que las nuevas implementaciones van a valer para algo es utilizar entrevistas con nuestros usuarios y nuestro target (lo cual veremos en otro post), analizar muy bien el sector y como no: realizar experimentos.
Un experimento es exactamente lo que te estás imaginando: suponer una hipótesis y hacer una prueba a ver qué pasa y si estabas en lo cierto o en el otro del muro.
Pero los experimentos hay que hacerlos con cuidado. El único motivo para aplicar un experimento es comprobar si nuestra hipótesis realmente mejoraría el producto.
En este caso vamos a plantearlo para la nueva web de Sopinet. Como sabréis hemos pasado por un potente rebranding. Hemos tirado al suelo el edificio y hemos construido uno mucho más amplio, más luminoso, moderno y muchisisisisisimo más bonito.
Pero claro, una vez tenemos la casa montada tenemos que ver realmente donde quedan mejor algunas cosas para facilitar la comodidad de nuestros visitantes.
Tipos de experimentos
Antes de continuar debemos dejar claro que hay varios tipos de experimentos, 2 concretamente:
- Test A/B
- Test multivariante
Básicamente se diferencian en que un test A/B existen únicamente 2 posibilidades: la “versión actual” y la versión con 1 única modificación.
Por ejemplo en Sopinet cuando entras en la home nos encontramos con esto:
Un experimento A/B que vamos a empezar a ejecutar dentro de poco es el comprobar si cambiando el tamaño del botón por uno más grande cambiaría realmente el CTR.
Otro experimento que haremos será cambiar el color a ver si llamando más la atención aumentamos el CTR.
En cambio un experimento multivariante sería realizar diferentes cambios a la web y luego ver cuales han funcionado mejor (esto es más difícil medirlo y además necesitas más tiempo y más tráfico, obviamente)
¿Y eso con qué se hace y cómo funciona?
Un buen ejemplo de herramienta (gratuita) a utilizar es Google Optimize. Digamos que es una herramienta muy sencilla que te permite aplicar un montón de cambios a tu web sin tener que introducir los cambios manualmente con códigos y variables. El programa se encarga de todo.
Su funcionamiento es sencillo, marcas un tiempo o volumen de impresiones de la página (cantidad de veces que se muestra) y algunas otras variables en función de tu interés.
Una vez todo preparado el experimento se pone en marcha.
La idea es que en un test A/B (y en el multivariante igual) se muestra cada versión a partes iguales del tráfico que recibe la web.
Volviendo al caso del botón en la home de Sopinet, si decidimos ponerlo de color rojo sopinetero, eso es un test A/B por lo cual el 50% del tráfico recibirá la versión con el botón normal que hay actualmente y el otro 50% verá el botón rojo.
Esto funcionará durante un tiempo determinado (o acumulando un número de impresiones determinadas) y finalmente el programa nos marcará los resultados. Nos darán porcentajes, tráfico y todo eso. Luego nosotros podremos tomar la decisión final de qué hacemos.
Esto está muy bien como te imaginarás porqué cada nueva implementación te podrás asegurar muy bien de si realmente va a tener impacto o no. También es cierto que se recomienda dar por válido un test con un resultado de un 80% de significación (y los más conservadores incluso hablan de un 98%). La idea es no tocar nada a no ser que estés muy seguroa.
Todo esto está genial pero tiene un factor clave muy importante a tener en cuenta. Solo puedes utilizar un test a la vez. Si empiezas a utilizar varios test a la vez, aunque sea en diferentes páginas nunca vas a saber a ciencia cierta cual es el que mejoró realmente el CTR y cual únicamente asistió. Por lo que es importante que vaya un test detrás de otro.
Y no sólo eso, sino que con los resultados de cada test replantear el siguiente, no ir haciendo test a lo loco sin fundamento. El objetivo es iterar hacia la mejor versión posible.
La idea es la siguiente, una vez tenemos nuestra web en marcha y funcionando viene la fase de testing. Le llamamos fase de testing al plantear los test que podríamos hacer ya que un proyecto sano vive en testing contínuo.
Por ello lo mejor es poner la página en un proyector o pantalla grande y hacer un brainstorming de ideas para testear, todo vale. “¿Y si la volvemos a hacer desde 0?” eso no es un test jejeje.
Finalmente tendremos un listado de tests que podríamos aplicar a la web. Pero probablemente esa lista sea larga, lo cual viene el siguiente problema: cómo los vamos a ordenar?
Pues bien, para ello tenemos algo llamado el índice ICE. Una metodología que nos puede ayudar a organizar los tests en base a unos parámetros relevantes para evitarnos el despilfarrar el tiempo y el dinero (¡básico en lean startup!)
El índice ICE
Gracias al índice ICE vamos a poder ordenar de manera prioritaria ese listado de experimentos, dando paso a los que sea más factible hacer al principio y retrasando aquellos que no tengan tanta prioridad.
El índice ICE realmente es el acrónimo de Impact, Confidence y Ease. Es decir:
- Impact: el impacto que puede tener este experimento sobre el total.
- Confidence: como estoy de seguro que este test verificará mi hipótesis.
- Ease: facilidad de ejecución.
La idea es puntuar del 1 al 10 (donde 1 es poco y 10 mucho) estos tres apartados para luego hacer una media simple. Luego empezar por los experimentos con mayor índice ICE.
Siguiendo el ejemplo de cambiar el color del botón a rojo sopinetero:
- Impact: 8
- Confidence: 9
- Ease: 8
→ Índice ICE: (8+9+8)/3 = 8,33.
Hemos pensado también en crear una mejora en la web, que es la de añadir un slider diciendo “¿Te llamamos? pidiendo datos que aparezca a los 3 minutos de sesión” pero no tenemos muy claro que pueda ser realmente relevante aunque a priori parece que si.
- Impact: 7
- Confidence: la verdad es que no lo tengo muy claro, aunque lo quiero probar: 5
- Ease: es un pequeño desarrollo que puede ser un rato de montar: 5
→ Índice ICE (7+5+5)/3 = 5,66
En este caso si tuviéramos que escoger entre estos dos test o experimentos empezaríamos por el primero ya que tiene un mayor índice ICE que el otro.
Los contras
Como pensarás este índice es bastante subjetivo. Realmente lo que puede ser fácil para unos puede resultar difícil para otros. O quizás ese impacto no es el que opina otra persona que pueda tener.
La respuesta es sí, tienes razón. Pero también es cierto que esta puntuación debe ser para la persona que realiza el test, en base a sus facultades, estrategia e información. Por lo que un mismo experimento puede tener múltiples puntuaciones en función de quién lo puntúe. Por este motivo es importante puntuar de manera conjunta los experimentos que conlleven el trabajo de más de una persona.
En Growth Hacking buscamos frameworks ágiles y rápidos que nos ayuden a iterar y aprender de manera cíclica y continuada. El índice ICE permite de manera rápida priorizar los experimentos y ponerlos en lista.
Y efectivamente, puede ser una metodología a la que probablemente le falten componentes pero este índice es suficientemente bueno como para poderlo aprovechar y empezar a trabajar de una manera ágil y veloz.
Deja un comentario