O que é Product Data Manager

Quando comecei em dados, em 2024, não havia um nome para o que eu estava fazendo. Meu título dizia “Senior Data Product Manager”, mas nem eu entendia direito o significado. Menos ainda as pessoas ao meu redor.

Dois anos depois, operando esse papel, consigo finalmente articular algo mais honesto: um Product Data Manager é a pessoa que garante que dados funcionem como produto — com consumidores definidos, contratos claros, qualidade mensurável e ciclo de vida intencional — e que constrói as pontes necessárias entre quem produz, quem transforma e quem consome dados.

Mas essa definição esconde uma verdade mais importante: estamos num ponto de inflexão onde as empresas percebem que dados são um produto, não um output. E essa percepção muda tudo!

O Vácuo Que Ninguém Fala Sobre

A indústria de dados cresceu tanto em complexidade que criou um problema: infraestrutura sem propósito claro.

Como Martin Kleppmann coloca em Designing Data-Intensive Applications, a maioria das aplicações modernas precisa de gestão de dados que vai muito além do que um único banco de dados consegue oferecer. A resposta da indústria foi adicionar camadas: data warehouses, data marts, data lakes, lakehouses, streaming platforms, feature stores. Cada uma resolve um problema real. Nenhuma resolve o problema central: alguém está decidindo o que construir com tudo isso? Geralmente o TechLead que faz essa função junto com o Data Engineering.

Você já trabalhou em uma empresa com:

✓ Data warehouse bem estruturado (BigQuery, Snowflake, Redshift)
✓ Engenheiros de dados competentes (pipelines, orquestração, qualidade)
✓ Cientistas de dados publicando modelos (ML, forecasting, recomendação)
✓ Mas ninguém sabe que produtos construir com tudo isso? ✗

Esse é o vácuo que o Product Data Manager preenche.

A maioria das empresas brasileiras trata dados como infraestrutura. Um custo operacional. Um departamento que suporta decisões de outros. O Fundamentals of Data Engineering descreve bem o ciclo que essa mentalidade cria: geração → armazenamento → ingestão → transformação → serving. Repare: esse ciclo é inteiramente técnico. Não menciona para quem nem por quê. Não é uma falha do livro — é a realidade de como a indústria pensou dados por décadas.

Zhamak Dehghani desafia isso em Data Mesh: dados devem ser tratados como produto, com domínios como preocupação primária, infraestrutura auto-gerenciável e governança federada. Mas entre a teoria do Data Mesh e a realidade do dia a dia, existe um abismo e quem cruza esse abismo é o Product Data Manager.

O TDWI (Transforming Data With Intelligence) é uma das principais fontes globais de educação, pesquisa e eventos para profissionais de dados e analytics. Fundada em 1995, a organização se dedica a capacitar profissionais e empresas a transformar dados em inteligência estratégica e valor de negócio

Contexto: O Brasil em 2026

Um Mercado em explosão: sem estratégia correspondente?

Conforme relatório da Brasscom (2025), o Brasil ocupa atualmente a 12ª posição no mercado global de cibersegurança e deve investir R$ 104,6 bilhões em segurança digital entre 2025 e 2028, representando um crescimento de 43,8% em relação ao ciclo anterior. Parece promissor. Mas olhe os dados complementares: o custo médio de uma violação de dados no Brasil chegou a US$ 1,36 milhão em 2024, enquanto dados de 2023 apontam cerca de 60 bilhões de tentativas de ataque cibernético no país. Crescimento em investimento não significa clareza de estratégia de dados.

Esses números revelam algo: as empresas estão investindo em reatividade — detecção, resposta a incidentes, ferramentas de segurança. Mas falta estrutura proativa em torno de como usar dados para decisão melhor e mais rápida.

A Inflexão

Empresas brasileiras de tech conseguiram resolver a primeira pergunta: “Como coletamos e armazenamos dados?” A infraestrutura de dados amadureceu. BigQuery, Snowflake, dbt, Airbyte — as ferramentas estão lá.

Agora enfrentam a segunda pergunta, muito mais difícil: “Temos dados e infraestrutura. Como transformamos isso em vantagem competitiva?”

Sem alguém pensando estrategicamente sobre dados como produto, a resposta padrão é: mais dados, mais warehouses, mais ferramentas, mais custo. A resposta certa não tem.. existem questionamentos:

Qual é o problema de negócio?
Quais dados resolvem?
Como organizamos isso como algo que alguém consome com confiança?

Por uma definição sólida

O que NÃO É

Três confusões que preciso eliminar:

