Duas equipes recebem seis meses e o mesmo orçamento. A primeira constrói camadas: banco de dados, autenticação, painel administrativo, integração de pagamento. No sexto mês, alguém usa o produto pela primeira vez. A segunda coloca uma versão tosca na mão de dez clientes na terceira semana, descobre que o problema não era o que imaginava, e refaz o escopo duas vezes antes do prazo.

As duas gastaram o mesmo. Só uma aprendeu algo. Essa é a diferença que o Produto Mínimo Viável tenta comprar, e o motivo pelo qual ele é o conceito mais citado e mais mal aplicado da criação de produtos digitais.

O que é um Produto Mínimo Viável

Produto Mínimo Viável (MVP, de minimum viable product) é a menor versão funcional de um produto capaz de entregar a proposta de valor central para um usuário real e devolver aprendizado sobre ela. As três palavras carregam três exigências distintas:

  • Produto: algo com que a pessoa interage de verdade. Uma tela estática, um slide ou um mockup não são MVP, porque não produzem comportamento, só opinião.
  • Mínimo: o corte entre o que é essencial para entregar a proposta de valor e o que é apoio. Recuperação de senha é necessária num produto em operação, e é dispensável para descobrir se alguém quer o produto.
  • Viável: tem que ser possível construir rápido e barato. Se validar a hipótese exige seis meses de engenharia, o que você tem não é um MVP.

Vale corrigir uma atribuição que circula bastante. O termo minimum viable product foi cunhado por Frank Robinson, da SyncDev, em 2001. Quem o popularizou foi Eric Ries, dez anos depois, em A Startup Enxuta, onde a definição é deliberadamente centrada em aprendizado: “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”.

Repare no que essa frase não diz. Não diz “mais barato”, não diz “mais rápido de programar”, não diz “com menos telas”. Diz máximo de aprendizado por unidade de esforço. É uma métrica de razão, e é por isso que um MVP caro pode ser correto e um MVP barato pode ser lixo. O ciclo em que ele opera, construir, medir e aprender, é o núcleo do modelo de startup enxuta.

MVP, protótipo e prova de conceito não são a mesma coisa

Boa parte do desperdício em projeto de produto vem de trocar um artefato pelo outro. Os três respondem perguntas diferentes, e usar o errado significa gastar para responder algo que ninguém perguntou.

Artefato Pergunta que responde Quem julga Sai para o mercado?
Prova de conceito (POC) Isso é tecnicamente possível? Equipe técnica Não
Protótipo A experiência faz sentido para quem usa? Usuários em teste guiado Não
MVP Alguém quer isso o bastante para usar (ou pagar)? Mercado, em uso real Sim

A POC responde sobre viabilidade técnica e morre no laboratório. O protótipo responde sobre usabilidade e desejo declarado, com atrito controlado. O MVP é o único dos três que expõe o produto a consequência real: a pessoa decide sozinha se volta, se paga, se indica. É o único que produz comportamento em vez de intenção, e por isso é o único que valida hipótese de negócio. Escrevemos com mais detalhe sobre o que separa validação de aparência em MVP não é site barato.

Os 6 tipos de MVP (e quando usar cada um)

Existe uma suposição implícita de que MVP é sempre software funcionando. Não é. O tipo certo depende da hipótese que está no banco dos réus.

Tipo Como funciona Melhor para testar
Concierge O serviço é entregue à mão, sem automação, para poucos clientes Se o problema é real e se a solução resolve
Mágico de Oz A interface parece automatizada; atrás dela há gente operando Se a experiência automatizada seria aceita
Página de captura Uma página descreve a oferta e mede quem se cadastra Se a proposta de valor atrai, antes de construir
Funcionalidade única Só a função central existe, o resto fica de fora Se a função central sustenta o uso recorrente
Remendado Ferramentas prontas costuradas (planilha, formulário, automação) Se o fluxo completo gera valor, sem código próprio
Pré-venda O produto é vendido antes de existir Se há disposição a pagar, o teste mais duro de todos

Os dois primeiros parecem improvisados e costumam ser os mais informativos. Um MVP concierge com quinze clientes atendidos à mão ensina mais sobre o problema do que três meses de desenvolvimento, porque quem entrega vê cada atrito acontecer. O mesmo raciocínio de experimentação barata aparece em outros formatos de teste rápido, como no marshmallow challenge.

Como construir um MVP em 6 passos

1. Entender o usuário antes de desenhar solução

