MVP não é versão incompleta — é a menor prova de que alguém paga pelo problema que você resolve

O erro mais caro em produto novo

O erro mais comum ao construir um MVP não é técnico — é conceitual. O time lê "Minimum Viable Product" e entende "versão simplificada do produto final". Corta telas, corta funcionalidades, mantém a mesma arquitetura mental de sempre, só que menor. Três meses depois, tem um produto pequeno que ninguém pediu, em vez de uma resposta rápida para uma pergunta que importava.

Um MVP não é um produto reduzido. É um experimento. E todo experimento existe para responder a uma pergunta específica — não para impressionar.

O que MVP realmente testa

Antes de escrever a primeira linha de código, vale escrever a pergunta que o MVP vai responder. Normalmente ela é uma destas três:

• Existe o problema? As pessoas realmente sentem essa dor com a frequência e intensidade que você imagina, ou é um problema que só incomoda em teoria?
• Sua solução resolve? Diante de uma forma concreta de resolver o problema, o comportamento das pessoas muda?
• Alguém paga por isso? Ainda que pequeno, existe disposição real de troca — dinheiro, tempo, atenção — pela solução?

Cada pergunta pede um experimento diferente, e cada experimento pede uma quantidade diferente de código. Às vezes a resposta cabe numa landing page com uma lista de espera. Às vezes cabe num processo manual por trás de uma interface simples, sem nenhuma automação real. Construir demais para a pergunta que você tem é o motivo número um de MVPs que morrem por excesso de escopo antes de aprender qualquer coisa.

Como saber o que cortar

Uma pergunta prática ajuda a decidir o que entra e o que fica de fora: "se essa parte não existir, a pessoa ainda consegue perceber o valor?" Se a resposta é sim, corta. Se a resposta é não, é o núcleo — e o núcleo, só ele, já é difícil o bastante de acertar.

Onboarding bonito, configurações avançadas, personalização, múltiplos planos de preço: quase tudo isso é decoração de um produto que ainda não provou o essencial. Adicione depois que o essencial estiver validado — nunca antes.

Sinais de que você validou (e sinais de que só construiu)

Validar não é "lançamos e algumas pessoas usaram". É diferente de "construímos e ninguém reclamou". Sinais reais de validação:

• Pessoas voltam sem você precisar lembrá-las.
• Alguém oferece pagar antes de você pedir.
• Usuários pedem mais de algo específico — não feedback genérico de "está bom".

Sinais de que você só construiu, sem validar nada:

• Uso concentrado só nos primeiros dias, depois silêncio.
• Feedback educado e vago ("legal", "interessante", "vou testar depois").
• Ninguém sentiu falta quando o produto saiu do ar por um dia.

O primeiro cliente pagante muda tudo

Existe um salto qualitativo entre "pessoas gostaram" e "alguém tirou o cartão da carteira". O primeiro é opinião. O segundo é comportamento — e comportamento não mente. Um MVP bem desenhado é o caminho mais curto e mais barato até esse segundo momento. Tudo o que vem antes dele é hipótese; tudo o que vem depois é produto de verdade.