MVP virou desculpa para entregar menos. A diferença entre um produto mínimo viável e um produto simplesmente incompleto está na clareza sobre o que está sendo validado.
O termo Minimum Viable Product foi cunhado em 2001 por Frank Robinson, CEO da SyncDev, e ganhou alcance global uma década depois, quando Eric Ries o reformulou em The Lean Startup (2011). Na definição de Ries, um MVP é “a versão de um novo produto que permite ao time coletar o máximo de aprendizado validado sobre os clientes com o menor esforço”.
Na prática, o conceito foi sendo deturpado. “MVP” virou justificativa para entregar produtos sem acabamento, sem fluxo completo e sem qualidade mínima. “É um MVP” tornou-se a resposta padrão para qualquer crítica de qualidade.
A diferença entre um MVP bem construído e um produto simplesmente inacabado é grande, e ela aparece em quatro pontos.
Um MVP não é um produto incompleto. É um produto completo para um escopo deliberadamente pequeno.
A diferença é fundamental. Um produto incompleto tem funcionalidades pela metade, fluxos que quebram e qualidade visual abaixo do aceitável. Um MVP bem construído faz uma coisa, ou poucas coisas, com qualidade suficiente para que o usuário consiga usar e o time consiga aprender algo com o uso.
O “mínimo” do MVP não é sobre qualidade. É sobre escopo.
Todo MVP deveria começar com uma pergunta explícita: o que a gente está tentando descobrir?
Essa pergunta é central na formulação original de Ries. O MVP existe pra validar uma hipótese de negócio, não pra “lançar o produto mais rápido”. Se a hipótese não é clara antes de começar a construir, o MVP não vai ser mínimo nem viável. Vai ser um produto de baixa qualidade sem nenhuma aprendizagem estruturada pra justificá-lo.
A hipótese define o escopo. O escopo define o que entra e o que fica para depois. Sem hipótese, qualquer corte de funcionalidade parece arbitrário e qualquer crítica de qualidade parece válida. Os exemplos clássicos que a literatura de MVP usa (o vídeo inicial do Dropbox, o Airbnb com fotos próprias, a Zappos vendendo sapatos sem estoque) têm em comum o fato de que todos tinham uma hipótese específica a testar. Não eram cortes aleatórios.
Um MVP com problemas sérios de usabilidade não valida a hipótese de negócio. Valida que o produto é difícil de usar. Os dois são coisas diferentes.
Se o usuário abandona o produto no onboarding, o time não aprendeu se a proposta de valor funciona. Aprendeu que o onboarding está ruim. O dado que volta pra equipe não responde a pergunta que o MVP deveria responder.
Por isso a frase de Eric Ries continua atual: “Remove any feature, process or effort that does not directly contribute to the learning you seek.” Remova qualquer funcionalidade, processo ou esforço que não contribua diretamente para o aprendizado que se busca. A leitura usual desse princípio costuma parar na primeira metade: cortar funcionalidade. Mas a segunda metade é a que importa: o que sobra precisa contribuir para o aprendizado. Qualidade abaixo do aceitável atrapalha esse aprendizado tanto quanto excesso de funcionalidade.
Qualidade mínima não é oposta à velocidade. É o que torna a velocidade útil.
O termo tem prazo de validade. Um produto que está em produção há seis meses com usuários reais não é mais um MVP. É um produto com dívidas acumuladas que precisam ser pagas.
Manter o rótulo de MVP por tempo indeterminado é uma forma de evitar a conversa sobre qualidade e investimento que precisa acontecer. Vira escudo. E quando vira escudo, perdeu a função original, que era ferramenta de aprendizado.
Em projetos da VM2, MVP só faz sentido quando existem três coisas no início: uma hipótese explícita do que se está testando, um critério claro de sucesso (o que vai sair desse teste como “validado” ou “refutado”), e um plano para o que vem depois (continuar, pivotar, ou parar).
Sem isso, o que costuma ser proposto como MVP é, na prática, um produto curto com prazo apertado. Pode até funcionar, mas é outra coisa. Chamar de MVP só confunde a conversa sobre qualidade e responsabilidade.
A gente prefere ser direto: ou é um produto completo pra escopo pequeno e funciona como ferramenta de aprendizado, ou é uma primeira versão com plano de evolução claro. Os dois são caminhos válidos. O que não funciona é misturar os dois e chamar de MVP quando a conversa fica difícil.
Referências consultadas: Frank Robinson, SyncDev (2001); Eric Ries, “The Lean Startup” (2011); Steve Blank, “The Four Steps to the Epiphany” (2005).
Acessibilidade não é só obrigação legal. É a diferença entre uma plataforma que funciona para todos e uma que exclui parte do mercado silenciosamente.
A escolha de tecnologia para um projeto digital não começa pela tecnologia. Começa pela pergunta certa: o que essa plataforma precisa fazer?
36% das empresas gastam mais tempo resolvendo problemas de APIs do que desenvolvendo funcionalidades. O problema quase nunca é a API. É a documentação tratada como anexo, não como produto.
