Muita empresa chama qualquer iniciativa de dados de projeto. Outras passaram a chamar qualquer dashboard, dataset, score ou modelo de produto. A troca de nome parece pequena, mas embaralha orçamento, responsabilidade e critério de valor.
O efeito aparece rápido. Um time entrega um score de propensão em doze semanas, a publicação entra no status report e a iniciativa é declarada concluída. Três meses depois, o uso caiu, o negócio mudou a regra comercial e o modelo continua no ar porque ninguém mede adoção nem tem mandato claro para evoluir ou desligar. O artefato existe, mas a responsabilidade não.
A diferença central
Projeto de dados é um modo de execução. Data product é um 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. A entrega desse artefato não transforma automaticamente o resultado em produto.
Para virar produto, o ativo precisa ter usuário real, decisão-alvo, responsável, critério de qualidade, métrica de adoção e ciclo de vida explícito. Essa distinção não é só semântica. Na formulação de Zhamak Dehghani sobre data mesh, tratar dados como produto é um princípio estrutural, não um apelido novo para entregável técnico.
O que caracteriza 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, integrar uma fonte, publicar um dashboard, fazer uma análise, construir um modelo ou validar uma hipótese.
Projetos são necessários. O erro aparece quando a empresa usa lógica de projeto para algo que deveria continuar vivo depois da entrega.
Quando isso acontece, o time comemora a publicação, mas ninguém assume perguntas que determinam valor:
- 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 a decisão mudou.
Sem essas respostas, o projeto acaba, e o passivo permanece.
O que caracteriza um data product
Data product é um ativo de dados gerido como produto.
Ele pode ser dataset, score, modelo, métrica, API, feature store ou outro ativo reutilizável. O formato varia. A responsabilidade precisa existir. Em outro texto do Martin Fowler sobre design de data products, o ponto fica mais nítido: dashboard pode consumir um data product, mas não deveria ser tratado automaticamente como um.
Um data product precisa responder quem usa, para qual decisão, com que frequência, com qual nível de qualidade, quem é o responsável, como a adoção será medida e quando vale evoluir, pausar ou aposentar.
Essa é a diferença operacional: projeto entrega algo; produto continua respondendo por valor.
Onde a confusão aparece
A confusão costuma aparecer em três situações.
A primeira é medir maturidade pelo volume de entregas. Quanto mais dashboard, dataset e modelo, mais parece que a empresa evoluiu. Só que volume de artefato não é volume de decisão melhor.
A segunda é aceitar pedido de solução antes da decisão estar clara. O negócio pede "um dashboard" ou "um modelo", mas a pergunta de fundo deveria ser que comportamento precisa mudar.
A terceira é evitar a conversa 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. A McKinsey chamou atenção para isso em 2024 ao defender que data products precisam ser operados como negócio, não como projeto, com responsáveis capazes de acompanhar KPIs, reuso e valor ao longo do tempo.
Como diagnosticar
Uma pergunta resolve boa parte da ambiguidade: se a equipe original sair, esse ativo continua tendo dono?
Se a resposta for negativa, provavelmente existe uma entrega de projeto, não um produto operado.
Outros sinais ajudam:
- existe backlog, mas não existe métrica de adoção;
- existe dashboard, mas não existe decisão-alvo;
- existe responsável técnico, mas não existe responsável por valor;
- existe documentação, mas não existe rotina de revisão;
- existe uso aparente, mas ninguém sabe dizer qual decisão melhorou.
Esses sinais não invalidam o ativo. Eles mostram que a organização ainda não criou a responsabilidade necessária para tratá-lo como produto.
O papel do DPM
Quando a empresa entende essa diferença, a pergunta seguinte deixa de ser semântica e vira operacional: quem sustenta isso no dia a dia?
O Data Product Manager fecha essa lacuna no nível do squad, domínio ou ativo.
Ele ajuda a transformar entregas em produtos com discovery, priorização, contrato, ciclo de vida, qualidade percebida e adoção. O DPM protege o produto contra dois riscos: nascer sem problema real e continuar vivo sem valor real.
Se quiser aprofundar a fronteira entre papéis, leia DPM vs Data Translator.
O papel do Data Translator
O Data Translator opera uma camada acima. Ele conecta data products ao contexto organizacional.
Na prática, isso significa perguntar quais produtos sustentam apostas estratégicas, onde squads diferentes estão resolvendo o mesmo problema, quais ativos deveriam ser priorizados por impacto e quais deveriam 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
| 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 e custo | Adoção, qualidade, impacto e ciclo de vida |
| Depois da publicação | Encerramento | Operação, evolução ou aposentadoria |
| Risco principal | Entregar algo que não muda decisão | Manter algo que perdeu valor |
Essa tabela também muda a conversa de orçamento. Se algo é projeto, a empresa financia execução. Se algo é produto, financia vida útil.
O impacto no ROI
Quando projeto e produto se misturam, o cálculo de ROI fica contaminado.
A empresa calcula o custo de construir, mas esquece o custo de operar. Calcula 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. O custo real está na construção, na manutenção, na governança, no retrabalho, na dívida técnica e na oportunidade perdida de manter ativo sem impacto.
Como fazer a passagem
Um projeto de dados pode ser um excelente ponto de partida. O cuidado é desenhar a passagem para produto antes da publicação.
O mínimo necessário é definir usuário e decisão-alvo, nomear responsável pelo produto e responsável técnico, escrever critérios de qualidade, combinar métrica de adoção, criar rotina de revisão e 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.
Antes de aprovar a próxima iniciativa, a pergunta útil é direta: isso será uma entrega pontual ou um produto com dono depois da publicação?
Se for entrega pontual, trate como projeto e encerre direito. Se for produto, não aprove sem responsável, ciclo de vida e métrica de adoção.