Um brief para construir um CRM do zero. O problema: ninguém sabia por onde começar. Conduzi o discovery que definiu o ponto de partida — 5 entrevistas, matriz de priorização, MVP defendido com evidência e protótipo funcional via vibe coding.
O brief pedia um CRM do zero. As entrevistas revelaram que o ponto de partida não era contatos nem campanhas — era Jornadas. Defender um MVP menor do que o pedido exige argumento mais forte do que preferência de design. Exige evidência de usuário.
A Cactus Gaming usava um CRM contratado de terceiros. A decisão estratégica de construir uma solução própria foi tomada com base em controle de dados, customização e custo de longo prazo. O brief era amplo: construir um CRM do zero para substituir o atual.
Amplo demais. Um CRM pode ser dezenas de coisas — gestão de contatos, segmentação, automação de campanhas, análise de cohort, jornadas de comunicação, scoring de leads. Construir tudo seria meses de desenvolvimento sem valor entregue. A pergunta que o brief não respondia era: por onde começar?
Minha função no projeto foi conduzir o discovery que definiria esse ponto de partida — entrevistar, mapear, priorizar e defender um MVP específico baseado no que os usuários realmente precisavam primeiro.
Entrevistei cinco usuários internos que trabalhavam diariamente com o CRM contratado. O roteiro não perguntou "o que você quer no novo sistema". Perguntou o que eles faziam, onde travavam e o que os fazia perder mais tempo.
Três eixos emergiram com consistência em todas as entrevistas:
Revelou onde estava o valor real do CRM para cada perfil. Não foram contatos nem relatórios. Foi a gestão de jornadas de comunicação — criar, monitorar, ajustar. Isso apareceu em todas as cinco entrevistas.
Revelou os pontos de fricção não óbvios. Configurar condições de jornada, visualizar o estado atual de jornadas ativas, entender por que uma automação falhou. Problemas de clareza, não de funcionalidade ausente.
Revelou as hipóteses dos usuários — algumas boas, algumas que validaram por que certas funcionalidades do CRM atual existiam mesmo parecendo dispensáveis. Nem tudo que irrita é dispensável.
Os dados das entrevistas convergiam para um único objeto: a Jornada. Não um contato, não uma campanha, não um relatório. A Jornada era o que os usuários criavam, monitoravam e ajustavam com mais frequência — e onde o CRM atual mais causava fricção.
O MVP foi delimitado em torno de um único objeto — a Jornada — com um ciclo completo de três momentos. Tudo que ficou fora foi documentado como backlog priorizado: não descartado, só postergado até o ciclo central estar funcionando e validado.
A proposta de MVP foi apresentada à liderança com uma matriz de priorização que tornava a lógica visível: valor de negócio × frequência de uso × viabilidade técnica no prazo. Jornadas dominava as três dimensões.
A resistência foi previsível: "mas precisamos de gestão de contatos também" e "sem segmentação o CRM não funciona". A resposta foi baseada nos dados das entrevistas — não em opinião de design. Os usuários não pediam contatos nem segmentação como primeiro passo. Pediam Jornadas funcionando bem.
Defender um escopo menor do que o pedido é contraintuitivo. A pressão natural é a de entregar o máximo possível para parecer mais valioso. Mas um MVP que tenta cobrir tudo não valida nada — ele apenas distribui o esforço de desenvolvimento por um conjunto de funcionalidades nenhuma das quais funciona bem o suficiente para ser usada no dia a dia.
A proposta foi aprovada.
"A evidência de usuário transforma a conversa. Não é o designer dizendo que quer começar por Jornadas. São cinco usuários, em cinco entrevistas independentes, dizendo que é onde passam mais tempo e onde têm mais problemas. Isso não é opinião. É dado."
Com o escopo aprovado, desenvolvi protótipos em alta fidelidade no Figma para as três áreas do MVP. Mas para validação com usuários, o Figma tem limitações — interações complexas de drag and drop e lógica condicional são difíceis de prototipar fielmente sem que o usuário sinta a diferença.
Optei por gerar um protótipo funcional usando vibe coding — Claude Code + Tailwind CSS — para criar uma versão navegável do Journey Builder que permitisse testar as interações reais antes do desenvolvimento começar. O protótipo funcional não era o produto final. Era uma pergunta: o fluxo de drag and drop que projetamos no Figma realmente funciona quando você tenta usá-lo?
O protótipo foi usado em sessões de teste com dois dos usuários entrevistados. O que o Figma não havia revelado ficou evidente: a interface de configuração de condicionais estava mais complexa do que parecia nas telas estáticas. Usuários conseguiam criar a jornada mas travavam na hora de adicionar a primeira condição. O ajuste foi feito antes do desenvolvimento — não depois.
A entrevista com usuários reais antes de qualquer tela foi o que tornou possível defender um MVP menor do que o pedido com argumento sólido. O protótipo funcional via vibe coding revelou um problema de usabilidade que o Figma não havia capturado — e revelou antes do desenvolvimento começar, quando o custo de mudança é baixo.
O projeto foi descontinuado antes da implementação completa. O discovery está feito, o protótipo existe, o backlog está priorizado — mas o produto ainda não está em produção. O investimento de discovery precisa de continuidade para gerar valor real. Discovery sem implementação é pesquisa, não produto.
Ampliaria a amostra de entrevistas para cobrir todos os perfis de usuário.
Cinco entrevistas revelaram padrões consistentes, mas o CRM seria usado por perfis diferentes — analistas, gerentes, time de produto. Expandir as entrevistas para cobrir todos os perfis teria validado se a convergência para Jornadas se mantinha em todos os grupos ou se era uma preferência específica dos usuários mais operacionais que foram entrevistados.
Definiria também critérios explícitos de sucesso do MVP durante o discovery. O MVP foi aprovado, mas sem métricas de validação: como saberíamos que as Jornadas estavam funcionando bem o suficiente para partir para o próximo módulo? Taxa de conclusão de jornadas criadas, tempo médio para configurar uma jornada, número de edições pós-ativação. Essa definição precisaria ter acontecido durante o discovery — não depois do lançamento.