‍

Hoy en día, es prácticamente una norma que un equipo de producto organice el desarrollo de requerimientos y otras tareas dentro de un Product Backlog.

De hecho, una de las mayores responsabilidades del Product Owner radica en la gestión continua de este listado de tareas, que hay que definir, priorizar y estimar.

Esto tiene su justa razón: a medida que un equipo escala en su número de integrantes al igual que un producto escala en su número de usuarios, las interrelaciones entre distintas funcionalidades y complejidad creciente de nuevos proyectos va en ascenso. 🤯

Es necesario, entonces, crear sistemas que permitan gestionar esa complejidad y generar mayor claridad y eficiencia en los procesos de trabajo.

Pero, también es cierto, que el desarrollo de un producto no solo implica tareas de entrega. De funcionalidades que se desarrollan y lanzan al mercado.

Sino que también hay que resolver el continuo desafío de saber qué es lo que deberíamos construir.

El origen de toda nueva funcionalidad se encuentra muchas veces en un pedido de mejora, observación de la competencia o algún objetivo de negocio.

Por esta razón, todo Product Manager debe ser capaz de extraer los supuestos que yacen dentro de cada idea u oportunidad de producto y elaborar hipótesis que necesiten ser probadas para validar su idoneidad.

Esta compleja gestión, que involucra distintas técnicas de validación como la investigación, el prototipado y el desarrollo de experimentos, es rara vez gestionada con la misma rigurosidad con la que se desarrolla un Product Backlog en un Product Delivery.

He visto muchos equipos seguir la metodología Scrum para aplicar sus mejores prácticas y tener el mejor Product Backlog posible, que luego se encuentran con un desorden en las distintas tareas de validación que preceden las tareas de desarrollo.

No tienen un marco metodológico claro para afrontar las tareas de Discovery. En muchas ocasiones, hacen una combinación extraña de procesos que suelen omitir pasos importantes en proyectos de alta incertidumbre o cargar de procesos una iniciativa simple. 🙅🏼

En específico, creo que la ausencia de un “Discovery Backlog”, la contraparte del “Product Backlog” en el Discovery, aporta a la desorganización de los esfuerzos de investigación y validación de ideas.

Y, en mi opinión, es algo de lo que prácticamente nadie habla.

Por esta razón, en este artículo me gustaría desarrollar el objetivo de un Discovery Backlog y sus principales beneficios al ser integrado en un proceso de Discovery.

Comencemos por afrontar una verdad.

‍

Las ideas por validar también necesitar un enfoque metódico para su validación.

Durante el desarrollo de un producto, son varias las cosas que pueden salir mal:

• Lanzar y no alcanzar los objetivos que un busca.
• Avanzar con el desarrollo de una tarea sin un objetivo concreto.
• Cambiar prioridades en el medio de la ejecución de una tarea.

Y la lista puede continuar.

He notado en todo este tiempo que muchos equipos de desarrollo no tienen trazabilidad acerca de cuáles fueron las decisiones que se fueron tomando en el camino hasta llegar al requerimiento que está desarrollando.

Hay una pérdida de contexto enorme. 😵‍💫

La desconexión entre los objetivos y lo que se entrega muchas veces es sorprendente.

Y el Product Backlog, sinceramente no tiene nada que hacer frente a eso. Su propósito es hacer más eficiente el desarrollo del producto, independientemente de los resultados que obtenga el negocio y el mercado.

Entonces:

• ¿Cómo puedo conectar los objetivos de negocio con hipótesis a validar?
• ¿Cómo puedo llevar las iniciativas del Product Roadmap a la acción?
• ¿Cómo puedo organizar las distintas tareas de validación y experimentación?

Son preguntas que dejan un hueco libre.

Y, en mi opinión, este representa el lugar ideal para implementar un “Discovery Backlog”.

‍

Integrar un “Discovery Backlog” permite organizar y gestionar mejor la validación de distintas iniciativas y supuestos.

Al igual que uno cuenta con un Product Backlog para las tareas relacionadas con la entrega del producto (Delivery), uno puede contar con un Discovery Backlog orientado a la gestión de tareas de validación y descubrimiento (Discovery).

A menos que trabajemos en proyectos, los productos son de naturaleza iterativa. Se construyen a lo largo del tiempo. ♻️

Esto significa que el flujo de ideas por validar es constante, con independencia de los objetivos que se definan en cierto período de tiempo.

Por ende, siempre debemos estar validando hipótesis a partir de pequeños experimentos que demuestren la conveniencia de avanzar con el desarrollo de una idea.

El Product Discovery es, entonces, un proceso continuo al igual que el Delivery.

Este proceso continuo de validación se debe gestionar semana a semana, al igual que el desarrollo de un producto.

El Discovery Backlog toma como insumo dos tipos de tareas:

• Un supuesto (una idea sin fundamentos, que responde a un objetivo, problema u oportunidad).
• Una tarea de análisis (lo que lancemos a producción debe volver a Discovery como tarea de análisis para que se le haga el seguimiento necesario que determine si alcanzo los resultados deseados).

En este Backlog, los supuestos se transforman en hipótesis, y las hipótesis en experimentos que al ser validados, se transforman en certezas. En hallazgos o aprendizaje que se puede transformar en un requerimiento por desarrollar.

El objetivo de un Discovery Backlog es conectar la estrategia de una empresa y sus objetivos con las iniciativas por desarrollar. 💡

Y lo hace a través de la gestión de las distintas tareas de validación, para asegurarse de lo que se termine desarrollando sea algo que realmente tenga un impacto notable.

No es una tarea menor, para nada.

Y merece que sea llevada con el mismo nivel de rigurosidad que un Product Backlog, de manera continua y metódica.

‍

El desarrollo de producto se comprende en dos ciclos continuos de trabajo: transformar supuestos en certezas, y certezas en producto.

Gestionar un Discovery Backlog se trata de aprender, mientras que gestionar un Product Delivery se trata de crear valor. Ambas listas de tareas están fuertemente interrelacionadas.

Debemos aprender para crear valor. Y a partir de la creación de valor, aprendemos.

Es necesario que no se deje de lado la importancia de contar con un proceso de desarrollo de producto “punta a punta” que explique como evoluciona una idea hacia una funcionalidad.

De esta manera, estaremos lanzando al mercado funcionalidades que sean relevantes tanto para el negocio como para el usuario y que tengan una gran probabilidad de resonar entre tu base de usuarios. 🚀

Para lograr esto, se debe gestionar un Discovery de la misma manera y con la misma importancia con la que se gestiona un Delivery.

Lo cierto es que implementar un Discovery Backlog puede traer muchos beneficios en el corto plazo como:

• Se establece un marco de trabajo para la producción de aprendizaje valioso.
• Las ideas tienen un proceso adecuado de validación.
• Se conectan iniciativas estratégicas del Product Roadmap con accionables concretos.
• Se trabaja en base a objetivos y se fomenta la experimentación.

Obsesiónate con aprender constantemente de forma metódica y crear evidencia accionable en un contexto donde justamente la incertidumbre y complejidad predominan.

¡Éxitos con la implementación de tu Discovery Backlog! 👋🏼