Prova de conceito vs protótipo: o que construir primeiro?

Uma prova de conceito, um protótipo e um MVP respondem a três perguntas diferentes. Pague para construir o errado e você gasta semanas provando algo que já sabia.

Um fundador chegou até nós ano passado com um orçamento assinado para um “protótipo” do app de logística dele: quarenta mil dólares, uma versão clicável de cada tela. O que de fato tirava o sono dele era se o app conseguiria puxar dados ao vivo de três transportadoras cujos sistemas ninguém na empresa havia tocado. Isso não é uma pergunta de protótipo. Ele estava prestes a pagar para descobrir que as telas ficavam bonitas, enquanto a única coisa capaz de matar a empresa continuava sem teste.

É essa a armadilha de prova de conceito vs protótipo. Uma prova de conceito responde a uma pergunta: isso pode de fato ser construído? Um protótipo responde a outra: isso faz sentido para quem vai usar? Um MVP responde a uma terceira: alguém vai pagar por isso? Três artefatos, três riscos, e eles não são três tamanhos da mesma coisa. O trabalho real do fundador é gastar dinheiro apenas na pergunta que ainda não sabe responder. Se você sabe que a parte técnica é trivial, uma prova de conceito é desperdício. Se você sabe que as pessoas querem e sabe que dá para construir, pule as duas e construa a coisa.

Aqui está como diferenciar cada uma, e como decidir para onde seu dinheiro deve ir primeiro.

O que uma prova de conceito realmente prova

Uma prova de conceito é um experimento descartável que testa se um risco técnico específico tem solução. Não o produto inteiro. A única parte que te deixa nervoso.

A prova de conceito real do fundador de logística eram duas semanas de um engenheiro tentando se autenticar naquelas três APIs de transportadoras e normalizar os dados em um feed único. Um script feio, sem interface, sem tela de login, nada que um cliente veria algum dia. A saída era um sim ou um não. Voltou como “sim para duas delas, e a terceira exige um plano enterprise pago”. Essa resposta valeu mais do que a versão clicável de quarenta mil dólares, porque mudou o modelo de preços do negócio inteiro antes de uma linha de produto de verdade ser escrita.

Uma prova de conceito é certa quando a sua maior incerteza é uma frase que começa com “será que dá”. Será que dá para integrar com o sistema de prontuário daquele hospital. Será que dá para rodar esse algoritmo de matching rápido o bastante para parecer instantâneo. Será que dá para um modelo de IA extrair os campos certos de um PDF bagunçado de forma confiável. Quando o risco é viabilidade técnica, nada mais que você construa importa até essa pergunta ter resposta, porque um produto lindo em cima de uma integração impossível é só um jeito caro de descobrir que a integração era impossível.

O que uma prova de conceito não é: ela não é a primeira versão do seu produto. Você a joga fora. Reaproveitar código de prova de conceito como fundação é um dos erros mais caros que vemos, porque aquele código foi escrito para responder uma pergunta rápido, não para ser mantido por um time durante três anos.

O que um protótipo realmente prova

Um protótipo testa se a coisa faz sentido antes de alguém construí-la de verdade. O risco que ele elimina não é “isso pode ser construído”, e sim “esse é o formato certo para quem vai usar”.

A maioria dos protótipos não é código nenhum. São telas clicáveis, feitas numa ferramenta de design, que deixam um usuário real navegar por um fluxo e se confundir na sua frente. O valor está inteiro em assistir a essa confusão acontecer enquanto mudar uma tela ainda custa uma tarde em vez de uma sprint. Se você já sentou atrás de alguém usando seu produto e sentiu o estômago afundar quando a pessoa passou reto pelo botão do qual você tinha orgulho, você entende para que serve um protótipo. Ele tira esse aperto no estômago do pós-lançamento e o traz para antes de você pagar pela construção.

Protótipos vêm em fidelidades, e a palavra é usada para todas elas, o que faz parte da confusão. Um rascunho em papel é um protótipo. Um wireframe em caixas cinzas é um protótipo. Um mockup perfeito, clicável, com a cara exata do app pronto, é um protótipo. Eles ficam num espectro que vai de “tosco o bastante para testar o fluxo” a “polido o bastante para testar a sensação”, e os mais polidos começam a se misturar com o trabalho de design que você faria de qualquer forma. Escrevemos sobre onde essa linha fica no nosso texto sobre wireframe versus mockup; em resumo, um wireframe testa o encanamento e um mockup testa a pintura.

Um protótipo é certo quando a sua maior incerteza é sobre pessoas, não sobre máquinas. Será que entendem o fluxo. Será que confiam o bastante para colocar o cartão. Será que o onboarding faz sentido para alguém que não é você. Quando a parte técnica é banal e bem trilhada mas a experiência não está provada, o trabalho é de um protótipo.

Onde entra o MVP, e por que os três se confundem

A terceira palavra que os fundadores usam é MVP, e ela pertence a essa conversa porque responde ao risco que as outras duas não tocam: o mercado vai de fato pagar.

