MVP, protótipo ou prova de conceito: o que construir primeiro

Cada um testa um risco diferente. Esta tabela compara os três lado a lado.

Uma prova de conceito, ou PoC, verifica se algo é tecnicamente possível. Normalmente é um pequeno trecho de código que resolve um problema difícil e ignora todo o resto: sem design, sem contas, sem acabamento.

Por exemplo, uma startup que quer extrair o valor total de fotos de recibos escritos à mão deve testar primeiro se um modelo de IA consegue lê-los com precisão suficiente. Se não conseguir, nenhum design vai salvar o produto.

A maioria dos produtos não precisa de PoC. Se a sua ideia é feita de partes já testadas, como contas, pagamentos, formulários e dashboards, o risco técnico é baixo e uma PoC só adia a pergunta de verdade.

O código de uma PoC costuma ser descartado. Ele foi escrito para responder rápido a uma pergunta, não para sustentar um produto.

Um protótipo mostra como o produto vai funcionar antes que alguém escreva código de produção. Pode ser um conjunto de rascunhos ou uma interface clicável e realista, que se comporta quase como o produto real.

O guia da Nielsen Norman Group sobre protótipos de baixa e alta fidelidade explica bem essa escolha. Rascunhos simples são mais rápidos e estimulam críticas sinceras; protótipos de alta fidelidade mostram um comportamento realista, o que importa quando você testa fluxos específicos.

Um protótipo também é a melhor ferramenta para alinhar as pessoas. O AutoIntel, uma ferramenta B2B para o mercado alemão de carros usados, começou como um protótipo interativo com anúncios de exemplo. O cliente percorreu o protótipo com a equipe e todos combinaram quais campos e filtros importavam antes de orçar o processamento de dados.

Um MVP, ou produto mínimo viável, é a menor versão do seu produto que usuários reais conseguem usar de verdade. Ele tem contas funcionando, dados reais e, onde importa, pagamentos reais.

O objetivo é aprender, não lançar por lançar. Nas palavras do Lean Startup, o MVP é construído para “começar o processo de aprendizado o mais rápido possível”.

Um MVP mede o que um protótipo não consegue: se as pessoas voltam e se pagam. No CarPixly, um estúdio de fotos com IA para anúncios de carros, qualquer pessoa pode se cadastrar e explorar o estúdio de graça, e o pagamento acontece no momento de valor, na renderização. Um modelo assim mostra com clareza quantos visitantes viram usuários pagantes.

A maioria dos MVPs leva de 6 a 14 semanas para ficar pronta, conforme a complexidade. Os nossos guias sobre quanto tempo leva para desenvolver um MVP e quanto custa um MVP SaaS trazem as faixas por nível.

Comece pela incógnita mais arriscada. Faça estas perguntas em ordem:

• Existe uma chance real de não dar para construir? Por exemplo, o produto depende de um modelo de IA, de um sensor de hardware ou de uma API que ainda não foram testados. Faça uma prova de conceito.
• Não está claro se as pessoas entendem a solução ou se a querem? Faça um protótipo e teste com usuários.
• As pessoas entendem e querem a solução, e a dúvida é se vão usar ou pagar? Faça um MVP.

A maioria das startups para na segunda pergunta. A tecnologia geralmente já está provada; o que falta provar é se o produto faz sentido para as pessoas a quem ele se destina.

Não sabe qual é o maior risco da sua ideia? Mande um briefing curto e diremos por qual passo começaríamos, e por quê.

Um protótipo só é útil se pessoas reais o experimentarem. A boa notícia é que você precisa de menos participantes do que a maioria dos fundadores imagina.

A pesquisa de Jakob Nielsen mostrou que testar com 5 usuários revela a maior parte dos problemas de usabilidade de um design. O conselho dele é fazer várias rodadas pequenas em vez de um único estudo grande.

Uma rodada de teste simples funciona assim:

• Dê a cada pessoa uma tarefa realista, como “agende um serviço para a próxima terça”.
• Observe o que ela faz, sem ajudar nem explicar.
• Anote onde ela hesita, entende errado ou desiste.
• Corrija os piores problemas e teste a próxima versão com pessoas novas.

Pergunte também sobre o comportamento atual: como as pessoas resolvem o problema hoje e quanto isso custa a elas. Isso diz mais sobre a demanda do que perguntar se elas “usariam” o seu produto.

Um protótipo feito de rascunhos é uma ferramenta de aprendizado e é redesenhado depois. Um protótipo de alta fidelidade criado com componentes reais é diferente: os fluxos, as telas e o design system dele viram o ponto de partida do MVP.

É por isso que desenhamos com componentes reutilizáveis desde a primeira tela. Quando o protótipo está testado e aprovado, o desenvolvimento começa sobre os mesmos componentes, em vez de reinterpretar uma imagem.

Com a prova de conceito acontece o contrário. O código dela responde a uma pergunta e normalmente é reescrito direito dentro do MVP, porque nunca foi pensado para usuários reais.

Cada passo deve terminar com uma resposta clara, não com uma impressão. Escreva o que significa “sucesso” antes de começar, para que o resultado não possa ser reinterpretado depois conforme a sua expectativa.

• A prova de conceito deu certo quando a parte difícil funciona com dados realistas, com a precisão ou a velocidade de que o produto precisa. “Funciona com três arquivos de teste” não basta se os usuários vão enviar milhares.
• O protótipo deu certo quando a maioria dos usuários de teste conclui a tarefa principal sem ajuda e descreve, com as próprias palavras, o problema que ele resolve.
• O MVP deu certo quando usuários reais voltam sem lembretes, ou pagam, com uma frequência que justifica o próximo investimento.

Se um passo falhar, isso também é útil. Uma prova de conceito que não funcionou evita um desenvolvimento caro. Um protótipo confuso mostra que é preciso mudar o fluxo enquanto as mudanças ainda são baratas.

Defina também um prazo para cada passo. Um protótipo que continua sendo polido depois de meses deixou de ser um teste e virou um produto que ninguém pode usar ainda.

Às vezes, sim. Se a ideia já foi testada, por exemplo com uma versão manual do serviço, talvez você já saiba o suficiente para ir direto ao MVP.

Por exemplo, uma pessoa que há meses conecta clientes a professores particulares manualmente, com planilhas e mensagens, já conhece os fluxos e as perguntas que as pessoas fazem. Um protótipo confirmaria sobretudo o que ela já sabe.

Pular o protótipo faz sentido quando três coisas são verdade: a tecnologia está provada, você já viu pessoas reais passarem pelo processo e sabe qual parte do processo o software deve assumir primeiro. Se faltar alguma delas, o protótipo continua sendo a forma mais barata de descobrir.

Os mesmos erros aparecem o tempo todo:

• Chamar protótipo de MVP. Cliques em um protótipo mostram entendimento, não uso nem pagamento. Não confunda uma coisa com a outra.
• Polir uma prova de conceito até virar produto. Código escrito para responder a uma única pergunta vira uma base frágil para tudo o que é construído em cima dele.
• Pular o protótipo. Construir um MVP antes de testar os fluxos significa pagar desenvolvedores para descobrir problemas de design.
• Colocar coisa demais no MVP. Cada funcionalidade extra adia o momento em que você descobre se o núcleo funciona.
• Testar com amigos. Quem gosta de você vai elogiar a ideia. Teste com pessoas que têm o problema e nenhum motivo para serem gentis.

Pronto para escolher o primeiro passo? Conte sobre a sua ideia e ajudamos você a decidir entre prova de conceito, protótipo e MVP.