Produto mínimo viável: o guia do fundador não-técnico

Um produto mínimo viável não é a versão mais barata que você consegue lançar. É a mais enxuta que ainda prova se alguém vai pagar. Veja como um fundador não-técnico decide esse escopo.

No quadro branco havia 41 post-its, cada um uma funcionalidade que, segundo o fundador, “tinha que entrar no MVP”: login social, dashboard, painel de admin, relatório em PDF, dois idiomas. A gente fez uma pergunta que ele não esperava: se você só pudesse manter três desses post-its, quais seriam? Ele travou, não por falta de resposta, mas porque ninguém tinha pedido que ele escolhesse antes. Esse é o problema real de quase todo produto mínimo viável. Não é tamanho. É escolha.

Um produto mínimo viável (MVP, do inglês minimum viable product) é a menor versão de um produto que já permite testar a aposta central do negócio com gente de verdade. A palavra que carrega o peso na frase não é “mínimo”. É “viável”. Mínimo é fácil: corta tudo. Viável é difícil: significa que a versão reduzida ainda precisa provar alguma coisa que você não sabia antes de construí-la. A maioria dos MVPs erra exatamente aí. Fica pequena no eixo errado.

Este guia é para o fundador não-técnico que vai pagar por esse primeiro build e precisa decidir o escopo sem ser refém da lista de desejos de ninguém. Vamos definir o termo direito, mostrar o erro que ele esconde e dar um framework de quatro perguntas para você cortar 41 post-its até sobrar o que importa.

O que é um produto mínimo viável (de verdade)

A definição mais citada é a de Eric Ries, que popularizou o termo em 2008: a versão de um produto novo que permite ao time coletar o máximo de aprendizado validado sobre os clientes com o menor esforço possível. Releia a parte do meio. A unidade de saída de um MVP não é um produto. É aprendizado. O produto é só o instrumento que produz esse aprendizado.

Na prática brasileira de 2026, o termo virou sinônimo de “primeira versão feita com pressa”. Os dois sentidos parecem iguais e não são. Uma primeira versão feita com pressa entrega software. Um MVP entrega uma resposta para uma pergunta que você ainda não conseguia responder. Você pode construir as duas coisas com o mesmo código e a mesma equipe. A diferença está no que você decidiu testar antes de começar.

Vale tirar do caminho uma confusão comum de quem pesquisa a sigla. MVP, neste contexto, é Minimum Viable Product. Não é o “MVP” de esporte ou de games (Most Valuable Player), e não tem relação com “dado mínimo viável”, uma expressão que aparece solta em buscas mas não é um conceito de produto. Quando um investidor ou um dev fala em MVP numa conversa sobre o seu negócio, é sempre a versão mínima viável do produto.

O erro que quase todo MVP comete

Já defendemos em outro texto que a maioria dos MVPs não valida nada: constroem algo, sentem que progrediram e não saem do lugar com nenhuma certeza nova. Não vamos repetir o argumento aqui. O ponto operacional, o que muda a sua decisão de escopo, é este: o MVP fica mínimo na dimensão errada.

O fundador dos 41 post-its queria cortar funcionalidades até caber no orçamento. Lógico, mas insuficiente. Cortar pela metade uma lista ruim te dá meia lista ruim. A pergunta certa não é “o que cabe no prazo”, é “qual é a única coisa que esse build precisa provar”. Quando você responde isso primeiro, o escopo praticamente se desenha sozinho: tudo que não serve à prova sai, por mais bonito que seja o post-it.

É por isso que tantos MVPs terminam com dezenas de cadastros e zero aprendizado. Eles testaram se dava para construir o produto. Isso você já sabia que dava. O que você não sabia, e o que o MVP existia para descobrir, era se alguém se importa o suficiente para pagar.

As quatro perguntas que definem o escopo do seu MVP

Esse é o framework que a gente usa com fundador antes de escrever uma linha de código. Quatro perguntas, na ordem. Cada uma corta o escopo de um jeito diferente, e juntas elas transformam uma lista de desejos numa aposta enxuta.

1. Qual é a única coisa que precisa ser verdade para o negócio existir?

Todo negócio repousa sobre uma hipótese que, se for falsa, derruba tudo o resto. Para um marketplace de serviços, é que prestadores qualificados aparecem quando há demanda. Para um SaaS de gestão de clínica, é que o gestor troca a planilha por software se ele resolver a parte chata do agendamento. Escreva essa frase. Se você não consegue escrever, o MVP não tem alvo, e nenhum corte de escopo vai consertar isso.

