Protótipo, MVP ou produto? Como validar uma ideia antes de investir

Muitos projetos de produto começam pelo fim: constroem a solução antes de saber se o problema existe, quem o tem e quanto está disposto a pagar para o resolver. Quando a resposta chega, já se gastou o orçamento.

Protótipo, MVP e produto respondem a perguntas diferentes. Confundi-los é pagar para responder à pergunta errada. Este guia mostra o que construir em cada fase, um calendário de quatro semanas para validar uma ideia e os sinais que indicam se deves avançar ou parar.

Primeiro o problema, depois a solução

Antes de decidir o que construir, valida o problema e o processo à volta dele. Quem tem este problema? Como o resolve hoje: com que ferramentas, com que passos, com quanto tempo perdido? O que lhe custa não o resolver?

Estas respostas dizem-te se há um problema que vale a pena resolver e mostram por onde a solução tem de passar. Uma solução desenhada sem perceber o processo do cliente resolve um problema que ninguém tem, ou resolve o certo da forma errada.

Escreve a hipótese

Antes de escrever uma linha de código, completa esta frase:

"Acredito que [tipo de cliente] vai pagar [valor] por [solução] porque [problema]."

Se não consegues preencher todos os espaços, ainda não estás pronto para construir. E define já o que conta como sucesso e como falha: que resposta, de quantas pessoas, te faria avançar ou parar.

Protótipo, MVP ou produto: o que construir em cada fase

Protótipo

• Pergunta a que responde: "as pessoas percebem isto e querem-no?"
• O que tem: ecrãs clicáveis, uma página de apresentação, um vídeo curto a mostrar a ideia.
• O que não tem: backend real, autenticação, pagamentos.

MVP

• Pergunta a que responde: "alguém usa e paga por isto?"
• O que tem: o fluxo principal a funcionar de verdade, só com as funcionalidades que provam o valor. Por trás, parte do trabalho pode ser feita à mão.
• O que não tem: tudo o que não é preciso para responder à pergunta.

Produto

• Pergunta a que responde: "como sirvo isto a muitos clientes de forma fiável?"
• O que tem: robustez, segurança, desempenho, testes, monitorização e suporte.
• Quando: só depois de o MVP mostrar um sinal claro de que há procura.

O que é (e o que não é) um MVP

MVP quer dizer Minimum Viable Product, e as três palavras contam:

• Minimum: o menos possível para responder a uma pergunta.
• Viable: funciona de verdade, não é uma maqueta.
• Product: alguém pode usar e pagar.

Não é um MVP:

• um Figma "interativo" sem backend;
• uma página de "brevemente" com lista de espera;
• uma versão "beta" que demora meses a sair.

Estas coisas têm valor, mas validam interesse, não um produto. Pertencem à fase de protótipo.

Um calendário de 4 semanas para validar

Quatro semanas são um ritmo de trabalho, não uma promessa: o objetivo é chegar a uma resposta, não a um produto acabado.

Semana 1: entrevistas. Conversa com potenciais clientes sobre o problema e sobre como o resolvem hoje. Sem demonstrações, só perguntas. Continua até começares a ouvir as mesmas respostas. Procura padrões, não elogios.

Semana 2: protótipo. Ecrãs, uma página de apresentação e um vídeo curto. Ainda sem código real.

Semana 3: pré-venda ou equivalente. Mostra o protótipo a pessoas que encaixam no perfil e pede um compromisso concreto: um pagamento antecipado, um piloto pago, uma carta de intenção ou uma reunião com quem decide. Um sim com compromisso vale mais do que muitos elogios.

Semana 4: construção mínima. Só o fluxo de que precisam as pessoas que se comprometeram. Fazer parte do trabalho à mão nos bastidores é aceitável nesta fase. O objetivo é entregar ao primeiro cliente.

Sinais para avançar e sinais para parar

Estás no caminho certo quando:

• há clientes dispostos a pagar antes de o produto existir;
• pedem funcionalidades específicas, não genéricas;
• reclamam quando alguma coisa falha, porque já dependem dela.

É altura de parar ou mudar de rumo quando:

• a resposta de quase toda a gente é "interessante, mas…";
• pedem desconto antes de verem valor;
• ninguém recomenda a solução a outras pessoas.

Parar também é um resultado. Descobrir em quatro semanas que a ideia não pega custa muito menos do que descobri-lo depois de construir o produto.

Os MVPs que falham (e porquê)

• Demasiado completos. A vontade de "fazer bem" atrasa o lançamento até o mercado já ter mudado.
• Construídos antes de perceber o processo. A solução não encaixa na forma como o cliente trabalha, e ninguém a adota.
• Sem distribuição planeada. Construiu-se, lançou-se e ninguém soube. Fazer chegar o MVP às pessoas certas faz parte do MVP.
• Sem critérios de sucesso e de falha. "Se correr bem, continuamos" não é um critério. Define antes de construir o que conta como sinal para avançar.

Conclusão

Construir na ordem certa não é lento. É a forma mais rápida de chegar a algo que funciona: primeiro o problema e o processo, depois o protótipo, depois o MVP e só no fim o produto. Em cada fase, constrói apenas o necessário para responder à pergunta dessa fase.

Perguntas frequentes

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

O protótipo testa se as pessoas percebem e querem a ideia, sem backend real. O MVP testa se alguém a usa e paga por ela, com o fluxo principal a funcionar de verdade.

Quanto tempo demora validar uma ideia?

Depende do problema e do acesso aos clientes. O calendário de quatro semanas deste artigo é uma referência de ritmo: entrevistas, protótipo, pré-venda e construção mínima.

Um MVP pode ter processos manuais por trás?

Sim. Nesta fase, fazer parte do trabalho à mão nos bastidores é uma forma barata de testar o valor antes de automatizar.

Quando devo passar de MVP a produto?

Quando o MVP mostra um sinal claro de procura: clientes que pagam, que voltam a usar e que recomendam a solução.