Quatro fontes cobrem quase tudo: entrevistas exploratórias (abertas, nunca questionário), observação da pessoa resolvendo o problema com o que ela tem hoje, vivência da própria rotina dela, e leitura de avaliações de produtos concorrentes. As avaliações são a fonte mais subestimada: são reclamações específicas, gratuitas e escritas sem que ninguém tenha pedido.

2. Escrever a hipótese de valor como uma aposta falseável

Hipótese de valor não é “acho que as pessoas vão gostar”. É uma frase que pode dar errado de forma verificável: “gestores de clínica com 3 a 10 profissionais vão trocar a planilha de agenda por isso porque perdem 6 horas por semana consolidando horários”. Quando a hipótese não pode ser derrubada por um número, o MVP não tem como reprovar em nada.

3. Cortar o escopo pela hipótese, não pelo orçamento

Aqui está o erro mais caro do processo inteiro. Escopo mínimo é o conjunto de funcionalidades sem as quais a proposta de valor não se completa para o usuário, e nada além disso. O teste é simples: remova a funcionalidade e pergunte se o usuário ainda consegue percorrer a jornada do problema até a solução. Se consegue, ela fica fora desta versão. Tratamos o método de corte em como definir o escopo do primeiro produto digital.

4. Construir com a tecnologia mais chata que resolve

A pergunta não é qual tecnologia é a melhor, é qual entrega a experiência mais rápido. Planilha na retaguarda, formulário na frente e uma automação no meio já sustentam um MVP de operação real. Escrever código próprio na primeira versão só se justifica quando a hipótese é sobre a própria tecnologia.

5. Testar com meta, não com demonstração

Demonstração guiada produz elogio. Teste com meta produz dado. Entregue ao usuário um objetivo concreto (“agende uma consulta para quinta”), pare de falar e peça que narre em voz alta o que está pensando. Cada hesitação é um item de trabalho. Defina de antemão qual ação você espera: qualquer desvio entre o esperado e o observado é uma pergunta nova.

6. Iterar removendo, não somando

A tentação depois do primeiro teste é adicionar o que faltou. Na prática, a maior parte da confusão vem de excesso, não de ausência. Comece cortando o que poluiu a jornada e só então avalie o que entra. Depois de duas ou três voltas, você sabe se a hipótese de valor se sustenta ou se é hora de mudar de aposta.

MVP em projetos, em TI e em empresa já estabelecida

Em gestão de projetos, MVP é a primeira entrega que já produz resultado para quem vai usar, e não a primeira etapa de um cronograma. A diferença é a mesma da capa deste artigo: incremento por camadas entrega valor apenas no fim, incremento por fatias entrega em cada passo. Essa lógica de entrega fatiada é o que métodos ágeis organizam em ciclo.

Em TI e software, o cuidado é outro: MVP não autoriza dívida técnica indiscriminada. Ele autoriza escopo menor, não qualidade menor no que ficou dentro. Um MVP que cai na primeira semana de uso não invalida a hipótese, ele impede o teste.

Em empresa já estabelecida, o MVP tem usos que a leitura de startup não cobre. Serve para explorar mercado adjacente sem expor a marca principal, para testar uma tecnologia em escala controlada, e para abrir frente nova sobre produto existente. Serve também para responder a pergunta mais silenciosa de todas: aquela ferramenta interna que a operação usa há anos tem mercado fora daqui? Essa é a hipótese que tratamos em sua empresa provavelmente tem um produto digital escondido, com a triagem em 3 critérios para saber se uma ferramenta interna vira produto. Se a resposta for sim, o passo seguinte não é construir: é decidir como aquilo cobra, porque produto sem modelo de receita continua sendo custo.

Os 5 erros que transformam um MVP em desperdício

  • Definir o mínimo pelo orçamento. “Mínimo é o que cabe em 30 mil” produz um produto que não entrega proposta de valor nenhuma, e portanto não testa nada. O corte é pela hipótese.
  • Lançar sem hipótese escrita. Sem uma aposta declarada antes, qualquer resultado vira interpretação favorável. Aprovado e reprovado deixam de existir.
  • Confundir MVP com versão feia. Feiura não é requisito. Escopo curto é. Um MVP com uma função só, bem feita, valida mais que dez funções pela metade.
  • Medir opinião em vez de comportamento. “Achei ótimo” não é dado. Uso repetido, cadastro concluído e pagamento efetuado são.
  • Tratar reprovação como fracasso. Descobrir em três semanas que a ideia não tem mercado é o retorno esperado do investimento, não a perda dele. O projeto morre quando o estoque de hipóteses acaba, não quando uma delas cai.

