essa é uma seção de tecnologia da news experimental, siga essa news também no linkedin & você pode se desinscrever dessa seção e se manter nas outras se quiser (:
15 de fevereiro de 2026
sexta treze, meu aniversário de 35 anos, decidi abrir essa news pra compartilhar o dia a dia de desenvolvimento de software no furacão tecnológico que é 2026.
aqui espero ser um afago aos devs mais novos e uma mãozinha às pessoas não técnicas (:
nessa primeira edição, apresento o projeto principal em que estou trabalhando e deixo uns links bacanas que vi na semana.
hoje vamos falar de: descoberta de produto, entrevista com usuários e linguagem ubíqua.
Bora lá!
__
Mono Repo
O projeto principal da vez.
Estou construindo um Software as a Service (SaaS) para facilitar a compra de imóveis em leilão no Brasil, por enquanto ele chama: leilaonomapa.com
Descoberta de produto: antes de codar, entender pra quem
Uma dica que posso dar a quem quer construir o próprio software: antes de tudo, faça uma descoberta de produto. No mundo de gestão de produto, existe uma metodologia chamada Product Backlog Building (PBB) que estrutura isso muito bem. A ideia central é: parta do problema e do impacto pro usuário antes de entrar nos detalhes técnicos.
Na prática, isso começa com uma pergunta simples: quem são seus usuários?
No meu caso, o usuário pode ser:
leiloeiros querendo divulgar seus leilões;
investidores em imóveis de leilão;
advogados ou assessores especialistas em compra e venda em leilão;
pessoas comprando seu primeiro imóvel.
Repare que cada uma dessas pessoas vai usar a plataforma de um jeito, priorizando funcionalidades diferentes. No PBB, chamam isso de definição de personas e o ponto é que quando você enxerga o produto sob a perspectiva de quem realmente o utiliza, muda sua mentalidade. Você para de pensar só em implementação técnica e começa a se preocupar com a experiência real.
entender o processo na cabeça do usuário
De início, criei um fluxo do processo de busca, seleção, análise e compra de imóvel de leilão baseado num curso da área e analisando meus “concorrentes”.
Não é suficiente.
Fazer entrevistas com potenciais usuários é essencial. É aí que você descobre pontos cegos no mercado — e pra um SaaS, isso é crucial, especialmente se a gente for aplicar o que o Marc Lou indica: começar com um software simples que resolva apenas uma dor, sem colocar mil coisas logo de cara. (Eu não tô fazendo bem isso... mas enfim rs)
Esse é o coração do PBB: identificar o problema real antes de definir funcionalidades. Em vez de sair codando uma lista desorganizada de features, você mapeia problemas, expectativas e personas e as funcionalidades surgem com um motivo claro pra existir.
o maior insight que tive até agora
... veio entrevistando um leiloeiro. como achei um leiloeiro?! mandando muitas mensagens, todos os dias, via linkedin, instagram e whatsapp, conversando com diferentes pessoas que vão me guiando pra outros contatos. esse é o caminho das pedras rs
Bom, ele disse que a maior dificuldade do processo é que, quando a documentação (a análise jurídica) é muito complicada, rola um “vai e vem”: tem que ver quanto vai custar a regularização jurídica, somar na análise comercial e aí sim saber se vale a pen
Ele disse que cada caso é um caso.
E minha curiosidade no momento é: é mesmo?
Há mais de 5 anos trabalhando com automações corporativas, vi muitos casos em que as pessoas consideravam um processo difícil de padronizar e no fim era totalmente automatizável.
Falar a língua deles
Uma coisa que você vai perceber fazendo entrevistas, as pessoas falam da mesma etapa do processo, mas de formas diferentes:
no caso do leilaonomapa o leiloeiro chama de “análise jurídica”, o investidor usa mais termos em inglês e chama de “due diligence”, mas o advogado vai falar em português mesmo: “diligência documental”.
Isso é um problema clássico de engenharia de requisitos. Se cada persona usa um termo diferente pro mesmo conceito, como você modela um sistema que atenda todos?
No Domain-Driven Design, do Eric Evans, isso virou o conceito de linguagem ubíqua (ubiquitous language): criar um vocabulário comum entre todos os envolvidos (devs, usuários, stakeholders) pra que o código reflita o domínio real do negócio, sem tradução perdida no caminho.
Na prática, pro Leilão no Mapa, isso significa que eu preciso decidir: qual termo o sistema vai adotar? Depende muito do cliente que quero atender... é bom que esse termo seja compreendido por todas as partes, inclusive um comprador mais leigo... então, preferi usar “análise jurídica”.
__
Merge Conflict
descobrir demanda vs. criar demanda
Uma objeção à minha própria “metodologia” é aquele argumento popularizado pelo Steve Jobs: as pessoas não sabem o que precisam ou querem.
Kevin O’Leary (do Shark Tank) contou que nos anos 90, quando sua empresa Softkey fazia software educacional pra Apple, Jobs disse pra ele algo como “Eu não ligo pro que os estudantes querem, eles não sabem o que querem até eu dizer o que querem.” [link]
Você pode criar algo e gerar o desejo de compra nelas depois.
Isso tem sido em parte verdade nessa minha experiência, mas é uma tensão que todo mundo que constrói produto enfrenta. O PBB resolve isso parcialmente: ele não pede pro usuário dizer o que quer como solução, e sim que descreva seus problemas e expectativas.
A solução é construída a partir daí, pelo menos backlog já sai priorizado por valor, não por achismo... mas sim, é limitado pela visão dos entrevistados.
__
Outras Branches
Links e referências que me chamaram atenção na semana.
Rotina da Carol Paiffer, uma das Mulheres Mais Ricas do Brasil: empreender E comunicar é tudo na tentativa e erro. Não tem um mapa exato, o dia a dia é teste, ajuste, teste de novo. Bom lembrete pra quem tá construindo e divulgando algo do zero.
VS Code entra na era dos multi-agentes de IA: Agora tem um workspace unificado pra coordenar diferentes agentes ao mesmo tempo. da pra rodar em paralelo pesquisa, refatoração, testes... com suporte nativo a Claude e Codex. [release notes | canal no YouTube
Até o próximo commit, Michelle (:
