De um produto genérico, feito para todos, a um produto com público e propósito bem definidos.

Visão geral

Ao longo de três meses, tive um produto no ar chamado Orby, um assistente pessoal no WhatsApp com IA. A premissa era simples: e se o brasileiro pudesse ter um assistente inteligente, que fizesse tudo por ele, sem precisar instalar nada? Sem fricção de onboarding, sem novo app, tudo dentro do canal que já usava todo dia. O Orby fazia lembretes, controlava gastos, monitorava preços, gerava textos, pesquisava na internet, e muito mais, tudo o que o usuário precisasse para organizar seu dia, no seu próprio WhatsApp.

Ao final desses três meses, o produto tinha 78 usuários e praticamente zero de receita. Os dados de uso mostraram o que a ideia original ignorava: as pessoas praticamente só usavam o financeiro, e, em especial, a parte de vínculo entre parceiros, e nada mais. Esse sinal, cruzado com uma análise de mercado que revelou um espaço pouco explorado no Brasil, foi o argumento para descartar o produto e reconstruir do zero.

O Coupe é o resultado desse processo, um app mobile nativo para casais gerenciarem finanças juntos, construído por mim, do zero, solo, cobrindo estratégia de produto, design e desenvolvimento. Este case documenta as decisões que levaram até ele: o raciocínio por trás do pivot, por que o canal mudou, quais alternativas de design foram descartadas e por quê, e quais hipóteses o produto precisa validar para provar que a direção estava certa.

Orby: o produto e o que ele me ensinou

O Orby era um assistente pessoal no WhatsApp com IA. A premissa era simples, eliminar fricção de onboarding: sem app para instalar, sem curva de aprendizado, tudo dentro do canal que o brasileiro já usa todos os dias.

Em semanas estava no ar, com tudo o que o usuário precisava para gerenciar toda a sua vida (pelo menos era o que eu achava): lembretes recorrentes, controle financeiro, vínculo financeiro entre parceiros, monitoramento de preços, geração de conteúdo, transcrições e resumos de áudios, resumos de vídeos, busca de estabelecimentos locais, pesquisas em tempo real, entre outras funcionalidades e integrações.

O Orby tinha uma estrutura muito robusta de classificação de intenção e roteamento de Tools, onde cada tool tinha seus prompts específicos com suas regras. A taxa de acerto de uma classificação da mensagem do usuário para a atribuição correta de uma tool e sua execução era aproximadamente 95%.

O Orby tentava resolver a vida inteira do usuário de uma vez. Fazia muita coisa e, mesmo assim, não tinha resposta para a pergunta mais básica de todas: para quem ele existe?

Alguns números após 3 meses de lançamento

• 78 usuários cadastrados
• 2 usuários pagantes
• 37% de ativação (uso nos primeiros 3 dias)
• 18% de retenção D7

O sinal que os dados mostraram

A retenção D7 de 18% indicava que o produto não tinha virado hábito. Com isso, fiz uma survey e enviei para os usuários ativos, e isso me confirmou: por mais que os usuários conhecessem metade da capacidade do Orby, quase todos usavam apenas o controle e a gestão financeira com vínculo de parceiro. A maioria não precisava das outras soluções e não fazia questão de tê-las.

Junto disso, um achado interessante: quem usava controle e gestão financeira entre parceiros tinha um comportamento completamente diferente, voltava com mais frequência, reportava problemas e pedia melhorias. Era engajamento de quem tinha um problema real sendo resolvido.

Um terceiro dado fechou o diagnóstico. O Orby tinha um web app completo onde o usuário podia criar e consultar tudo, não só visualizar. Quase ninguém o acessava. Isso revelou uma contradição interna: a proposta de valor era “sem app, tudo no WhatsApp”, mas havia um web app paralelo contradizendo essa promessa. Dois canais completos sem divisão clara de propósito não somam valor, dividem atenção. O produto não sabia o que era.

A decisão de pivotar

A decisão de pivotar o Orby e reconstruir do zero precisava ser baseada em mais do que o comportamento de 78 usuários. Então, eu precisava entender se havia espaço real para o que os dados de uso sugeriam. Com isso, fiz rapidamente:

