O que é MVP e por que ele não é a versão barata do produto

O orçamento chega por e-mail no meio da tarde. Você abre o anexo, desce direto pro valor no fim da página e fecha o arquivo. Não cabe.

Aí você volta pra lista de funcionalidades que mandou pra três empresas e começa a riscar. Primeiro sai o aplicativo pro cliente. Ainda não cabe, então sai a integração com o banco. Quando o que sobrou cabe no dinheiro, você responde o e-mail com uma frase curta: "vamos começar pelo MVP".

Quase todo mundo que já teve uma ideia de sistema fez essa conta. E ela parece responsável: gastar menos agora e crescer quando der certo. O problema é que a lista riscada não responde pergunta nenhuma, e o dinheiro gasto nela pode não te ensinar nada.

O que é MVP (ou produto mínimo viável)

MVP é a sigla em inglês de minimum viable product, o produto mínimo viável. Também aparece como mínimo produto viável, e por isso muita gente escreve MPV. O termo foi criado por Frank Robinson em 2001 e ficou famoso com Steve Blank e Eric Ries.

Num texto de 2009, o Ries definiu o MVP como a versão de um produto novo que deixa o time aprender o máximo sobre os clientes com o menor esforço. E na frase seguinte deixou um aviso que some de quase todo resumo sobre MVP: MVP, apesar do nome, não é sobre criar produtos mínimos.

A definição põe o mínimo no esforço e o máximo no aprendizado. Quem lê "produto mínimo" e entende "produto barato" ou "produto com menos botão" pegou a palavra errada da sigla.

Por isso eu uso uma definição mais curta: MVP é a menor coisa que responde a pergunta que está travando a sua decisão. Às vezes essa coisa é um app. Quase sempre dá pra começar com menos, como uma tela pra clicar ou um teste com meia dúzia de documentos de verdade.

O desenho do skate ao carro, que o Henrik Kniberg usou em 2016 pra explicar o MVP, mostra isso melhor do que qualquer definição. Em cima, o carro chega em partes: primeiro a roda, depois o eixo, depois a carroceria. Ninguém anda numa roda, então só no fim dá pra saber se a pessoa queria mesmo um carro. Embaixo, cada etapa já leva a pessoa a algum lugar: skate, patinete, bicicleta, moto. A cada uma você aprende o que ela precisa, e às vezes descobre que a bicicleta já bastava.

O próprio Ries avisa que, se o objetivo é só coçar uma coceira clara ou montar algo pra vender rápido, você não precisa de MVP. Ele serve quando existe uma dúvida em que errar sai caro.

Construir, medir e aprender é o método científico aplicado ao produto

No livro A Startup Enxuta, de 2011, o Ries pôs o MVP dentro de um ciclo que ele chama de construir, medir e aprender. Você constrói alguma coisa, lança na frente de quem vai usar, mede como a pessoa reage e aprende se segue no caminho ou muda de rota.

Quem passou por uma aula de ciências reconhece o desenho. A hipótese é a dúvida que trava a sua decisão, e o MVP é o experimento que testa essa hipótese. Medir é observar o que acontece quando gente de verdade usa. Aprender é tirar a conclusão, mesmo quando ela derruba a ideia. No método Lean Startup, toda startup é um grande experimento que tenta responder uma pergunta.

E, como num laboratório, o plano anda ao contrário do ciclo. O Ries manda decidir primeiro o que você precisa aprender, depois o que vai medir, e só então o que construir. Quem começa pelo construir acaba na lista riscada.

Produto pela metade não responde pergunta nenhuma

Volta pra lista riscada. A versão cortada vai pro ar alguns meses depois, e pouca gente usa. Você fica sem saber o motivo. Pode ser que a ideia não preste, que tenha faltado justamente a parte que você riscou ou que o problema do cliente nem fosse esse.

Com produto pela metade, qualquer resultado tem mais de uma explicação. Você gastou o dinheiro e continua sem saber qual delas vale.

É como construir meia ponte pra descobrir se as pessoas querem atravessar o rio. Ninguém atravessa meia ponte, e isso não diz nada sobre a vontade de chegar do outro lado. Pra saber se tem gente querendo atravessar, um barco a remo responde muito antes da ponte.

