Como construir um MVP sem exagerar no escopo

Todo fundador sabe que precisa lançar um produto mínimo viável. O problema é que quase ninguém concorda sobre o que “mínimo” quer dizer, e essa confusão custa caro. Tem time que sobe uma landing page e chama de MVP; tem time que passa nove meses polindo uma plataforma que ninguém pediu e dá exatamente o mesmo nome.

A palavra que derruba todo mundo é “viável”. Um MVP não é uma versão encolhida do produto final: é o menor experimento capaz de responder à única pergunta de que a sua ideia inteira depende. Pense assim e você economiza meses. Pense errado e vai construir uma resposta linda para uma pergunta que ninguém fez.

Este guia mostra como recortar um MVP em torno de uma única hipótese arriscada, como escolher o build mais leve possível e como escapar da armadilha de construir demais, que mata muito mais primeiros produtos do que código ruim jamais matou.

Comece pela hipótese, não pelas funcionalidades

Antes de escrever uma linha de código ou uma única user story, responda uma coisa: qual é a afirmação que precisa ser verdade para esse negócio dar certo e de que você menos tem certeza hoje? Essa é a sua hipótese mais arriscada, e o MVP existe só para testá-la. Nada além disso.

Na maioria das ideias iniciais, o risco mora na demanda: alguém vai usar isso de verdade, ou pagar por isso? Em algumas, o risco é a viabilidade técnica: dá para construir? Em outras, é um comportamento bem específico: o usuário vai fazer aquela coisa incomum que o produto exige? Seja qual for, escreva como uma afirmação que dá para provar falsa, com um número junto, do mesmo jeito que você faria num sprint de validação de 30 dias para a sua ideia de startup. “Pelo menos 30% de quem cai na página entra na lista de espera” dá para testar. “As pessoas vão amar isso” não dá.

Escolha o build mais leve que gera prova de verdade

Com a pergunta na mão, fica fácil: escolha o jeito mais barato de respondê-la com honestidade. Código costuma ser a opção mais cara, então trate-o como último recurso, não como ponto de partida. O leque de MVPs, do mais leve ao mais pesado:

O segredo está em casar o build com a pergunta. Se o risco é demanda, uma landing page com uma chamada para ação de verdade resolve em um dia, sem produto nenhum. Se o risco é saber se as pessoas vão concluir um fluxo complexo, talvez você precise de uma versão que funcione, mas dá para fingir o backend (a abordagem “Wizard of Oz”) e tocar tudo na mão enquanto o usuário acha que está automatizado. Empresas hoje famosas rodaram MVPs concierge em que os próprios fundadores entregavam os pedidos a dedo muito antes de existir qualquer automação.

35%

A armadilha de construir demais

Construir demais é o modo padrão de fracassar, e quase nunca parece um erro enquanto está acontecendo. Cada feature acrescentada soa razoável sozinha. Juntas, elas empurram o lançamento meses para a frente e soterram o sinal que você queria ler.

São três os motivos que levam o fundador a construir demais, e os três são emocionais, não estratégicos:

• Medo do julgamento. Um MVP cru dá vergonha, então você fica polindo até parecer “pronto”. Só que quem decide o que está pronto é o usuário, não o seu desconforto.
• Confundir esforço com progresso. Entregar funcionalidade dá uma sensação de produtividade. Mas o único progresso que conta é descobrir se alguém quer aquilo.
• Fugir da pergunta que assusta. Enquanto você está construindo, nunca precisa ouvir um usuário real dizer não. Construir vira uma forma de adiar a verdade.

Cada feature que você adiciona antes de lançar é uma aposta de que você já sabe o que o usuário quer. A graça do MVP é justamente partir do princípio de que você não sabe.

A disciplina é cortar até doer e só então lançar. Se você está confortável com o tão pouco que o seu MVP faz, é quase certo que construiu demais.

Não lance algo que não testa nada

Existe o fracasso oposto, e ele é igualmente comum: o MVP tão mínimo que ninguém consegue nem completar a ação central. Uma landing page é ótima para medir demanda, mas, se a sua pergunta de verdade é “as pessoas vão usar o fluxo”, a landing page não responde nada. O “mínimo” esbarra sempre no “viável”: o produto precisa deixar um usuário real fazer a coisa central e gerar um sinal claro.

O teste de viabilidade é simples: um estranho, sem nenhuma explicação sua, consegue completar a única ação de que o seu negócio depende e te dar um dado sobre se faria de novo? Se sim, é viável. Se a pessoa precisa de você olhando por cima do ombro dela, você tem uma demo, não um MVP.

É aqui também que um bom sócio técnico mostra o valor dele. Decidir o que fingir e o que construir de verdade, e construir rápido a parte de verdade, é uma questão de julgamento, e é por isso que vale ter ao lado alguém que já lançou produto antes, seja um cofundador técnico que você encontra pela rede ou um primeiro engenheiro que já passou por isso.

Seu MVP em quatro passos

1. Dê nome à hipótese mais arriscada

   Escreva a única coisa que precisa ser verdade como uma afirmação que dá para provar falsa, com um número junto. Essa frase resume sozinha tudo o que o seu MVP precisa fazer.

2. Escolha o build mais leve que a testa

   Comece pelo topo do leque de MVPs (landing page, concierge, no-code) e só desça em direção a código de verdade quando um teste mais leve não conseguir responder à pergunta.

3. Defina um prazo em semanas

   Limite o build a poucas semanas. O prazo é a trava que mantém o escopo honesto: tudo o que não serve à pergunta central cai fora para caber no tempo.

4. Combine antes o que significa “deu certo”

   Defina o critério antes de lançar, para ler o resultado com honestidade em vez de racionalizar depois. Aí coloque na frente de usuário real e observe o que eles fazem, não o que dizem.

Quando o MVP te der um sinal claro, a pergunta seguinte passa a ser se aquela tração inicial é real e se repete: o começo da busca pelo product-market fit. Mas essa busca só arranca depois que você lançou algo de verdade, pequeno o bastante para aprender com ele. Construa o experimento, não o produto. O produto vem depois da prova.