Prioriza tu backlog de CRO

¿Qué es un backlog?

Backlog de producto

En Scrum Guides definen el backlog de producto como un "listado ordenado de todas las tareas conocidas que se necesitarán en un producto".

Backlog del sprint

El backlog del sprint es definido en Scrum Guides como "un conjunto de tareas seleccionadas para el sprint, acompañadas de un plan para entregar el incremento del producto y cumplir el objetivo del sprint. El backlog del sprint es una estimación efectuada por parte del equipo de desarrollo sobre qué funcionalidad se entregará en el próximo incremento y el trabajo necesario para entregar esa funcionalidad".

Por cierto, al que le interese conocer más sobre metodologías ágiles, le invito a conocer al equipo de Drive to Improve, profesionales de alto nivel especializados en este tipo de temas y con los que he tenido la suerte de trabajar varios años en Softonic.

El backlog de CRO

De igual manera que cuando hablamos de desarrollo de producto enmarcado en metodologías ágiles tiene sentido diferenciar claramente entre el backlog de producto y el backlog del sprint, cuando hablamos de estrategias de mejora de la conversión, es necesario diferenciar entre nuestro roadmap de conversión y nuestro backlog de conversión.

El roadmap de CRO

Podríamos decir que el roadmap de CRO es el equivalmente al backlog de producto, es decir, un listado ordenado de todas las hipótesis orientadas a la mejora de la conversión que se quieren validar durante el proyecto.

Digamos que el roadmap es la hoja de ruta del proyecto de mejora de la conversión, con un enfoque más estratégico y de largo plazo, que se centra en las diferentes áreas de actuación y su ejecución en el tiempo.

El backlog de CRO

Por su parte, el backlog de CRO equivaldría al sprint backlog.

Lo podríamos definir como un conjunto de hipótesis seleccionadas para el sprint, acompañadas de un plan para validarlas y cumplir el objetivo del sprint.

Igual que en el bakclog del sprint, el backlog de CRO también ha de incluir una estimación por parte del equipo sobre qué hipótesis se validarán durante el sprint y el trabajo necesario para validar esas hipótesis.

A diferencia del roadmap, el backlog de CRO contiene acciones de mejora de la conversión específicas, con un enfoque más táctico y de corto plazo, centradas en las diferentes acciones que se están ejecutando en el momento presente y/o en la próxima iteración.

Merece la pena destacar dos cuestiones en relación al backlog.

👉 El backlog contiene un conjunto de hipótesis a testear

Una hipótesis es "una conjetura científica que requiere una contrastación con la experiencia".

La hipótesis es un enunciado no verificado que una vez refutado o confirmado dejará de ser hipótesis para convertirse en un enunciado verificado.

Destacamos la idea de las hipótesis y recogemos la definición por varios motivos:

• porque que un backlog de CRO se componga de hipótesis, que a su vez están definidas como conjeturas científicas, nos debería recordar que cuando hacemos CRO estamos jugando en el ámbito de la ciencia, no de la opinática
• porque pone de manifiesto por qué metdologías como el A/B testing y la experimentacón son tan relevantes en un programa de conversión, puesto que una hipótesis, para dejar de ser hipótesis y convertirse en un enunciado verificado, tiene que pasar por un proceso de contrastación con la experiencia
• y porque, siendo el elemento fundamental del backlog, la correcta definición de las hipótesis determinará en buena medida el éxito de nuestros esfuerzos de optimización

Tira publicada en la web de Scott Adams

👉 Las hipótesis están priorizadas por su valor de negocio potencial

Otro elemento que debería caer por su propio peso es el hecho de que las hipótesis que contenga nuestro backlog de optimización deberían estar priorizadas por su potencial impacto en el negocio.

Y si la correcta definición de las hipótesis que se van a testear es crítica, la priorización de las mismas no se queda atrás.

Es importante centrarse en las hipótesis que, en el caso de ser verificadas, vayan a generar más rentabilidad de negocio.

Priorizar no es fácil y puede llegar a consumir mucho tiempo.

De ahí que necesitemos de un modelo que nos permita evaluar de manera sistemática y para cada hipótesis, su potencial, importancia y coste de validación.

¿Cuál es el propósito del backlog de CRO y por qué es importante?

Si bien es cierto que el backlog es una herramienta importante para todas las personas que tengan interés en el producto o proyecto al que hace referencia, en el caso del product owner/manager (aka el responsable del producto) pasa a ser una herramienta de gestión y comunicación crítica.

🔂 El backlog de CRO es clave en la gestión de todo el workflow de optimización

Trabajar en un proyecto de conversión implica estar alineado con buena parte de la organización. Y ejecutar el backlog requiere de la colaboración de múltiples perfiles profesionales (desarrolladores e ingenieros, diseñadores, coppywritters, negocio, operaciones, datos...).

Un proyecto de este tipo implica la movilización de una cantidad significativa de recursos de la empresa, lo que automáticamente genera una dinámica y una carga de tareas relevante.

En este sentido el backlog se erige como una herramienta clave para la gestión eficiente de todo el flujo de trabajo.

💬 El backlog de optimización facilita y mejora la comunicación con todos los stakeholders

La comunicación es otro de los elementos clave para el éxito de cualquier proyecto de conversión.

Cuantos más recursos se inviertan en el proyecto más se incrementará el flujo de comunicación necesario para utilizar esos recursos de la manera más eficiente posible.

El backlog de CRO es "the place to go" para conocer el estado del proyecto, disponiendo todos los stakeholders de la misma información, en el mismo lugar y en tiempo real.

Además, un backlog de CRO bien trabajado y priorizado facilita mucho la discusión con el equipo, lo que a su vez se traduce en eficiencia y mejora de la productividad.

