A versão útil de uma página sobre mim.

Faço meu melhor trabalho em produtos em que comportamento do usuário, operação e tecnologia estão misturados.

Na Loadsmart, isso significou transformar auditoria de fretes, disputas e pagamentos em um fluxo de produto. No Zenklub, significou transformar restrições clínicas e operacionais em um escopo viável para atendimentos presenciais. No EBANX, significou reduzir a dependência do suporte humano sem tratar self-service como simples contenção de tickets.

O domínio não precisa ser simples. Preciso de um problema importante, acesso às pessoas que convivem com ele e uma forma concreta de descobrir se o produto mudou alguma coisa. Sou menos útil quando o trabalho consiste principalmente em manter um roadmap herdado.

Tento comprar informação, não certeza.

Separo o que sabemos daquilo que estamos apenas assumindo. Depois procuro a hipótese que, se estiver errada, torna o restante da solução irrelevante.

Na Loadsmart, uma expansão de pagamentos parecia estrategicamente atraente. A pesquisa indicou que muitos clientes já estavam ancorados nos próprios ERPs e dificilmente moveriam aquele workflow para o TMS. Recomendei não seguir com a iniciativa naquele momento.

No EBANX, a resposta precisava ser diferente. Definimos critérios de sucesso, avaliamos fornecedores, lançamos o chatbot gradualmente e usamos dados de resolução e escalonamento para orientar a expansão.

A reversibilidade importa. Quando o custo de errar é limitado, prefiro uma entrega pequena. Quando a premissa central está fraca, prefiro parar antes que entusiasmo vire custo afundado.

Sou hands-on, mas não finjo ser engenheiro.

No Fio, trabalhei diretamente em estratégia, fluxos, UX, product design, prompts e no pipeline que conecta sumarização, criação de roteiro e text-to-speech. Levei um produto para iPhone até o TestFlight usando React Native, Supabase, RevenueCat, analytics e ferramentas de desenvolvimento assistidas por IA.

Isso me permite prototipar, investigar falhas e discutir decisões técnicas com muito mais precisão. Também defino métricas e uso dados de produto para avaliar adoção, confiabilidade e comportamento.

Meus limites importam. Não sou engenheiro de produção, designer visual especialista ou cientista de dados. Em sistemas críticos, espero que engenharia seja responsável por arquitetura, segurança e qualidade interna do código. Minha contribuição é conectar o problema do usuário, o comportamento desejado, a experiência e o desempenho real do sistema.

O Fio me deixou muito menos impressionado com demos.

Fazer um pipeline de IA funcionar uma vez foi relativamente fácil. Fazer esse pipeline produzir bons episódios, ancorados nas fontes e com qualidade consistente, foi o verdadeiro problema de produto.

Também aprendi que uma tese elegante não cria comportamento. Imaginei um podcast semanal automático, enquanto meu próprio uso levantou a possibilidade de que ouvir imediatamente fosse mais valioso. Um e-mail para a waitlist não gerou inscrições. Alternativas gratuitas como o NotebookLM aumentaram a exigência para justificar disposição a pagar.

O Fio não é uma história limpa de sucesso. Ele me obrigou a separar quatro coisas que antes eu poderia ter confundido: uma ideia interessante, uma experiência agradável, um sistema confiável e um produto ao qual as pessoas voltam e pelo qual estão dispostas a pagar.

Sou bom em encontrar a decisão escondida dentro de um workflow complicado.

Comecei no atendimento ao cliente. Por isso, costumo enxergar produtos por meio de exceções, tickets e trabalho manual, não apenas pela jornada que deveria acontecer.

No EBANX, essa perspectiva ajudou a estruturar produtos de self-service que aumentaram a taxa de self-service em 60 pontos percentuais e reduziram SLAs de reembolso e pagamento de dias para minutos. No Zenklub, conectei necessidades dos profissionais, restrições operacionais e adoção, contribuindo para um aumento de 25 pontos no NPS e de 44 pontos percentuais no engajamento da principal funcionalidade. Na Loadsmart, apliquei o mesmo raciocínio a workflows financeiros que processaram mais de US$2 milhões em faturas auditadas.

O padrão não é um setor. É decompor o sistema, identificar a decisão central e manter o time conectado ao resultado.

Tenho lacunas reais.

Minha experiência mais forte está em produtos B2B, operações e self-service. O Fio mostrou que ainda não tenho a mesma profundidade em distribuição de produtos de consumo, retenção ou disposição a pagar.

Consigo construir e depurar protótipos assistidos por IA, mas minha profundidade técnica não substitui um engenheiro experiente.

