A maioria dos MVPs não é
A sigla foi esticada até virar qualquer coisa que um fundador lança com pressa. A versão que sobrevive é, em grande parte, exercício de marketing. A versão que ajuda é uma aposta falseável — e quase ninguém escreve a aposta antes de começar.
Há alguns meses um fundador nos mostrou o MVP dele. Era uma aplicação web funcional, construída em sete semanas por um freelancer que ele encontrou na Workana. Tinha autenticação, dashboard, três fluxos centrais, painel de admin e integração com Stripe. Custou R$ 38 mil. Ele estava orgulhoso, e tinha nos chamado porque queria ajuda para “escalar”. Fizemos uma pergunta: o que esse MVP te ensinou que você ainda não sabia?
Ele pausou. Disse que os clientes gostaram. Depois disse que três se cadastraram. Depois disse que dois dos três eram amigos. Aí ficamos em silêncio por um minuto, porque chegamos juntos à mesma conclusão. O MVP não validou nada. Construiu algo. São coisas diferentes.
Eric Ries cunhou “minimum viable product” em 2008. A frase aparece em The Lean Startup com uma definição específica e cuidadosa — a versão de um produto novo que permite ao time coletar a maior quantidade de aprendizagem validada sobre clientes com o menor esforço possível. Leia duas vezes. A unidade de saída não é um produto. A unidade de saída é aprendizagem. Tudo o mais é efeito colateral.
Quase ninguém que usa o termo em 2026 quer dizer o que Ries queria. A sigla foi esticada até significar qualquer coisa que um fundador lança com pressa, e a versão que vence no LinkedIn é em grande parte um exercício de marketing — uma aplicação funcional, um tweet de lançamento, um print de três cadastros e um post sobre “validação de product-market fit”. Isso não é validação. É teatro vestido com vocabulário de validação.
A corrupção é estrutural
A razão pela qual o MVP deixou de funcionar como mecanismo de aprendizagem não é que os fundadores ficaram preguiçosos. É que o custo de construir o artefato caiu mais rápido que o custo de descobrir o que o artefato deveria testar. Em 2008, construir uma aplicação web funcional do zero exigia seis engenheiros e quatro meses. O atrito forçava o fundador a pensar muito sobre o que construir, porque construir qualquer coisa era caro. Em 2018, com no-code e freelancers baratos, o custo desabou. Em 2024, com IA assistindo desenvolvimento, desabou de novo.
O que não desabou — e não tinha como desabar — foi o trabalho cognitivo de decidir o que testar. Definir a afirmação falseável, desenhar o teste que de fato a falsearia, escolher a métrica, escolher a população, escolher o limiar: esse trabalho tem a mesma dificuldade em 2026 e em 2008. Não é problema de ferramenta. É problema de pensamento.
Aconteceu uma coisa estranha. O custo de construir caiu para perto de zero, enquanto o custo de decidir o que construir permaneceu constante. O caminho de menor resistência virou: pular o pensar, começar a construir. Fundadores que antes seriam forçados pela economia da época a buscar clareza agora podem simplesmente pular a etapa de clareza. O MVP virou uma construção, não um teste. E o vocabulário ficou — porque “MVP” continua soando disciplinado, mesmo quando o trabalho não mostra nenhuma da disciplina que o termo originalmente implicava.
O resultado é uma categoria de artefato que chamamos de MVP teatral. Parece um MVP. Custa o que um MVP custaria. É lançado no prazo de um MVP. Mas não conta nada ao fundador que ele já não sabia, porque nenhuma afirmação foi especificada antes do início da construção.
O teste que importa: escreva a aposta primeiro
A única mudança que converte um MVP teatral em um real é brutalmente simples. Antes de qualquer linha de código, o fundador escreve uma frase:
“Se, até [data], não tivermos visto [comportamento específico] de [população específica], em [limiar específico], estamos errados sobre [afirmação específica].”
Essa frase não é um slogan. É um contrato. Compromete o fundador com uma afirmação falseável e com uma definição de fracasso. As duas metades importam. Sem a afirmação, não há nada para testar. Sem a definição de fracasso, não há aprendizagem — qualquer resultado pode ser racionalizado como “promissor”.
Três fundadores com quem trabalhamos no ano passado usaram uma versão dessa frase antes de escopar a primeira construção. Um deles escreveu: “Se, em sessenta dias depois do lançamento, menos de 30% das pequenas clínicas que onboardamos tiverem feito login no dashboard pelo menos três vezes no segundo mês, a tese de care assíncrono está errada e devemos pivotar.” Sessenta dias depois, o número era 11%. Não lançaram v2. Voltaram para reentrevistar as clínicas, descobriram que o gargalo não era interesse em care assíncrono, e reconstruíram em torno de um fluxo totalmente diferente. Esse MVP fez exatamente o que MVP serve para fazer. Não entregou um produto para escalar. Entregou uma tese para parar de construir em cima.
Os outros dois fundadores se recusaram a escrever a frase. Perguntamos. Disseram que não conseguiam escolher um número, porque não sabiam que número era razoável. Apontamos que não saber qual número é razoável é exatamente o problema que o MVP deveria resolver. Se você não consegue articular como é o sucesso antes de começar, não vai conseguir reconhecer sucesso ou fracasso quando terminar. Só vai conseguir racionalizar o resultado que veio.
Por que a frase é a parte difícil
A razão pela qual a maioria dos fundadores pula a frase é que a frase os obriga a confrontar as partes do negócio que deixaram vagas. Para escrever uma afirmação falseável, você precisa conhecer o cliente específico o bastante para especificá-lo. Precisa conhecer o comportamento específico o bastante para instrumentá-lo. Precisa conhecer o limiar específico o bastante para defendê-lo. Nenhuma dessas é habilidade técnica. Todas são disciplina comercial.
Por isso o problema do MVP raramente é problema de engenharia. É problema de clareza comercial fantasiado de problema de construção. O fundador contrata um desenvolvedor porque desenvolvedor pode ser contratado. O trabalho de clareza não tem fornecedor óbvio. Então o fundador compra o que dá pra comprar, lança o que dá pra lançar, e a pergunta original — o que estamos testando? — vai sendo silenciosamente abandonada no caminho.
Um bom parceiro de engenharia é a penúltima linha de defesa contra isso. Um bom parceiro de engenharia se recusa a começar a codar até que o fundador tenha respondido às quatro perguntas: que afirmação estamos testando, que comportamento a falsearia, qual a população, qual o limiar? A última linha de defesa é o próprio fundador. Se o parceiro não empurra e o fundador não escreve a frase, o que se lança é, na melhor das hipóteses, uma aplicação funcional, e o fundador descobre, um ano depois, que gastou quarenta mil reais aprendendo nada.
O que um MVP não é
O ponto de escrever isso tudo não é ser preciosista com o termo. É sinalizar uma confusão de categoria que custa runway aos fundadores. Então, para evitar dúvidas:
Um MVP não é um produto pequeno. Pode ser pequeno ou grande; o que importa é se está montado para testar algo. Um MVP não é um lançamento. Lançar é uma atividade separada, às vezes parte do teste, às vezes não. Um MVP não é “a coisa que lançamos antes de construir o produto de verdade”. Se a coisa lançada não muda uma decisão real com base no resultado, chamar de MVP é só pegar dignidade emprestada do termo original.
Também não é o máximo que dá pra construir em três meses. A maioria dos fundadores, quando forçada a reduzir escopo, reduz no eixo errado — corta o acabamento e mantém a amplitude. Um MVP de verdade corta a amplitude, com força, e mantém acabamento suficiente para que o comportamento de um cliente real seja observável. Oito funcionalidades mal feitas te dizem menos que duas funcionalidades bem feitas, porque o que importa é o atrito do cliente, não a área de superfície.
A versão do termo que valeria manter
Já pensamos em jogar a sigla fora. Está tão corrompida que defendê-la cansa. Mas há um uso que ainda se justifica, e a disciplina de distinguir esse uso vale mais do que o trabalho de inventar uma palavra nova.
A versão que vale a pena manter é o menor artefato que, posto na frente de um cliente real, gera um sim ou um não para a hipótese remanescente mais cara. Esse é o teste. Três coisas precisam ser verdade para o artefato qualificar. Tem que ser pequeno o bastante para a construção não exceder a aprendizagem. Tem que estar na frente de um cliente real — não amigo, não designer, não time. E tem que produzir uma resposta — sim ou não — que muda o que o fundador constrói depois.
Se o seu MVP não muda o que você constrói depois, não é um. Seja lá o que for, não é o que Ries falou. E a pergunta que vale fazer, antes de escrever a spec, é a mesma que nosso amigo em São Paulo não conseguiu responder: o que isso me ensinaria que eu já não sei?
Se você não consegue dizer, não construa. O MVP mais barato é o que você não lança — porque escrever a frase é o que você efetivamente devia para a empresa.