1. Não é “Product Manager que usa dados”. Como Ellen Merryweather do Product School observa, ser data-driven é diferente de ter dados como seu produto. Um PM tradicional usa dados para decidir sobre features. Um Data Product Manager é responsável pelo produto de dados em si.

2. Não é “Engenheiro de Dados com visão de negócio”. Engenheiros de dados pensam em pipelines, orquestração, escalabilidade, qualidade no nível de schema e transformação. Isso é essencial, mas é infraestrutura. Um PDM pensa em: quem consome esse dado? Qual é o contrato entre produtor e consumidor? O que acontece quando o dado falha?

3. Não é “Head de Analytics”. Analytics responde perguntas sobre o negócio usando dados existentes. PDM cria os produtos de dados que possibilitam essas respostas — e muitas outras que ninguém imaginava ainda.

Um Product Data Manager é a pessoa que:

Define o que é um data product na organização — não qualquer dataset, mas algo com consumidores identificáveis, valor mensurável e SLAs explícitos
Operacionaliza a ideia de dados como produto — tirando do abstrato e colocando em roadmap, priorização e entrega
Cria contratos entre produtores e consumidores de dados — definindo o que é entregue, com que qualidade, com que frequência, e o que acontece quando algo quebra
Traduz necessidades de negócio em decisões sobre arquitetura de dados — sem ditar soluções técnicas, mas garantindo que as decisões técnicas sirvam aos objetivos de produto

Segundo o TDWI, é uma função que faz ponte entre estratégia de negócio, estratégia de dados e gestão de produto, responsável por definir, priorizar e guiar o ciclo de vida de produtos de dados — datasets curados e reutilizáveis, ferramentas de analytics ou aplicações dirigidas por IA desenhadas para entregar valor mensurável ao negócio.

| O TDWI (Transforming Data With Intelligence) é uma das principais fontes globais de educação, pesquisa e eventos para profissionais de dados e analytics. Fundada em 1995, a organização se dedica a capacitar profissionais e empresas a transformar dados em inteligência estratégica e valor de negócio.

O que Faz um Data Product ser um Produto

Antes de falar de responsabilidades, preciso estabelecer algo que a maioria das empresas brasileiras não entende: nem todo dataset é um data product.

O Fundamentals of Data Engineering descreve propriedades que diferenciam um data product de uma tabela qualquer num warehouse. Adaptando para a realidade que encontrei:

Um data product de verdade tem:

1. Consumidores definidos Você sabe exatamente quem usa, como usa e com que frequência. “Qualquer pessoa que quiser” não é consumidor definido.

2. Contrato explícito (Data Contract) O consumidor sabe o que esperar: schema, granularidade, frescor, semântica de cada coluna, o que cada valor significa. Quando o contrato muda, há um processo. Isso não é burocracia — é o que permite que consumidores confiem no dado.

3. SLAs e SLOs Como Kleppmann enfatiza em DDIA, confiabilidade não é um conceito vago — é mensurável. Um data product tem SLOs definidos: latência máxima de atualização, taxa de erros aceitável, disponibilidade. E quando esses SLOs são violados, há um processo claro de resposta.

4. Observabilidade própria Você consegue responder sem investigar manualmente: “Esse dado está saudável agora? Quando foi a última atualização? Há drift na distribuição dos valores?” Isso é diferente de monitorar pipelines — é monitorar o produto.

5. Descoberta e documentação Alguém que nunca viu esse dado antes consegue entender em menos de 5 minutos: o que é, de onde vem, o que significa, como usar, o que não fazer com ele, quem é o dono.

6. Ciclo de vida intencional Tem um dono. Tem roadmap. Tem critérios claros de quando desativar. Dados sem dono acumulam como lixo técnico — e lixo de dados é mais perigoso que lixo de código porque pessoas tomam decisões em cima dele.

As Três Dimensões de Responsabilidade

Dimensão 1: Estratégia de Dados como Produto

Você define:

O que construir — quais datasets, ferramentas, aplicações de dados merecem ser produtos vs ficarem como ativos internos de um time
Para quem — consumidores primários e secundários, com necessidades explícitas mapeadas
Por quê — impacto empresarial concreto, não “melhorar os dados”
Como priorizar — sob restrições reais de capacidade técnica, recursos e janelas de oportunidade

Exemplo real: Não é suficiente ter um data warehouse com 70+ threat intelligence collectors coletando dados de fontes diversas. A pergunta que um PDM faz é: qual é o produto de dados que criamos com isso?

