Liderança de Produto para resolver problemas complexos.

A PagueVeloz operava o Pix como participante indireto, processando milhões de eventos por mês e dependendo da infraestrutura de terceiros para uma parte crítica da operação. Essa dependência afetava disponibilidade, autonomia e custo.

O cenário anterior acumulava indisponibilidades relevantes, com impacto operacional e financeiro significativo.

Outra iniciativa importante disputava a capacidade do mesmo time. Diante do prazo regulatório e da criticidade da migração, decidi sequenciar as entregas: mantê-las em paralelo aumentaria o risco de interrupção e retrabalho.

Liderei a frente de produto da migração para participante direto, com ISPB próprio, coordenando prioridades e dependências entre Produto, Engenharia, Compliance e Jurídico. Por ser infraestrutura financeira regulada e de alta criticidade, o trabalho precisava equilibrar requisito regulatório, estabilidade da operação, experiência do cliente e viabilidade econômica.

O go-live aconteceu em abril de 2026, dentro do prazo da Resolução BCB 496/2025. A migração eliminou a dependência do participante indireto anterior, reduziu a exposição a indisponibilidades e trouxe uma redução relevante no custo unitário da operação.

O Motor de Pagamentos é a infraestrutura central que sustenta todas as jornadas transacionais da PagueVeloz, processando bilhões de reais em TPV e dezenas de milhões de transações por ano. Nessa escala, pequenas variações já geram impacto financeiro e de experiência relevante.

Liderei a atuação de Produto junto à Engenharia e à operação para aumentar a resiliência no pagamento de cashout. O time tratou as mensagens de erro recebidas e construiu um motor de decisão baseado nessas mensagens, para orientar a tratativa das falhas de repasse. Essa atuação foi acompanhada por rotinas de monitoramento de gargalos, taxas de sucesso e incidentes.

A taxa de erros de repasse apresentou uma queda relevante após o tratamento estruturado das mensagens de erro e a construção do motor de decisão, fortalecendo a resiliência do pagamento de cashout.

Diferenças residuais de saldo, às vezes de poucos centavos, podiam impedir a conclusão de um repasse de cashout. A rotina de reprocessamento automático tinha limitações nesses cenários, e o tratamento manual dessas falhas gerava custo operacional.

Direcionei a investigação e o alinhamento entre Engenharia e negócio para revisar o comportamento do cashout. Uma das decisões foi tratar automaticamente pequenas diferenças residuais dentro de um limite controlado: o custo desse complemento era menor do que deixar o repasse falhar e precisar recriar todo o pagável.

A revisão contribuiu para evitar uma perda expressiva de receita, além de aumentar a taxa de sucesso dos repasses e reduzir o tratamento manual desses casos.

A operação de Open Finance estava dividida entre fornecedores, sob uma restrição de arquitetura que impedia manter estruturas paralelas no longo prazo.

Manter a operação dividida preservaria o desenho existente, mas ampliaria custo e complexidade. Como boa parte das integrações já estava concentrada em um dos provedores, consolidar as frentes era o caminho mais racional.

Liderei a migração para o provedor consolidado, avaliando impactos, coordenando a transição e conduzindo a negociação comercial com base no contexto da integração já existente.

A migração foi concluída ao longo de alguns meses, mantendo a infraestrutura crítica de Open Finance em funcionamento durante toda a transição, sem interrupção percebida pelo usuário final.

Resultado financeiro da negociação não divulgado nesta página.

A PagueVeloz atua como Instituição de Pagamento (IP), o que coloca no meu time a responsabilidade de construir as jornadas regulatórias de Pix e Open Finance. O app Carteira Serasa também precisa oferecer essas mesmas jornadas ao usuário final, mas o time do app vinha reconstruindo essa lógica por conta própria, em vez de reaproveitar o que a infraestrutura de pagamentos já tinha resolvido.

Liderei a unificação de dezenas de jornadas entre múltiplas squads, eliminando o desenvolvimento paralelo de fluxos regulatórios e centralizando sua manutenção, que meu time, como IP, já atualizava a cada mudança de norma do Banco Central.

A unificação reduziu de forma relevante o esforço duplicado de desenvolvimento: antes gasto uma vez pelo meu time, como Instituição de Pagamento, e outra pelo time do app, reconstruindo o que já existia.

Um dos produtos sob minha responsabilidade usava dados cadastrais da Receita Federal, na V1 da API. Como a V1 apresentava inconsistências, deleguei a condução da migração para a V2 a uma PM do meu time, esperando resolver os problemas existentes.

Depois da migração, os sinais da operação mostraram um aumento expressivo nos chamados. Assim que fui informada da piora, decidi pelo rollback para a versão anterior, mesmo conhecendo as limitações que haviam motivado a mudança.

Em vez de escolher entre duas versões que não atendiam completamente às necessidades da operação, negociei com o time interno responsável a inclusão de uma terceira alternativa no roadmap, desenhada para as particularidades do produto. Após o rollback, os chamados retornaram ao patamar anterior.

O case mostra, acima de tudo, a importância de acompanhar o comportamento de uma mudança depois do lançamento e estar disposta a reverter uma decisão quando os indicadores mostram que ela não está funcionando.

A 99 desenvolvia a Verificação na Blitz, um recurso de segurança que integra sistemas da polícia aos dados da 99 para checagem de motoristas parceiros durante abordagens de trânsito.

Atuei como ponte entre as equipes brasileiras e o time de tecnologia na China no desenvolvimento do recurso. Reuni-me pessoalmente com a Secretaria de Segurança Pública de São Paulo; a articulação com a do Rio de Janeiro foi conduzida pelo time Jurídico. Acompanhei os testes entre as equipes de engenharia da polícia e da 99 na China.

A funcionalidade foi lançada no Rio de Janeiro, até o período em que estive na 99. Minha contribuição se concentrou em conectar interlocutores locais e globais e acompanhar a integração e os testes necessários ao lançamento.

O Banco Original queria lançar um produto de Crédito com Garantia de Recebíveis de Cartão, mas automatizar a esteira de crédito por completo levaria mais tempo do que o desejado para entrar no mercado.

Negociei entre Negócios e Tecnologia um MVP com jornada funcional para o cliente e mesa de crédito operada manualmente por seis meses, preservando os requisitos críticos de segurança e dados.

Esse recorte permitiu lançar o produto e validar a operação antes de investir na automação completa, com o produto no ar antes da concorrência.