Passei por seis empresas em domínios bem diferentes: e-commerce, infraestrutura de pagamento, viagens, logística, core banking e hoje governança corporativa. A conclusão que ficou de tudo isso é desconfortável para quem gosta de código.
O gargalo quase nunca é técnico.
O que trava produto é decisão errada tomada cedo, com informação que estava disponível e ninguém buscou. E na maioria das vezes a pessoa em melhor posição pra evitar aquilo era a engenharia, que ficou calada porque “produto que decide”.
O que muda quando o engenheiro entende o negócio
Uma cena que se repete.
Chega a demanda: “adicionar filtro por data no relatório”. O engenheiro estima três dias, faz, entrega. Ninguém usa.
O que aconteceu foi que alguém pediu o filtro porque estava exportando pra planilha toda segunda pra montar um número que a diretoria pedia. O problema era o número, não o filtro. A solução certa era um indicador na tela, meio dia de trabalho, e resolveria de verdade.
A pergunta que economizaria três dias é uma só: “pra que você precisa disso?”.
Ela não é falta de educação. É a diferença entre executar escopo e resolver problema, e é o que separa quem é caro de quem é valioso.
As quatro perguntas
Não precisa de curso de produto. Precisa de quatro perguntas antes de estimar.
Quem vai usar e com que frequência? Uma funcionalidade que três pessoas usam uma vez por trimestre pede uma solução diferente da que trezentas pessoas usam por dia. Muda a arquitetura, não só a prioridade.
O que essa pessoa faz hoje sem isso? Sempre existe um jeito atual. Planilha, gambiarra, pedido pro suporte. Entender o jeito atual mostra o problema real e quase sempre revela que o pedido era um sintoma.
Como a gente vai saber que deu certo? Se ninguém consegue responder, a funcionalidade não tem critério de sucesso, e sem critério de sucesso ela nunca vai ser removida nem melhorada. Só vai existir.
O que acontece se a gente não fizer? A resposta honesta às vezes é “nada”. Vale saber antes.
O trecho que a engenharia enxerga sozinha
Tem um tipo de informação que só quem constrói tem, e ela muda decisão de produto o tempo todo.
Custo relativo. “Essa versão custa duas semanas, essa outra custa dois dias e resolve 80%” é uma frase que reordena roadmap. Quem decide não tem como saber isso, e raramente pergunta.
Efeito colateral estrutural. “Se a gente fizer assim, cobrança por uso fica inviável depois” é o tipo de aviso que vale um trimestre. Pricing e modelo de dados estão amarrados, e quem percebe primeiro é quem modela.
Risco operacional. “Isso funciona até uns dez mil registros por cliente, e o cliente X já tem oito mil” é informação que ninguém mais no time possui.
Guardar esse conhecimento e depois dizer “eu avisei” é a pior versão do papel. Falar cedo, com número, é a melhor.
O erro na direção oposta
Existe o engenheiro que se apaixona por produto e para de se importar com o código. Discute posicionamento, opina em preço, e entrega sistema que ninguém consegue manter.
Isso é troca, não evolução. O valor está na interseção: alguém que entende o problema de negócio e sabe qual é o custo real de cada caminho técnico. Essa combinação é rara e é o que faz alguém ser chamado antes da decisão, em vez de depois.
Como começar amanhã
Três hábitos baratos.
Peça pra assistir uma call de suporte ou de vendas por mês. Uma hora ouvindo cliente reclamar ensina mais sobre o produto que um trimestre de refinamento.
Antes de estimar, escreva em uma frase qual problema aquilo resolve. Se não conseguir, você achou uma pergunta pra fazer.
Olhe os números do que você construiu. Quantas pessoas usaram a funcionalidade do mês passado? Se você não sabe, você está construindo sem retorno, e sem retorno não existe calibragem.
Por que isso é carreira
O mercado paga por escassez.
Gente que escreve código bom é abundante e vai ficar mais abundante. Gente que escreve código bom e sabe qual código não precisa ser escrito continua rara, porque isso exige contexto que não se aprende em documentação.
É também o que separa quem é chamado pra executar de quem é chamado pra decidir. Escrevi sobre a versão inicial disso em de júnior a pleno, e é a mesma habilidade que aparece mais tarde, com outro nome, quando alguém vira fundador.