Como uma pergunta sobre churn virou um MVP que gerou R$ 800 mil em receita no primeiro mês.
Meio do ano, churn subiu 10–20%. A reação óbvia seria defensiva. A gestão perguntou outra coisa: como transformar esse risco em oportunidade?
A resposta não estava em reter mais, estava em capturar melhor. O problema dos clientes não era volume de leads. Era visibilidade.
Poderíamos ter construído tudo. O risco era exatamente esse.
Fiz análise competitiva em vez de começar um discovery do zero, pra entender como o mercado já resolvia esse problema. Mapeei quais conceitos fazia sentido adaptar e validei a estratégia com o time. Usei MoSCoW pra separar o essencial do diferencial e priorizei 3 features pro MVP (importação de leads, tratamento de lead, dashboard de gestão), deixando relatórios avançados e painéis de evento fora do escopo. Estruturei as stories com contexto de negócio, não só requisito técnico. Validei escopo e prioridades com stakeholders, acompanhei o time até o go-live.
Analisar concorrentes em vez de partir pra discovery do zero.
Por quêAproveitar o que o mercado já validava sobre esse problema, em vez de reconstruir esse aprendizado do zero.
ImpactoBase concreta pra adaptar conceitos ao nosso contexto, validada com o time antes de qualquer story.
Priorizar 3 features no MVP e deixar o resto fora.
Por quêO problema mais urgente era visibilidade e rastreabilidade em tempo real; relatórios avançados e painéis de evento eram diferenciais, não críticos pro launch.
ImpactoMVP entregue dentro do prazo de 2 meses, focado no que resolvia a dor real do cliente.
Lançar direto com usuários reais, durante os eventos, sem fase de testes controlada.
Por quêCom o calendário do evento fixo, a decisão foi assumir o risco de validar em produção, reforçando suporte e monitoramento como plano de contingência.
ImpactoIncidentes em produção, suporte bastante acionado, resolvidos rápido, mas virou o principal aprendizado do projeto.
Criar um canal único no Slack pra centralizar os reports do ambiente produtivo.
Por quêOs reports do incidente chegavam direto pro time de desenvolvimento, pulverizados, competindo com entregas e correções de bugs que já estavam no capacity.
ImpactoFluxo de reports centralizado e triado, sem sobrecarregar o time nem atrasar as entregas em andamento.
Validação completa antes de escalar custa menos do que parece, muito menos do que um incidente em produção durante um evento ao vivo. Desse projeto ficou um padrão que uso hoje em qualquer discovery: questionar a demanda, porque nem sempre o problema é o óbvio, e priorizar sem dó, porque MVP não é tudo que seria legal. Com mais controle sobre o calendário, teria optado por um rollout gradual, com feature flag pra validar com um grupo reduzido de usuários antes de abrir pra todo mundo.
Prazo apertado não elimina a opção de validar em camadas, só exige escolher melhor onde cortar.