MVP virou a palavra que se usa pra justificar entrega ruim.
“É só o MVP” quer dizer, na prática, que está mal feito e todo mundo combinou de não falar sobre isso. E como todo mundo sabe que o MVP nunca é refeito, a dívida entra no produto pela porta da frente, com aval.
A ideia original não era essa.
O que a sigla realmente diz
Produto mínimo viável. As três palavras importam, e a que se ignora é a do meio.
Mínimo é o menor escopo. Todo mundo lembra dessa.
Viável quer dizer que funciona de verdade pra quem usa. Um produto que perde dado, cai toda hora ou exige que alguém do time faça a operação na mão não é viável. É demonstração.
E produto quer dizer que alguém consegue usar sozinho, sem apresentação e sem manual.
O MVP não é uma versão pior. É um escopo menor, feito direito. Uma funcionalidade que funciona bem vale mais que cinco pela metade, e essa frase é fácil de concordar e difícil de praticar.
A pergunta que o MVP deveria responder
MVP não existe pra entregar rápido. Existe pra aprender barato.
A pergunta certa é: qual é a maior incerteza que, se estiver errada, joga fora o resto do trabalho?
Essa incerteza raramente é técnica.
“As pessoas pagam por isso?” não se descobre com software. Descobre-se com uma página de vendas e um botão de compra que leva a um formulário.
“Elas conseguem usar sem treinamento?” descobre-se com protótipo clicável e cinco pessoas.
“A operação funciona com a gente fazendo na mão?” descobre-se fazendo na mão por duas semanas, com dez clientes, antes de escrever qualquer linha.
Se a maior incerteza for essa última, o MVP certo é uma planilha e uma pessoa. Isso ofende engenheiro, e é frequentemente o caminho mais rápido.
O que não é MVP
Metade do produto final. Cortar funcionalidade pela metade e entregar o esqueleto produz algo que ninguém consegue usar e que não ensina nada. Não valida nem a hipótese nem a execução.
Protótipo em produção. Código feito pra jogar fora, colocado no ar porque funcionou na demonstração. Esse é o caminho pelo qual a dívida técnica nasce grande e adulta.
Um trimestre de trabalho. Se demora um trimestre, não é mínimo. É a primeira versão, o que é legítimo e é outra coisa.
Desculpa pra pular teste. Aqui eu sou intransigente. Um MVP sem teste nenhum não permite mexer depois, e mexer depois é o ponto inteiro de um MVP: ele existe pra ser mudado a partir do que se aprende. Sem teste, cada mudança é uma aposta.
O corte que vale fazer
O que dá pra cortar sem virar demonstração:
Escopo de casos. Atenda um tipo de cliente, não sete. Um fluxo, não todos.
Automação. Faça na mão o que der. Cadastro manual, e-mail enviado por pessoa, relatório montado à noite. Isso é aceitável e reversível.
Interface de administração. Use o banco, use um script, use o painel do provedor.
Escala. Funcione com cem usuários. Otimizar pra cem mil antes de ter cem é a definição de trabalho jogado fora.
O que não dá pra cortar: integridade de dado, autenticação, controle de acesso e a capacidade de saber o que aconteceu. Essas quatro coisas, quando faltam no começo, custam dez vezes mais depois, e uma delas pode custar um vazamento.
O momento em que ele deixa de ser MVP
Todo MVP bem-sucedido vira produto sem que ninguém anuncie. Um dia tem trezentos clientes rodando em cima do que era “só pra testar”.
Isso é ótimo e precisa de um marcador. A conversa que quase nunca acontece: “esse experimento virou produto, agora ele precisa de teste, de monitoramento e de um dono”.
Sem essa conversa, o sistema envelhece com a estrutura de protótipo e a responsabilidade de produto, e é assim que se acumula o legado que ninguém quer manter três anos depois.
O sinal de que você entendeu
Você consegue responder duas perguntas antes de começar.
Qual é a hipótese que estou testando?
O que eu faço se ela for falsa?
Se a resposta da segunda for “a gente segue e faz o resto do roadmap”, não é MVP. É a primeira entrega de um plano que já estava decidido, e chamar de MVP só serve pra baixar o padrão de qualidade sem baixar a expectativa.
Escrevi sobre a mesma leitura, aplicada ao dia a dia de quem constrói, em o engenheiro que entende produto.