Product Engineer na PostHog: Como o Papel Realmente Funciona

PostHog construiu uma empresa de $450M sem product managers

Isso não é um erro de digitação. A PostHog, plataforma open-source de product analytics, atingiu um valuation acima de $450 milhoes (conforme reportado na cobertura da Serie B pelo TechCrunch em 2023) empregando zero product managers tradicionais. Em vez disso, apostaram tudo em um papel que chamam de product engineer.

De acordo com o guia da product.engineer, um product engineer é um engenheiro de software que é dono de todo o ciclo de vida do produto: conversar com usuários, decidir o que construir, construir, lançar e medir se funcionou. A PostHog não inventou esse conceito, mas talvez tenha construído a estrutura organizacional mais deliberada em torno dele entre todas as empresas no mesmo estágio.

Como a pesquisa da product.engineer mostra, o modelo da PostHog é um dos mais deliberados exemplos de cultura de product engineering. Este artigo detalha exatamente como a PostHog opera. Como estruturam times. Como contratam. Quanto pagam. Por que acreditam que product managers criam mais problemas do que resolvem. E se esse modelo pode funcionar para o seu time ou para a sua carreira.

Se você esta considerando uma vaga na PostHog, avaliando o modelo deles para a sua própria empresa, ou simplesmente curioso sobre como uma cultura de product engineering funciona quando levada ao extremo lógico, este é o deep dive que você precisa.

O modelo organizacional da PostHog

Times pequenos, propriedade total

A PostHog se organiza em torno do que chamam de "small teams." Cada time tem tipicamente de duas a seis pessoas, e cada engenheiro naquele time funciona no papel combinado de construtor-e-dono. Não existem product managers dedicados. Não existem project managers. Ninguém cujo trabalho em tempo integral seja escrever specs ou gerenciar backlogs.

Cada small team é dono de uma área específica do produto. No início de 2026, essas áreas incluem:

• Product Analytics (o produto core de dashboards e insights)
• Session Replay (gravação de sessões de usuários)
• Feature Flags (experimentacao e rollouts)
• Surveys (feedback de usuários in-app)
• Data Warehouse (conexão com fontes de dados externas)
• Web Analytics (tracking leve de websites)
• Pipeline (ingestao e transformacao de eventos)
• Infrastructure (manter tudo funcionando)

O lider de cada small team e geralmente o engenheiro mais senior. Ele define a direção, mas também escreve código todos os dias. Não existe uma camada gerencial que para de codar.

O que "sem PMs" realmente significa

Preciso ser preciso aqui, porque "sem PMs" e constantemente mal interpretado. Não significa que ninguém faz trabalho de produto. Significa que os engenheiros fazem o trabalho de produto eles mesmos. As responsabilidades que um PM lidaria em uma empresa tradicional ainda são tratadas. Elas apenas são distribuidas pelo time de engenharia.

Especificamente, engenheiros na PostHog devem:

1. Conversar com clientes diretamente via canais da comunidade no Slack, tickets de suporte e entrevistas com usuários
2. Priorizar seu próprio roadmap com base em feedback de clientes, dados de uso e metas de negócio
3. Projetar soluções (as vezes com input do designer único por área)
4. Construir e lançar com overhead mínimo de revisão
5. Medir resultados usando o próprio produto (naturalmente)
6. Escrever conteúdo público incluindo entradas de changelog, tutoriais e blog posts

Isso não é uma aspiracao teorica. E a realidade operacional diaria. A PostHog pública seu handbook de forma aberta, e você pode ler as expectativas palavra por palavra.

Por que eliminaram o papel de PM

James Hawkins, CEO da PostHog, escreveu extensivamente sobre essa decisão. O raciocínio central se resume a três crencas:

