Em muitas empresas de produto, o backlog virou uma lixeira organizada.

Chegou uma ideia? Backlog.

Um pedido de cliente? Backlog.

Um bug sem urgência? Backlog.

Uma pista de discovery? Backlog.

Uma intuição do Product Manager? Backlog.

Uma frase ouvida numa reunião comercial? Backlog.

Você coloca tudo lá "para não esquecer". E alguns meses depois, acaba com 300, 500, às vezes 1.000 linhas que ninguém mais entende de verdade.

Isso não é transparência.

É ruído.

Um backlog que contém tudo não esclarece nada. Ele só passa a ilusão de que a informação existe em algum lugar, quando na verdade ela ficou inutilizável.

O backlog não deveria ser um depósito de ideias. Não deveria ser uma base de pedidos de clientes. Não deveria ser uma ferramenta de discovery. Não deveria ser um arquivo morto. Não deveria ser o cemitério dos bugs que ninguém quis tratar.

Um backlog é uma ferramenta de ação.

Ele serve para organizar uma informação já madura o bastante para que várias pessoas trabalhem juntas.

Transparência não é mostrar tudo

O argumento clássico para colocar tudo no backlog é o da transparência.

"Pelo menos tudo fica visível."

Na teoria, soa atraente. Na prática, quase sempre é falso.

Um backlog de 500 linhas não é transparente. Ele é opaco. Ninguém sabe direito o que importa. Ninguém sabe o que ainda é válido. Ninguém sabe o que é estratégico, o que é antigo, o que foi recusado, o que é só uma ideia, o que veio de um cliente importante, o que já foi rediscutido três vezes.

Tudo fica visível, então nada mais é legível.

A transparência que serve para algo não é expor tudo. É tornar as decisões compreensíveis.

Por que este assunto está no roadmap?

Por que aquele outro não está?

Por que este bug está sendo tratado agora?

Por que este pedido de cliente continua sendo um sinal, mas não vira trabalho?

Por que este assunto foi recusado?

Uma ideia imatura pode ficar fora do backlog sem ser escondida. Ela só ainda não está pronta para virar um objeto coletivo.

É preciso separar os espaços:

• uma memória de produto;
• uma base de sinais;
• notas de reflexão;
• decisões;
• recusas;
• um backlog.

Nem tudo precisa virar backlog.

Antes do backlog: o espaço pessoal do Product Manager

Antes de um assunto entrar no backlog, ele pode existir em outro lugar.

E esse outro lugar não precisa ser padronizado.

Um Product Manager pode trabalhar no Obsidian. Outro no Apple Notes. Outro no Trello. Outro num caderno. Outro numa base mais estruturada. O nome não importa muito: jardim do PM, antessala, estacionamento, notas pessoais, tanto faz.

Enquanto o trabalho continua individual, cada um pode usar a ferramenta que funciona para ele.

E isso é até melhor.

O espaço pessoal do PM serve para absorver a tempestade de ideias. Você coleta, conecta, investiga, deixa descansar, apaga. Algumas ideias vão amadurecer. Outras vão sumir. Muitas nunca merecem ser vistas por outra pessoa.

Isso é normal.

Uma ideia de três linhas jogada ali "para não esquecer" não tem lugar numa ferramenta coletiva. Ela ainda não está pronta para tomar a atenção de um desenvolvedor, de um designer, de um data analyst, de um sales ou de um C-level.

Enquanto uma ideia continua sendo um pensamento individual, ela não precisa de uma ferramenta coletiva.

O backlog começa quando o assunto vira colaborativo

A verdadeira regra de entrada é simples:

O backlog começa quando o assunto deixa de ser um pensamento individual e vira um trabalho coletivo.

Se o Product Manager continua investigando sozinho, ainda não é backlog.

Se o assunto exige um estudo de viabilidade, é preciso falar com os desenvolvedores. Aí o backlog pode virar algo útil.

Se o assunto se apoia numa hipótese de uso ou de valor, talvez seja preciso explorar os dados de produto com um data analyst. Aí o backlog pode virar algo útil.

Se o assunto exige um desenho de interface, é preciso trabalhar com o design. Aí o backlog pode virar algo útil.

Se o assunto vem do suporte, talvez seja preciso reunir suporte, produto, data e desenvolvimento. Aí o backlog pode virar algo útil.

Mas entrar no backlog não significa jogar três linhas e pedir para os outros se virarem.

O Product Manager precisa colocar para fora um mínimo do que tem na cabeça:

