Product Management — o futuro é dos Builders
Semana passada vi um time financeiro escrever scripts em Python para automatizar uma rotina que antes consumia horas por semana. No mesmo período, um time jurídico começou a usar o NotebookLM para extrair cláusulas de contratos de mais de 100 páginas. E tenho visto, cada vez com mais frequência, times internos substituindo planilhas por pequenos sistemas construídos no Lovable em uma tarde.
Nenhuma dessas soluções passou por um time de engenharia de software ou por Product Managers.
Esse movimento tem me feito refletir bastante sobre as mudanças que a inteligência artificial está trazendo para o fluxo de desenvolvimento de produtos e, mais especificamente, para a cadeira de Product Management. A reflexão veio de lugares diferentes: um papo sobre liderança de produto na Product Arena, o artigo The product lifecycle is broken do Ravi Mehta, e um episódio do Lenny’s Podcast com Nikhyl Singhal.
Tudo isso converge para a quebra de um grande paradigma do nosso mercado: a de que construir software é, necessariamente, caro e demorado.
Como era o cenário antes
Quando comecei a aprender sobre gestão de produtos digitais, me deparei logo de cara com o fluxo clássico de desenvolvimento em Cascata, que se assemelha muito com uma esteira de produção Fordista.
O PM define o “o quê”, senta com o Designer para definir o “como”, depois envolve o Tech Lead que monta a especificação técnica e por fim o trabalho vai para desenvolvimento, testes e implantação. Cada um com seu papel bem definido e sua arena de atuação delimitada.
Com o tempo, o modelo Ágil surgiu como uma resposta a esse formato: ciclos curtos, entregas incrementais, aprendizado a cada iteração e ajuste de rumo. É, sem dúvida, uma evolução importante — e mudou a forma como boa parte dos times trabalha hoje. Mas mesmo em times que se dizem ágeis, a estrutura de papéis tende a ser a mesma: PM, Designer, Engenheiro. E qualquer experimento real, por menor que seja, ainda depende da fila do time de desenvolvimento para sair do papel.
Esse modelo fazia sentido porque construir software sempre foi caro e demorado. Adiávamos ao máximo o desenvolvimento, testando hipóteses e validando cenários antes de escrever uma linha de código, porque cada hora de engenharia valia muito. Como consequência, muitas iniciativas simplesmente nunca viravam prioridade.
Como a IA tem mudado o jogo
Hoje, em uma tarde, é possível colocar um sistema no ar — com autenticação via SSO, banco de dados, backend e frontend — hospedado em plataformas como Supabase ou Vercel, entre outras.
Isso muda drasticamente a forma como a disciplina de gestão de produtos trabalha. Nosso papel continua sendo descobrir como atingir metas e objetivos de negócio, a diferença é que o gargalo deixou de estar no desenvolvimento e passou a estar no processo de descoberta.
É nesse cenário que a figura do Builder ganha corpo. O gestor de produtos moderno, na minha visão, deveria estar menos preocupado em construir um PRD com requisitos detalhados e mais preocupado em construir experimentos, usando IA, para validar suas hipóteses e ideias de negócio.
Isso não significa matar o Ágil — significa adaptá-lo. Os ciclos curtos e o aprendizado iterativo continuam fazendo todo o sentido; o que muda é que eles ganham um novo protagonista. O PM agora pode construir seu próprio experimento, aprender com ele e ajustar o rumo sem precisar entrar na fila do time de engenharia.
O Product Manager de hoje é uma pessoa mais hands-on e menos dependente de outros times para conquistar seus objetivos. Conseguimos construir MVPs inteiros para validar hipóteses sem envolver o time de desenvolvimento. E como o custo e o tempo para construir caíram muito, esse MVP pode ser descartado depois — o que importa é o aprendizado que ele gerou.
O outro lado da moeda
Toda essa liberdade tem um custo. O primeiro é a governança: com vários times construindo soluções em paralelo, o código — que antes vivia em um ambiente controlado pela Engenharia — passa a estar muito mais disperso. Gerenciar isso é um desafio real.
O segundo são as vulnerabilidades de segurança introduzidas por soluções vibe-codadas. Sabemos que segurança ainda é uma frente em que muitos LLMs falham. Acredito que aqui existem dois caminhos complementares: um ferramental, com agentes especialistas em segurança revisando o código gerado; e outro cultural, explicando aos times que segurança precisa ser prioridade tanto quanto a funcionalidade daquilo que estão construindo.
Uma visão de futuro
Assim como a produtividade cresceu com a IA, as expectativas de entrega têm crescido na mesma proporção. Se antes esperava-se que gerássemos valor em três frentes, hoje espera-se que entreguemos em dez. Nesse cenário, o perfil que tende a se destacar — não só em produto — é o de execução: o profissional hands-on que constrói soluções e pensa AI First.
A cadeira de gestão de produtos está em constante mudança, e o ferramental que aprendemos precisa evoluir junto. Que a nossa caixa de ferramentas contenha, cada vez mais, MVPs e protótipos — e cada vez menos PRDs e especificações de negócio.
Vamos conversar?
Se você trabalha com produto e tem visto algo parecido (ou algo completamente diferente) no seu dia a dia, gostaria muito de ouvir seu ponto de vista. Me chama no LinkedIn — o link está aqui no site — e vamos trocar uma ideia.