Crenca 1: Perda de contexto mata velocidade. Cada handoff entre um PM é um engenheiro degrada a qualidade da informação. O PM conversa com o usuário, interpreta sua dor, escreve um documento e passa uma versão filtrada para o engenheiro. Na hora que o código e escrito, o contexto original já se foi. Quando o engenheiro conversa com usuários diretamente, essa compressao nunca acontece.

Crenca 2: Engenheiros que entendem usuários constroem produtos melhores. Um PM pode escrever uma spec dizendo "usuários querem tempos de carregamento mais rápidos." Um engenheiro que assistiu um usuário ficar encarando um spinner por 8 segundos entende algo mais profundo do que qualquer ticket consegue transmitir. O peso emocional da observação direta muda como você constrói.

Crenca 3: Times pequenos se movem mais rápido sem overhead de coordenação. PMs gastam quantidades enormes de tempo coordenando entre design, engenharia, lideranca, vendas e suporte. Remova o PM, de aos engenheiros acesso direto a todos esses canais, e você elimina reunioes que existem puramente como mecanismos de repasse de informação.

Os dados internos da PostHog suportam isso. De acordo com suas métricas publicadas, eles lançaram mais de 200 melhorias de produto em um único trimestre com um time de aproximadamente 45 pessoas. Isso é aproximadamente uma melhoria lançada por pessoa por semana, um ritmo extraordinário para um produto B2B SaaS.

Como a PostHog contrata product engineers

O perfil que procuram

As descricoes de vaga da PostHog são refrescantemente específicas sobre o que querem. Com base em suas vagas publicas e handbook, o candidato ideal:

• Tem 5+ anos de experiência em engenharia de software
• Já lançou produtos que usuários reais dependiam
• Consegue articular opinioes sobre o que construir, não apenas como construir
• Escreve bem (porque grande parte do papel envolve comunicação escrita)
• Se sente confortavel conversando com clientes sem um PM como intermediário
• Tem opinioes fortes sobre qualidade de produto e experiência do usuário
• Prefere lançar rápido a planejar extensivamente

Note o que esta ausente desta lista. Não há mencao a requisitos específicos de tech stack (embora rodem principalmente Python, TypeScript, React, ClickHouse e Django). Não há enfase em system design em hiperescala. O sinal que otimizam e product sense combinado com velocidade de entrega.

O processo de entrevista

A PostHog pública seu processo de entrevista abertamente. Tipicamente segue esta estrutura:

O SuperDay é o elemento mais distintivo. Em vez de um desafio de código artificial, eles pagam candidatos para trabalhar em um problema real por um dia inteiro. Você recebe acesso ao codebase, uma issue real para resolver, é a expectativa de lançar algo (ou fazer progresso significativo). Eles pagam candidatos por esse tempo, o que é tanto etico quanto revelador. Se você consegue entregar valor real em um dia com orientação mínima, provavelmente pertence a esse papel.

Essa abordagem filtra pesadamente por autonomia. Se você precisa de direção extensiva, specs detalhadas ou apoio constante em decisões de arquitetura, o SuperDay vai expor isso imediatamente. Também é um filtro para velocidade de entrega. Um dia não é tempo suficiente para planejamento extenso. Você tem que tomar decisões rapidamente e se mover.

O que desqualifica candidatos

Com base em padrões de pessoas que compartilharam suas experiencias de entrevista na PostHog publicamente, sinais comuns de rejeicao incluem:

• Fazer perguntas demais antes de tentar uma solução (sugerindo dependência de specs)
• Propor arquiteturas excessivamente complexas quando uma abordagem mais simples funcionaria
• Focar em edge cases antes de resolver o problema central
• Não demonstrar curiosidade sobre usuários ou impacto no negócio
• Escrever código que funciona mas e difícil para outros entenderem

O padrão subjacente: eles rejeitam pessoas que otimizam para corretude em vez de velocidade, ou que constroem para engenheiros em vez de para usuários. Se você quer se preparar para uma entrevista na PostHog, estude os padrões que cobrimos no nosso guia de entrevista para product engineer.

Quanto a PostHog paga product engineers