Reprovar rápido tem valor econômico direto: cada mês que a hipótese errada sobrevive é um mês de engenharia e de janela de mercado gasto no produto errado. É o mesmo cálculo que aparece na diferença entre produto digital e negócio digital. Para software vendido por assinatura, o roteiro está em como validar uma ideia de micro SaaS; para o conceito aplicado a produto corporativo, em o que é MVP de produto digital.

MVP não é etapa de projeto. É postura diante da incerteza: em vez de apostar seis meses numa suposição, você compra informação em lotes pequenos e ajusta a rota enquanto ela ainda é barata de ajustar. É essa velocidade de aprendizado, mais do que a tecnologia usada, que costuma separar quem lança produto de quem lança projeto, e é o mecanismo por trás de boa parte dos casos de inovação disruptiva: entrar pequeno, num nicho que o incumbente não defende, e subir com o aprendizado.

Perguntas frequentes

O que é um Produto Mínimo Viável (MVP)?

Produto Mínimo Viável é a menor versão funcional de um produto capaz de entregar a proposta de valor central para um usuário real e devolver aprendizado sobre ela. As três palavras impõem exigências distintas: produto significa algo com que a pessoa interage de verdade (mockup não conta), mínimo é o corte entre o essencial e o acessório, e viável é ser possível construir rápido e barato.

Quem criou o conceito de MVP?

O termo minimum viable product foi cunhado por Frank Robinson, da SyncDev, em 2001. Quem o popularizou foi Eric Ries, em 2011, no livro A Startup Enxuta, com uma definição centrada em aprendizado: 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.

Qual a diferença entre MVP e protótipo?

O protótipo responde se a experiência faz sentido, e é julgado por usuários em teste guiado, com atrito controlado. O MVP responde se alguém quer o produto o bastante para usar ou pagar, e é julgado pelo mercado em uso real. O protótipo não sai para o mercado; o MVP sai. Só o MVP produz comportamento em vez de intenção declarada.

Qual a diferença entre MVP e prova de conceito (POC)?

A prova de conceito responde se algo é tecnicamente possível, é julgada pela equipe técnica e morre no laboratório. O MVP responde se existe demanda, é julgado pelo mercado e vai para as mãos do cliente. Fazer POC quando a dúvida é de demanda, ou MVP quando a dúvida é técnica, é gastar para responder uma pergunta que ninguém fez.

Quais são os tipos de MVP?

Os seis tipos mais usados são: concierge (serviço entregue à mão), Mágico de Oz (interface parece automatizada, com gente operando atrás), página de captura (mede quem se cadastra antes de construir), funcionalidade única, remendado (ferramentas prontas costuradas, como planilha e formulário) e pré-venda (o produto é vendido antes de existir). O tipo certo depende de qual hipótese está sendo testada.

Como fazer um MVP passo a passo?

Seis passos: entender o usuário antes de desenhar solução; escrever a hipótese de valor como aposta falseável; cortar o escopo pela hipótese, não pelo orçamento; construir com a tecnologia mais simples que resolve; testar com meta concreta em vez de demonstração guiada; e iterar removendo o que confundiu antes de adicionar o que faltou.

Qual é o escopo mínimo de um MVP?

É o conjunto de funcionalidades sem as quais a proposta de valor não se completa para o usuário, e nada além disso. O teste prático é remover a funcionalidade e perguntar se o usuário ainda percorre a jornada do problema até a solução. Se percorre, ela fica fora desta versão. Recuperação de senha, por exemplo, é necessária em produto em operação e dispensável para descobrir se alguém quer o produto.

O que é MVP em projetos?

Em gestão de projetos, MVP é a primeira entrega que já produz resultado para quem vai usar, não a primeira etapa do cronograma. A diferença é entre incremento por camadas, que entrega valor apenas no fim, e incremento por fatias, que entrega em cada passo. É a lógica que os métodos ágeis organizam em ciclos curtos.

MVP em TI significa aceitar código ruim?

Não. MVP autoriza escopo menor, não qualidade menor no que ficou dentro do escopo. Um MVP que cai na primeira semana de uso não invalida a hipótese: impede o teste, porque o usuário abandona por instabilidade e não por falta de valor. A economia vem de fazer menos coisas, não de fazer mal as que entraram.

E se o MVP der errado?

Reprovar é resultado esperado, não fracasso. Descobrir em três semanas que a ideia não tem mercado é o retorno do investimento, não a perda dele. Se há caminho de pivô, reaproveite o aprendizado e reformule a proposta de valor; se não há, encerre. Um projeto morre quando o estoque de hipóteses acaba, não quando uma delas cai.