A resposta que desenvolvemos foi um projeto que criamos uma ferramenta de observabilidade para monitorar a saúde dos dados da plataforma. Não “um dashboard com métricas”. Mas um produto com: consumidores definidos (equipes técnicas que precisam saber se podem confiar nos dados), contrato claro (o que cada métrica significa, como é calculada, com que frescor), SLOs (latência de detecção de problemas, cobertura dos collectors monitorados), e roadmap de funcionalidades.

A diferença sutil mas fundamental: sem essa estrutura, esse projeto seria um projeto interno. Com ela, é um produto que outras equipes dependem e que evolui intencionalmente. Existe próposito não é uma mera experimentação.

Dimensão 2: Execução de Produto

Você trabalha com engenheiros e cientistas para:

Traduzir visão em requisitos que respeitem as restrições do sistema de dados
Garantir que decisões de arquitetura sirvam aos objetivos de produto (não o contrário)
Definir o que “pronto” significa — não só “pipeline rodando”, mas “consumidor consegue usar com confiança”
Medir sucesso com métricas que conectam dados a resultados de negócio

Exemplo: Report Processing A iniciativa começou como demanda operacional: “automatizar PDFs”. A abordagem de engenharia pura seria: script que extrai texto e salva num banco.

A abordagem de produto foi diferente. Perguntei: quem usa? Com que frequência? Qual é a decisão que esse dado habilita? A resposta revelou que o valor não estava na extração — estava na consulta. Analistas precisavam fazer perguntas sobre dezenas de relatórios e não conseguiam.

Transformei em um produto com fases claras:

Garantir dados corretos no PPT — Assegurar que os dados extraídos chegam com integridade total no formato esperado para apresentações
Geração de análise — Criar análises que sustentem os dados, educando consumidores sobre o contexto e significado do que está sendo apresentado
Geração de relatórios — Sintetizar insights em formato consumível por stakeholders (executivos, times técnicas)
Logging e tratamento de erro — Implementar sistema de logs para diagnosticar falhas, permitindo melhoria contínua e debug quando algo sai errado

Cada fase tinha contrato claro, consumidores definidos, e critérios de sucesso que não eram técnicos (“pipeline rodou sem erro”) mas de produto (“analista conseguiu responder sua pergunta em menos de 2 minutos”).

Sem essa estrutura de produto com fases claras e observabilidade, seria só um script que “funcionava ou não funcionava”. Com ela, é um ativo escalável com mecanismos de manutenção, confiabilidade e educação de usuários.

Dimensão 3: Governança que Habilita

Este é o ponto onde a maioria das organizações brasileiras fracassa. Governança de dados é vista como compliance burocrático: “preenche esse formulário para conseguir acesso”, “esse dado não pode ser compartilhado”, “precisa de aprovação do comitê de dados”.

Um PDM repensa governança como infraestrutura que habilita consumo confiável:

Data contracts entre times — não como documento legal, mas como API entre produtores e consumidores de dados
Ownership claro — cada data product tem um dono que responde por sua saúde, não um comitê que se reúne mensalmente
Quality dimensions explícitas — completude, accuracy, timeliness, consistency, valididade — definidas por produto, não como padrão genérico que ninguém segue
Policies como código — regras de acesso e qualidade implementadas em ferramentas, não em documentos que ninguém lê

Essa é uma área onde estou investindo estudo, pretendo fazer um deep dive dedicado quando tiver experiência mais consolidada na implementação.

Por Que o Brasil Precisa Disso Agora? Não sei… mas eu preciso para construir uma nova carreira

1. A Transição de Infraestrutura para Produto é Iminente

Há 3 anos, a pergunta era “como armazenamos dados?”. Em 2026, nas empresas de tech brasileiras, isso está resolvido. A pergunta agora é “como transformamos isso em vantagem competitiva?” — e essa pergunta é de produto, não de engenharia.

2. O Custo da Ausência é Tangível

Kleppmann mostra que sistemas de dados mal projetados não apenas falham — falham de formas que são caras para consertar tarde. No contexto brasileiro, onde violações de dados custam US$ 1,36 milhão em média e o volume de ataques cresce exponencialmente, a ausência de alguém pensando estrategicamente sobre dados como produto não é um problema abstrato. É dinheiro perdido.

3. A Demanda por Habilidades Excede a Oferta

Entre 2021 e 2024, vagas que exigem competências em IA quadruplicaram no Brasil. Vagas em data science, data engineering e analytics explodiram. Vagas em gestão estratégica de produtos de dados? Praticamente inexistentes.

Isso não é porque não precisam. É porque as empresas ainda não deram nome ao problema. Quando derem (e darão) vão descobrir que não há ninguém preparado.