🔮 Un backlog de conversión bien trabajado nos ayuda a hacer estimaciones más precisas

Una parte importante en la comunicación con el equipo se dedica a tareas de planificación y estimación.

El backlog constituye el mejor punto de partida para que el equipo inicie esas discusiones.

Cuanto más actualizado y mejor organizado esté el backlog, más credibilidad tendrá entre los integrantes del equipo, todos estarán mejor alineados en torno a las prioridades y las conversaciones serán más productivas.

¿Cómo priorizar el backlog de conversión?

Template en Google Sheets para priorizar el backlog de conversión

Introducción al PIE Framework

En el artículo en el que comentamos los elementos esenciales a considerar en un proyecto de CRO ya introdujimos brevemente el framework PIE, del equipo de Wider Funnel, como un enfoque muy útil de cara a priorizar las hipótesis de nuestro backlog.

Vamos a detallar aquí en los detalles sobre el modelo y en cómo podemos aplicarlo en nuestro proyecto.

📈 ¿Cómo evaluar el Potencial de una hipótesis?

El potencial de una hipótesis está relacionado con el margen de mejora que tienen las páginas o secciones de la web donde la hipótesis va a ser validada.

En líneas generales se puede afirmar que cuanto peor sean el diseño y/o la usabilidad de una página, mayor será el potencial de mejora, y mayor será el potential score de la hipótesis.

Para asingar un scoring a cada hipótesis tendremos que analizar en detalle datos: datos de nuestra herramienta de analítica web, datos de nuestra base de datos de clientes...

Es importante también complementar estas fuentes de datos con un análisis heurístico de nuestra web efectuado por alguien con experiencia en proyectos de conversión.

🔝 ¿Cómo evaluar la Importancia de una hipótesis?

La importancia de una hipótesis está relacionada con el valor del tráfico que recibe esa página.

Y el valor del tráfico puede entenderse rápidamente, por ejemplo, analizando el % de tráfico total que la visita o el coste que nos supone la adquisición de ese tráfico.

Una página puede tener un margen de mejora espectacular, pero es clave entender cuál es la importancia de la página, entendida como

💰 ¿Cómo evaluar la sencillez (o el coste) de implementación para validar una hipótesis?

Es muy interesante la propuesta del PIE framework, porque contempla no sólo la evaluación el coste técnico de la ejecución del experimento, sino las barreras organizacionales o políticas del mismo.

Coste técnico

Llegar a un consenso sobre cómo evaluar técnicamente el coste de ejecutar una hipótesis es relativamente sencillo.

El scoring podría salir de una simple discusión del equipo encargado de la ejecución, pues el valor relativo de cada prueba podría obtenerse fácilmente a la hora de situar, en una escala del 1 al 10, cada una de las hipótesis a validar en función de su sencillez.

Se podría sistematizar un poco más la estimación del coste técnico, desgranando y ponderando el coste de cada una de las actividades necesarias para sacar adelante la validación de cada hipótesis.

Si para validar una hipótesis se necesita que el equipo de contenidos produzca los textos, que el diseñador produzca imágenes y que el equipo de desarrollo implemente el código necesario en la web, podemos asignar distintos valores a cada uno de estos recursos, adaptándolos a nuestra propia realidad y contexto.

Split y ponderación de los costes técnicos de validar una hipótesis

Coste político

Son muchas las barreras políticas que podemos encontrarnos a la hora de trabajar sobre una página o conjunto de páginas en particular.

Como regla de tres simple podemos afirmar que cuantos más stakeholders tengan interés en esa página, más difícil será hacer cambios sobre la misma.

La velocidad es uno de los valores esenciales en un programa de CRO y saltar obstáculos no técnicos también tiene un coste en términos de tiempo.

Herramientas para gestionar el backlog de CRO

Hoy en día hay muchísima variedad de herramientas que podemos utilizar.

Como siempre, la más adecuada dependerá de tu propio contexto: presupuesto, tamaño del equipo, complejidad técnica del proyecto...

Sin entrar en demasiados detalles, comentamos breve opinión de algunas que utilizamos mucho.

Google Sheets

Si tuviera que elegir 1, sólo 1 herramienta para desarrollar TODAS mis funciones, seguramente elegiría las hojas de cálculo de Google.

Independientemente del tamaño de la empresa y de las características del proyecto de CRO a ejecutar, Google Sheets siempre es clave en algún punto del proceso.

Una herramienta de cálculo potente, integrada con todo el universo internet a base de APIs y conectores, colaborativa...

No puede faltar a la hora de definir y trabajar el backlog de conversión.

Y de cara a la priorización, quizás sea la herramienta más adecuada en la mayoría de casos.

Trello, de Atlassian

Trello es el hermano pequeño de Jira. De hecho, podría ser el hermano adoptado, porque Atlassian pagó en 2017 $425 millones por hacerse con el control Trello, una de las herramientas de gestión de proyectos más utilizadas del mundo.

Si Google Sheets es perfecta para priorizar, Trello lo es para gestionar el workflow de CRO.

Es una herramienta tremendamente sencilla en su uso y perfecta para colaborar con equipos multidisciplinares.

A la hora de comunicar el status del proyecto, cumple muy bien con su función.

Jira, de Atlassian

Jira es la herramienta de desarrollo que por lo general utilizan las empresas con un componente de software avanzado y equipos de desarrollo de cierta envergadura.

Una herramienta muy potente, muy flexible, totalmente integrada en el flujo de desarrollo del el equipo de ingeniería.

A no ser que coincidas de pleno con el perfil mencionado, es una opción que seguramente no te interese :)