Resposta direta
Projeto de dados é uma iniciativa temporária com começo, fim e entregáveis. Data product é um ativo contínuo com usuário, owner, qualidade, adoção, lifecycle e responsabilidade por impacto. Um projeto pode criar um data product, mas não deveria ser confundido com ele.
Muita empresa chama qualquer iniciativa de dados de projeto. Outras passaram a chamar qualquer dashboard, dataset ou score de produto. As duas coisas parecem inofensivas, mas criam um problema sério: a organização deixa de saber se está financiando uma entrega temporária ou assumindo uma responsabilidade contínua.
A diferença entre projeto de dados e data product muda quem decide, quem mantém, como se mede valor e quando aquilo deveria ser encerrado.
A diferença em uma frase
Projeto de dados é o modo de execução. Data product é o ativo operado depois que a execução termina.
Um projeto pode construir um dashboard executivo, um modelo de propensão, uma base curada, uma API analítica ou um score de risco. Mas o fato de algo ter sido entregue não transforma automaticamente esse artefato em produto.
Para virar produto, ele precisa ter usuário real, decisão-alvo, owner, critério de qualidade, métrica de adoção, SLA proporcional ao caso e ciclo de vida explícito.
O que é um projeto de dados
Projeto de dados é uma iniciativa com escopo, prazo, equipe e entregáveis. Ele existe para resolver uma necessidade específica: migrar um pipeline, construir um modelo, publicar um dashboard, integrar uma fonte, fazer uma análise ou validar uma hipótese.
Isso não é ruim. Projetos são necessários. O problema aparece quando a empresa usa a lógica de projeto para algo que deveria continuar vivo depois da entrega.
Quando isso acontece, o time comemora o go-live, mas ninguém assume as perguntas difíceis:
- quem responde pela evolução;
- quem mede adoção;
- quem corrige quando a qualidade cai;
- quem decide se o ativo continua justificando custo;
- quem garante que aquilo mudou alguma decisão.
Sem essas respostas, o projeto acaba, mas o passivo fica.
O que é um data product
Data product é um ativo de dados gerido como produto. Ele não é definido pelo formato. Pode ser dashboard, dataset, score, modelo, métrica, feature store, API ou agente. O que define é a responsabilidade em torno dele.
Um data product precisa responder:
- quem usa;
- para qual decisão;
- com que frequência;
- com qual nível de qualidade;
- quem é owner;
- como se mede adoção;
- quando vale evoluir, pausar ou aposentar.
Essa é a diferença central: projeto entrega algo; produto continua respondendo por valor.
Onde as empresas se confundem
A confusão normalmente aparece em três situações.
Primeiro, quando a área de dados mede maturidade pelo volume de entregas. Quanto mais dashboard, mais dataset, mais modelo, mais parece que a empresa evoluiu. Só que volume de artefato não é volume de decisão melhor.
Segundo, quando o negócio pede solução antes de explicitar decisão. O pedido chega como "preciso de um dashboard" ou "quero um modelo", mas a pergunta real deveria ser: que comportamento ou escolha precisa mudar?
Terceiro, quando ninguém quer falar de sunset. Produtos ruins, redundantes ou sem adoção seguem vivos porque desligar parece politicamente mais difícil do que manter. O catálogo cresce, o custo sobe e o valor percebido cai.
Como saber se você tem produto ou só projeto
Uma pergunta simples resolve boa parte da ambiguidade: se a equipe original sair, esse ativo continua tendo dono?
Se a resposta for não, provavelmente você tem uma entrega de projeto, não um produto.
Outros sinais:
- existe backlog, mas não existe métrica de adoção;
- existe dashboard, mas não existe decisão-alvo;
- existe owner técnico, mas não existe owner de valor;
- existe documentação, mas não existe rotina de revisão;
- existe uso aparente, mas ninguém sabe dizer qual decisão melhorou.
Nenhum desses sinais invalida o ativo. Eles apenas mostram que ele ainda não está sendo operado como produto.
O papel do DPM
O Data Product Manager entra justamente para fechar essa lacuna no nível do squad ou domínio. Ele ajuda a transformar ativos de dados em produtos com discovery, priorização, contrato, lifecycle e adoção.
Esse papel é essencial quando a organização quer parar de tratar dados como fila infinita de demanda. O DPM protege o produto de dados contra dois riscos: nascer sem problema real e continuar vivo sem valor real.
Se quiser aprofundar essa fronteira de papel, leia DPM vs Data Translator.
O papel do Data Translator
O Data Translator opera uma camada acima. Ele não substitui o DPM. Ele conecta data products ao contexto organizacional.
Na prática, isso significa perguntar:
- quais produtos de dados sustentam as apostas estratégicas;
- onde squads diferentes estão resolvendo o mesmo problema;
- quais ativos deveriam ser priorizados por impacto no negócio;
- onde governança, qualidade e adoção precisam virar conversa executiva;
- quais produtos devem ser encerrados porque deixaram de justificar custo.
O Translator cuida da coerência entre produtos, áreas e decisões. Por isso o eixo Produto de Dados é uma das competências centrais do Radar.
A tabela mental
Pense assim:
| Tema | Projeto de dados | Data product |
|---|---|---|
| Natureza | Temporária | Contínua |
| Sucesso | Entrega concluída | Decisão melhorada |
| Dono | Gerente do projeto ou time executor | Owner nomeado do ativo |
| Métrica | Prazo, escopo, custo | Adoção, qualidade, impacto, lifecycle |
| Depois do go-live | Encerramento | Operação, evolução ou sunset |
| Risco principal | Entregar algo que não muda decisão | Manter algo que perdeu valor |
Essa tabela parece simples, mas muda a conversa de orçamento. Se algo é projeto, você financia execução. Se é produto, você financia vida útil.
O erro de ROI
Quando projeto e produto se misturam, o ROI fica contaminado. A empresa calcula o custo de construir, mas esquece o custo de operar. Calcula o benefício esperado, mas não mede adoção. Aprova novas iniciativas, mas não desconta o peso de manter produtos antigos.
É por isso que a disciplina de Economia de Dados importa tanto. O custo real não está apenas na construção. Está na manutenção, na governança, no retrabalho, na dívida técnica e na oportunidade perdida de manter ativo sem impacto.
Como transformar projeto em produto
Um projeto de dados pode ser um excelente ponto de partida. O cuidado é desenhar a passagem para produto antes do go-live.
O mínimo necessário:
- definir usuário e decisão-alvo;
- nomear owner de produto e owner técnico;
- escrever critérios de qualidade e atualização;
- combinar métrica de adoção;
- definir rotina de revisão;
- documentar quando o ativo deve ser evoluído, reformulado ou aposentado.
Esse é o território do módulo Data Product Thinking e do L5 Framework: sair da entrega pontual e entrar em ciclo de produto.
A pergunta que destrava a conversa
Na próxima vez que alguém pedir um projeto de dados, faça uma pergunta antes de discutir ferramenta, prazo ou squad:
isso precisa ser uma entrega pontual ou um produto com dono depois do go-live?
Se for entrega pontual, trate como projeto e encerre direito. Se for produto, não aprove sem owner, lifecycle e métrica de adoção.
Essa distinção reduz desperdício, melhora priorização e torna o investimento em dados mais defensável na mesa executiva.