Introdução
Recentemente tive a oportunidade de falar no GDG Rio de Janeiro sobre uma transformação que venho vivendo na minha rotina de trabalho: a transição de um papel tradicional de Product Manager para algo que aqui na Árvore temos chamado de Product Engineer.
Não é nem produto virando engenharia, e nem de engenharia virando produto.
É algo novo, no meio do caminho.
E, curiosamente, essa transformação começou com duas mudanças acontecendo ao mesmo tempo: uma mudança organizacional na área de tecnologia e a adoção mais intensa de ferramentas de AI no ciclo de desenvolvimento.
Neste texto, compartilho um pouco de como essa mudança aconteceu e o que ela mudou na prática na minha forma de trabalhar.
O jeito antigo
Antes dessa mudança, minha rotina como Product Manager era bastante familiar para quem trabalha com produto.
Grande parte do meu tempo era dedicada a atividades como:
- cerimônias ágeis
- mediação entre áreas
- documentação
- entrevistas com usuários
- visitas a clientes
- definição de roadmap e OKRs
- reuniões estratégicas
- acompanhamento de métricas
E é claro que esse modelo continua funcionando em muitas organizações.
Mas existe uma característica importante nele: a separação entre quem pensa o produto e quem implementa o produto.
Como PM, eu ajudava a estruturar o problema, priorizar soluções e orientar o desenvolvimento. Mas a tradução dessas decisões para código dependia completamente da engenharia.
A mudança na área de tecnologia
Em 2025, a área de tecnologia da Árvore passou por uma revisão estrutural.
Parte dessa mudança envolveu a adoção de um modelo inspirado no Shape Up, em substituição ao formato tradicional de squads trabalhando em ciclos curtos de sprint.
Isso trouxe algumas mudanças importantes:
- ciclos de desenvolvimento mais longos (6 semanas)
- menos rigidez de cerimônias
- propostas de iniciativas mais autorais
- times mais dinâmicos, formados de acordo com o problema a ser resolvido
Mas talvez a mudança mais significativa tenha sido a reconfiguração dos papéis dentro da área.
Ao invés de funções rigidamente separadas, começamos a experimentar uma maior interseção entre produto, design e engenharia.
Foi nesse contexto que começou a surgir o papel que chamamos internamente de Product Engineer.
Quando achei que produto estava acabando
Honestamente, minha primeira reação a essa mudança foi de preocupação.
Será que ela significava que a disciplina de produto estava sendo diluída, minimizada?
Mas, com o tempo, fui percebendo que, na verdade, a mudança representava uma expansão do papel de produto dentro da tecnologia.
Se antes o pensamento de produto estava concentrado em uma função específica (o PM), agora ele passava a influenciar mais diretamente o modo como as soluções eram construídas.
Na prática, algo como isto começou a acontecer:
- produto passou a operar mais próximo da implementação
- engenharia passou a operar com mais contexto de usuário e negócio
Uma forma simples de visualizar isso é imaginar um yin-yang entre produto e engenharia.
O papel da AI nessa mudança
Nesse mesmo período, ferramentas de AI começaram a se tornar parte do nosso cotidiano de desenvolvimento.
E comecei a refletir sobre duas formas possíveis de usar esse tipo de tecnologia.
A primeira é o aprofundamento vertical: um especialista usa AI para se tornar ainda melhor no que já faz.
A segunda é uma expansão horizontal: usar AI para ampliar o alcance do que uma pessoa consegue fazer.
Foi daí que me ocorreu a seguinte metáfora:
A AI não necessariamente me tornou uma engenheira full-stack.
Mas ela ampliou minha capacidade de participar do processo de construção do software.
O que mudou na prática
Hoje minha rotina já inclui atividades que antes não faziam parte do meu dia a dia.
Entre elas:
- navegar em repositórios de código
- abrir e revisar pull requests
- implementar pequenas mudanças com apoio de AI
- testar soluções localmente
- trabalhar em pareamento com desenvolvedores
Hoje já tenho mais de 70 contribuições no GitHub, algo que seria impensável para mim alguns meses atrás.
Grande parte desse processo acontece com apoio de ferramentas como o Cursor, que permitem interagir com o código por meio de linguagem natural.
E, nessa nova rotina, eu reparei em algo importante: que a minha principal vantagem nesse processo não é técnica. Ela vem da minha bagagem de produto.
Depois de alguns anos trabalhando com o mesmo sistema, acumulamos um tipo de conhecimento que não está necessariamente documentado em nenhum lugar: o conhecimento das regras de negócio, das exceções, das decisões históricas e das necessidades reais dos usuários.
Esse contexto faz muita diferença quando estamos trabalhando com AI.
Enquanto uma pessoa puramente técnica pode entender melhor a estrutura do código, a pessoa de produto costuma ter mais clareza sobre o que exatamente precisa acontecer no comportamento do sistema.
Isso aparece especialmente na hora de escrever prompts.
Quando descrevo uma alteração para a AI, eu não estou apenas dizendo o que mudar no código. Eu estou explicando:
- qual é a regra de negócio envolvida
- qual comportamento do usuário precisa ser preservado
- quais exceções precisam ser consideradas
- como aquela mudança se encaixa no fluxo maior do produto
Esse tipo de direcionamento ajuda a AI a gerar implementações mais próximas do que realmente precisamos.
A complementariedade entre produto e engenharia
Quando comecei a trabalhar dessa forma, percebi que cada área continua trazendo um tipo de contribuição essencial.
Do lado de produto, entram coisas como:
- entendimento de regras de negócio
- capacidade de priorização
- contexto do usuário
- escrita de prompts mais eficientes
Do lado de engenharia, continuam sendo fundamentais:
- arquitetura e escalabilidade
- revisão crítica de código
- infraestrutura e segurança
- boas práticas de desenvolvimento
Não se trata de substituir um papel pelo outro.
Trata-se de aumentar a zona de interseção entre eles.
Tornando o PM mais “fazente”
No fundo, a principal mudança que senti ao longo desses últimos meses foi essa: a AI tem nos permitido reduzir a distância entre pensar uma solução e começar a construí-la.
Isso faz com que o trabalho de produto se torne mais concreto, mais experimental e mais próximo da implementação.
Produto deixa de ser apenas gestão.
Ele passa a se aproximar da engenharia no sentido mais literal da palavra: pensar, estruturar e construir.
Pra quem tem o perfil mão-na-massa como eu, essa nova era tem sido uma aventura muito gratificante! :)