O Que Distingue Um Bom Product Data Manager

1. Entenda que Dados São Sistemas, Não Artefatos

Kleppmann dedica capítulos inteiros para mostrar que dados não são “coisas” estáticas — são o resultado de dataflows contínuos onde cada transformação introduz possibilidades de erro, latência e inconsistência. Um bom PDM (a área de Data Engineering é minha bussóla para atingir isso!) entende que garantir qualidade de um data product significa entender o fluxo inteiro: da fonte ao consumo, cada etapa com suas próprias garantias e limitações.

Isso tem implicação prática: quando um consumidor reclama que “o dado está errado”, um PDM ruim diz “vou pedir pro engenheiro consertar”. Um PDM bom diz: “onde no fluxo a qualidade degradou? É um problema de fonte, de transformação, de frescor, ou de semântica?” A resposta muda completamente a ação.

2. Pensa em Trade-offs de Arquitetura como Decisões de Produto

DDIA apresenta trade-offs fundamentais que permeiam toda decisão de sistema de dados: consistência vs disponibilidade, latência vs throughput, normalização vs denormalização, batch vs stream. Um engenheiro vê esses trade-offs como decisões técnicas. Um PDM entende que cada um tem implicação no produto:

“Escolher batch em vez de stream significa que nosso data product terá latência de 24h. Isso é aceitável para o caso de uso X? Não para o Y. Então precisamos de dois produtos, não de um compromisso que não serve nenhum.”
“Denormalizar essa tabela acelera queries em 10x mas torna updates 5x mais complexos. Para o consumidor A, isso vale a pena. Para o B, não.”

Não é sobre ditar soluções técnicas. É sobre garantir que trade-offs sejam feitos com consciência do impacto no produto.

3. Pensa como Designer

Se você vem de design, tem uma vantagem real: entende experiência do consumidor de dados. Como dados são consumidos? O dashboard é claro? A interface de query é intuitiva? A documentação é escaneável?

Engenheiros frequentemente resolvem “tecnicamente correto mas não usável”. Um bom PDM resolve “correto E usável”.

Exemplo concreto: Um dashboard que mostra “13 vulnerabilidades críticas” é tecnicamente correto. Um dashboard que mostra “13 vulnerabilidades críticas — 8 remediadas na semana passada — 5 requerem ação — 2 dependem de update do fabricante” é produto. A diferença não é técnica. É de design de experiência.

4. Fala Linguagens Diferentes — Com Precisão

Com executivos: ROI, redução de risco, velocidade para insight, economia de custos — sem jargão técnico
Com engenheiros: trade-offs de arquitetura, SLOs, contratos, impacto de decisões técnicas no produto — sem generalizações vagas
Com consumidores de dados: utilidade prática, confiança, tempo economizado — sem presumir conhecimento técnico

5. Confortável com Incerteza

Dados é um campo em movimento. Como Kleppmann nota, não existe uma solução universal — cada decisão envolve trade-offs que dependem do contexto. Um bom PDM aceita incerteza (“não sabemos ainda qual modelo de governança vai funcionar melhor, vamos experimentar”) mas não aceita ambiguidade evitável (“não sabemos quem consome esse dado” — isso é falha de produto, não incerteza legítima).

As Responsabilidades Reais

1. Definir o Que Qualifica como Data Product

Nem todo dataset precisa ser um produto. Um PDM define os critérios: quando um ativo de dados merece investimento em contrato, SLA, observabilidade, documentação e ciclo de vida — e quando pode ficar como ativo interno de um time. Essa decisão sozinha já evita meses de trabalho desperdiçado.

2. Criar e Manter Data Contracts

O contrato entre quem produz e quem consome dados é o fundamento de tudo. Sem ele, consumidores não confiam, produtores não sabem o que podem mudar, e cada quebra vira uma crise política. Um PDM define o formato desses contratos, garante que sejam atualizados, e mediation conflitos quando mudanças em um lado impactam o outro.

3. Definir e Monitorar SLOs para Dados

Inspiração direta de SRE, adaptada para dados: qual é a latência aceitável de atualização? Qual é a taxa de erros tolerável? O que acontece quando um SLO é violado? Um PDM não opera os alertas — mas define o que eles significam e garante que haja processo de resposta.

4. Garantir Observabilidade de Produto (Não só de Pipeline)

Monitorar que um pipeline rodou sem erro é necessário mas insuficiente. Um PDM garante observabilidade de produto: o dado chegou com a qualidade esperada? O consumidor conseguiu usá-lo? Houve drift na distribuição? Essa é a diferença entre saber que o sistema funcionou e saber que o produto entregou valor.