Filosofia de remuneração

A PostHog usa uma calculadora de remuneração transparente. E uma das poucas empresas que pública sua formula salarial abertamente. A formula leva em conta:

• Nível do papel (IC5, IC6, etc.)
• Localizacao (ajustado por um fator de localizacao baseado no custo de mao de obra)
• Step dentro do nível (progressão de experiência dentro de um determinado nível)

De acordo com a calculadora pública deles (início de 2026) e cruzada com dados do Levels.fyi, a remuneração na PostHog cai nessas faixas:

Esses números incluem salário base mais equity. A PostHog concede equity como opcoes com vesting de 4 anos e cliff de 1 ano. Para uma empresa no estágio de valuation deles, o upside de equity é real mas especulativo.

Comparado a empresas FAANG, a remuneração em dinheiro da PostHog e menor. Um engenheiro senior no Google ou Meta pode ganhar $350K-$500K em comp total. Mas a comparação e enganosa. A PostHog oferece algo que essas empresas não conseguem: autonomia radical, impacto direto no cliente é a ausência de burocracia organizacional. Para uma análise mais profunda das faixas de mercado, veja nosso detalhamento salarial.

Para colocar em perspectiva brasileira: mesmo com o fator de localizacao mais baixo (0.55x), um engenheiro senior remoto no Brasil ganharia aproximadamente $110K-$148K por ano em comp total, o que é significativamente acima do mercado local para a maioria das empresas de tecnologia brasileiras.

Ajustes salariais por localizacao

A PostHog e totalmente remota e ajusta a remuneração com base na localizacao. Suas bandas publicadas mostram multiplicadores de localizacao variando de 0.55x (regiões com custo de mao de obra mais baixo) a 1.15x (San Francisco, Nova York). Essa é uma prática comum entre empresas remote-first, embora permaneca controversa.

A implicacao prática: um engenheiro senior em Lisboa ganha aproximadamente 70% do que o mesmo papel paga em San Francisco. Se isso é justo depende da sua filosofia sobre pagar por mao de obra versus pagar por output. A PostHog argumenta que ajustes de localizacao os ajudam a contratar globalmente enquanto permanecem competitivos em cada mercado local.

Para desenvolvedores no Brasil, isso significa que você pode acessar salários em dolar significativamente acima do que empresas locais como iFood, Nubank ou TOTVS pagam, mesmo com o desconto de localizacao aplicado.

Um dia na vida de um product engineer na PostHog

Como é a realidade diaria? Com base em posts de funcionarios, aparicoes em podcasts e documentação do handbook, aqui esta um dia representativo:

Manhã (trabalho assincrono):

• Checar dados de uso do PostHog para sua área de produto (literalmente usando o produto que você constrói)
• Ler e responder feedback de usuários na comunidade do Slack
• Revisar PRs abertos de colegas de time
• Lançar uma melhoria pequena que estava em progresso

Meio do dia (construção focada):

• Trabalhar no projeto principal do sprint (ciclos de 2 semanas)
• Tomar decisões de design on the fly, consultando o designer do time quando necessário
• Fazer push de código para produção (PostHog faz deploy varias vezes por dia)

Tarde (comunicação e planejamento):

• Escrever um update breve no canal do time sobre o que foi lançado
• Participar de um standup de 30 minutos (a única reuniao recorrente que a maioria dos times tem)
• Gravar um Loom curto para uma feature que você lançou, para o changelog
• Ler tickets de suporte ao cliente para identificar padrões

O que é notavelmente ausente: nada de sprint planning que leva duas horas, nenhuma sessão de grooming de backlog, nenhum sync com PM, nenhum comite de design review, nenhum board de revisão de arquitetura. A carga de reunioes e mínima pelos padrões da industria. A maioria dos engenheiros da PostHog reporta gastar menos de 4 horas por semana em reunioes.

O modelo da PostHog comparado a outras culturas de product engineering

