Diário de Produto - Dia 4

Verificamos que o fluxo de assinatura está com mais de 60% de abandono. Olhando os tickets que foram abertos sobre o assunto vimos algumas reclamações sobre o nosso provedor de pagamento. Olhando pro formulário - que é gerado automaticamente por eles - chegamos em algumas hipóteses de fricção.

A primeira investigação foi como customizar melhor essa UI. Vimos que não é muito flexível, e como temos experiência com outros provedores a próxima investigação foi sobre o trabalho que daria trocar o provedor. A equipe de engenharia fez em 2 dias uma prova de conceito e aprovou, era super fácil. Aí a trama ficou mais complexa.

Nosso financeiro levantou uma bandeira: O parceiro atual acumula todos os pagamentos do mês (lembrando que vêm do mundo inteiro) e nos envia de uma vez só. Aí pra fazer nosso registro contábil o pessoal emite uma nota fiscal do total, anexa o arquivo no sistema contábil que utilizam e pronto, tudo certinho.

Se o provedor de pagamento for enviando os pagamentos um a um, é necessário gerar uma NF pra cada pagamento e subir uma a uma manualmente no sistema, multiplicando o trabalho por 2 ordens de grandeza.

Adivinhem: o possível novo provedor de pagamento oferece sim a facilidade de acumular pagamentos por mês - contanto que não seja no Brasil. Exatamente onde fica nossa sede contábil.

O interessante nesse caso é que isso que eu descrevi pode até parecer o problema a ser resolvido, mas se a gente vai cavando pra chegar na causa-raiz já temos no mínimo uma descoberta de problema que ninguém estava olhando: Por que nossa contabilidade tinha que subir essas NFs na mão? Era uma ineficiência escondida que por ser uma vez por mês alguém fazia numa boa, mas por conta disso acaba travando experimentos que poderíamos fazer.

A task então virou outra: Integrar nosso sistema contábil com o provedor de pagamento, recebendo as transações automaticamente. Ficamos super animados com isso, fomos lá caçar a documentação do tal sistema, que é famoso e muita empresa usa, e: “Não oferecemos API para o módulo financeiro”.

Em 2024, gente?

Estamos em plena era do nocode, onde a integração cada vez mais simples entre sistemas está aumentando exponencialmente a capacidade de fazer operações e criar ferramentas. Ter uma API é perder o bonde, e quando todo mundo resolver migrar suas contas pros seu concorrente pra poder fazer algo simples como conectar o pagamento na contabilidade, será tarde demais pra você repensar sua arquitetura.

Nossa ideia é melhorar a vida do nosso contábil, então não cogitamos sugerir trocar o sistema, isso só geraria complicação. Vamos mergulhar mais fundo nas tasks de registros de caixa pra descobrir como seria possível deixar isso menos manual.

Isso tudo aumentou a complexidade do desenho desta tarefa, então enquanto investigamos a decisão é não atacar agora a fricção de pagamento. Botamos eventos de tracking em cada botão da UX do pagamento pra entender melhor os diferentes comportamentos e enquanto as métricas acumulam partimos pra desenhar as features que vão atender o novo público que descobrimos nas entrevistas.

Posso ajudar suas decisões de produto também. Saiba mais sobre meu trabalho aqui: produtoopentalent.com