O desperdício mais caro de um time de dados raramente começa na modelagem. Ele começa quando alguém chega com um pedido que já vem embalado como solução: "precisamos de um modelo de churn", "precisamos de um dashboard de performance", "precisamos automatizar esse fluxo". O nome da solução dá uma sensação de clareza, mas esconde a parte decisiva: que problema real a empresa está tentando formular?
Problem framing é a disciplina de segurar essa conversa antes que ela vire backlog. A Slalom define problem framing como a passagem de um objetivo abstrato para um problema que pode ser tratado com dados. No contexto de produto, Marty Cagan lembra que poucas coisas são mais desperdiçadoras do que investir energia em resolver um problema pelo qual ninguém realmente mudaria de comportamento (SVPG). Em times de dados, esse erro vira sprint, custo e retrabalho.
O que é problem framing em dados
Em dados, problem framing é o enquadramento do problema antes de analisar, modelar ou construir. O trabalho é transformar uma demanda vaga em decisão-alvo, hipótese, dados necessários, granularidade adequada, restrições, responsável pela adoção e critério de sucesso.
Esse processo não existe para desacelerar por burocracia. Ele existe para impedir que o time resolva com eficiência uma pergunta mal formulada, tecnicamente inviável ou organizacionalmente irrelevante.
Por que isso importa
A McKinsey coloca a definição do problema de negócio logo no início do trabalho de tradução, antes mesmo da construção analítica. O motivo é simples: quando o framing é fraco, tudo o que vem depois fica contaminado. A métrica pode estar errada, a base pode ser insuficiente, a ação esperada pode nunca ter sido combinada e a área patrocinadora pode descobrir tarde demais que queria outra coisa.
Esse problema aparece tanto em casos sofisticados quanto em pedidos cotidianos. Ele surge num projeto de IA para retenção e também num relatório comercial mensal. O padrão é o mesmo: a empresa pede uma peça, mas não explicita a decisão que espera melhorar com ela.
Onde o pedido costuma quebrar
Antes de virar backlog, o pedido costuma quebrar em alguns pontos recorrentes:
- a decisão-alvo não está clara;
- o usuário real não participou da conversa;
- a métrica central tem definição conflitante;
- o dado existe, mas não com qualidade ou granularidade suficiente;
- a liderança quer certeza onde só existe probabilidade;
- a ação posterior nunca foi combinada;
- a solução foi escolhida antes da hipótese.
Teresa Torres insiste que discovery começa com um outcome claro, não com uma solução favorita, porque sem esse norte a equipe não consegue comparar caminhos nem aprender rápido (Product Talk). Em dados, a lógica é a mesma: sem outcome e sem decisão-alvo, o backlog vira fila de artefato.
As 12 perguntas antes do backlog
Use estas perguntas como filtro inicial:
- Que decisão precisa melhorar?
- Quem toma essa decisão hoje?
- Com que frequência essa decisão acontece?
- Que evidência é usada atualmente?
- O que está errado ou insuficiente no processo atual?
- Que hipótese queremos testar?
- Que dados seriam necessários?
- Esses dados existem com qualidade, granularidade e permissão adequadas?
- Que ação será tomada se a hipótese se confirmar?
- Que ação será tomada se a hipótese cair?
- Que métrica mostrará mudança real?
- Quem será responsável pela adoção depois da entrega?
Se as respostas forem vagas, a demanda precisa de framing antes de entrar no backlog. A melhor entrega, nesse caso, não é técnica. É formular melhor o problema.
Dois exemplos rápidos
No caso clássico de churn, o pedido fraco é "precisamos de um modelo de churn". O pedido bem formulado é "queremos identificar contas com maior risco de não renovar nos próximos 90 dias para priorizar a atuação do time de customer success em contas estratégicas e reduzir perda de receita". Essa segunda formulação muda tudo o que vem depois: janela temporal, custo de falso positivo, base necessária, métrica de sucesso e quem será responsável pela ação.
O mesmo vale para um caso menos sofisticado. "Precisamos de um relatório de performance de vendas" pode significar pelo menos quatro problemas diferentes: revisar forecast, comparar produtividade de canal, entender gargalo regional ou redefinir carteira. Sem framing, o time entrega um relatório genérico. Com framing, ele entende que decisão comercial precisa ser melhorada e qual evidência de fato importa para isso.
Como usar em rituais reais
Na etapa de descoberta, as 12 perguntas ajudam a revelar o que ainda está implícito demais para execução. Em vez de aceitar a solução nomeada, o time força clareza sobre decisão, hipótese e dados disponíveis.
No planejamento, esse material melhora a priorização porque permite comparar iniciativas pelo valor da decisão que cada uma pode melhorar, não pelo brilho da tecnologia envolvida. Projetos aparentemente sofisticados perdem força quando a hipótese é fraca, e pedidos simples ganham prioridade quando a consequência é clara.
Na revisão, o framing original vira base de aprendizado. Se a hipótese não sobreviveu ao uso real, a empresa documenta por quê antes de arquivar, reformular ou escalar. Esse tipo de memória evita que o time repita o mesmo erro com um nome diferente.
Relação com Strategic Framing
Problem framing organiza a pergunta. O Strategic Framing em Dados conecta essa pergunta a prioridade, portfólio, métrica executiva e narrativa de decisão. Em organizações mais complexas, as duas disciplinas precisam andar juntas.
Uma pergunta pode estar bem formulada e ainda assim não merecer prioridade. Uma prioridade pode estar no topo da agenda e ainda assim ter sido formulada de maneira ruim demais para o time executar com qualidade.
O papel do Data Translator
O Data Translator sustenta problem framing quando a organização quer correr direto para a solução. Ele traduz o pedido do negócio para uma hipótese que dados consegue avaliar e traduz a restrição técnica para uma consequência que liderança consegue arbitrar.
Esse repertório conecta Análise, BI e Comunicação, Produto de Dados e Estratégia de Negócio.
Critério final
Uma demanda está pronta para o backlog quando o time consegue completar esta frase:
Vamos usar dados para melhorar a decisão de [quem] sobre [qual escolha], porque acreditamos que [hipótese], e saberemos que funcionou quando [métrica de decisão] mudar.
Se a frase não fecha, o backlog ainda está cedo demais.
Para aprofundar, leia Como definir uma métrica de decisão e faça o Radar de Competências para localizar onde sua fluência de framing ainda quebra.