A PostHog não esta sozinha em abracar essa abordagem, mas sua implementação e das mais extremas. Aqui esta como se comparam:

A Linear chega mais perto do modelo da PostHog mas mantém direção de founders mais forte nas decisões de produto. A Vercel da aos engenheiros propriedade significativa mas mantém PMs para iniciativas estrategicas maiores. O Stripe emprega PMs mas tem uma cultura forte de pensamento de produto liderado por engenheiros.

Da minha perspectiva: o que a PostHog acerta e erra

Tendo contratado mais de 600 engenheiros em duas startups e na AWS, e orientado mais de 12.000 engenheiros em crescimento de carreira, vi todos os sabores de organização de engenharia. O modelo da PostHog e impressionante mas não universalmente aplicavel.

O que eles acertam: eliminar o gap de contexto entre usuários e builders produz produtos genuinamente melhores. Toda vez que vi um engenheiro sentar com um usuário real por 30 minutos, o próximo PR dele era fundamentalmente diferente do que teria sido lendo um ticket. A PostHog sistematiza essa exposição. Eles também atraem talentos extraordinarios porque seu modelo apela para o tipo de engenheiro senior que saiu de uma big tech precisamente porque estava cansado de construir specs que outra pessoa escreveu.

O que é mais difícil de replicar: esse modelo requer um bar de contratação excepcionalmente alto. Nem todo engenheiro quer (ou consegue) fazer trabalho de produto. Nem todo engenheiro é articulado o suficiente para escrever conteúdo voltado ao cliente ou confiante o suficiente para conduzir entrevistas com usuários. A PostHog consegue manter isso porque são seletivos, bem financiados e constroem um produto para desenvolvedores (que são mais faceis para engenheiros terem empatia). Uma empresa construindo software de seguros para reguladores de sinistros enfrentaria um desafio totalmente diferente. O gap de expertise de domínio entre builder e usuário e muito maior.

Você deveria se candidatar a PostHog como product engineer?

Você prosperaria la se:

• Você tem opinioes sobre o que construir, não apenas como
• Você acha energizante conversar com usuários ao inves de drenante
• Você prefere lançar coisas imperfeitas rápido a lançar coisas perfeitas devagar
• Você escreve bem e gosta de comunicação pública
• Você esta confortavel tomando decisões sem aprovação de cima
• Você quer seu impacto medido em resultados de usuário, não em story points

Você teria dificuldade la se:

• Você prefere desafios técnicos profundos a amplitude de produto
• Você não gosta de trocar contexto entre codar, escrever e pesquisar usuários
• Você precisa de specs claras antes de começar a construir
• Você acha conversas com clientes desconfortaveis ou improdutivas
• Você valoriza estabilidade e processo ao inves de velocidade e ambiguidade
• Você define senioridade apenas por profundidade técnica

Se o modelo da PostHog te empolga mas você não tem certeza se esta pronto, leia nosso guia sobre como se tornar um product engineer. A transição de engenharia de software tradicional para product engineering e aprendivel, mas requer prática deliberada em áreas que a maioria dos engenheiros nunca desenvolve. Você também pode navegar vagas atuais no nosso roundup de vagas para product engineer para ver como as vagas da PostHog se comparam a outras no mercado.

As implicacoes mais amplas para a industria

O sucesso da PostHog sem PMs não é um argumento de que todas as empresas deveriam demitir seus product managers. E evidencia de que uma estrutura organizacional específica, construida em torno da propriedade de produto liderada por engenheiros, pode produzir resultados excepcionais quando as condicoes estão certas.

Essas condicoes incluem: um produto focado em desenvolvedores, uma empresa totalmente remota com normas fortes de comunicação escrita, um bar de contratação alto com dia de trial pago, times pequenos com limites claros de propriedade, transparência radical (handbook público, remuneração pública, roadmap público) e lideranca que genuinamente acredita que engenheiros devem ser donos de resultados de produto.