A maioria das funcionalidades da sua lista não toca nessa única coisa. Elas tornam o produto mais completo, não a aposta mais testável. No quadro dos 41 post-its, exatamente quatro tinham relação com a hipótese central. Os outros 37 eram conforto.

2. Qual é o caminho mais curto até alguém pagar?

Cadastro não é validação. Elogio não é validação. A única evidência forte de que existe negócio é dinheiro saindo da conta de outra pessoa para a sua, ou pelo menos um compromisso formal de que vai sair. Então pergunte: do estado atual até a primeira cobrança real, qual é o caminho mais curto? Tudo que está nesse caminho entra no MVP. Tudo que está fora dele espera.

Esse teste mata funcionalidades que parecem essenciais. Painel de admin não está no caminho do pagamento, você administra na mão no começo. Relatório em PDF não está no caminho, ninguém deixa de pagar por falta de PDF na semana um. Login social não está no caminho, e-mail e senha resolvem. O que está no caminho costuma ser desconfortavelmente pouco, e é esse desconforto que indica que você acertou o escopo.

3. O que dá para fazer na mão antes de virar código?

Boa parte do que parece precisar de software, no começo, é gente fazendo trabalho que o sistema vai automatizar depois. Isso tem nome: MVP concierge. Você entrega o resultado manualmente, com planilha, WhatsApp e esforço humano, e só constrói o software quando já provou que o resultado tem valor. É o conselho que Paul Graham resume em fazer coisas que não escalam: no começo, o trabalho braçal é a estratégia, não o atalho. O clássico é a história do fundador que vendeu o produto numa landing page antes de existir produto, atendeu os primeiros pedidos pessoalmente e só depois codou.

Para o fundador não-técnico, essa é a alavanca mais subestimada. Cada fluxo que você faz na mão por mais algumas semanas é um fluxo que você não paga para construir antes de saber se ele importa. E você aprende coisas, no atendimento manual, que nenhum dashboard de analytics te conta. O custo é o seu tempo. O retorno é não queimar orçamento de desenvolvimento que ainda não se justifica.

4. O que você teria vergonha de mostrar a um cliente pagante?

Aqui é onde “mínimo” encontra “viável” e os dois precisam coexistir. A versão certa do MVP não é a mais feia que você consegue lançar. É a primeira versão que você teria orgulho de colocar na frente de alguém que vai pagar. Essas duas coisas não são opostas. O concierge corta a quantidade de coisas; a barra de qualidade decide quão bem as poucas coisas que sobraram são feitas.

Um produto pode ter uma única funcionalidade e ser excelente nela. Pode ter uma só tela e essa tela funcionar, carregar rápido e não perder dados. Mínimo é sobre escopo. Viável é sobre padrão. Quando o fundador usa “MVP” como desculpa para entregar algo quebrado, ele não está sendo enxuto, está sabotando o próprio teste: o cliente que recusa um produto mal-acabado não te ensinou que a ideia é ruim, te ensinou que o acabamento estava ruim. Você gastou o tiro e não mediu nada.

O que é MVP: os exemplos famosos e o que eles de fato ensinam

Quem pesquisa “produto mínimo viável” sempre topa com os mesmos dois casos. Vale revisitá-los, porque quase todo mundo tira deles a lição errada.

O primeiro é o vídeo do Dropbox. Antes de construir a sincronização de arquivos, que era tecnicamente difícil, a equipe gravou um vídeo de três minutos mostrando o produto funcionando como se já existisse. A lista de espera explodiu da noite para o dia. A lição que repetem é “faça um vídeo”. A lição real é que eles foram mínimos no build e máximos na aposta: testaram a única coisa que precisava ser verdade, que havia desejo, sem construir a parte cara.

O segundo é o da loja de sapatos que virou um gigante do e-commerce. O fundador, antes de montar estoque, tirava fotos de sapatos em lojas físicas, anunciava online e, quando alguém comprava, ia até a loja, pagava o preço cheio e enviava. Dava prejuízo por venda. Não importava. Ele não estava testando logística, estava testando se as pessoas comprariam sapato pela internet sem experimentar. Concierge puro. A aposta vinha antes do sistema.

Os dois casos passam no mesmo teste das quatro perguntas. Eles isolaram a hipótese central, foram pelo caminho mais curto até a evidência e fizeram na mão tudo o que dava para fazer na mão. Nenhum dos dois era um produto completo. Os dois eram viáveis no que importava.

Como criar um produto mínimo viável: o passo a passo

