Com IA, desenvolvedores precisam virar mini-PMs

A mudança provocada pela IA

O texto defende que desenvolvedores precisam deixar de ser apenas executores de requisitos e passar a compreender o contexto de negócio e decidir parte do produto. O ponto de partida é uma conversa com um novo CEO, que, após ouvir outros executivos e líderes, concluiu que oferecer contexto empresarial aos engenheiros era o maior fator para elevar o desempenho de uma equipe. Segundo o autor, essa mudança já alterava a trajetória de empresas, embora a separação entre gerentes de produto e desenvolvimento ainda fosse predominante.

Nesse modelo tradicional, um gerente de produto ou analista de negócios aprende sobre o domínio e transforma o conhecimento em requisitos técnicos; em outra configuração, o gerente já tem experiência no setor e entende diretamente as necessidades dos usuários. O autor considera a segunda alternativa mais eficaz em domínios B2B complexos. Nos dois casos, porém, a equipe técnica permanece distante do domínio: recebe tarefas e devolve código funcionando.

Do código escasso às decisões de produto

Para o autor, esse formato era problemático, mas isso ficou mais evidente com a IA. Antes, projetos longos e o alto custo de escrever código faziam parecer aceitável gastar meses alinhando partes interessadas e reunindo requisitos. O planejamento detalhado, as estimativas e os tickets extensos eram respostas à possibilidade de retrabalho caro: um erro na definição de uma funcionalidade ou na arquitetura podia comprometer o projeto.

Com modelos de linguagem cada vez melhores em transformar linguagem natural em código, essa escassez teria sido reduzida. Isso desloca a atenção para perguntas anteriores à implementação: como os usuários utilizarão a solução e por que determinada funcionalidade é importante. Se os desenvolvedores não souberem responder, programar mais rápido terá benefício limitado.

A primeira etapa da mudança é dar aos engenheiros contexto e responsabilidade pelo problema, não apenas pela solução. A segunda é permitir que tomem decisões menores de produto, como aprimorar interações, lidar com casos-limite e definir respostas para erros. Os gerentes de produto continuariam responsáveis pelas grandes apostas, pela priorização e por decisões de maior risco ou sem uma alternativa claramente superior, preservando a coerência do produto. Já escolhas menores, com várias opções igualmente boas, não precisariam subir sempre na hierarquia.

O processo sugerido é pesquisar o problema, propor uma ou mais soluções, compartilhá-las no Slack ou em um RFC, aguardar e responder ao feedback, ajustar a proposta e, sem objeções, criar um ticket e implementar. Assim, o desenvolvedor ganha autonomia sem eliminar a revisão, enquanto o gerente de produto deixa de ser o gargalo de todas as decisões e pode se concentrar no trabalho estratégico. O autor ressalta, porém, que a gestão de produto não se torna obsoleta: alguém ainda precisa decidir o que fazer e o que não fazer.

Como facilitar a transição

O texto reconhece que a mudança pode ser bem recebida por uns e rejeitada por outros. O autor valoriza a iteração rápida e a autonomia sobre resultados, mas lamenta a perda do trabalho profundo dedicado a explorar um problema até chegar a uma compreensão clara. Ele também não oferece um roteiro universal. Sua previsão é que conhecer apenas sintaxe e frameworks não bastará e que a maioria dos desenvolvedores terá de se tornar uma espécie de gerente de produto ou poderá se tornar obsoleta, porque tarefas totalmente especificadas são material adequado para agentes de programação.

Para facilitar a transição, líderes devem compartilhar gravações de conversas com clientes e vendas, feedback do suporte e métricas como adoção, cancelamento e negócios ganhos ou perdidos. Também devem envolver engenheiros desde o início, reunindo gerente de produto, designer e engenheiro para trabalhar a partir do problema e testar protótipos, em vez de começar com especificações prontas. Por fim, é preciso formalizar quais decisões pertencem ao time e experimentar a mudança em uma equipe, por tempo limitado e com avaliação posterior. A conclusão é que a engenharia deve migrar de uma função de tradução para uma função de criação, e cabe aos gestores tornar essa passagem possível.