Tem alguns meses que eu não escrevo para o meu blog. A falta de tempo e a dedicação excessiva no trabalho têm me deixado com margem quase nula para sentar, organizar os pensamentos e publicar algo estruturado. A rotina de lidar com arquitetura de software e decisões de negócio consome uma energia mental considerável. Estou com a cabeça cheia de ideias que quero documentar aqui, mas vou, mais uma vez, tentar retomar o hábito da escrita de forma gradual.

Dentre os vários assuntos que venho maturando, quero falar sobre como o papel do Gerente de Produto mudou ao longo dos anos. Eu considero essa função uma das mais vitais na área de tecnologia, e é preocupante ver como muitas empresas hoje não dão o menor valor a esse profissional. Ou pior, não fazem a menor ideia do que deveriam esperar de uma pessoa que ocupa essa cadeira.

Como minha formação base é em engenharia de software e eu sempre gostei de programar e entender como as coisas funcionam no backend, ao longo dos anos fui percebendo uma dinâmica muito clara: a verdadeira responsabilidade do sucesso ou do fracasso de um software, de um sistema, de um aplicativo ou de qualquer produto de tecnologia recai sobre a pessoa de produto. Escrever código não é nada perto de saber o que fazer, por que fazer e qual problema exato estamos tentando resolver.

O esvaziamento da função de produto no mercado

Depois da explosão de cursos rápidos de formação e da sopa de letrinhas de cargos que misturam produto, design, marketing e growth, o mercado perdeu completamente a noção da importância e da gravidade que essa pessoa tem dentro de uma operação de tecnologia.

Eu já vi muitas empresas em que o profissional de produto desempenha, na prática, o papel de um anotador de pedidos. A rotina do sujeito se resume a escrever títulos vagos em cards do Jira e entrar na reunião diária apenas para perguntar aos desenvolvedores em que dia a tarefa fica pronta. Já vi contextos em que uma única pessoa cuida de quatro, cinco ou dez produtos ao mesmo tempo, simplesmente repassando instruções superficiais para os programadores e esperando que eles resolvam as lacunas de regra de negócio por conta própria.

E existem aqueles que eu considero os piores para a saúde de uma operação: os míopes. Eles só conseguem enxergar uma variável de cada vez. Não são capazes de analisar múltiplos cenários, entender as camadas de infraestrutura ou prever os impactos colaterais de uma decisão. Tem o míope de interface, que acha que tudo se resolve mudando a cor do botão ou o fluxo de telas, ignorando que o gargalo real está em uma consulta de banco de dados não otimizada. Tem o míope de escalabilidade, que quer adotar uma arquitetura complexa de microsserviços para um sistema interno que terá uma dúzia de acessos simultâneos. E tem o míope de receita, que empurra funcionalidades goela abaixo para bater uma meta trimestral, gerando uma dívida técnica que vai travar a equipe de engenharia pelo resto do ano.

Eu sei que estar aqui apontando falhas no mercado é uma posição confortável para mim, dado o tempo que tenho lidando com tecnologia. Pode soar babaca, eu confesso. Ter uma visão completa, que consegue transitar entre o código, a infraestrutura e o modelo de negócios, não é algo que se aprende em cursos de alguns meses ou um bootcamp de 15 dias. Exige anos de experiência e, principalmente, exige ter lidado com muitos tipos de projetos e problemas diferentes. Lidar com cenários caóticos ao longo da vida é o que te ajuda a construir uma visão de negócio apurada. Você só entende o impacto de uma falha de comunicação entre servidores depois que vê o faturamento da empresa parar numa sexta-feira à noite por causa de uma integração mal desenhada.

E é exatamente na compreensão sistêmica que a maioria das pessoas de produto falha hoje.

O abismo técnico e a geração do código gerado

Lidar com tecnologia é lidar com regras. Se você não é capaz de mapear e entender profundamente todas as regras que cercam o seu produto, você será incapaz de entregar um trabalho de qualidade. O fato de os times de engenharia terem sido tomados por profissionais de produto que não possuem base técnica tornou o cenário atual muito instável.

Eu sei que vão dizer que para mim é fácil falar isso porque eu entendo de código. Vão argumentar que a pessoa de produto não precisa saber programar ou dominar arquitetura de sistemas para construir um bom software. Eu concordo em parte com essas afirmações. O problema é o contexto em que estamos inseridos.