5. Facilitar Descoberta e Adoção

Dados que ninguém encontra são dados que não existem. Um PDM pensa em catalogação, documentação acessível, e educação ativa de consumidores. Não “documentação técnica que engenheiros leem” mas “alguém que nunca viu esse dado consegue decidir em 5 minutos se serve para o que precisa”.

6. Gerenciar o Ciclo de Vida, incluindo Fim

Datasets têm fim de vida. Um PDM define critérios claros de desativação, comunica proativamente aos consumidores, e garante que o processo não seja traumático. Dados zumbis — presentes mas sem dono, sem consumidores, sem qualidade — são mais perigosos que dados ausentes porque pessoas os usam sem saber que estão ruins.

A Realidade Incômoda: Carreira, Salário, Reconhecimento

Salário

Dados é novo demais no Brasil para haver salários padronizados. Internacionalmente, salários de Product Manager nos EUA variam de $103k a $166k/ano, com média de $130k. Para Senior Data Product Managers, a média é $160k. No Brasil, estimativas apontam R$ 12k a R$ 30k/mês dependendo de setor, localização, senioridade e tamanho da empresa.

Carreira

Dois caminhos principais:

Liderança organizacional — Chief Data Officer, VP of Data, VP of Product — onde a experiência de PDM se torna base para decisões estratégicas de toda a organização de dados
Autoridade técnica — consultor independente, referência em data product strategy, fundador

A transição para liderança é mais natural porque PDMs já operam na interseção entre técnica e negócio.

Reconhecimento

A verdade dura: dados são invisíveis quando funcionam. Quando você faz bem, as decisões parecem óbvias. O crédito vai para quem usou os dados. Quando faz mal, todo mundo sabe.

Você escolhe esse papel por:

Impacto real em cima de ambiguidade
Resolução de problemas que afetam toda a organização
Capacidade de influenciar sem autoridade direta

Não por validação externa.

Então… você Deveria Virar Product Data Manager?

Responda Honestamente

Você entende que dados são sistemas com fluxos, trade-offs e pontos de falha — não tabelas estáticas?
Você gosta de entender “por quê” e “para quem” antes de “como”?
Você consegue traduzir entre técnico e negócio sem perder precisão em nenhum dos lados?
Você se energiza com problemas de longo prazo que não têm resposta óbvia?
Você aceita que reconhecimento será proporcional a problemas evitados, não a features visíveis?
Você entende que governança não é burocracia — é infraestrutura de confiança?

Habilidades Técnicas Mínimas

Você não precisa ser engenheiro de dados. Mas precisa ter:

SQL: conseguir ler e entender queries complexas, identificar ineficiências
Conceitos de banco de dados: NoSql, Relacional vs OLAP, normalização, indexação, schema design
Noções de pipeline: como dados fluem de A para B, onde podem quebrar, latency vs throughput
Versionamento e Git: entender fluxos de código, PRs, quando algo quebra produção
Métricas básicas: conseguir definir e medir o que importa (SLOs, latência, qualidade)

A Decisão: se a maioria das perguntas são “sim” E você tem curiosidade em desenvolver os skills técnicos: vale muito a pena.

Entra com expectativas certas:

Impacto real, não validação imediata
Complexidade, não clareza total
Problemas que ninguém mais na organização tem capacidade ou mandato para resolver

O resto segue naturalmente.

O Diferencial Brasileiro

O Brasil tem uma oportunidade real agora: mercado de dados está em crescimento (43.8% de investimento em segurança até 2028), infraestrutura existe (BigQuery, Elasticsearch rodando em produção), mas organização de dados como produto é praticamente inexistente.

A empresa que contratar um Product Data Manager profissional em 2026 terá vantagem simples: alguém que garante que cada investimento em dados tenha consumidor definido, expectativas claras, qualidade mensurável.

Enquanto outras empresas ainda estão debatendo “vamos fazer um data lake?”, essa já está pensando “qual problema esse dado resolve? Quem consome? Como sabemos que funciona?”

A oferta de pessoas que entendem produto e sistemas de dados? Praticamente inexistente no Brasil. Quem estiver preparado vai ter espaço para influenciar como a organização pensa dados — não porque é visionário, mas porque é literalmente a única pessoa pensando assim.

Leitura recomendada:

“Designing Data-Intensive Applications” — Martin Kleppmann
“Fundamentals of Data Engineering” — Joe Reis & Matt Housley