Como uma hipótese sobre leads dispersos virou um MVP em 2 meses, adotado por 80% dos clientes no primeiro mês.
Atuei como Product Owner de uma plataforma web (SaaS) de gestão de leads para concessionárias, acessada via login por gestores e vendedores das lojas.
Os gestores de concessionárias tinham leads dispersos entre planilhas, Facebook e Instagram.
Minha hipótese: centralizá-los aumentaria a fidelização aos eventos. 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 gamificação e página de captura 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; gamificação e página de captura podiam esperar, não eram críticas 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 Service Desk no Slack pra centralizar os reports do ambiente produtivo.
Por quêOs devs eram acionados de modo informal, via WhatsApp, e os reports chegavam pulverizados, competindo com entregas e correções de bugs que já estavam no capacity.
ImpactoCategorias e severidades definidas por mim, Kanban no ClickUp, ~3 chamados/dia com resposta em até 2 dias úteis; o histórico alimentou o backlog e embasou a vaga de QA e a adoção de cenários de teste antes dos lançamentos.
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.