Se três ou quatro dessas condicoes estão faltando, o modelo colapsa. Você acaba com engenheiros que não conversam com usuários, constroem o que for tecnicamente interessante e nunca medem resultados. Isso não é product engineering. E engenharia sem accountability.

Para mais sobre as diferenças entre essas abordagens, veja nosso detalhamento de product engineer vs software engineer.

Principais conclusões

• A PostHog eliminou product managers inteiramente e da a cada engenheiro ownership completo da descoberta do problema até a feature lançada.
• A contratação deles prioriza pensamento de produto sobre expertise técnica especifica; eles ensinam o stack, não o instinto.
• Engenheiros assistem gravacoes de sessao de usuários reais horas apos lançar e escrevem resenhas publicas de ship com dados.
• O modelo da PostHog prova que times pequenos e autonomos de product engineers podem superar organizações muito maiores.

FAQ

Qual tech stack a PostHog usa para product engineers?

A stack principal da PostHog inclui Python (Django) para o backend, TypeScript e React para o frontend, ClickHouse para dados de analytics, PostgreSQL para dados da aplicação e Redis para caching. Fazem deploy na AWS usando Kubernetes. No entanto, o processo de contratação deles enfatiza pensamento de produto acima de expertise em tecnologia específica. Eles declararam publicamente que preferem contratar um ótimo pensador de produto que precisa aprender ClickHouse do que um especialista em ClickHouse que não consegue tomar decisões de produto.

Você precisa de experiência em product management para ser product engineer na PostHog?

Nenhuma experiência formal de PM e necessária. O que a PostHog procura e evidencia de que você tomou decisões de produto no passado, seja em um emprego anterior, um projeto pessoal ou uma contribuição open-source. Demonstrar que você consegue priorizar com base em valor para o usuário ao inves de elegancia técnica importa mais do que qualquer certificação de PM ou título anterior de PM.

Como o salário de product engineer na PostHog se compara ao FAANG?

A remuneração em dinheiro na PostHog e tipicamente 60-80% do que empresas FAANG pagam para senioridade equivalente. No entanto, a PostHog oferece equity significativo em uma empresa de alto crescimento, autonomia radical, carga mínima de reunioes é o tipo de impacto direto que grandes empresas não conseguem proporcionar. Muitos engenheiros que entram na PostHog explicitamente trocam dinheiro por propriedade e agencia. Se essa compensação faz sentido depende da sua situação financeira e objetivos de carreira.

O modelo sem PM da PostHog pode funcionar em empresas maiores?

Se torna significativamente mais difícil conforme empresas escalam além de 100-150 engenheiros. A PostHog consegue manter o modelo porque seu produto e voltado para desenvolvedores (reduzindo o gap de empatia com o usuário), seus times permanecem pequenos (2-6 pessoas) e seu bar de contratação e extremamente alto. Empresas como o Spotify tentaram modelos similares e eventualmente reintroduziram PMs em escala. O sweet spot para esse modelo puro parece ser empresas com menos de 200 engenheiros construindo produtos técnicos.

Qual é o caminho de carreira para um product engineer na PostHog?

A PostHog oferece uma trilha IC (contribuidor individual) que progride de mid-level passando por senior até staff e níveis de principal. Não há requisito de migrar para gestão. Os ICs mais seniors na PostHog influenciam a estratégia de produto no nível da empresa enquanto ainda escrevem código diariamente. Alguns lideres de time tem responsabilidades de gestão, mas essas são leves comparadas a papeis tradicionais de engineering management. A PostHog explicitamente valoriza contribuição IC acima de influência organizacional.

Leitura relacionada

• O Que é um Product Engineer? O Guia Definitivo
• Product Engineer Job Description: O Que Procurar
• Salário de Product Engineer: O Que o Mercado Paga em 2026
• Entrevista para Product Engineer: Como se Preparar é o Que Esperar
• Como se Tornar um Product Engineer