Desde a pandemia, o mercado global de tecnologia foi inundado por pessoas que fizeram treinamentos superficiais de programação. Profissionais que aprenderam a rodar comandos no terminal, mas não entendem os fundamentos de como a memória de um computador funciona ou como os protocolos de rede se comunicam. E, nos últimos anos, com a popularização da inteligência artificial generativa, a qualidade técnica de muitos programadores deteriorou de uma maneira que chega a assustar quem tem conhecimento das fundações. Ver uma nova geração chegando ao mercado e copiando blocos de código gerados por IA, sem entender a complexidade do que estão inserindo no repositório da empresa, dá medo.

Nesse contexto, se a sua empresa tem um time de desenvolvimento experiente, com arquitetos sólidos e bons profissionais de testes, você pode se dar ao luxo de ter uma pessoa de produto mediana. O time de engenharia compensa a falta de profundidade da especificação. Eles vão ler a tarefa rasa, vão identificar os buracos na regra de negócio, vão fazer as perguntas difíceis e vão construir uma solução que para em pé.

Mas, se o seu time de desenvolvimento não é maduro o bastante, ter alguém de produto que não sabe especificar é a receita garantida para bugs em produção, prazos estourados e falhas sistêmicas recorrentes.

O que me motivou a sentar e escrever isso hoje foi cruzar com uma publicação antiga do Jeff Atwood, onde ele diz que escrever código é fácil, difícil é entender o problema.

No cenário atual, cercados por inteligências artificiais treinadas com bilhões de parâmetros de código aberto, essa frase faz um sentido enorme. A inteligência artificial sabe a sintaxe. Ela sabe como escrever o laço de repetição. O que falta é quem saiba explicar o problema para a máquina e para os desenvolvedores menos experientes. Se você tem um profissional de produto técnico e experiente no seu time, ele consegue pegar um problema de negócios, destrinchar as regras e passar uma especificação tão bem amarrada que até um desenvolvedor júnior, com a ajuda de uma IA, consegue produzir um software funcional e seguro.

A anatomia de uma especificação técnica de verdade

Para ilustrar a diferença entre gerenciar tarefas e gerenciar produtos, vou usar um exemplo prático focado em ecossistemas de pagamentos. É um cenário complexo que envolve múltiplas integrações, dinheiro transitando e alta criticidade.

Imagine que a necessidade de negócio da empresa seja:

"Precisamos parar de perder vendas quando o sistema da operadora de cartão de crédito principal fica fora do ar."

Como um profissional de produto mediano escreve a especificação no sistema de gestão de tarefas:

Título: Fazer o sistema tentar cobrar de novo.

Descrição: Quando o cliente tentar comprar e der erro na adquirente A, o sistema deve tentar cobrar na adquirente B automaticamente para não perdermos a venda.

Critério de aceite: A venda precisa ser aprovada na segunda tentativa se a primeira falhar.

Essa especificação joga todo o peso da decisão arquitetônica e das regras de negócio no colo do desenvolvedor. Se o programador não tiver experiência prévia com arranjos de pagamento, ele vai colocar um bloco de tratamento de erro genérico, tipo um try/catch no código e tentar processar o cartão novamente para qualquer tipo de recusa.

Como um profissional maduro de produto técnico escreveria essa especificação:

Título: Implementação de roteamento inteligente e fallback lógico para transações de cartão de crédito.

Contexto: Nossa taxa de conversão tem quedas significativas devido a instabilidades da adquirente principal. Precisamos de um roteamento de contingência para a adquirente secundária, estritamente condicionado aos códigos de erro de resposta estruturados.

Regras de negócio e comportamento do sistema:

1. O fallback só deve ser acionado em caso de erros de infraestrutura da adquirente principal (exemplos: HTTP 500, falha de comunicação, timeout após 8000ms, ou códigos referentes a sistema indisponível).

2. O sistema não deve fazer retentativa se o erro retornado for ligado à segurança ou ao saldo do portador do cartão. Erros como "51 - Saldo Insuficiente", "05 - Não Honrar", "41 - Cartão Roubado" ou falhas de validação de CVV devem ser repassados imediatamente para o front-end. Tentar um cartão roubado em duas adquirentes diferentes aumenta nosso score de fraude e risco de chargeback. Além de prejudicar a reputação da empresa junto às bandeiras.

3. Tratamento de idempotência: Antes de acionar a adquirente secundária, o banco de dados deve registrar uma chave de idempotência atrelada ao identificador do pedido. Se houver falha de rede e a nossa aplicação não receber a confirmação se a adquirente principal efetuou a cobrança, o sistema não deve tentar novamente. O status do pedido deve ir para "processamento pendente" e aguardaremos a conciliação via webhook.

