Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
En muchas organizaciones de producto, el backlog se ha convertido en un basurero ordenado.
¿Llega una idea? Backlog.
¿Una petición de cliente? Backlog.
¿Un bug no urgente? Backlog.
¿Una pista de discovery? Backlog.
¿Una intuición del Product Manager? Backlog.
¿Una frase escuchada en una reunión comercial? Backlog.
Se guarda todo "para no olvidar". Y unos meses después, tenemos 300, 500, a veces 1.000 líneas que ya nadie entiende de verdad.
Eso no es transparencia.
Es ruido.
Un backlog que lo contiene todo no clarifica nada. Solo da la ilusión de que la información existe en algún lugar, cuando en realidad se ha vuelto inutilizable.
El backlog no debería ser un depósito de ideas. No debería ser una base de peticiones de clientes. No debería ser una herramienta de discovery. No debería ser un archivo. No debería ser el cementerio de los bugs que no hemos querido resolver.
Un backlog es una herramienta de acción.
Sirve para organizar información ya suficientemente madura como para que varias personas puedan trabajar juntas.
La transparencia no consiste en mostrarlo todo
El argumento clásico para poner todo en el backlog es el de la transparencia.
"Al menos, todo es visible."
En teoría, suena bien. En la práctica, suele ser falso.
Un backlog de 500 líneas no es transparente. Es opaco. Nadie sabe realmente qué importa. Nadie sabe qué sigue siendo válido. Nadie sabe qué es estratégico, qué es antiguo, qué está rechazado, qué es solo una idea, qué viene de un cliente importante, qué ya se ha rediscutido tres veces.
Todo es visible, así que ya nada es legible.
La transparencia útil no consiste en exponer todo. Consiste en hacer comprensibles las decisiones.
¿Por qué está este tema en la roadmap?
¿Por qué ese otro no está?
¿Por qué se resuelve este bug ahora?
¿Por qué esta petición de cliente sigue siendo una señal pero no se convierte en trabajo?
¿Por qué se rechazó este tema?
Una idea inmadura puede quedarse fuera del backlog sin estar oculta. Simplemente no está lista todavía para convertirse en un objeto colectivo.
Hay que distinguir los espacios:
- una memoria de producto;
- una base de señales;
- notas de reflexión;
- decisiones;
- rechazos;
- un backlog.
No todo tiene que convertirse en backlog.
Antes del backlog: el espacio personal del Product Manager
Antes de que un tema entre en el backlog, puede existir en otro lugar.
Y ese otro lugar no necesita estar estandarizado.
Un Product Manager puede trabajar en Obsidian. Otro en Apple Notes. Otro en Trello. Otro en un cuaderno. Otro en una base más estructurada. El nombre no importa demasiado: jardín del PM, sala de espera, parking, notas personales, lo que sea.
Mientras el trabajo es individual, cada uno puede usar la herramienta que mejor le funciona.
De hecho, es preferible.
El espacio personal del PM sirve para absorber la tormenta de ideas. Se recoge, se conecta, se profundiza, se deja reposar, se elimina. Algunas ideas madurarán. Otras desaparecerán. Muchas nunca merecerán ser vistas por nadie más.
Es normal.
Una idea de tres líneas guardada "para no olvidar" no tiene lugar en una herramienta colectiva. No está lista todavía para movilizar la atención de un desarrollador, un diseñador, un data analyst, un sales o un directivo.
Mientras una idea sigue siendo un pensamiento individual, no necesita una herramienta colectiva.
El backlog empieza cuando el tema se vuelve colaborativo
La regla de entrada real es simple:
El backlog empieza cuando el tema deja de ser un pensamiento individual y se convierte en trabajo colectivo.
Si el Product Manager sigue trabajando solo, todavía no es backlog.
Si el tema requiere un estudio de viabilidad, hay que hablar con los desarrolladores. Ahí el backlog puede volverse útil.
Si el tema se basa en una hipótesis de uso o de valor, quizás hay que explorar los datos de producto con un data analyst. Ahí el backlog puede volverse útil.
Si el tema requiere diseño de interfaz, hay que trabajar con el equipo de diseño. Ahí el backlog puede volverse útil.
Si el tema viene del soporte, quizás hay que reunir a soporte, producto, data y desarrollo. Ahí el backlog puede volverse útil.
Pero entrar en el backlog no significa depositar tres líneas y pedirle a los demás que se las arreglen.
El Product Manager debe extraer un mínimo de lo que tiene en mente:
- por qué se mira este tema;
- qué público objetivo está implicado;
- qué dolor u oportunidad se persigue;
- qué valor se espera;
- qué pregunta debe resolverse;
- qué señales existen ya;
- qué colaboración es necesaria.
No es una checklist burocrática. Es el mínimo para permitir que otras personas trabajen contigo.
Una petición del tipo "hazme un análisis de datos sobre este tema" no basta. Una petición del tipo "mira si vale la pena" tampoco.
El backlog debe permitir una colaboración estructurada. No debe delegar un pensamiento todavía difuso.
El backlog no reemplaza la conversación
Hay una trampa inversa: querer formalizarlo todo.
Crear templates por todas partes. Añadir campos. Imponer checklists. Convertir cada ticket en un mini-dosier. Escribir para cubrirse las espaldas en lugar de escribir para trabajar.
No es mejor.
El nivel de detalle necesario depende del equipo, del tema y del contexto compartido.
Cuando un Product Manager lleva tres años trabajando con el mismo desarrollador, no siempre necesita escribir tanto como cuando el desarrollador acaba de llegar hace tres meses.
Cuando el equipo habla todos los días, algunas cosas pueden quedarse en lo oral.
Cuando el equipo es nuevo, está distribuido o trabaja en un tema de riesgo, hay que explicitar más.
Los conceptos de Definition of Ready y Definition of Done pueden ayudar. Dan referencias. Pero deben mantenerse vivos. No deben convertirse en una burocracia que reemplace el juicio.
Un desarrollador no debe aceptar un ticket que no entiende.
Si faltan elementos para evaluar la viabilidad, debe pedirlos.
Si falta el contexto de negocio, debe pedirlo.
Si no entiende el valor, debe decirlo.
Una user story nunca fue creada para reemplazar la conversación. Sirve para desencadenarla.
El backlog debe pensarse de la misma manera.
Estructura la conversación. No la reemplaza.
Un backlog debe ser limitado
Un backlog ilimitado es contradictorio con una roadmap limitada.
Si la roadmap NNL supuestamente protege a la empresa de la dispersión, el backlog no puede absorber todo lo que la roadmap rechaza.
En una roadmap Now / Next / Later, el Now depende de la capacidad real del equipo. El Next debe permanecer limitado. Incluso el Later, que se supone representa el campo de lo posible, no puede contener cincuenta direcciones distintas. Si no, vuelve a ser un inventario.
El backlog debe prolongar esa restricción.
No sirve de nada tener una roadmap clara y un backlog que contiene todo lo demás.
La misma lógica aplica a los bugs.
Si se aplica una política de cero bugs, un defecto real debe resolverse. Si no es un defecto, puede requalificarse. Si el tema no merece ser resuelto, se asume y se descarta.
Pero acumular bugs en el backlog para más tarde es barrer la suciedad bajo la alfombra.
Creemos que preservamos información. En realidad, conservamos una decisión que no se tomó.
Un backlog limitado protege la capacidad del equipo. También protege la energía mental. Una lista infinita crea una tensión permanente: todo lo que no se ha hecho, todo lo que quizás se hará, todo lo que se guarda por si acaso, todo lo que espera sin razón clara.
No es neutro.
Un backlog que crece cansa.
Si añado esto, ¿qué elimino?
La regla de higiene debería ser simple:
Si añado esto, ¿qué elimino?
Elegir es renunciar.
Añadir sin quitar equivale a negar la capacidad real del equipo. Es actuar como si el tiempo, la atención del producto, la disponibilidad de los desarrolladores, la capacidad de diseño, el análisis de datos y la carga del soporte fueran extensibles.
No lo son.
Un tema puede salir del backlog por varias razones:
- el mundo ha cambiado;
- el negocio ha cambiado;
- la estrategia de producto ha cambiado;
- el conocimiento de producto ha avanzado;
- el tema ya no es pertinente;
- el tema es demasiado débil;
- el tema está fuera de la roadmap;
- el tema nunca maduró.
Hay que poder descartar.
El backlog no debe proteger las viejas ideas de la eliminación. Debe proteger la capacidad del equipo para actuar sobre los temas correctos.
Los tickets viejos se pudren
Se subestima el envejecimiento de los tickets.
Una idea creada hoy y releída seis meses después no es necesariamente un buen recuerdo. A menudo está caducada.
El producto ha cambiado. Los clientes han cambiado. El mercado ha cambiado. Las prioridades han cambiado. El equipo ha aprendido. La técnica ha evolucionado. La IA quizás ha hecho posible lo que no lo era, o ha vuelto inútil lo que parecía importante.
Retomar un ticket viejo puede ser peor que empezar de cero.
El peligro también viene de la aversión a la pérdida. Como el ticket existe, queremos preservarlo. Como alguien escribió algo, dudamos en descartarlo. Como una petición fue capturada, queremos darle una oportunidad.
Pero un ticket no es un activo por el hecho de existir.
Un ticket viejo no es necesariamente un recuerdo. A menudo es una hipótesis podrida.
Si el tema vuelve a resultar interesante, podemos reabrirlo limpiamente. Pero hay que reevaluarlo en el contexto actual, no retomar mecánicamente una formulación antigua.
Un solo backlog para romper los silos
No creo en los backlogs separados por tipo de trabajo.
Un backlog de producto.
Un backlog técnico.
Un backlog de bugs.
Un backlog de soporte.
Un backlog de discovery.
En un mismo equipo, esa fragmentación rompe la priorización.
Claro que si varios equipos trabajan en ámbitos distintos, pueden tener varios backlogs o varias vistas. Pero en un espacio de priorización dado, hace falta un backlog único.
¿Por qué?
Porque no se priorizan categorías. Se priorizan dolores, riesgos y valor.
Un tema procedente del soporte puede requerir soporte, un data analyst y un desarrollador.
Un tema de producto puede requerir producto y diseño, sin gran implicación técnica.
Un tema de exportación puede no requerir diseño, pero sí un fuerte conocimiento de negocio y una validación técnica sobre tratamientos de datos.
El razonamiento correcto no es: "¿en qué backlog va este tema?"
El razonamiento correcto es: "¿qué problema estamos abordando, y qué personas necesitamos?"
También por eso la distinción bug / feature suele ser demasiado pobre. El cliente siente un dolor. No se pregunta si pertenece al backlog de bugs, al de producto o al técnico.
La pregunta es: ¿qué dolor es prioritario respecto a la estrategia, los clientes y la capacidad real?
Una petición de cliente no es un item de backlog
Capturar una petición de cliente es importante.
Pero una petición de cliente no es un item de backlog.
Es una señal.
Los clientes suelen ser muy buenos explicando sus problemas. Saben describir un dolor, una restricción, un contexto, una frustración, una obligación de negocio.
Son mucho menos fiables a la hora de proponer la solución correcta.
Hay que tomar la petición como material de aprendizaje, no como una instrucción de ejecución.
Una petición de cliente puede alimentar el backlog. Pero no es automático.
Puede quedarse en una base de señales.
Puede conectarse con otras peticiones.
Puede surgir más adelante.
Puede no surgir nunca.
Puede no corresponder a la estrategia de producto.
Puede no encajar en la roadmap.
Puede referirse a un caso demasiado aislado.
Puede ser interesante, pero no lo suficientemente importante.
El backlog no debe absorber todas las peticiones de clientes con el pretexto de no perderlas.
Una petición de cliente es material de aprendizaje, no una instrucción de ejecución.
Registrar ciertos rechazos sin recrear un backlog oculto
¿Hay que registrar los rechazos?
A veces, sí.
Pero registrar un rechazo no significa mantener un tema pendiente.
Algunos rechazos merecen una traza porque crean conocimiento histórico. Hoy rechazamos por una razón determinada: coste, estrategia, viabilidad, falta de competencia, baja demanda, mal momento.
Un año después, la decisión puede cambiar.
El negocio puede haber evolucionado.
La posición de producto puede haber cambiado.
La IA puede hacer viable lo que antes era demasiado costoso.
El equipo puede haber contratado un data analyst.
La viabilidad técnica puede haber evolucionado.
En esos casos, es útil entender por qué el tema había sido rechazado.
Pero no todos los rechazos merecen una traza. Muchas ideas débiles pueden simplemente desaparecer.
Si el rechazo es estructurante, recurrente o transversal, puede incluso convertirse en un PDR. Se documenta entonces la decisión, su contexto, sus alternativas y las condiciones que podrían hacerla evolucionar.
La traza del rechazo debe servir a la memoria. No debe recrear un backlog oculto.
En la era de la IA, el backlog ya no es el lugar donde se piensa
El punto más importante hoy es quizás este: el backlog ya no es el lugar adecuado para pensar el producto.
Herramientas como Jira, Notion o sus equivalentes siguen siendo a menudo herramientas de tarjetas. Procesadores de texto mejorados. Espacios donde se organizan items, estados, campos, comentarios.
Pueden ser útiles para coordinar la acción.
Pero son muy débiles para construir una reflexión de producto.
Los agentes de IA integrados en estas herramientas a veces mejoran un texto, reformulan un ticket, proponen un resumen. Es útil en el margen. Pero no es un sistema de pensamiento.
El activo real está aguas arriba.
Un contexto de producto rico puede contener:
- fuentes;
- entrevistas transcritas;
- notas atómicas;
- notas temáticas;
- glosarios;
- decisiones;
- PDR;
- normas;
- datos de producto;
- consultas SQL;
- análisis;
- señales de clientes;
- vínculos entre features existentes y features ausentes.
Con la IA, ese contexto se vuelve consultable.
Se pueden pedir los puntos ciegos.
Comparar opciones.
Conectar entrevistas.
Identificar recurrencias.
Generar una consulta SQL para verificar un comportamiento en los datos.
Transformar una entrevista en temáticas.
Conectar un dolor de cliente con features existentes o ausentes.
Construir un ticket solo al final.
En esta lógica, Jira o Notion se convierten en cadenas de salida. Se empuja información allí cuando está lista para ser trabajada colectivamente.
El ticket ya no es el lugar donde se piensa.
Es el lugar donde se empuja el resultado de un pensamiento ya estructurado.
El backlog de discovery es un contenedor inadecuado
El "backlog de discovery" se convierte entonces en un concepto problemático.
La discovery maneja señales ricas. Requiere comparar, conectar, analizar, cruzar, reformular, sintetizar.
Una entrevista de cliente no debería terminar directamente como una tarjeta.
Puede ser transcrita. Dividida en temas. Conectada con los dolores. Conectada con los desafíos del cliente. Conectada con los desafíos del producto. Conectada con las features existentes. Conectada con las features ausentes. Cruzada con otras entrevistas. Verificada en los datos de producto.
Un backlog no sabe hacer bien eso.
Una lista de tarjetas es demasiado pobre para sostener ese trabajo.
La discovery necesita un cerebro.
El backlog no es más que una herramienta de acción.
Algunos resultados de discovery pueden obviamente terminar en el backlog. Pero solo cuando están suficientemente maduros para una colaboración estructurada.
El backlog no debe ser el lugar donde la discovery se piensa.
El backlog es desechable
Por último, hay que aceptar una idea incómoda: el backlog es desechable.
Un item de backlog sirve hasta la entrega.
Después, pierde gran parte de su valor.
Los tickets se desincronizan. Las specs se desincronizan. Los arbitrajes cambian durante la realización. El comportamiento final en producción suele diferir de lo que se había escrito al principio.
La única realidad duradera es lo que se entrega.
El código fuente.
El comportamiento del producto.
La documentación mantenida desde esa realidad.
Eso no significa que el backlog no sirva para nada. Sirve para coordinar. Sirve para hacer trabajar a varias personas juntas. Sirve para pasar de una intención a una acción.
Pero no hay que tratarlo como un archivo sagrado.
Hay que invertir en él el mínimo de tiempo útil.
Lo suficiente para colaborar.
Lo suficiente para actuar.
No tanto como para producir una documentación que se pudrirá.
El backlog no es una fuente de verdad. Es un soporte temporal de coordinación.
Conclusión
Un buen backlog no contiene todo lo que la empresa podría hacer.
Contiene aquello en lo que está lista para trabajar juntos.
Lo que es inmaduro se queda fuera del backlog.
Lo que es señal sigue siendo señal.
Lo que está rechazado puede a veces registrarse, pero en otro lugar.
Lo que pertenece a la discovery se trabaja en un sistema de contexto.
Lo que es un bug real debe tratarse, no almacenarse.
Lo que entra en el backlog debe poder avanzar hacia la acción.
En la era de la IA, esta distinción se vuelve aún más importante. El Product Manager puede construir un contexto mucho más rico aguas arriba: fuentes, entrevistas, notas, glosarios, decisiones, análisis, datos, sparring partner de IA.
El backlog sigue siendo útil.
Pero debe quedarse en su lugar.
No es el cerebro del producto.
No es la memoria completa de la empresa.
No es un depósito de ideas.
Es una herramienta de acción.
Para saber más
Cero bugs: dejemos de gestionar inventarios de defectos Roadmap NNL: alinear sin dispersar Por qué las organizaciones prefieren las decisiones blandas