Presentamos el backlog del producto
Una vez tengas claros los resultados, el equipo podrá reunirse para generar ideas de productos que ayudarán a crearlos. El primer paso pragmático que puedes dar para lograrlo es adoptar un backlog del producto.
En nuestro trabajo, nos hemos dado cuenta de que muchos equipos de productos utilizan un solo backlog de Jira para recopilarlo todo: solicitudes de funciones, oportunidades grandes y pequeñas, tareas y subtareas, errores e incidencias urgentes, e ideas sobre el futuro del producto.
Todos nos contaban la misma historia. El backlog se descontrola porque la lista de tickets es cada vez más larga y se convierte en una fuente de ansiedad. Estos backlogs desorganizados y sobredimensionados no ayudan a establecer prioridades en ningún nivel, desde los cambios tácticos hasta las grandes inversiones nuevas.
Los equipos acabaron trasladando estos debates a hojas de cálculo, pero cada trimestre se encontraban con los mismos problemas. Los datos relevantes se perdían, las decisiones no se registraban y los recursos se asignaban con poco tiempo siguiendo el instinto o las opiniones más insistentes.
Pero hay una forma mejor de hacerlo: un backlog del producto diseñado en función de los resultados y distinto del backlog de entrega para el trabajo diario.
¿Qué es un backlog del producto?
Un backlog del producto es donde las ideas se crean, se priorizan y se comparten en hojas de ruta en relación con los resultados y los objetivos. Contiene todas las ideas, los datos relevantes, las oportunidades y las soluciones referentes al producto, y es propiedad del equipo de productos. Más que planificar la ejecución de tareas específicas, sirve para debatir sobre en qué se debe invertir y por qué. Se puede invitar a las partes interesadas de la empresa a participar en el backlog para que colaboren en las prioridades y las hojas de ruta y analicen el progreso general de las iniciativas del producto que hay en marcha.
El backlog del producto viene a ser el punto de encuentro para el equipo de productos, y se comparte con los colaboradores de toda la empresa. Es un espacio específico para todo lo que sea necesario supervisar (desde ideas vagas hasta oportunidades completas) y que permite ir ajustándolas a lo largo del tiempo en función de la información que obtienen, los comentarios de los clientes y los cambios en los objetivos generales.

Backlog del producto y backlog de entrega
El backlog del producto está separado del backlog de entrega, y cada uno tiene una finalidad específica.
El backlog de entrega es para gestionar las tareas de entrega, crear planes de entrega y hacer un seguimiento del progreso. Contiene el desglose del trabajo (epics, historias, tareas y subtareas) para cumplir con los compromisos y es propiedad del equipo de ingeniería. Es donde todo el equipo se reúne y colabora para tratar los problemas relacionados con la entrega: secuenciación, dependencias, capacidad e hitos técnicos.
Como resulta obvio, el backlog del producto y el backlog de entrega están estrechamente relacionados. El trabajo en el backlog de entrega conduce a ideas en el backlog del producto, que a su vez conducen a los resultados deseados. Esto ofrece a los responsables, gerentes y desarrolladores una visión global sobre el trabajo del equipo para obtener resultados a medida que avanzan por los ciclos de descubrimiento y entrega.
A diferencia del backlog del producto, todos los elementos del backlog de entrega son planes concretos que en algún momento se llevarán a cabo. Por el contrario, el backlog del producto sirve para idear y hacer lluvias de ideas, y también para planificar. Algunas ideas del producto nunca tendrán prioridad ni figurarán en las hojas de ruta, y esto no supone ningún problema.
Al separar las preocupaciones generales sobre el producto de la planificación y el seguimiento de las entregas, los equipos pueden establecer prioridades de forma más eficaz, conectar el trabajo con los resultados y evitar los backlogs descontrolados que intentan servir para todo y para todos.