• Análise de mercado: entender o tamanho do mercado financeiro para casais, a penetração de produtos relacionados e não relacionados (produtos financeiros de uso individual) no Brasil, etc.
• Análise de competidores: mapear possíveis competidores, entender estratégia de posicionamento e coletar inspirações de design.

E a decisão mais importante: por que sair do WhatsApp?

Essa foi a decisão mais contraintuitiva do processo. Sair do WhatsApp significava abrir mão de uma vantagem de distribuição real. O brasileiro não precisa ser convencido a instalar o WhatsApp, ele já está lá. Exigir o download de um app novo é fricção adicional na aquisição.

Mesmo assim, a decisão foi migrar para um app mobile nativo. O raciocínio teve quatro partes.

1. WhatsApp tem teto de experiência baixo para finanças: finanças pessoais precisam de visualização de dados. Gráficos, totalizadores por mês, comparação entre categorias, progresso de metas. Nada disso é viável em uma conversa de chat. O WhatsApp funciona bem para entrada de dados por mensagem de voz ou texto, mas falha quando o usuário precisa ter clareza sobre o estado geral das suas finanças. Um casal tentando entender como fechou o mês não consegue fazer isso em um histórico de mensagens.
2. O produto para casal exige estado compartilhado visível: a funcionalidade de vínculo entre parceiros no Orby mostrava engajamento alto porque resolvia um problema real. Mas a experiência era limitada: cada um via sua própria thread de conversa. Havia unificação de dados financeiros do casal, mas o WhatsApp não permitia uma experiência agradável. Para um produto cujo núcleo de valor é a gestão financeira a dois, a ausência de uma visão compartilhada não é um problema de UX, é um problema de produto.
3. O app nativo resolve o canal de aquisição de outra forma: a vantagem de distribuição do WhatsApp é real, mas o público de casais querendo organizar finanças juntos tem uma característica específica: os dois precisam usar o produto. Isso muda a dinâmica de aquisição. Um membro do casal convence o outro. A indicação acontece dentro do próprio relacionamento. Isso reduz o problema de aquisição de uma busca em massa por usuários para uma busca por casais, onde a conversão interna é natural.
4. O web app do Orby já provou que a web não resolve: essa foi a evidência empírica que fechou o argumento. O Orby tinha um web app completo, funcional, onde o usuário podia criar e consultar tudo, não apenas visualizar. E quase ninguém usava. Isso eliminava a web como caminho: não era falta de interface visual ou de funcionalidade, era uma questão de comportamento. O usuário brasileiro não tem o hábito de abrir uma aba no navegador para gerenciar finanças do dia a dia. Ele pega o celular. Um app nativo ocupa espaço na tela inicial, recebe notificações, está a um toque de distância no momento exato em que o usuário precisa registrar um gasto. Nenhuma versão web entrega isso com a mesma naturalidade. Continuar na web seria repetir o mesmo erro com uma interface diferente.

Definindo o que seria o produto

Escrevi uma frase que precisava ser verdadeira para o produto valer a pena existir:

O lugar onde um casal organiza o dinheiro, acompanha as metas e constrói os planos juntos.

Essa frase funcionou como filtro de decisão. Cada funcionalidade, fluxo ou elemento de interface foi avaliado contra ela. O que não serve à frase não entra no produto.

Com isso, fiz Jobs To Be Done, que me guiaram tanto no escopo do produto quanto na hierarquia das decisões de design ao longo de todo o processo.

1. Quero saber quanto gastamos juntos neste mês sem precisar perguntar para o parceiro.
2. Quero ver meus gastos separados dos do meu parceiro quando quiser.
3. Quero registrar despesas rapidamente, sem abrir planilha.
4. Quero que nossas metas de poupança tenham progresso visível para os dois.
5. Quero entender em quais categorias estamos gastando mais.

Principais decisões que orientaram o projeto

1. Privacidade granular, não binária