• por que estamos olhando para este assunto;
• qual público está envolvido;
• qual dor ou qual oportunidade está em jogo;
• qual valor se espera;
• qual pergunta precisa ser decidida;
• quais sinais já existem;
• qual colaboração é necessária.

Isso não é um checklist burocrático. É o mínimo para permitir que outras pessoas trabalhem com você.

Um pedido do tipo "me faz uma análise de dados sobre esse assunto" não basta. Um pedido do tipo "vê se vale a pena" também não basta.

O backlog precisa permitir uma colaboração estruturada. Ele não deve delegar um pensamento ainda vago.

O backlog não substitui a conversa

Existe uma armadilha inversa: querer formalizar tudo.

Criar templates em todo canto. Adicionar campos. Impor checklists. Transformar cada ticket num minidossiê. Escrever para se proteger em vez de escrever para trabalhar.

Isso não é melhor.

O nível de detalhe necessário depende do time, do assunto e do contexto compartilhado.

Quando um Product Manager trabalha há três anos com o mesmo desenvolvedor, ele nem sempre precisa escrever tanto quanto quando um desenvolvedor acabou de chegar há três meses.

Quando o time conversa todo dia, algumas coisas podem ficar no verbal.

Quando o time é novo, distribuído ou está num assunto arriscado, é preciso explicitar mais.

As noções de Definition of Ready e Definition of Done podem ajudar. Elas dão referências. Mas precisam continuar vivas. Não podem virar uma burocracia que substitui o julgamento.

Um desenvolvedor não deve aceitar um ticket que não entende.

Se faltam elementos para avaliar a viabilidade, ele deve pedi-los.

Se falta o contexto de negócio, ele deve pedir.

Se ele não entende o valor, ele deve dizer.

Uma user story nunca foi feita para substituir a conversa. Ela serve para provocá-la.

O backlog deve ser pensado da mesma forma.

Ele estrutura a conversa. Ele não a substitui.

Um backlog precisa ser limitado

Um backlog ilimitado é contraditório com um roadmap limitado.

Se o roadmap NNL deveria proteger a empresa da dispersão, o backlog não pode absorver tudo o que o roadmap recusa.

Num roadmap Now / Next / Later, o Now depende da capacidade real do time. O Next precisa continuar limitado. Até o Later, que em tese representa o campo do possível, não pode conter cinquenta direções diferentes. Senão, ele volta a ser um inventário.

O backlog deve prolongar essa restrição.

Não adianta ter um roadmap claro e um backlog que guarda todo o resto.

Mesma lógica para os bugs.

Se você aplica uma política de zero bug, um defeito real precisa ser tratado. Se não é um defeito, ele pode ser requalificado. Se o assunto não vale o esforço de tratar, você assume isso e descarta.

Mas acumular bugs no backlog para depois é varrer a poeira para debaixo do tapete.

Você acha que está preservando uma informação. Na verdade, está guardando uma decisão não tomada.

Um backlog limitado protege a capacidade do time. Ele também protege a energia mental. Uma lista infinita cria uma tensão permanente: tudo o que você não fez, tudo o que talvez você faça, tudo o que você guarda por via das dúvidas, tudo o que espera sem razão clara.

Isso não é neutro.

Um backlog que cresce cansa.

Se eu adiciono, o que eu tiro?

A regra de higiene deveria ser simples:

Se eu adiciono isso, o que eu tiro?

Escolher é abrir mão.

Adicionar sem tirar é negar a capacidade real do time. É agir como se o tempo, a atenção do produto, a disponibilidade dos desenvolvedores, a capacidade de design, a análise de data e a carga do suporte fossem elásticos.

Eles não são.

Um assunto pode sair do backlog por vários motivos:

• o mundo mudou;
• o negócio mudou;
• a estratégia de produto mudou;
• o conhecimento de produto avançou;
• o assunto não é mais relevante;
• o assunto é fraco demais;
• o assunto está fora do roadmap;
• o assunto nunca amadureceu.

É preciso poder descartar.

O backlog não deve proteger as ideias velhas contra a exclusão. Ele deve proteger a capacidade do time de agir sobre os assuntos certos.

Os tickets velhos apodrecem

A gente subestima o envelhecimento dos tickets.

Uma ideia criada hoje e relida seis meses depois não é necessariamente uma boa memória. Ela costuma estar vencida.

