Conversão caiu de 68% para 41% em duas semanas. Oito histórias, duas sprints, sem cancelar o resto do roadmap.
A conversão da jornada de consentimento no Open Finance caiu de 68% para 41% em duas semanas, uma queda abrupta, não gradual. A jornada depende de bancos parceiros externos em cada etapa: seleção do banco, autenticação, consentimento e proposta. Cada dia parado era receita perdida e mais chamados no suporte. Ao mesmo tempo, o time seguia comprometido com uma entrega de roadmap já prometida à diretoria, com capacity alocado, o que tornava qualquer decisão sobre prioridade mais delicada.
Não sabíamos onde na jornada as pessoas estavam saindo, quando a queda começou nem por quê. Com capacidade limitada para atacar tudo ao mesmo tempo, qualquer hipótese errada custava tempo que a operação não tinha.
Conduzi a investigação sozinha. Comparei a taxa de conversão de cada etapa do funil (seleção do banco, autenticação, consentimento, proposta) antes e depois da queda para localizar o ponto exato de abandono, olhando também o tempo médio de conclusão de cada etapa e o volume de sessões abandonadas. Do lado técnico, cruzei taxa de erro, tempo de resposta e taxa de sucesso das chamadas de API com o volume de chamados no suporte e os relatos recorrentes de tela travada e erro genérico.
Usei IA para estruturar hipóteses e redigir as histórias de usuário, mas validei cada dado técnico e financeiro contra a fonte real antes de levar qualquer número à diretoria. Levantei três hipóteses e avaliei cada uma numa matriz de impacto x esforço, contemplando o risco de não agir, priorizando a de maior impacto antes de desenhar a solução.
Priorizar a hipótese de instabilidade no parceiro de integração antes das outras duas.
Por quêA queda abrupta e os relatos de tela travada apontavam para uma causa técnica externa, não para uma mudança de produto ou regulatória.
ImpactoParti direto para health check, status visível e retry, sem gastar tempo em hipóteses menos prováveis.
Fatiar a entrega do roadmap em vez de cancelá-la.
Por quêJá existia um fluxo de trabalho esperado pela diretoria e o capacity já estava comprometido, e cancelar geraria outro problema de confiança.
ImpactoDecidi entregar uma versão simplificada na data combinada e as melhorias secundárias na sprint seguinte.
Levar o trade-off explícito para a diretoria, com impacto financeiro e esforço estimados.
Por quêEm crise, a tentação é escalar o problema sem proposta.
ImpactoA prioridade foi decidida ali, na mesma reunião, sem precisar de novas rodadas de aprovação depois.
Traduzir o diagnóstico em 8 histórias de usuário, priorizadas com MoSCoW e divididas em 2 sprints.
Por quêCada causa identificada (timeout sem alternativa, falta de status visível do parceiro, ausência de retry) derrubava a conversão em um ponto diferente do funil. Fatiar em histórias pequenas, cada uma com critério de aceite e impacto esperado próprio, permitia atacar primeiro o que sustentava a queda.
ImpactoA sprint 1 concentrou os must haves que estancavam a sangria (timeout com opções reais, health check, retry automático, sinalização de status); a sprint 2 trouxe os should e could haves que sustentaram e ampliaram o ganho, fechando em uma projeção de 60 a 65% de conversão recuperada.
Nem toda urgência é igual: o incidente foi para a frente da fila porque sangrava receita todos os dias, e o regulatório só entraria à frente se tivesse prazo definido.
O aumento de confiança não vem da rapidez ou da urgência em agir, vem de saber exatamente onde procurar e o que priorizar primeiro.