yampa · yampa · 2021–presente
Como estratégia de negócio, pesquisa com usuários e um workflow AI-first viraram o jogo de um SaaS em dificuldade.
Staff Product Designer · Design Manager
Contexto
O usuário típico do yampa é um pequeno empresário. Alguém que toca uma padaria, uma loja, uma agência. O controle financeiro é uma entre dezenas de tarefas disputando sua atenção, e quase sempre perde para o core business.
A dor real não é falta de tempo. É priorização: eles não conseguem enxergar como uma rotina financeira bem cuidada mudaria a trajetória da empresa, então nunca dão a ela a atenção necessária. O produto precisava provar esse valor antes de pedir esforço.
Havia uma segunda camada de complexidade. O yampa atendia dois públicos muito diferentes: clientes vindos da 4blue, uma empresa de educação financeira cujos cursos já tinham tornado a dor visível, e usuários de mar aberto, que chegavam com um nível de consciência muito mais baixo. Mesmo produto, dois pontos de partida completamente diferentes na jornada.
Fase Um — Estratégia de Negócio
Quando entrei, o yampa era totalmente dependente da empresa mãe, com um modelo de preço que não escalava.
Antes de tocar em qualquer tela, trabalhei com o CEO no negócio em si. Introduzimos um modelo de assinatura em níveis, desenhado em torno de quanta orientação cada segmento realmente precisava. Usuários com mais consciência conseguiam se virar sozinhos. Usuários com menos consciência precisavam de mais acompanhamento, e estavam dispostos a pagar por isso.
Precificação é design. A forma como um produto cobra molda como as pessoas o usam, o que esperam dele e se permanecem. A receita cresceu significativamente sem um aumento proporcional de assinantes.
Fase Dois — yampa 2.0 e a decisão que não foi tomada
O 2.0 era uma reconstrução completa. Nova experiência, nova arquitetura, mobile-first.
Fizemos a pesquisa direito. Dezenas de entrevistas. Mapeamos dois perfis principais: empreendedores por oportunidade, que herdaram o negócio ou escolheram uma área que amavam, e empreendedores por necessidade, que abriram uma empresa porque não tinham outra escolha. Dentro de cada grupo, as operações maiores geralmente tinham alguém dedicado ao financeiro. As menores, a maioria, faziam tudo sozinhas.
Os testes de usabilidade revelaram nosso ponto cego: os usuários dispostos a participar eram quase sempre clientes da 4blue. Nossa amostra de pesquisa estava enviesada para o público que já entendia o valor.
Então veio a decisão que nunca foi tomada. O produto precisava escolher: construir para o cliente 4blue, mais adiante na jornada, ou para o usuário de mar aberto, que precisava primeiro ser convencido.
Levantei essa questão repetidamente. Apresentei os dados de segmentação, pressionei por uma decisão nas revisões de produto, e perdi essa discussão mais de uma vez. O foco seguia alternando entre os dois públicos, e cada pivô diluía um pouco mais a personalidade do produto, até que ele não se conectou com nenhum dos dois.
Olhando para trás, eu deveria ter pressionado mais forte e mais cedo, quando o custo de escolher ainda era baixo. Isso também é responsabilidade minha. Depois de dois anos de trabalho, uma semana antes do lançamento, o 2.0 foi cancelado por dívida técnica crítica. A indecisão tinha custado o tempo que a fundação técnica precisava.
Fase Três — A Reconstrução AI-First
Perder dois anos de trabalho força clareza. Não podíamos bancar outro ciclo de dois anos, então mudei a forma como o próprio trabalho era feito.
Introduzi um workflow AI-first: penso no problema com o Claude antes de abrir o Figma. Intenção, casos de borda, especificações. Depois desenho, e construo eu mesmo os componentes React com Claude e Cursor, enviando direto para o repositório. Sem handoff. Quem desenha é a mesma pessoa que entrega.
Isso não é prototipação com IA. É código de produção: a nova home (a tela no hero acima), todo o módulo de fluxo de caixa, a listagem de lançamentos, a navegação. Eu desenhei e implementei tudo.
Para dar escala: só a nova home teria levado pelo menos um mês de idas e vindas no processo antigo. Trabalhando assim, levou três dias.
Todo o frontend foi reconstruído em dois meses. O ciclo design-produção caiu 70%, e as decisões de design pararam de morrer na tradução.
Impacto
Além dos números: o design system foi adotado por todo o time de engenharia, e o event tracking foi instrumentado em todo o produto, então as decisões vinham de dados de ativação, adoção e churn em vez de opinião.
O crescimento do MRR teve muitos pais: vendas, marketing e timing de mercado fizeram sua parte. O que eu possuo diretamente: a arquitetura de precificação, a experiência do produto e a velocidade de entrega que tornou a iteração possível.
Pessoas
Muitas pessoas passaram por esse projeto. Algumas ficaram tempo suficiente para crescer com ele — e esse crescimento foi a melhor parte do trabalho.
Lauren, Silas e Matheus apareceram todo dia e se tornaram colaboradores mais afiados e resilientes através de cada pivot e recomeço. Ver essa evolução valeu mais do que qualquer lançamento.
Bruno e Rapha mantiveram a direção estratégica nos momentos mais difíceis. As decisões nem sempre foram fáceis, mas sempre foram tomadas.
Para todos que ainda estão construindo o yampa — boa sorte com o que vem a seguir.
Aprendizados
Um produto que não escolhe seu usuário acaba não sendo escolhido por ninguém. O 2.0 não falhou por causa do design ou da engenharia. Falhou porque uma decisão estratégica foi adiada até ser tarde demais. Hoje eu pressiono por essa decisão desde o primeiro dia, mesmo quando é desconfortável.
A pesquisa segue a mesma regra: se os participantes dispostos vêm todos de um único segmento, você não está aprendendo sobre o seu mercado. Está confirmando o seu viés.
E a velocidade mudou de significado para mim. Com IA no workflow, o trade-off entre rápido e refinado desabou. O gargalo não é mais construir. É decidir o que merece ser construído.
Quer conversar sobre como esse workflow poderia funcionar para o seu time?
Fale comigo →
