MVP em oito semanas: o que entra, o que fica de fora

MVP virou desculpa para duas coisas opostas: entregar qualquer coisa mal feita, ou nunca entregar porque "ainda falta". Nenhuma das duas é o conceito.

Um MVP é a menor versão que já resolve o problema de verdade para alguém. As duas partes importam: menor e de verdade.

O corte que funciona

Divida tudo o que o produto deveria fazer em três listas:

Sem isso não existe produto. Se o seu SaaS é de agendamento, agendar é isso. Sem agenda não tem produto — tem site institucional.

Sem isso o produto existe, mas dói. Relatório, exportação, notificação, personalização. Dói, mas dá para viver algumas semanas com processo manual por trás.

Isso é para quando der certo. Integração com cinco sistemas, app nativo, painel de administração completo, multi-idioma.

O MVP é a lista 1 inteira, bem feita. Não é metade da lista 1 com um pedaço da 3 porque pareceu impressionante na demonstração.

O que nunca entra no corte

Existem itens que parecem "fase 2" e não são:

• Autenticação e permissão de verdade. Consertar isso depois significa reescrever o acesso a dado inteiro.
• Backup. No primeiro dia. O momento em que você percebe que precisava é sempre tarde demais.
• Um jeito de saber o que os usuários fazem. Sem isso, a fase 2 vira adivinhação.
• Modelagem de dados pensada. Interface se refaz em uma semana. Estrutura de dados errada contamina tudo o que vem depois.

Como oito semanas se dividem

Na prática, em um projeto de porte médio:

• Semanas 1–2: discovery, fluxos e modelagem. Nada de código de produto ainda — e essa é a parte que mais economiza depois.
• Semanas 3–6: desenvolvimento em ciclos curtos, com ambiente de homologação disponível desde o primeiro ciclo. O cliente vê o produto crescendo, não um relatório de progresso.
• Semana 7: teste de fluxo, borda e regressão. Correções fechadas com checklist de aceite.
• Semana 8: publicação, monitoramento ligado, backup configurado, plano de rollback pronto.

O sinal de que o recorte foi bom

Um MVP bem recortado deixa o time desconfortável. Sempre parece que falta alguma coisa importante — e falta mesmo. A diferença é que agora existe gente usando, e a lista do que falta passou a ser escrita por elas, não por nós.

Exemplo ilustrativo de recorte

Imagine um sistema de agendamento para uma pequena clínica. Um recorte possível:

• Lista 1 (sem isso não existe produto): cadastro de profissionais e horários, agendamento pelo recepcionista, lista do dia, cancelamento e remarcação, acesso com login por perfil.
• Lista 2 (existe, mas dói): lembrete automático por mensagem, relatório mensal, exportação de pacientes.
• Lista 3 (para quando der certo): agendamento pelo próprio paciente, integração com convênios, aplicativo nativo.

O MVP entrega a lista 1 funcionando de ponta a ponta, com um cliente real usando. (O exemplo é ilustrativo: cada negócio terá listas diferentes.)

Como saber se o MVP está funcionando

Defina antes de lançar, por escrito, três números simples:

• Uso: quantas pessoas usam por semana e quantas voltam.
• Resultado: o problema original melhorou? Por exemplo, quanto tempo a tarefa leva agora comparado a antes.
• Atrito: onde as pessoas travam ou pedem ajuda.

Sem esses números, a conversa da fase 2 vira opinião. Com eles, vira decisão: investir mais, ajustar ou mudar de rota.

Erros comuns de quem monta um MVP

• Pular o discovery: começar a construir sem entender o fluxo real (veja o artigo sobre discovery antes do código).
• Construir para um usuário imaginário: combine com ao menos uma pessoa real que vai testar desde as primeiras semanas.
• Cortar qualidade em vez de escopo: a regra é fazer menos coisas, bem feitas, e não muitas coisas pela metade.
• Lançar sem monitoramento: sem saber o que acontece em produção, o time descobre os problemas pelo cliente.
• Tratar o MVP como produto final: ele é o começo de um ciclo de aprendizado, com revisões e próximos passos planejados.

O produto que sai em oito semanas e é usado por dez pessoas ensina mais do que o produto perfeito que sai em doze meses. E custa uma fração: um MVP de porte pequeno começa perto de R$ 6 mil, contra os R$ 50 mil de uma plataforma completa construída no escuro.