Também tenho um padrão de trabalho que preciso corrigir. Quando o contexto muda e ainda não entendo completamente um novo escopo, às vezes passo tempo demais tentando resolver a incerteza sozinho. Isso atrasa o momento em que o time poderia ajudar e pode fazer minhas perguntas aparecerem tarde.

Estou trabalhando para expor hipóteses e lacunas mais cedo, mesmo quando meu raciocínio ainda está incompleto. Curiosidade e autoconhecimento não resolvem isso sozinhos. Essas lacunas diminuem com prática e evidência.

Colaboro melhor quando o problema é compartilhado e as responsabilidades estão claras.

Com designers, prefiro explorar alternativas cedo e discutir o comportamento que a experiência deveria produzir, em vez de apenas revisar uma interface pronta.

Com engenheiros, levo contexto, restrições e critérios de sucesso. Espero que eles participem da construção da solução e desafiem hipóteses fracas.

No Zenklub, diferentes grupos discordavam sobre aumentar a adoção de uma experiência que ainda trazia riscos. Transformamos essas preocupações em critérios e criamos um rollout gradual.

A maior parte da minha experiência foi com lideranças funcionais e times de produto, não trabalhando diretamente para founders. Nessa relação, quero ter acesso ao raciocínio por trás das decisões. Consigo trabalhar com convicções fortes. Trabalho pior quando uma preferência pessoal é apresentada como um fato que não pode ser examinado.

Não trato discordância como uma disputa de convicção.

Procuro as crenças que estão produzindo cada posição e o que poderia torná-las testáveis.

No Zenklub, a liderança queria aumentar a adoção, enquanto CX e o time clínico estavam preocupados com a qualidade da experiência e com a relação com os profissionais. Um rollout gradual permitiu observar adoção e experiência antes de expandir a mudança.

Também não protejo uma decisão apenas porque ajudei a criá-la. Na Loadsmart, recomendei abandonar uma tese de pagamentos depois que a pesquisa enfraqueceu sua premissa de adoção. Em outro lançamento, um rollout parcial quebrou um fluxo crítico e precisou ser revertido.

Mudar de ideia, pausar ou reverter uma decisão não é indecisão quando as evidências mudaram. Faz parte de ser responsável pelo produto.

Quero um papel de Product Manager com responsabilidade real por um produto.

Quero trabalhar próximo de usuários, designers e engenheiros, participando da definição do problema, criação, lançamento e evolução.

A IA deve mudar o comportamento ou a economia do produto, não aparecer como mais uma funcionalidade no roadmap. O Fio ampliou minha capacidade de trabalhar diretamente com protótipos, prompts, avaliações de qualidade e limitações do sistema. Não quero transformar isso em um título inflado.

Procuro um time pequeno, com lideranças fortes, em que eu possa assumir um problema importante e continuar responsável pelo que acontece depois do lançamento.

Não procuro uma função baseada principalmente em coordenar vários times, produzir apresentações executivas ou gerenciar um backlog já definido por outra pessoa.

Trabalho melhor em um ambiente exigente e com pouco teatro.

Quero colegas que se comuniquem diretamente, exponham pensamentos ainda incompletos e consigam mudar de posição sem transformar discordância em uma disputa de status.

Prefiro times pequenos, ciclos curtos, contato frequente com usuários e proximidade com o produto funcionando. Não preciso de conforto constante. Preciso de contexto, feedback claro e acesso às decisões que mudam o problema ou o mandato.

Também trabalho melhor quando os rituais servem ao trabalho, e não quando o trabalho existe para alimentar os rituais. Apresentações não são um problema quando estão ancoradas no produto. Um ambiente dominado por decks, alinhamentos recorrentes e decisões tomadas longe do time reduz minha energia e minha utilidade.

Quero aprender com pessoas melhores do que eu, não apenas receber autonomia sem direção.

Não me contrate se a função for principalmente uma camada de coordenação.

Se a necessidade central for storytelling executivo, manter vários times alinhados ou navegar política organizacional, existem Product Managers mais adequados.

Também não sou a pessoa certa para substituir um engenheiro de ML, liderar sozinho uma linguagem visual sofisticada ou trazer um playbook maduro de crescimento para produtos de consumo. Minha experiência com produtos de consumo ainda está concentrada no Fio, onde os principais riscos de demanda e retenção continuam sem resposta.

Provavelmente seria um fit ruim para uma empresa em que IA é decorativa, o roadmap já está fixo ou pedidos de vendas viram prioridade sem investigar os padrões por trás deles.

Meu melhor trabalho exige acesso ao problema e responsabilidade pela decisão. Sem essas condições, eu tenderia mais a questionar o sistema do que simplesmente operá-lo.