O produto mudou. Os clientes mudaram. O mercado mudou. As prioridades mudaram. O time aprendeu. A técnica evoluiu. A IA talvez tenha tornado possível o que não era, ou tornado inútil o que parecia importante.

Retomar um ticket velho pode ser pior do que começar do zero.

O perigo vem também da aversão à perda. Como o ticket existe, você quer preservá-lo. Como alguém escreveu alguma coisa, você hesita em descartar. Como um pedido foi capturado, você quer dar uma chance a ele.

Mas um ticket não é um ativo só porque existe.

Um ticket velho não é necessariamente uma memória. Muitas vezes é uma hipótese mofada.

Se o assunto voltar a ser interessante, você pode reabri-lo direito. Mas é preciso reavaliá-lo no contexto atual, não retomar mecanicamente uma formulação antiga.

Um único backlog para quebrar os silos

Eu não acredito em backlogs separados por natureza de trabalho.

Um backlog de produto.

Um backlog técnico.

Um backlog de bugs.

Um backlog de suporte.

Um backlog de discovery.

Dentro de um mesmo time, essa fragmentação quebra a priorização.

Claro, se vários times trabalham em escopos diferentes, eles podem ter vários backlogs ou várias visões. Mas dentro de um espaço de priorização, é preciso um backlog único.

Por quê?

Porque a gente não prioriza categorias. A gente prioriza dores, riscos e valor.

Um assunto vindo do suporte pode exigir suporte, um data analyst e um desenvolvedor.

Um assunto de produto pode exigir produto e design, sem grande desafio técnico.

Um assunto de exportação pode não exigir design, mas pedir um forte conhecimento de negócio e uma validação técnica sobre tratamentos de dados.

O raciocínio certo não é: "em qual backlog vai este assunto?"

O raciocínio certo é: "qual problema estamos resolvendo, e de quais pessoas precisamos?"

É também por isso que a distinção bug / feature costuma ser pobre demais. O cliente sente uma dor. Ele não fica se perguntando se ela pertence ao backlog de bug, ao backlog de produto ou ao backlog técnico.

A pergunta é: qual dor é prioritária diante da estratégia, dos clientes e da capacidade real?

Um pedido de cliente não é um item de backlog

Capturar um pedido de cliente é importante.

Mas um pedido de cliente não é um item de backlog.

É um sinal.

Os clientes costumam ser ótimos para explicar os problemas deles. Eles sabem descrever uma dor, uma restrição, um contexto, uma frustração, uma obrigação de negócio.

Eles são bem menos confiáveis para propor a solução certa.

Então é preciso encarar o pedido como um material de aprendizado, não como uma ordem de execução.

Um pedido de cliente pode alimentar o backlog. Mas isso não é automático.

Ele pode ficar numa base de sinais.

Ele pode ser conectado a outros pedidos.

Ele pode reaparecer mais tarde.

Ele pode nunca reaparecer.

Ele pode não combinar com a estratégia de produto.

Ele pode não caber no roadmap.

Ele pode dizer respeito a um caso isolado demais.

Ele pode ser interessante, mas não importante o bastante.

O backlog não deve absorver todos os pedidos de clientes só para não perdê-los.

Um pedido de cliente é um material de aprendizado, não uma ordem de execução.

Rastrear certas recusas sem recriar um backlog escondido

Vale a pena rastrear as recusas?

Às vezes, sim.

Mas rastrear uma recusa não significa manter um assunto a fazer.

Algumas recusas merecem um registro porque criam um conhecimento histórico. Você recusa hoje por um motivo específico: custo, estratégia, viabilidade, falta de competência, baixa demanda, timing ruim.

Um ano depois, a decisão pode mudar.

O negócio pode ter evoluído.

A posição do produto pode ter mudado.

A IA pode tornar viável o que era caro demais.

O time pode ter contratado um data analyst.

A viabilidade técnica pode ter evoluído.

Nesses casos, é útil entender por que o assunto tinha sido recusado.

Mas nem toda recusa merece um registro. Muitas ideias fracas podem simplesmente sumir.

Se a recusa é estruturante, recorrente ou transversal, ela pode até virar um PDR. Aí você documenta a decisão, o contexto dela, as alternativas e as condições que poderiam fazê-la mudar.

O registro da recusa deve servir à memória. Ele não deve recriar um backlog escondido.

Na era da IA, o backlog não é mais onde a gente pensa

O ponto mais importante hoje talvez seja este: o backlog não é mais o lugar certo para pensar o produto.