Uma prova de conceito prova que pode ser construído. Um protótipo prova que faz sentido. Nenhum dos dois prova que alguém quer o bastante para abrir a carteira. Esse é o trabalho do produto mínimo viável, e é a razão pela qual um MVP tem que ser software real, funcionando, usado por clientes reais com dinheiro real ou dados reais em jogo. Um protótipo clicável não valida demanda, porque ninguém tem nada em risco ao clicar por uma demo. É o risco que o trabalho de customer development de Steve Blank coloca no centro de tudo. Já defendemos que a maioria das coisas que os fundadores chamam de MVP é pequena demais para provar qualquer coisa na nossa análise do produto mínimo viável, e essa pergunta de demanda é exatamente o que um esforço de validação de mercado foi feito para responder.

Os três se confundem porque podem se sobrepor numa única construção, e porque os fornecedores têm incentivo para manter as palavras vagas. Se o mesmo experimento de duas semanas prova que a integração funciona e é mostrado a três clientes que dizem “eu pagaria por isso”, ele fez o trabalho de uma prova de conceito e de uma validação improvisada de uma vez só. Tudo bem. O objetivo não é rodar três projetos separados numa sequência rígida. O objetivo é saber qual risco cada hora de gasto está de fato comprando, para você não pagar um designer para polir telas quando o seu problema real é um banco de dados que você não tem certeza se existe.

Prova de conceito vs protótipo: o que vem primeiro?

A resposta honesta: o que atacar a sua maior incerteza. Não existe ordem universal, e qualquer fornecedor que te dá uma sem perguntar sobre o seu risco está vendendo um processo, não pensando na sua empresa.

Dito isso, há um padrão útil. Quando um projeto carrega risco técnico real, a prova de conceito vem primeiro, porque não adianta testar se os usuários amam um fluxo que não pode ser construído. Viabilidade é o portão de tudo. Quando a parte técnica é comum (mais um CRUD, mais um marketplace, mais um dashboard) e o risco mora inteiro em se as pessoas vão usar e pagar, você pode pular a prova de conceito e começar por um protótipo, e depois ir direto para um MVP.

A falha que mais vemos são fundadores rodando a ordem ao contrário por empolgação. O protótipo é a parte divertida. É visual, é compartilhável, faz a ideia parecer real, e você pode mostrar para o seu cônjuge. Então os fundadores gastam no protótipo primeiro, se apaixonam por ele, e só descobrem o problema de viabilidade meses depois, quando um engenheiro finalmente tenta construir a parte difícil. A essa altura existe um design lindo do qual todo mundo já gosta e uma parede técnica que ninguém checou. Ordene o seu gasto por risco, não pelo que é satisfatório de olhar.

O teste de uma pergunta para decidir no que pagar

Aqui está o método que percorremos com os fundadores. Leva uns cinco minutos e é só uma pergunta, feita com honestidade.

Escreva a única coisa mais capaz de matar este projeto. Não uma lista. Uma frase. Então olhe com que palavra ela começa.

• Se começa com “será que dá para construir”: isso é risco técnico. Pague por uma prova de conceito.
• Se começa com “será que as pessoas vão entender, confiar ou usar”: isso é risco de design. Pague por um protótipo.
• Se começa com “será que alguém vai pagar, o mercado existe”: isso é risco de mercado. Pague por um MVP, ou por uma validação mais barata antes de construir qualquer coisa.
• Se você não consegue escrever uma frase com honestidade, você ainda não tem uma decisão de gasto. Você tem pensamento a fazer.

A disciplina está em recusar gastar num risco que você já eliminou. Se você já integrou com aquele provedor de pagamento em três projetos passados, “será que dá para construir os pagamentos” não é o seu risco, e uma prova de conceito para isso é teatro. Se dez clientes já estão implorando por isso e pagando concorrentes por uma versão pior, “será que alguém vai pagar” está respondido, e rodar uma validação longa é procrastinação vestida de rigor.

A regra de bolso: construa uma prova de conceito só quando o seu maior risco for “isso pode ser construído”, um protótipo só quando for “será que vão usar”, e se você já sabe as duas respostas, pare de testar e construa a coisa de verdade. Eric Ries resumiu bem o objetivo por trás disso em A Startup Enxuta: “O único jeito de vencer é aprender mais rápido do que todo mundo.” Cada um desses artefatos é só uma forma de comprar barato um pedaço específico de aprendizado. Se não está comprando um aprendizado que você ainda não tem, não é barato. É uma conta.

Um protótipo pode ser uma prova de conceito?

Às vezes, e é aqui que as palavras de fato se sobrepõem. Um protótipo pode servir de prova de conceito quando a parte arriscada é a própria interação, não o encanamento por trás dela.

