Multidrop: ativação medida até a receita

A Multidrop investia pesado em marketing e anúncios para atrair criadores de infoprodutos. Os usuários chegavam, criavam conta, e travavam antes da primeira ação que gera receita: criar o primeiro produto e o link de venda, ou se afiliar a um produto para começar a promover.

Sem essa primeira ação, não rodava a máquina de dinheiro. Ad spend virava custo afundado.

O produto estava tecnicamente pronto há anos. O gargalo era experiência. Reestruturei a arquitetura de persona, reescrevi o onboarding depois de uma primeira tentativa que falhou, e transformei reembolso em inteligência de produto ao invés de compliance.

Escopo: Fui o único designer de produto e atuei como Lead Product Designer.

Autoridade de decisão: Propus arquitetura de produto, defini priorização com o squad, e conduzi experimentos de validação. Nas decisões estruturais, apresentei evidência ao CEO antes da implementação.

Período: set 2024 a ago 2025.

Resultado estrutural: €14 milhões em vendas no primeiro ano após o redesign de ativação, com abandono do onboarding caindo de 50% para 25% e a base crescendo de 0 para 100 clientes pagantes.

Como achei o gargalo: montei o funil no Mixpanel, do cadastro até a primeira ação geradora de receita. A amostra canônica reúne 3,1 mil novos cadastros em uma janela de 30 dias. O abandono era de 50% antes da primeira ação.

Cruzei com sessões gravadas no Hotjar. O padrão era claro: usuário caía em dashboard vazio, clicava duas ou três vezes sem resultado, saía. Estava vendo métrica do outro persona, não entendia onde começar.

Conversei com usuários que abandonaram e organizei os relatos por tema. A dor não era UI. Era cognição.

O produto servia duas personas completamente distintas. O Produtor quer criar produtos, configurar checkout, gerenciar afiliados e analisar faturamento. O Afiliado quer encontrar produtos para promover, acompanhar comissões e visualizar desempenho. O dashboard tratava ambos como o mesmo usuário, mostrando métricas erradas para cada lado. Resultado: nenhum dos dois chegava à primeira ação de receita.

O CEO queria dois produtos separados. Defendi um único produto com dois contextos para preservar componentes compartilhados e evitar fragmentar a base.

Havia alternativas diferentes para a arquitetura.

Alternativa A (pedida pelo CEO): dois produtos separados. Dobra custo de código, fragmenta base, fragmenta marca.

Alternativa B: manter produto único como estava. Continua com 50% de abandono.

Alternativa C (minha proposta): um produto com dois contextos. Componentes compartilhados, toggle explícito entre Produtor e Afiliado, navegação e métrica calibradas por contexto.

Como defendi a proposta: montei no Figma uma análise de reuso com variantes componentizadas. Não eram dois aplicativos independentes, mas um produto com contextos diferentes.

A engenharia resistiu no início: "é como manter dois apps." Apresentei a arquitetura de componentes compartilhados com alternância de contexto e um protótipo navegável com variantes. O lead de front-end aprovou depois de revisar.

Para o Produtor: foco em faturamento bruto, origem da receita (direta vs. afiliados), progressão temporal, tabela de vendas por produto e afiliado.

Para o Afiliado: foco em comissões totais, saldo pendente, próximo pagamento, cliques e conversões.

Esta é a decisão estrutural do case. A proposta preservou a base compartilhada e abriu caminho para o redesign do onboarding.

Decidida a arquitetura dual persona, a pergunta seguinte era prática: onde colocar o toggle que alterna contexto.

Primeira iteração: dropdown nas configurações. Nos testes de descoberta, o controle ficou escondido e os usuários operavam no contexto errado.

Segunda iteração: toggle visível no cabeçalho, com uma etiqueta explícita para a troca de contexto. A mudança tornou o controle encontrável nos testes.

Parece detalhe pequeno. Não é. O toggle é a porta do produto: onde você coloca o seletor de contexto determina se o usuário consegue operar, e consequentemente se fica ou abandona. É o mesmo princípio que define onde você coloca o seletor de conta, de cliente, ou de visão em qualquer dashboard operacional complexo.

A primeira tentativa de onboarding foi um tour guiado com tooltips. As sessões gravadas mostraram que o formato ensinava funções, mas não respondia ao que o usuário deveria fazer primeiro.

Falhou porque ensinava features sem resolver a ansiedade real: "o que eu faço primeiro". Usuário novo não quer tutorial. Quer saber se vale a pena investir tempo no produto.

A iteração que funcionou: transformar o próprio dashboard no tutorial. O widget "Primeiros Passos" com progress ring começando em 0% não é tutorial, é lista de conquistas desbloqueáveis. Cada passo salva estado no servidor, conexão instável não apaga progresso.

O mesmo sistema passou a apresentar tarefas calibradas pelo contexto do usuário.

Medição: comparei a taxa de conclusão em uma janela de 30 dias, com 3,1 mil novos cadastros no Mixpanel. O abandono caiu de 50% para 25%, uma redução de 25 pontos percentuais.

Aprendizado que levo para qualquer produto: onboarding não é tutorial. É produto sendo seu próprio professor, com progresso visível e conquistas desbloqueáveis no lugar de instruções.

A decisão mais transferível para domínios financeiros regulados.

A maioria dos sistemas trata reembolso como compliance: formulário genérico com "Outro" como escape, projetado para evitar chargeback e nada mais. Compliance, não inteligência.

Propus tratar reembolso como dado de produto, não só categoria legal, com motivos específicos do domínio.

O histórico mostrava que a categoria genérica "Outro" não explicava por que as pessoas pediam reembolso.

Depois do redesign, cada reembolso passou a alimentar um painel de qualidade e a funcionar como pesquisa de saída.

Paralelo direto com produto financeiro: em banco você tem dispute, chargeback, cancelamento de seguro, saque antecipado de investimento. Tratar esses eventos como compliance gera formulário. Tratar como sinal de produto gera inteligência. A mesma decisão arquitetural se aplica, com impacto ainda maior em receita e NPS.

Dois pilares paralelos que sustentaram todas as decisões acima.

Design system do zero. Tokens de cor, espaçamento, tipografia e grid, com governança compartilhada entre design e engenharia.

Isso foi precondição da arquitetura dual persona. Sem o sistema, o produto compartilhado teria se fragmentado.

IA no fluxo interno de design. Usei Cursor e Claude Code para prototipar e validar hipóteses antes do refinamento final.

O princípio que levo para qualquer contexto, incluindo design systems corporativos maduros: DS não é entrega, é precondição. Tokens centralizados, governança clara, e AI como acelerador de validação são o que permitem squads entregarem em paralelo sem comer consistência.