Juntando as quatro perguntas, a sequência fica assim, e ela vale tanto para quem vai contratar uma software house quanto para quem vai tocar com um freelancer.

Primeiro, escreva a hipótese central numa frase. Se ela depende de “e” para fazer sentido, você tem duas hipóteses; escolha a que derruba o negócio se for falsa. Segundo, desenhe o caminho mais curto até o pagamento e liste só o que está nesse caminho; esse rascunho costuma virar o ponto de partida natural de um documento de requisitos enxuto. Terceiro, marque o que dá para fazer na mão e tire do build. Quarto, defina a barra de qualidade do que sobrou, porque é nela que o “viável” vive. Só então você estima prazo e custo, e quase sempre o número fica menor do que a lista original sugeria.

O que esse processo evita é o padrão mais caro do mercado: pagar para construir um produto completo, lançar, descobrir que ninguém quer e só então olhar o escopo. A ordem certa é olhar o escopo primeiro. É mais barato discutir um post-it do que reescrever um sistema.

Antes de partir para o produto, vale ter feito a lição de casa de entender o problema. O MVP responde “alguém quer isto”; o discovery de produto responde “qual é exatamente o isto”. As duas etapas se reforçam, e pular a primeira costuma ser o que faz o fundador encher um quadro de 41 post-its sem saber qual deles importa.

MVP não é desculpa para software descartável

Existe um mito confortável de que o MVP é código para jogar fora, então qualquer gambiarra serve. Às vezes é verdade, e quando é, jogue fora mesmo. Mas o caso mais comum não é esse. O caso mais comum é o MVP que funciona, atrai os primeiros clientes e, por isso mesmo, vira a base do produto de verdade, com toda a pressa e todos os atalhos embutidos. Aí o que era para ser um teste barato vira uma dívida técnica que cobra juros por anos.

A saída não é construir tudo perfeito desde o início, isso contradiz o ponto inteiro do MVP. A saída é ser deliberado: enxuto no escopo, honesto sobre o que é descartável e o que vai virar fundação, e exigente na qualidade das poucas coisas que sobraram. Software bem feito não é luxo de quem tem tempo. É o que separa um teste que ensina de um que só queima caixa. Feito sob medida, made to fit, mesmo quando é pequeno.

Perguntas frequentes sobre produto mínimo viável

Qual é o produto mínimo viável de um negócio?
É a menor versão do produto que já testa a aposta central da empresa com clientes reais. Não é a versão mais barata nem a mais rápida por si só, é a mais enxuta que ainda consegue provar se as pessoas se importam o suficiente para pagar. Comece definindo a única hipótese que, se for falsa, derruba o negócio, e construa só o que serve para testá-la.

O que é MVP, com exemplos?
MVP é a sigla de minimum viable product, ou produto mínimo viável. O exemplo clássico é o Dropbox, que validou a demanda com um vídeo antes de construir a sincronização; outro é o e-commerce de sapatos que vendia sem ter estoque, comprando em loja física a cada pedido. Em ambos, o time foi mínimo no que construiu e rigoroso no que testou.

Como criar um produto mínimo viável?
Em quatro passos: escreva numa frase a hipótese que precisa ser verdade para o negócio existir; mapeie o caminho mais curto até alguém pagar e inclua só o que está nesse caminho; faça na mão tudo o que der para fazer sem código; e defina uma barra de qualidade da qual você não tenha vergonha diante de um cliente pagante. Estime custo e prazo só depois desses cortes.

O que é um verdadeiro MVP?
É o que passa no teste do “viável”: uma versão enxuta que ainda prova algo que você não sabia, com qualidade da qual você não tem vergonha diante de um cliente pagante. Uma primeira versão feita com pressa entrega software; um verdadeiro MVP entrega uma resposta. Se o build não foi desenhado para testar uma hipótese específica, não é um MVP, é só um produto pequeno.

O que significa “dado mínimo viável”?
Não é um conceito padrão de produto, e costuma ser uma confusão com “produto mínimo viável”. O que existe e é útil é a ideia de coletar o conjunto mínimo de evidências que confirma ou derruba a sua hipótese. Em produto, o termo correto é produto mínimo viável (MVP).

MVP é a mesma coisa que MVP de esporte ou de games?
Não. No contexto de negócios e software, MVP é Minimum Viable Product. No esporte e nos games, MVP é Most Valuable Player. São siglas iguais para conceitos sem relação; quando a conversa é sobre o seu produto, é sempre a versão mínima viável.