Digamos que a sua aposta seja um jeito radicalmente mais simples de lançar uma despesa, um gesto em vez de um formulário. Construir uma versão funcional desse gesto e colocá-la na frente de usuários testa tanto a viabilidade (“será que dá para fazer essa interação funcionar de forma fluida”) quanto o desejo (“as pessoas de fato preferem isso”). Um artefato, dois riscos eliminados. Mas o contrário raramente vale: uma prova de conceito quase nunca é um protótipo, porque uma POC costuma ser um script sem cabeça, sem interface para ninguém reagir. Ela prova que o motor liga. Não diz nada sobre se alguém quer dirigir o carro.

A armadilha é supor que a sobreposição sempre existe. Na maior parte das vezes não existe. A maioria dos riscos técnicos mora no backend, invisível, e a maioria dos riscos de usabilidade mora no frontend, e testar um não te diz nada sobre o outro. Suponha que são separados até conseguir explicar com clareza por que, no seu caso específico, são a mesma coisa.

Quanto cada um deve custar, em semanas e não em features

Os fundadores perguntam quanto isso custa, e a resposta útil está em tempo e escopo, não num valor em dinheiro, porque o valor em dinheiro é só o tempo multiplicado por uma taxa que você pode consultar na nossa análise de quanto custa de fato um aplicativo.

Uma prova de conceito deve ser pequena e rápida: de dias a duas ou três semanas, um engenheiro, uma pergunta. Se alguém te cobra dois meses por uma prova de conceito, ou está testando coisas demais de uma vez ou está construindo o seu produto na surdina e chamando de POC. Rebata. Uma prova de conceito que leva dois meses deixou de ser uma prova de conceito.

Um protótipo escala com a fidelidade. Um fluxo clicável tosco para testar uma jornada única são alguns dias de design. Um mockup polido, do app inteiro, são várias semanas, e nesse ponto você deveria se perguntar se está prototipando ou apenas fazendo a fase de design da construção real mais cedo, o que muitas vezes é bom, desde que você saiba que é isso que está pagando.

Um MVP é o caro, porque é software de verdade, e o custo dele é uma conversa inteira à parte. O erro é deixar um MVP se disfarçar de protótipo num orçamento, ou um protótipo se disfarçar de MVP. Quando o número parece grande demais para a palavra, a palavra costuma estar errada.

O erro que queima mais dinheiro

O erro mais caro é o que o fundador de logística quase cometeu: pagar para eliminar o risco que você não tem enquanto ignora o que você tem. Um protótipo lindo de um app cuja integração central acaba se revelando impossível. Uma prova de conceito sólida para um produto tecnicamente difícil que ninguém de fato quer. Um MVP completo construído antes de alguém checar se a parte difícil dava para construir.

A razão de isso acontecer sempre é que o risco divertido e o risco real costumam ser riscos diferentes. O divertido é visual e compartilhável. O real muitas vezes é chato, enterrado num backend, ou sentado numa pergunta desconfortável sobre se os clientes se importam. Os fornecedores, compreensivelmente, preferem te vender o divertido. A sua defesa é o teste de uma pergunta e a disposição de gastar o seu primeiro real na incerteza que de fato te assusta, mesmo quando é a parte menos fotogênica da ideia inteira. É essa a diferença entre um parceiro e uma caixa-preta: um parceiro pergunta qual risco você está eliminando antes de te dar um orçamento, e te tira da resposta cara-mas-satisfatória quando ela está errada.

Perguntas frequentes

Qual a diferença entre uma prova de conceito e um protótipo?
Uma prova de conceito testa se algo pode ser construído (viabilidade técnica). Um protótipo testa se faz sentido usar (design e usabilidade). Uma POC costuma ser um script descartável sem interface; um protótipo costuma ser telas clicáveis sem backend funcionando. Eles eliminam riscos diferentes e raramente são intercambiáveis.

O que vem primeiro, uma prova de conceito ou um protótipo?
O que atacar a sua maior incerteza. Como padrão, quando o projeto tem risco técnico real, a prova de conceito vem primeiro, porque não adianta testar se os usuários gostam de um fluxo que não pode ser construído. Quando a tecnologia é comum e o risco está todo na adoção, você pode pular a POC e começar por um protótipo.

Qual é um exemplo de prova de conceito?
Um experimento de duas semanas em que um engenheiro escreve um script feio para testar se o seu app consegue se autenticar em três sistemas externos e juntar os dados num feed único. Sem login, sem design, sem produto. A saída é um sim ou não sobre a única pergunta técnica que poderia matar o projeto.

Um protótipo pode ser uma prova de conceito?
Sim, quando a parte arriscada é a própria interação, e não o backend. Construir e testar um gesto novo prova ao mesmo tempo que ele funciona e que as pessoas o querem. Mas uma prova de conceito quase nunca é um protótipo, porque a maioria das POCs não tem interface para ninguém reagir.

Onde o MVP se encaixa em relação a POC e protótipo?
Um MVP é software real, funcionando, usado por clientes reais, e responde ao risco de mercado que os outros dois não tocam: alguém vai pagar. Uma prova de conceito prova que pode ser construído; um protótipo prova que faz sentido; um MVP prova que o negócio funciona. A maioria do que os fundadores chamam de MVP é, na verdade, protótipo ou uma primeira versão reduzida.