Engenharia Orientada a Produto

Você já abriu um arquivo do sistema e pensou:

“Quem foi o maluco que escreveu isso?”

Aí você descobre a verdade.

Foi você mesmo…

há dois anos atrás.

Ou pior.

Foi alguém que saiu da empresa e deixou um legado radioativo para trás.

Você olha para aquele código que parece um barco furado.

Cada bug que você mata, nascem dois novos, porque alguém fez mais outro puxadinho de gambiarra há três anos.

Então, você pensa:

“Se eu apenas reescrever esse serviço usando uma arquitetura orientada a eventos, isolar esses domínios e matar essa dívida técnica, tudo vai ficar bem.”

Sim, confia.

Aí você passa três semanas construindo a “Ferrari” da engenharia de software.

• O código está lindo.
• Os testes estão verdes.
• O deploy é impecável.

E sabe o que acontece depois?

Cri, cri, cri. Barulho de grilos.

• O usuário não liga.
• A métrica de negócio não move um milímetro.

Então você escuta que:

A empresa gastou um mês de engenharia cara para entregar uma obra de arte que não resolveu a dor de ninguém.

Dói ouvir isso, não é?

…e foi na dor que aprendi também.

✨ Código brilhante também pode ser inútil

Como engenheiros, nós amamos a complexidade.

Resolver quebra-cabeças difíceis libera dopamina.

• Queremos usar a tecnologia mais nova
• Escalar para milhões de requisições por segundo (mesmo que o sistema tenha 50 usuários simultâneos)
• Queremos “limpar a casa”
• Matar dívidas técnicas que nos assombram há anos

É compreensível.

Pois trabalhar em código ruim é insustentável e desgastante.

Mas aqui vai a real:

O cliente não paga por código bonito

Ele paga por problemas resolvidos.

Se o usuário consegue resolver o problema dele em menos de 3 cliques, ele tá feliz.

Ele não quer saber se por trás existe:

• um monólito
• microserviços
• event sourcing

…ou um hamster rodando numa roda alimentando um servidor.

Se funciona, pra ele tá ótimo.

É exatamente aqui que muitos engenheiros param de crescer na carreira.

E é sobre isso que o Drew Hoskins fala em seu livro, The Product-Minded Engineer: Building Impactful Software for Your Users.

Hoskins passou por empresas como Microsoft, Meta e Stripe construindo sistemas gigantescos.

Mas o segredo para o sucesso foi desenvolver um superpoder: a empatia.

🦸 A armadilha do engenheiro herói

Existe um vício silencioso na engenharia de software.

A cultura do engenheiro herói.

Aquele que:

• resolve os bugs impossíveis
• domina arquiteturas complexas
• cria soluções tecnicamente impressionantes

Isso é valorizado.

Mas existe um problema.

Às vezes otimizar engenharia não resolve problemas do usuário.

E essas duas coisas não são a mesma coisa.

Um engenheiro orientado a produto faz perguntas diferentes antes de escrever uma linha de código:

• Quem exatamente tem esse problema?
• Esse problema é realmente importante?
• Quantas pessoas sofrem com isso hoje?
• Qual é a menor solução possível que já gera valor?

Percebe a mudança?

O foco deixa de ser sofisticação técnica e passa a ser impacto real.

🕳️ Saindo da caverna do código

Hoskins defende que habilidades técnicas são apenas o ponto de partida.

O verdadeiro diferencial é desenvolver empatia pelo usuário.

Isso significa sair da famosa caverna do código.

Aquele lugar confortável onde ficamos entre:

• IDE
• pull requests
• pipelines de CI
• dashboards de observabilidade

Enquanto os usuários estão lá fora tentando usar o produto.

Se você quer realmente causar impacto (e crescer na carreira), você precisa calçar os sapatos do seu usuário.

Você precisa antecipar os movimentos dele.

Seja honesto…

Quando foi a última vez que você conversou com um usuário real antes de desenhar uma arquitetura?

ou

Quando foi a última vez que você observou alguém usando sua aplicação?

Não um colega.

Um usuário de verdade.

Porque quando você faz isso, algo curioso acontece.

Você percebe que:

• metade das features que você pensava construir não são tão importantes
• alguns problemas são muito maiores do que você imaginava
• às vezes uma solução simples resolve algo que parecia exigir uma plataforma inteira

É quase constrangedor.

Mas extremamente esclarecedor.

🔧 A síndrome do “vamos arrumar tudo antes”

Esse é um clássico.

O time percebe que o sistema está cheio de dívida técnica.

Então surge o plano heroico:

“Vamos parar tudo e refatorar direito.”

Os argumentos normalmente são legítimos:

• o sistema está frágil
• não escala
• o código está impossível de manter
• se continuar assim vai explodir

Tudo isso pode ser verdade.

Mas aí acontece algo curioso.

O time passa meses melhorando a infraestrutura…

enquanto o produto não melhora quase nada para o usuário.

• O backlog continua crescendo
• Os clientes continuam pedindo coisas
• E o valor entregue é mínimo

Enquanto isso…

• A engenharia está feliz.
• Arquitetura linda.
• Código impecável.

Valor para o usuário? Quase nenhum.

Um engenheiro com mentalidade de produto sabe negociar e priorizar.

Ele faz perguntas incômodas como:

• “Nós realmente precisamos reconstruir esse módulo agora, ou uma feature simples e direta entregaria 80% do valor na metade do tempo?”
• “Qual é o custo dessa refatoração versus o impacto real na vida de quem está usando nossa tela?”

🧩 A Dívida de Complexidade

Nós falamos muito sobre dívida técnica.

Mas quase ninguém fala sobre:

dívida de complexidade.

Cada camada nova adiciona:

• mais manutenção
• mais onboarding difícil
• mais incidentes
• mais tempo para mudar algo

Complexidade cobra juros compostos.

E a conta sempre chega.

Sempre.

Às vezes a arquitetura perfeita de hoje, vira o legado problemático de amanhã.

Por isso engenheiros maduros fazem uma pergunta simples:

“Essa complexidade gera valor proporcional?”

Se a resposta for não…

talvez você esteja apenas polindo engenharia,

não construindo produto.

📈 O tipo de engenheiro que realmente cresce

Aqui entra um ponto interessante.

Os engenheiros que mais crescem não são necessariamente os que:

• escrevem o código mais complexo
• dominam mais frameworks
• criam arquiteturas mais sofisticadas

São os que:

• entendem o negócio
• entendem o usuário
• sabem priorizar impacto
• resolvem problemas importantes rapidamente

Esses viram:

• Staff Engineers
• Principal Engineers
• Tech Leads estratégicos

Porque eles fazem algo raro:

conectam engenharia com resultado de negócio.

🚀 Engenharia que gera valor de verdade

Não seja o engenheiro que se esconde atrás de refatorações intermináveis.

Se a dívida técnica está realmente insustentável, aprenda a explicar ela como um problema de produto.

Mostre como ela está impedindo:

• entregas rápidas
• novas funcionalidades
• melhorias de experiência

Porque, no momento em que a dívida técnica começa a bloquear valor para o usuário, ela deixa de ser apenas um problema de engenharia.

Ela vira problema de negócio.

E quando for construir uma solução…

Segure a vontade de construir uma nave espacial quando uma bicicleta já leva o usuário até a padaria.

• Boas arquiteturas importam.
• Código limpo importa.
• Mas impacto importa mais.

Antes de abrir o próximo pull request, faça uma pergunta simples:

Isso resolve um problema real ou só deixa o código mais bonito?

Porque no fim do dia, usuários não usam arquitetura.

Eles usam produtos.

E bons engenheiros sabem a diferença.