O que é MVP: a definição e o que ele não é

MVP quer dizer produto mínimo viável, e a palavra que faz o trabalho na expressão não é “mínimo”: é “viável”. MVP é a menor versão capaz de responder uma dúvida real de negócio com gente de verdade usando. Se não responde nada, é só um produto pequeno.

Este texto traz a definição, as cinco coisas que MVP não é, a diferença em relação a protótipo e prova de conceito, os tipos que existem, como definir o escopo de um e como saber se funcionou.

O que MVP significa

A sigla vem do inglês minimum viable product, produto mínimo viável. A definição prática tem três partes, e todas as três precisam estar presentes:

• Mínimo: o menor recorte possível, com o que sobra sendo deliberadamente deixado de fora e registrado.
• Viável: funciona de ponta a ponta para o caso que se propõe resolver. Uma tela bonita que não conclui a tarefa não é viável.
• Produto: alguém usa de verdade, na vida real, e não numa demonstração conduzida por você.

O objetivo dele não é entregar valor máximo com esforço mínimo, embora isso soe bem. O objetivo é aprender a coisa mais importante que você ainda não sabe, gastando o mínimo. É por isso que dois MVPs do mesmo produto podem ser completamente diferentes: depende da dúvida que cada um precisa responder.

As cinco coisas que MVP não é

1. Não é versão malfeita. Pequeno e ruim são coisas diferentes: o pequeno resolve pouca coisa bem, o ruim não resolve nada com confiança e ensina o erro errado.
2. Não é a fase 1 do projeto grande. Chamar de MVP o primeiro terço de um escopo já decidido é renomear cronograma. MVP existe para questionar o escopo, não para começar a executá-lo.
3. Não é definido pelo orçamento. “Nosso MVP é o que cabe em 30 mil” define um limite de gasto, não um recorte de aprendizado.
4. Não é protótipo. Protótipo simula, MVP funciona. Ninguém aprende sobre comportamento real com algo que não faz nada.
5. Não é desculpa para não decidir. MVP sem hipótese escrita e sem número que a nega é produto pequeno com nome de método.

MVP, protótipo e prova de conceito

A ordem entre os três não é obrigatória. Protótipo é barato e resolve dúvida de usabilidade em dias; prova de conceito só se justifica quando existe risco técnico real; e o MVP é o único que responde a pergunta que mais mata produto, que é se alguém quer aquilo.

Os tipos de MVP

• Página com oferta. Descreve a solução e mede quantos chegam ao passo de pagar ou de se cadastrar. Responde sobre interesse com dinheiro à vista, e custa quase nada.
• Atendimento manual, com cara de produto. A pessoa pede pelo formulário e alguém executa à mão nos bastidores. Cara por unidade e imbatível para aprender o processo real.
• Serviço concierge. Você entrega o resultado pessoalmente para poucos clientes, sem software algum, para descobrir o que de fato precisa ser automatizado.
• Pré-venda. Cobrar antes de existir, com prazo combinado. É o sinal mais forte que existe, e o mais desconfortável de fazer.
• Produto funcional recortado. Software real, com um fluxo só, do começo ao fim. É o mais caro dos cinco, e o único adequado quando a dúvida é sobre uso continuado.

O erro comum é pular direto para o quinto quando a dúvida ainda é do primeiro. Se você não sabe se alguém pagaria, construir software é a forma mais lenta e caro de descobrir.

Como definir o escopo

1. Escreva a dúvida em uma frase falsificável. Não “acho que o mercado quer isso”, e sim “clínicas de dois a cinco profissionais pagam por mês para reduzir falta de paciente”.
2. Escolha um único fluxo, do início ao fim, e o mais crítico deles.
3. Liste o que fica de fora, por escrito. Essa lista é mais importante que a de dentro, e é o que evita a discussão voltar toda semana.
4. Resolva à mão o que der. Cadastro manual, relatório enviado por e-mail, cobrança fora do sistema. Tudo isso pode ser automatizado depois de haver cliente.
5. Defina antes o número que confirma ou nega. Combinar o limite depois de ver o resultado é o jeito mais comum de nunca reprovar uma ideia.

O método completo de recorte, com o que costuma transformar três meses em dezoito, está em escopo de projeto, e a conta de quanto cada recorte custa em quanto custa desenvolver um produto digital.

Como saber se funcionou

Um MVP não é avaliado por ter sido entregue, e sim pelo que ele ensinou. Quatro sinais, em ordem de força:

1. Alguém pagou, ou assinou compromisso com prazo. É o sinal mais forte e o mais raro.
2. Voltou a usar sem ser lembrado, na segunda semana. Uso repetido sem estímulo é a melhor evidência depois do pagamento.
3. Reclamou de algo específico, em vez de elogiar em geral. Reclamação detalhada significa que a pessoa se importa.
4. Indicou para alguém, o que só acontece quando o problema é real.

E dois sinais que parecem bons e não são: “achei muito legal” e “com certeza eu usaria”. Nenhum dos dois custa nada a quem fala, e por isso não informam. O roteiro de três semanas para colher esses sinais está em validação de MVP.

Os erros mais comuns

• Construir seis meses antes de mostrar a alguém. O problema não é o tempo, é descobrir tarde que ninguém queria.
• Testar com amigos e colegas, que distorcem qualquer sinal por educação.
• Perguntar em vez de observar. Opinião sobre uso futuro é ficção; comportamento diante de uma oferta real é dado.
• Adicionar recurso para evitar a rejeição, quando a rejeição era a informação.
• Não decidir no fim. MVP sem data de decisão vira produto por inércia.
• Confundir aprendizado com validação. Descobrir que ninguém quer é sucesso do método, e não fracasso do projeto.

Esse último ponto é o que mais separa quem usa o método de quem usa a palavra. As práticas em volta disso estão em startup enxuta e a sequência completa de começar em como criar uma startup. E vale a distinção final: MVP prova que existe produto; transformar isso em empresa é outro trabalho, tratado em negócio digital.

Perguntas frequentes