O tamanho do backlog é inversamente proporcional à frequência com que falamos com clientes
A afirmação de que “o tamanho do seu backlog é inversamente proporcional à frequência com que você fala com clientes” gera um amplo debate sobre prática de gestão de produto. Muitos argumentam que backlogs inchados geralmente são sinal de priorização fraca, medo de dizer não e de despejar toda ideia em tickets, enquanto outros observam que conversas frequentes com clientes podem, na verdade, aumentar o backlog, mas tornar as prioridades mais nítidas. Os participantes exploram estratégias como separar feedback bruto de trabalho acionável, podar agressivamente ou limitar tickets por tempo, e confiar em insights de vendas e suporte para focar em problemas reais dos clientes em vez de um monte de funcionalidades solicitadas.
Tamanho do backlog vs. falar com clientes
- Muitos discordam de que o tamanho do backlog seja inversamente proporcional ao contato com clientes.
- Alguns dizem: conversas frequentes com clientes geram mais pedidos e itens no backlog; o benefício é uma priorização mais inteligente, não uma lista menor.
- Outros argumentam: backlogs grandes tendem a ser “cemitérios” obsoletos de suposições; falar frequentemente com clientes expõe trabalho mais valioso e torna tickets antigos obviamente obsoletos.
- Consenso: a relação depende fortemente do contexto (startup em fase inicial vs. produto maduro, tipo de produto, disciplina da equipe).
O que deve entrar em um backlog?
- Uma corrente: o backlog deve conter apenas trabalho razoavelmente de curto prazo e acionável; ideias de longo prazo pertencem a documentos mais leves ou ferramentas separadas.
- Outra corrente: manter um único sistema pesquisável; usar tags, tipos de issue, status (por exemplo, “parked”) e fechamento automático para gerenciar a escala.
- Alguns tratam explicitamente o backlog como uma ferramenta diplomática de “sim, anotamos”; outros chamam isso de disfunção cultural e enfatizam que o trabalho do PM é dizer “não” com clareza.
- Vários recomendam fluxos separados:
- Feedback bruto / problemas de clientes.
- Descoberta de produto / opportunity trees.
- Tickets de entrega para trabalho que de fato vai acontecer.
Entrada do cliente vs. pedidos de funcionalidades
- Tema forte: clientes devem informar sobre problemas, não ditar a UI ou as soluções.
- Riscos apontados: construir de forma reativa cada pedido leva a produtos incoerentes e cheios de opções.
- Recomendado: sintetizar vários pedidos em problemas de raiz e projetar soluções mínimas e gerais alinhadas com a visão do produto e os objetivos de negócio.
Ferramentas e processos
- Abordagens mencionadas: Jira + Product Discovery, Productboard, agregadores especializados de feedback, trackers públicos de issues no GitHub, notas pessoais.
- Técnicas de higiene do backlog: grooming regular, expiração de issues antigas, limites de WIP, backlogs de equipe de “apenas iterações curtas”, dimensionamento por t-shirt ou valor/custo, frameworks de priorização (por exemplo, RICE, opportunity-solution trees).
Fatores organizacionais e culturais
- Backlogs grandes e insalubres costumam estar ligados a: organizações de produto fracas, rotatividade de PM, medo de dizer não e entrada descontrolada de vendas/suporte.
- Vários comentários enfatizam que vendas, suporte e CS são fontes ricas de insight estruturado do cliente.
- Observar usuários reais (e às vezes se passar por contas) é visto como inestimável para UX, mas a impersonação levanta sérias preocupações de segurança, privacidade e conformidade em alguns domínios, exigindo auditoria e controles fortes.