Tem um motivo pra esse jeito de cortar ser tão comum. Quem orça por lista de funcionalidades vai orçar a lista. Fábrica de software, agência e freela recebem uma lista e devolvem um preço pra ela, porque esse é o modelo de trabalho deles. Pouca gente nessa conversa pergunta o que você precisa descobrir antes de gastar. E quando o preço assusta, sobra pra você cortar a lista sozinho.

Com IA, a primeira versão sai em dias

Essa parte ficou muito mais fácil. Antes, testar uma ideia de sistema custava semanas de alguém programando. Hoje uma tela clicável sai numa tarde, e um protótipo que funciona de verdade sai em poucos dias, com a IA escrevendo boa parte do código.

Pra quem quer fazer um MVP, isso é ótimo. Algumas coisas que a IA faz bem nessa fase:

• Montar a tela pra alguém clicar. Você descobre se a pessoa entende o fluxo sem explicação antes de investir nele.
• Testar se a parte difícil é possível. Se a ideia depende de ler nota fiscal, contrato ou foto de documento, dá pra testar a leitura com arquivos reais antes de desenhar qualquer tela.
• Simular o que ainda não existe. Um relatório montado à mão, com ajuda da IA, mostra se alguém lê aquilo antes de você automatizar.
• Listar o que você está assumindo. Peça pra ela escrever as hipóteses escondidas na sua lista de funcionalidades. Costuma aparecer coisa que você nunca tinha posto em palavras.

Só que isso traz outro risco. Quando a primeira versão fica barata, a tentação é pedir a lista inteira, e o MVP vira o app quase pronto, com tudo dentro e nenhuma dúvida respondida. A IA faz o que você pede, e faz rápido. O que ela não sabe é qual dúvida você precisa tirar primeiro. Eu escrevi sobre esse app que nunca sai do quase no post sobre o que é vibe coding.

Escolher a pergunta continua sendo decisão sua

Nenhuma ferramenta escolhe a pergunta por você, porque ela depende do que você vai fazer com a resposta. Ficou mais fácil construir o teste, mas continua sendo trabalho decidir o que testar. Algumas perguntas ajudam a chegar lá:

• Qual dúvida, se der errado, derruba a ideia inteira? Comece por ela, antes de pensar em qualquer tela.
• O que você faria diferente com cada resposta? Se o sim e o não levam pro mesmo plano, essa dúvida não está travando nada.
• Quem precisa responder? Opinião do sócio ajuda pouco aqui. Vale a pessoa que vai usar, fazendo a tarefa de verdade, com o dado de verdade.
• O que conta como dar samba? Escreva isso antes de começar o teste. Depois, todo mundo acha um jeito de dizer que deu certo.

No protocolo antivibe, esse é o terceiro passo, o menor experimento. Ele vem depois de mapear o terreno e de priorizar o problema e o caminho. Por isso funciona: quando chega a hora de testar, você já sabe qual dúvida pesa mais e não gasta o experimento com detalhe.

Um teste com meia dúzia de guias antes de qualquer tela

Trabalhei com uma empresa de faturamento de anestesia que chegou pedindo um sistema inteiro: fila de faturamento, fechamento do mês, repasse por médico. É assim que quase todo pedido chega pra mim: com a solução já desenhada.

Só que tudo aquilo dependia de uma coisa só. A IA precisava ler a guia do procedimento, que chegava em foto ou PDF, e tirar dela paciente, procedimento e valores sem errar. Se a leitura falhasse, a fila, o fechamento e o repasse não serviam pra nada.

Então o primeiro passo foi um teste de poucos dias, sem tela nenhuma: meia dúzia de guias reais, lidas por três modelos de IA diferentes, com a conferência feita campo por campo. A dúvida que travava o projeto era se dava pra confiar nessa leitura. Dava, desde que uma pessoa conferisse cada guia antes de ela virar dinheiro.

Só depois disso o resto do sistema começou a ser construído, já sabendo onde a IA entra e onde a pessoa decide. Se o teste tivesse dado errado, o projeto mudaria de rumo gastando pouco, e ninguém teria construído meia ponte.

Antes de riscar a próxima linha da sua lista, escreva no topo da página qual dúvida, se der errado, derruba a ideia inteira. O seu MVP é o menor teste que responde essa linha. Se quiser ajuda pra encontrar a pergunta certa, entre em contato e me conte qual decisão está travada.