4. Criptografia: Os dados enviados para a adquirente secundária devem utilizar o padrão de criptografia exigido por eles para dados sensíveis do cartão.

5. Observabilidade: Todo evento de fallback acionado deve gerar um registro nos nossos sistemas de monitoramento contendo a identificação do lojista (merchant_id ), a bandeira do cartão e o tempo de resposta da tentativa original.

Os critérios de aceite que conseguem ver todo o cenário:

A tecnologia é apenas o meio de transporte da regra de negócio. Quando você altera o roteamento de pagamentos de uma empresa, você não está mudando apenas uma função em um servidor. Você está alterando o fluxo de caixa, a conciliação bancária, o atendimento ao cliente e as obrigações regulatórias. E é aqui que a maturidade do profissional de produto se prova.

Os critérios de aceite para essa tarefa não podem se limitar a verificar se o código compila ou se o teste automatizado passa. Uma especificação feita por alguém com extrema maturidade incluiria o seguinte plano de homologação cruzada:

1- Validação de engenharia: Simular timeouts forçados na adquirente principal e confirmar se a transação é roteada para a secundária respeitando a chave de idempotência. Confirmar que cartões com saldo insuficiente não disparam o roteamento.

2- Validação financeira e de tesouraria: A equipe financeira precisa homologar como essas transações vão cair na conta da empresa. A adquirente principal paga em D+30 (trinta dias). A adquirente secundária paga em D+14? Se sim, o fluxo de caixa da empresa muda quando o fallback é ativado. O profissional de produto precisa garantir que o sistema de relatórios financeiros consiga segregar as vendas por adquirente para que o financeiro saiba exatamente quanto dinheiro vai entrar em qual dia.

3- Validação de contabilidade e arquivos de conciliação: A maioria das empresas faz a conciliação de pagamentos lendo arquivos textuais padronizados (como posições bancárias ou extratos estruturados) que as operadoras enviam de madrugada. Se o pedido número 1000 foi processado na adquirente B, o sistema de gestão (ERP) da empresa precisa saber ler o arquivo de conciliação da adquirente B para dar baixa na nota fiscal. O critério de aceite exige que a equipe de contabilidade processe um arquivo de teste e confirme que o pedido não ficou pendente no balanço.

4- Validação de gravames e agenda de recebíveis: No mercado brasileiro, recebíveis de cartão de crédito podem ser dados como garantia para empréstimos. Isso é registrado em câmaras compensadoras. Se a empresa tem uma trava de domicílio bancário (gravame) configurada na adquirente principal, e o sistema começa a rotear as vendas para a adquirente secundária, essas vendas podem cair em uma conta bancária diferente, burlando a garantia do banco credor e gerando quebra de contrato. O gerente de produto precisa envolver o setor jurídico ou regulatório para garantir que a agenda de recebíveis da adquirente secundária esteja em conformidade com as obrigações da empresa.

5- Validação de atendimento ao cliente: A equipe de suporte precisa saber onde procurar a transação quando o cliente ligar reclamando. Se o atendente só tem acesso ao painel da adquirente principal, ele vai dizer ao cliente que a compra não existe, enquanto o cliente vê a cobrança na fatura do cartão (processada pela adquirente secundária). O critério de aceite exige que o painel interno de atendimento mostre de forma clara por qual caminho a transação foi aprovada.

Percebe a abrangência? Um desenvolvedor júnior, munido dessa instrução detalhada e com o apoio de ferramentas de assistência de código, consegue focar na implementação técnica com baixo risco de quebrar os processos internos da empresa. A complexidade do negócio foi mastigada, estruturada e documentada por quem entende as consequências de cada linha de código operando no mundo real.

Como as decisões de arquitetura afetam a sobrevivência da empresa

A falta de base técnica nos times de produto frequentemente resulta em decisões de engenharia equivocadas ou na incapacidade de questionar soluções propostas. Comparar abordagens tecnológicas e entender suas limitações práticas faz parte do trabalho.

Pense em um sistema que precisa processar atualizações de status de entregas de transportadoras e notificar os clientes. Um profissional de produto técnico sabe questionar a equipe de engenharia sobre a abordagem escolhida. Se estamos construindo um sistema que vai receber milhares de atualizações simultâneas em horários de pico, por que a equipe está propondo construir uma API síncrona tradicional que mantém conexões abertas com o banco de dados enquanto aguarda a resposta do servidor de e-mail? Não faria mais sentido usar uma arquitetura orientada a eventos, com filas de processamento, garantindo que o sistema absorva o pico de tráfego sem derrubar o servidor principal?