Backlog del producto | Backlog de entrega | |
|---|---|---|
¿Para qué sirve? | ¿En qué debemos invertir y por qué? | ¿Cómo podemos conseguirlo? |
¿Qué incluye? | Ideas del producto, problemas de usuario, oportunidades, soluciones, hipótesis | El desglose del trabajo: epics, historias, tareas, subtareas y errores |
¿Quién es el propietario? | Gestores de productos | Propietarios de productos, responsables de equipos de ingeniería, gestores de proyectos o programas |
¿Quién participa? | El equipo principal del producto: Gestores de productos, ingenieros, diseñadores. Otros equipos de productos de la empresa: Equipos de atención al cliente (ventas, soporte, éxito de los clientes, ingeniería de soluciones, equipos de campo) Liderazgo Partes interesadas de la empresa | El equipo principal del producto: Gestores de productos, ingenieros, diseñadores. Liderazgo en ingeniería |
Se prioriza en función de... | Metas, valor de negocio Comentarios y opiniones de los clientes Datos y análisis de productos Viabilidad técnica | Dependencias Capacidad del equipo La urgencia operativa (p. ej. errores y problemas de fiabilidad) |
Ventajas de un backlog del producto
Utilizar backlogs separados para el producto y la entrega tiene muchas ventajas:
Es un espacio seguro para que el equipo de productos comente posibles ideas, junto con los datos disponibles, sin preocuparse de su viabilidad o definición.
Reúne las conversaciones sobre los productos en un solo lugar, de modo que los equipos pueden ir desarrollando conocimientos sin tener que buscar en decenas de hojas de cálculo.
Crea una fuente de información compartida y una idea común sobre las prioridades del producto. Esto resuelve un problema habitual al que se enfrentan los equipos de productos: la toma de decisiones basada en el instinto o en las opiniones de los clientes y las partes interesadas más insistentes.
Aporta transparencia a las conversaciones sobre las prioridades y reúnen a todos los miembros de la empresa en un espacio compartido. Esto elimina muchos problemas a la hora de colaborar con las partes interesadas y los equipos orientados al cliente.
Está relacionado con el trabajo de entrega, por lo que las hojas de ruta no quedan desfasadas y permanecen fieles a la realidad, ya que tienen en cuenta las restricciones de entrega.
Cómo organizar el backlog del producto
Ideas, oportunidades, problemas, soluciones: el equipo de productos tiene que decidir qué incluir en el backlog del producto. Debería ser lo que el equipo trata de priorizar y su pensamiento acerca de las inversiones y prioridades del producto.

Es muy importante que el equipo de productos controle lo que se añade al backlog del producto y la estructura utilizada para clasificar y priorizar las ideas. De lo contrario, se corre el riesgo de que el backlog se convierta en la fuente de desorganización que se intentaba evitar desde un principio.
Para controlar el backlog, debe invitarse a las partes interesadas externas a contribuir solo de maneras predefinidas en lugar de otorgarles privilegios directos de creación y edición de elementos. Por ejemplo, estos colaboradores pueden añadir comentarios, votar ideas o etiquetar al cliente que ha solicitado una función.

A continuación se muestran dos marcos recomendados para estructurar un backlog del producto: rocas, piedras y guijarros, y listas largas, medianas y cortas. Recomendamos organizar el backlog del producto en torno a estos tres cubos y estas actividades.
En Jira Product Discovery, esto se consigue configurando vistas específicas para mostrar las ideas correctas y eligiendo los campos visibles para fomentar el debate (selección, valoración) e invitar a la colaboración (ideas, votos, comentarios, reacciones).
Rocas, piedras y guijarros
Muchos equipos de productos solo tienen un tipo de objeto: las ideas. Pero el backlog puede contener elementos de diferentes formas, tamaños y niveles de detalle, desde grandes apuestas nuevas hasta pequeñas mejoras en los productos.
Una práctica habitual es estructurar el backlog en tres categorías de elementos:
Rocas: inversiones importantes, oportunidades estratégicas y grandes apuestas nuevas
Piedras: inversiones medianas, mejoras sustanciales en el producto que conducen a los resultados
Guijarros: pequeñas inversiones, como corregir errores de poca envergadura y problemas en la experiencia de usuario
Lo mejor es crear áreas separadas para cada categoría en el backlog del producto y pensar en equilibrar las inversiones entre las tres reservando presupuesto y espacio en la hoja de ruta para cada una de ellas. Los guijarros, en particular, son difíciles de priorizar sin este tipo de intencionalidad. Una apuesta nueva y grande es emocionante, pero los pequeños errores tienen un efecto negativo grave en la experiencia del usuario.
Encontrarás más información sobre este marco en la sección Ideas.


