MVP é o acrônimo de Minimum Viable Product — produto mínimo viável. E é um dos conceitos mais usados e mais distorcidos em produto. Na prática, virou sinônimo de "entregar rápido com qualidade ruim". Isso não é MVP. É débito técnico disfarçado de metodologia.
Entender o que um MVP realmente é — e o que ele não é — muda como você prioriza, como você conversa com stakeholders e como você decide o que construir primeiro.
O que MVP não é
MVP não é um produto incompleto. Não é uma versão beta com bugs que você "vai consertar depois". Não é uma desculpa para lançar algo que não funciona. Essas versões existem — só não deveriam ser chamadas de MVP.
Quando um time lança algo quebrado e chama de MVP, está treinando usuários a esperarem pouco. Está também destruindo a metodologia por dentro: se o MVP não é usável, não dá para aprender nada com ele.
O que MVP realmente é
MVP é a menor versão do produto que valida a hipótese mais importante. Essa definição tem duas partes que precisam estar juntas.
"Menor versão" significa que você está deliberadamente cortando tudo que não é necessário para testar a hipótese. Não é preguiça. É foco. A maioria das features que um time quer colocar no MVP são hipóteses secundárias que podem esperar.
"Hipótese mais importante" significa que você precisa saber, antes de construir, qual é a pergunta que o MVP está respondendo. Se você não consegue formular a hipótese, não tem como saber o que é mínimo e o que é viável.
Como formular a hipótese do MVP
A hipótese precisa ser específica e falseável. "Acreditamos que usuários vão querer usar esse produto" não é uma hipótese — é um desejo. "Acreditamos que usuários de e-commerce abandonam o carrinho por não confiar no site, e que adicionar um selo de segurança visível vai reduzir o abandono em pelo menos 10%" é uma hipótese testável.
Para cada hipótese, defina: o que você está assumindo ser verdade, como você vai medir se é verdade ou não, e qual seria o resultado que te faria desistir do caminho. Esse último ponto é o mais difícil — mas é o que separa um experimento honesto de um projeto que vai continuar independente do resultado.
O que entra no MVP e o que fica de fora
A pergunta para cada feature candidata é: sem isso, consigo testar a hipótese principal? Se a resposta for sim, a feature fica de fora do MVP. Não para sempre — só para depois.
Isso significa que muitas coisas que parecem essenciais ficam de fora. Onboarding completo. Configurações de perfil. Notificações. Versão mobile. Tudo isso pode ser importante no produto final. Para o MVP, a pergunta é outra: o usuário consegue fazer o trabalho principal que você está testando sem essas coisas? Se consegue, corta.
O critério de viabilidade
"Viável" não é sinônimo de "funcional". É sinônimo de "suficiente para o usuário fazer o que precisa". Um MVP viável é aquele que entrega a promessa central do produto — mesmo que sem polimento, sem escala, sem automação. Um processo manual que simula uma feature automatizada pode ser um MVP perfeitamente viável se o objetivo é validar demanda antes de construir.
MVP e aprendizado
O MVP não termina no lançamento. Termina quando você tem resposta para a hipótese. Isso significa que, antes de lançar, você precisa definir como vai medir o resultado. Quais dados vai coletar? Com quantos usuários? Em quanto tempo vai considerar o resultado conclusivo?
Sem essas respostas definidas antes, é fácil interpretar qualquer resultado como positivo. "Não tivemos feedback negativo" não é aprendizado. "60% dos usuários que tentaram completar o fluxo principal chegaram até o fim, e nossa hipótese era 50%" é aprendizado. Para entender quais métricas usar, veja o artigo sobre métricas de produto que todo PM precisa conhecer.
Quando o MVP não é o caminho certo
Há contextos em que MVP faz pouco sentido. Produtos com forte efeito de rede (onde o valor só aparece com muitos usuários) precisam de uma massa crítica antes de poder validar qualquer coisa. Produtos com altos requisitos regulatórios precisam cumprir compliance antes de lançar qualquer versão. Produtos de infraestrutura precisam de confiabilidade desde o primeiro dia.
Nesses casos, a metodologia certa pode ser uma versão piloto fechada, um protótipo de alta fidelidade testado com usuários selecionados, ou um estudo de mercado. MVP é uma ferramenta, não um dogma. Para entender quando usar cada abordagem, o contexto do produto sempre vem antes do framework.
