Parte 2: Como o Mercado Livre sustenta autonomia técnica em escala
O título de product manager, no Meli, não define liderança de produto. O contexto, sim.
Na Parte 1, exploramos como o Mercado Livre construiu uma operação de engenharia sem paralelos na América Latina, com 18 mil engenheiros, 30 mil deploys por dia e uma plataforma interna chamada Fury que transformou infraestrutura em vantagem competitiva.
Leia a parte 1:
Mas escala técnica, por si só, não sustenta velocidade.
Agora, na Parte 2, o foco muda: como uma empresa desse porte, com 18 mil engenheiros, consegue entregar produto sem depender de uma estrutura massiva de product managers?
A resposta está em uma das decisões mais ousadas do Meli: reduzir ao mínimo o número de PMs e transformar engenheiros em líderes de decisão.
O título de product manager, no Meli, não define liderança de produto. O contexto, sim.
Recado: Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse aqui. Cupom de 10%: PRODUCTGURUS
A proporção é estratégia, não descuido: 1 PM para cada 18 engenheiros
Segundo Sebastián Barrios, ex-SVP de Tecnologia, o Meli opera com menos de 1.000 PMs para mais de 18 mil engenheiros, ou seja, cerca de 5% da força técnica dedicada à gestão de produto.
A mensagem implícita é clara: PM não é responsável por pensar, e engenheiro não é apenas executor.
Durante o processo seletivo, candidatos a engenharia são avaliados por sua capacidade de entender problemas de produto, definir trade-offs e propor soluções de impacto, não apenas por escrever código bonito.
Quem entra, entra para decidir. E para entregar.
Para comparação: em empresas como Meta, Google e Amazon, a proporção gira entre 1 PM para cada 5 a 7 engenheiros, com estruturas que variam entre 15% e 30% de PMs na área de tecnologia.
O Meli escolheu ser muito mais enxuto. E isso muda tudo.
Por dentro do modelo: como isso funciona na prática
O alinhamento no Meli não acontece por meio de OKRs em cascata. Ele acontece com clareza de direção e liberdade de execução.
A cada trimestre, a liderança define de 3 a 5 grandes vetores estratégicos. Esses direcionadores, que aparecem em reuniões abertas, dashboards e canais internos guiam a atuação das squads.
O resto é decisão local.
A squad define o backlog.
A engenharia propõe soluções.
O PM (quando presente) facilita a priorização e a conexão com stakeholders.
Não há comitês, nem PMO. O ciclo é curto, direto e transparente.
E a responsabilização vem de outro lugar: da revisão pública entre pares.
Como a qualidade se sustenta sem chefes operacionais
No Meli, as decisões de produto, tech e entrega são todas registradas em canais visíveis.
Pull requests são públicos. Métricas de squad são acessíveis. O histórico de mudanças fica disponível para qualquer engenheiro consultar.
“You don’t report to your manager. You report to your peers.” - Sebastián Barrios
Isso cria uma cultura de cobrança lateral, onde:
Erros não passam despercebidos.
Propostas são debatidas em Slack e GitHub.
Squads de alto desempenho se tornam referência natural para os outros.
Essa cultura só funciona porque a estrutura de plataforma do Meli permite liberdade com segurança.
Fury: a plataforma que permite squads decidirem e lançarem por conta própria
A Fury, plataforma interna do Mercado Livre, é o pilar invisível da autonomia técnica.
Segundo estudo do evento Reinvent24, a Fury gerencia mais de 24 mil microsserviços, integra pipelines automatizados de CI/CD e oferece rollback automático, auditoria, controle de acesso, observabilidade e infraestrutura serverless.
Ou seja: ela remove a complexidade para que as squads possam lançar produtos com independência real.
Ela também é:
Usada voluntariamente (os devs optam por ela porque é melhor).
Integrada com modelos de IA, como Verdi e GitHub Copilot, que aceleram desenvolvimento e revisão.
Escalável por região: a mesma plataforma opera no Brasil, México e Argentina.
A IA, nesse caso, não substitui decisão. Ela libera espaço para ela.
Engenharia como centro da decisão de produto
Em vez de criar squads onde o PM dita e o engenheiro executa, o Meli opera com o inverso: times onde o engenheiro propõe e o PM complementa.
A maioria das decisões de produto vem da engenharia, porque a engenharia tem:
Contexto de negócio.
Autonomia de execução.
Acesso direto ao impacto (via métricas, logs, NPS e suporte).
O papel do PM, nesse sistema, é traduzir prioridades amplas em clareza de critérios. O poder vem do contexto e não do cargo.
Fontes das Partes 1 e 2