O gerente de produto não vai escrever os scripts de configuração da infraestrutura, mas ele precisa entender o impacto do bloqueio de conexões nos custos mensais de servidores. Ele precisa entender que um banco de dados relacional clássico e bem indexado resolve 99% dos problemas de consistência transacional de uma empresa, enquanto tentar adotar tecnologias baseadas em blockchain apenas para dizer que o sistema é moderno pode multiplicar os custos operacionais por dez, sem entregar nenhum valor real para o usuário final. É sobre conectar a ferramenta técnica à viabilidade econômica da operação.

O delírio coletivo da engenharia de prompt

Isso nos leva a um dos temas mais debatidos e distorcidos que surgiram no mercado de tecnologia recentemente. Muitas empresas e profissionais abraçaram o termo "engenharia de prompt" com um fervor idiota. Deixe-me colocar isso da forma mais direta possível: o conceito de engenharia de prompt, da maneira como está sendo vendido por influenciadores da internet, é um verdadeiro delírio. Não tem relação alguma com a realidade do que de fato faz um Engenheiro de Prompt.

Nestas últimas semanas, vimos uma enxurrada de vídeos e publicações de novas inteligências artificiais gerando sistemas básicos e jogos rodando no navegador com apenas uma ou duas linhas de comando em linguagem natural. A reação de parte do público foi de um deslumbre desproporcional. Tratar a capacidade de um modelo de linguagem gerar uma versão do jogo Mario Kart ou um formulário de cadastro como o fim da profissão de desenvolvedor é uma idiotice.

Gerar código isolado não é engenharia. Sistemas reais operam em ambientes caóticos. Eles possuem integrações assíncronas com sistemas legados que rodam em servidores antigos. Possuem rotinas de conciliação bancária que leem arquivos de texto CNAB, onde um espaço em branco no lugar errado corrompe o lote inteiro. Sistemas reais lidam com falhas de rede de provedores terceirizados, regras de segurança de dados rigorosas, políticas de cache que expiram no meio de uma transação e dezenas de tabelas correlacionadas em um banco de dados que sofre bloqueios por concorrência de acesso.

Um comando genérico em uma interface de chat não resolve problemas de concorrência de banco de dados em um sistema de controle de estoque durante uma liquidação nacional. O que resolve isso é o pensamento sistêmico e o domínio das regras de arquitetura. O profissional do futuro não é o digitador de prompts; é a pessoa que domina a lógica estrutural dos problemas e usa as ferramentas disponíveis para acelerar a escrita da solução que ela já desenhou na cabeça. Meu próximo artigo será focado exclusivamente em detalhar por que a ideia da engenharia de prompt no desenvolvimento de software corporativo é uma narrativa furada.

O que sobra no final do dia

Nós, que trabalhamos construindo plataformas digitais, esquecemos com frequência que os softwares não existem em um vácuo acadêmico. Eles existem para resolver problemas do mundo físico, facilitar processos logísticos, transacionar valores ou otimizar o tempo das pessoas. A tecnologia pura, sem o lastro da regra de negócio, é apenas um amontoado de instruções consumindo energia elétrica.

Não dá para culpar exclusivamente os desenvolvedores menos experientes pelas falhas sistêmicas que encontramos nos aplicativos do dia a dia. Muitos deles estão operando na ponta final de uma linha de produção, tentando executar tarefas que chegaram até eles mal pensadas, com buracos lógicos e sem validação das consequências operacionais. O trabalho de antecipar os cenários de falha, de compreender as limitações da infraestrutura contratada, de mapear como o erro de um servidor afeta a equipe de contabilidade e de garantir que a tecnologia escolhida seja adequada para o contexto do negócio... esse trabalho é o coração da área de produto.

Se a pessoa responsável pelo produto na sua empresa não entende as regras estruturais e os limites da plataforma que ela mesma ajuda a construir, ela não está gerenciando um produto. Ela está apenas movimentando cartões de um lado para o outro em uma tela de gestão ágil. E terceirizar a lógica fundamental do seu negócio para processos superficiais ou para ferramentas de geração de código sem a devida supervisão arquitetônica é caminhar para problemas muito caros no futuro.

Convido você a observar o ambiente em que trabalha. Quando uma demanda complexa surge, quem é a pessoa que senta para desenhar as regras de negócio em todas as suas ramificações antes de abrir o editor de código? As soluções construídas hoje na sua equipe são baseadas em fundamentos técnicos sólidos e conhecimento do negócio, ou são apenas tentativas sucessivas de fazer algo funcionar até a próxima atualização do sistema?