Do código ao produto: por que larguei o editor

Vou começar admitindo uma coisa que pouca gente espera ouvir de um product manager: eu era bom de código. Bom mesmo. E foi exatamente isso que tornou a minha virada tão difícil.

A coisa mais difícil de largar nunca é aquilo em que você é ruim é aquilo em que você é bom. Por anos, o editor de código foi o meu lugar seguro. Diante de qualquer problema, minha primeira reação era a mesma: abrir o projeto e começar a construir. Havia um prazer quase físico em ver uma arquitetura limpa nascer, um bug sumir, um deploy passar verde. Eu me sentia útil no exato instante em que escrevia a primeira linha.

O problema é que utilidade e impacto não são a mesma coisa. Demorei para entender que eu podia passar uma semana inteira construindo com excelência técnica e, ainda assim, entregar algo que ninguém precisava. Largar o editor não foi desistir da engenharia. Foi parar de me esconder atrás dela.

Tem uma leitura preguiçosa da minha trajetória que diz que eu "deixei de ser técnico para virar gestor". Não foi isso. Eu não virei as costas para a engenharia subi uma camada de abstração.

Como desenvolvedor, minha pergunta era como construir. Como tech lead, ela virou o que vale a pena construir. Como product manager, ela se tornou por que isso importa para alguém. É o mesmo problema visto de mais longe e, de mais longe, você enxerga coisas que de dentro do código são invisíveis: o cliente que desistiu antes de chegar na tela bonita, a feature perfeita que resolvia a dor errada, o esforço do time sendo gasto no lugar de menor retorno.

O rigor de engenheiro não me abandonou nessa subida. Ele só mudou de objeto. Antes eu aplicava disciplina a sistemas; hoje aplico a mesma disciplina a decisões. A diferença é que decisão errada custa muito mais caro do que código errado e raramente aparece num stack trace.

Essa fluência técnica não caiu do céu. Ela foi forjada num lugar específico, e eu lembro bem de onde.

Começou na iniciação científica, no 3GEOLINK, com o Santuário Digital um projeto de geoprocessamento voltado à preservação cultural que acabou rendendo uma premiação internacional. Foi a primeira vez que o código que eu escrevia tocava algo maior do que ele mesmo. Não era software por software era tecnologia a serviço de preservar memória. Aquilo plantou uma semente que eu só fui entender anos depois: o que me movia não era a máquina, era o que a máquina fazia por gente.

Depois veio a Concert Technologies, onde passei de analista a Tech Lead e Scrum Master entre 2016 e 2023. Mergulhei fundo no full stack .NET Core, Angular, Flutter e, mais importante, comecei a liderar. Liderar dez pessoas me ensinou algo que escrever código sozinho nunca ensinaria: na maioria das vezes, o gargalo do time não era técnico. A gente sabia construir quase tudo. O que faltava era clareza sobre o que valia a pena ser construído. Aumentamos a qualidade em mais de 35% e reduzimos atrasos em 20% não escrevendo código mais esperto, mas alinhando melhor o porquê antes de começar.

Se eu tivesse que apontar o momento exato da virada, seria quando percebi que construir já não era mais o meu desafio. Eu conseguia entregar quase qualquer coisa. A pergunta que tirava meu sono passou a ser outra: estamos construindo a coisa certa?

Foi fundando a Tekeezy que essa pergunta ficou impossível de ignorar. Tocar uma software house do zero me tirou o luxo de pensar só em entrega. De repente eu era responsável pelo resultado de negócio, não pela qualidade do commit. Não dá para se esconder atrás de um código bonito quando é a receita que está em jogo, quando um cliente vai ou fica, quando o churn é um número que mexe na sua folha. Crescemos a receita em mais de 60%, mantivemos churn abaixo de 5% e construímos uma base de mais de dez clientes de Kienbaum e CDL a ChildFund e isso não veio de ser a software house mais técnica. Veio de entender o negócio de cada cliente melhor do que a feature que eles pediam.

Ali ficou claro: o código tinha virado a parte fácil. A parte difícil e a mais valiosa era a decisão sobre onde apontá-lo.

Largar o editor não significou apagar o engenheiro. Pelo contrário tem um DNA técnico que carrego para dentro do produto todo dia e que me faz um PM diferente:

Penso em sistemas, não em telas. Onde muita gente vê uma lista de features, eu vejo fluxos, dependências e efeitos colaterais. Engenharia me ensinou que tudo se conecta e que a feature mais perigosa é a que parece isolada.

Falo a língua de quem constrói. Sento com o time de desenvolvimento sem tradutor. Isso reduz o ruído entre estratégia e execução a quase zero eu sei o que estou pedindo, sei o que custa, e sei quando um "impossível" é de verdade ou é só preguiça de pensar.

Decomponho o impossível. A maior herança da engenharia talvez seja essa: pegar algo grande e assustador e quebrar em pedaços pequenos e executáveis. É o que eu fazia com arquitetura de software e é exatamente o que faço hoje com um roadmap.

Trato rigor como respeito. Dado, evidência, hipótese testável engenharia me deu a alergia ao "eu acho". Levo esse mesmo rigor para a mesa de decisão de produto, onde o "eu acho" costuma custar caro.

Construo para aprender, não para impressionar. A cultura de MVP e iteração não é teoria pra mim é o jeito que eu sempre trabalhei. Versão mínima, no ar, aprendendo com uso real, melhorando. Bonito é o que funciona e ensina.

No fim das contas, eu não deixei de ser engenheiro. Eu virei um engenheiro de resultados e o editor passou a ser uma ferramenta entre várias, não o centro de tudo.

O que me move hoje, liderando produto na eTrilhas, é exatamente o que me movia naquele primeiro projeto no 3GEOLINK: construir algo que importa para uma pessoa real. Mudou a camada, mudou o vocabulário, mudaram as métricas. A raiz é a mesma.

Se tem uma coisa que essa virada me ensinou, é que carreira não é sobre acumular o que você sabe fazer é sobre ter coragem de soltar o que já domina para abraçar o que ainda te assusta. Eu larguei o editor para cuidar da pergunta que vem antes dele. E é dessa pergunta que nasce todo produto que vale a pena.