Lista larga, mediana y corta
Otra forma sencilla y práctica de estructurar un backlog del producto es la que propone Brent Johnston, uno de los primeros en adoptar Jira Product Discovery. Brent describió el trabajo con productos como estar manejando constantemente tres cubos: la lista larga, la mediana y la corta.
El equipo de productos recopila las ideas de las listas larga, mediana y corta del backlog del producto, e invita a las partes interesadas de toda la empresa a colaborar.

La lista larga lo incluye todo: ideas que quizá algún día se lleven a cabo, problemas, oportunidades o soluciones. Podría haber más de 200 ideas en esta lista.
El equipo de producto hace una selección en la lista larga a partir de sus conocimientos del mercado, las inquietudes estratégicas y operativas, y las necesidades de los clientes y la empresa para convertirla en una lista mediana.
La lista mediana es una preselección de las posibles prioridades: oportunidades atractivas en las que el equipo podría invertir. De una lista larga de 200 ideas, de 10 a 20 de ellas podrían incluirse en la lista mediana.
Estas son las ideas que parecen una buena apuesta porque son importantes desde el punto de vista estratégico, surgen con frecuencia en las conversaciones con los clientes o tienen un gran potencial para deleitar a los usuarios. Se les debe dar prioridad en una lista corta, normalmente con las opiniones de las diferentes partes interesadas de la empresa.
Para obtener más información, consulta Priorización.
La lista corta es básicamente la hoja de ruta del producto: incluye las ideas que el equipo de productos se ha comprometido a seguir explorando. Estas tareas ponen en práctica las oportunidades, los problemas o las soluciones para empezar a crear una experiencia de producto o mejorar una existente.
El equipo revisa esta lista con regularidad en función de la información obtenida y la mantiene actualizada. Esta es la lista que el resto de la empresa puede esperar que se actualice con más frecuencia.
Para obtener más información, consulta Crear hojas de ruta.

Cómo crear un backlog de producto en Jira Product Discovery
Creamos Jira Product Discovery como el lugar donde los equipos de productos pueden recopilar sus ideas, colaborar en ellas y priorizar. En Jira Product Discovery puedes crear uno o varios backlogs de producto, denominados "proyectos de descubrimiento".
Por lo general, es mejor incluir a las personas que trabajan juntas día a día en el mismo proyecto (por ejemplo, una división o varias). Sin embargo, bastantes clientes de Jira Product Discovery utilizan un solo proyecto para alojar varios equipos y productos. Esto es especialmente útil cuando se requiere un alto nivel de colaboración entre esos equipos.
Aquí tienes una demostración sobre cómo hacerlo:
Con el plan Premium de Jira Product Discovery, puedes visualizar las ideas de varios proyectos en un solo lugar, creando vistas que muestren las ideas de varios proyectos y cuenten la historia completa de los planes de productos de una organización.
¿Y ahora qué?
En lo que queda de este manual, explicaremos con detalle cómo utilizar el backlog del producto para hacer lo siguiente:
Lleva las ideas desde el inicio hasta la entrega
Crea canales de comentarios y recopila datos relevantes para validar las ideas
Priorizar las ideas que tendrán más repercusión
Crear hojas de ruta para que los equipos y las partes interesadas puedan respaldarlas.
Proporcionaremos ejemplos de cómo lo hacemos en el equipo de Jira Product Discovery mediante Jira Product Discovery y otros productos.