Tudo compartilhado por padrão ignora que casais têm finanças parcialmente separadas. Tudo privado com compartilhamento manual por item gera atrito em cada lançamento. A decisão foi um terceiro modelo: privacidade configurada por conta e cartão, não por lançamento. O usuário define uma vez, e o fluxo diário é sem fricção. O saldo combinado considera só o que foi marcado como compartilhado. Isso espelha como casais realmente organizam o dinheiro.

2. O produto tem dois donos

Em apps individuais, um usuário inativo é uma perda. Em um produto de casal, um usuário inativo degrada o valor para o outro também. Se o parceiro para de lançar gastos, o saldo fica incompleto e o produto perde sentido para os dois. A decisão foi sequenciar o valor: o produto precisa ser útil para o primeiro usuário antes do parceiro entrar, não depender do vínculo para funcionar. A visão casal só aparece após o vínculo, mas todas as funcionalidades individuais funcionam desde o primeiro acesso.

3. Compartilhado como padrão, privado como exceção

Quando um formulário não sinaliza um padrão, a maioria dos usuários escolhe privado por inércia. Num produto de casal, isso cria uma contradição: o app existe para organizar finanças juntos, mas o design empurra para o isolamento. A decisão foi inverter: com parceiro vinculado, a conta nasce compartilhada. O toggle existe, mas o rótulo é “conta privada”. O usuário age ativamente para não compartilhar. Definir o padrão é tomar uma posição de produto. Um app de finanças para casais que tem privado como padrão não está alinhado com o próprio propósito.

Validação

Conduzi testes de usabilidade com os usuários, pessoas em um relacionamento que já tinham o hábito de organizar finanças juntos de alguma forma, seja planilha, outro app ou conversa no WhatsApp.

As sessões focaram em três pontos diretamente ligados aos objetivos do produto: o usuário entendia o que era visível para o parceiro e o que não era, sem precisar ler nenhuma documentação? A alternância entre as visões “eu”, “parceiro” e “casal” correspondia à forma como o casal naturalmente pensa sobre o próprio dinheiro? O produto fazia sentido para o primeiro usuário antes do segundo entrar, ou parecia incompleto sem o vínculo ativo?

O objetivo central era entender se o modelo do produto correspondia ao modelo mental de um casal real. O Coupe tem regras de negócio específicas: contas compartilhadas e privadas coexistem, o saldo do casal reflete só o que foi marcado como compartilhado, e o produto precisa funcionar individualmente antes do parceiro entrar. Essas regras precisavam ser compreendidas intuitivamente, sem explicação.

Modelo de negócio

O freemium do Orby criou o incentivo errado: o produto precisava ser útil o suficiente no free para reter, mas não tanto que eliminasse a razão para pagar. No Coupe, a decisão foi estruturar a conversão em torno do valor real: trial com acesso completo, sem pedir cartão, seguido de um corte claro. Se o usuário não converte, o problema é o produto, não o modelo. Essa clareza é útil: sinal de baixa conversão aponta diretamente para gaps de valor percebido, não para barreiras de entrada.

Aprendizados

Engajamento diferenciado vale mais que volume: 78 usuários com comportamento médio fraco escondiam um subgrupo com comportamento completamente diferente. Em bases pequenas, os outliers positivos são o sinal mais valioso.

Público definido simplifica cada decisão: quando o produto é para casais, “isso deve entrar?” tem uma resposta mais rápida e mais honesta do que quando o produto é para todos.

Canal e produto são inseparáveis: sair do WhatsApp foi contraintuitivo, mas o canal limitava a experiência de forma estrutural. O web app existia e não engajou. A decisão de ir nativo precisava dos dois dados para ser sólida.

O que a IA mudou, e o que ela não muda

A IA acelerou a execução de forma real. E aí está o perigo: quando construir uma funcionalidade leva horas, a tentação de adicionar é constante. O Orby tinha dez funcionalidades não porque dez eram necessárias, mas porque eram fáceis de construir. A IA remove a fricção técnica, não remove a pergunta mais importante: isso precisa existir? No Coupe, cada decisão de escopo passou pelo filtro dos jobs. A IA muda quem pode construir um produto. Não muda o que vale a pena construir.