Ferramentas como Jira, Notion ou equivalentes ainda costumam ser ferramentas de cartões. Editores de texto turbinados. Espaços onde você organiza itens, status, campos, comentários.

Elas podem ser úteis para coordenar a ação.

Mas são muito fracas para construir uma reflexão de produto.

Os agentes de IA integrados a essas ferramentas às vezes melhoram um texto, reformulam um ticket, propõem um resumo. Isso é útil na margem. Mas não é um sistema de pensamento.

O verdadeiro ativo está lá atrás.

Um contexto de produto rico pode conter:

• fontes;
• entrevistas transcritas;
• notas atômicas;
• notas temáticas;
• glossários;
• decisões;
• PDRs;
• normas;
• dados de produto;
• consultas SQL;
• análises;
• sinais de clientes;
• ligações entre features existentes e features ausentes.

Com a IA, esse contexto vira algo que você consegue consultar.

Você pode pedir os pontos cegos.

Comparar opções.

Conectar entrevistas.

Identificar recorrências.

Gerar uma consulta SQL para verificar um comportamento na data.

Transformar uma entrevista em temas.

Ligar uma dor de cliente a features existentes ou ausentes.

Construir um ticket só no fim.

Nessa lógica, Jira ou Notion viram linhas de saída. Você empurra uma informação para lá quando ela está pronta para ser trabalhada coletivamente.

O ticket não é mais o lugar onde a gente pensa.

É o lugar onde a gente empurra o resultado de um pensamento já estruturado.

O backlog de discovery é um recipiente ruim

O "backlog de discovery" vira então um conceito ruim.

A discovery lida com sinais ricos. Ela exige comparar, conectar, analisar, cruzar, reformular, sintetizar.

Uma entrevista com cliente não deveria terminar direto como um cartão.

Ela pode ser transcrita. Recortada em temas. Ligada às dores. Ligada aos interesses do cliente. Ligada aos interesses do produto. Ligada às features existentes. Ligada às features ausentes. Cruzada com outras entrevistas. Verificada nos dados de produto.

Um backlog não sabe fazer bem isso.

Uma lista de cartões é pobre demais para carregar esse trabalho.

A discovery precisa de um cérebro.

O backlog é só uma ferramenta de ação.

Alguns resultados de discovery podem, claro, terminar no backlog. Mas só quando ficam maduros o bastante para uma colaboração estruturada.

O backlog não deve ser o lugar onde a discovery se pensa.

O backlog é descartável

Por fim, é preciso aceitar uma ideia desagradável: o backlog é descartável.

Um item de backlog serve até a entrega.

Depois, ele perde boa parte do valor.

Os tickets se desatualizam. As specs se desatualizam. As decisões mudam durante a execução. O comportamento final em produção muitas vezes é diferente do que tinha sido escrito no começo.

A única realidade duradoura é o que foi entregue.

O código-fonte.

O comportamento do produto.

A documentação mantida a partir dessa realidade.

Isso não quer dizer que o backlog não serve para nada. Ele serve para coordenar. Ele serve para fazer várias pessoas trabalharem juntas. Ele serve para passar de uma intenção a uma ação.

Mas não dá para tratá-lo como um arquivo sagrado.

É preciso gastar ali o mínimo de tempo útil.

O bastante para colaborar.

O bastante para agir.

Não o bastante para produzir uma documentação que vai apodrecer.

O backlog não é uma fonte de verdade. É um apoio temporário de coordenação.

Conclusão

Um bom backlog não contém tudo o que a empresa poderia fazer.

Ele contém aquilo em que ela está pronta para trabalhar junto.

O que é imaturo fica fora do backlog.

O que é sinal continua sinal.

O que foi recusado às vezes pode ser rastreado, mas em outro lugar.

O que é discovery se trabalha num sistema de contexto.

O que é bug real precisa ser tratado, não estocado.

O que entra no backlog precisa poder avançar rumo à ação.

Na era da IA, essa distinção fica ainda mais importante. O Product Manager pode construir um contexto muito mais rico lá atrás: fontes, entrevistas, notas, glossários, decisões, análises, dados, sparring partner de IA.

O backlog continua útil.

Mas ele precisa ficar no lugar dele.

Não é o cérebro do produto.

Não é a memória completa da empresa.

Não é um depósito de ideias.

É uma ferramenta de ação.

Para saber mais

Zero bug: vamos parar de administrar estoques de defeitos Roadmap NNL: alinhar sem dispersar Por que as organizações preferem decisões frouxas