Protótipo, MVP e produto: onde fica a linha

Protótipo responde se a ideia faz sentido para quem olha para ela. MVP responde se gente de verdade vai usar, e talvez pagar, quando aquilo é a única opção que ela tem.

No dia a dia essas palavras viram sinônimo e o time paga a conta. O stakeholder pede um protótipo, o dev entende produto, e três semanas depois uma demo descartável está atendendo cliente de verdade. Vou explicar como eu separo cada coisa na hora do refinamento.

Quatro coisas, quatro perguntas

Cada uma existe para responder uma pergunta só. Se você não consegue escrever essa pergunta em uma frase, está construindo sem motivo.

• Spike: dá para fazer? É um experimento curto, com tempo limitado, sobre uma dúvida técnica. A API do gateway aceita estorno parcial? Conseguimos ler esse formato de arquivo? A entrega é uma resposta, não uma funcionalidade.
• Protótipo: isso faz sentido para quem vai usar? Simula a experiência com telas, fluxo falso e dados de exemplo. Você observa a pessoa e anota onde ela trava.
• MVP: vai ser usado de verdade e vale o esforço? É a menor versão que resolve uma tarefa de ponta a ponta para usuários reais, com dados reais e consequência real.
• Produto: conseguimos manter e crescer? Aqui confiabilidade, suporte, cobrança e permissões pesam tanto quanto a funcionalidade principal.

Só os dois últimos precisam sobreviver a um cliente que não é seu amigo. Os dois primeiros podem ser feios, incompletos e até errados.

O que medir em cada etapa

O spike se mede pela dúvida que sumiu. Você termina com sim, não ou sim, mas custa tanto. Mais nada importa.

O protótipo se mede pelo comportamento na sua frente. Cinco pessoas concluem a tarefa sem ajuda? Onde hesitam? Explicam o valor com as próprias palavras? "Achei bonito" é ruído. Hesitação é dado.

O MVP se mede por uso repetido e algum tipo de compromisso: cadastro que volta, agendamento feito, cartão cadastrado, equipe que abandona a planilha. A primeira visita fala do seu marketing. A segunda fala do seu produto.

O produto se mede por retenção, custo de operar e quanto do backlog virou correção em vez de evolução. Quando o bug come a sprint, você tem um produto, tenha planejado ou não.

Uma ideia atravessando as quatro etapas

Imagine uma pequena escola de idiomas que quer deixar o aluno remarcar aula sem ligar para a secretaria. Essa é a ideia. Vamos ver o caminho.

Começa pelo spike, porque tudo depende do sistema de agenda que a escola já usa. Dá para ler os horários livres e gravar uma mudança de volta? Dois dias de investigação. Resposta: lê sim, grava não. Então toda remarcação passa por uma confirmação da secretaria. Isso muda o desenho inteiro e descobrimos antes de construir qualquer coisa.

O protótipo é um fluxo clicável com cinco alunos fictícios e horários inventados. O PO senta com três alunos de verdade e com a secretária. Os alunos entendem na hora. A secretária pergunta quem aprova a mudança e como ela vai enxergar isso. Nenhuma especificação teria levantado essa pergunta, e custou uma tarde.

O MVP é uma turma, um professor, aulas reais. Entrada pelo celular, o aluno escolhe novo horário, o pedido cai numa lista que a secretária aprova. Sem lembrete, sem pagamento, sem segunda unidade. Acompanhamos por duas semanas: quantos pedidos chegaram, quantas ligações deixaram de existir, quantos alunos voltaram a usar.

Só quando esses números se sustentam vira produto: mais professores, lembretes, perfis de acesso, histórico de alterações, exportação de dados. Cada item nasce de algo que o MVP ensinou, não de um brainstorm.

Quando jogar o código fora e quando manter

Código de spike vai para o lixo. Sempre. Foi escrito para aprender, então pula teste, tratamento de erro e nome decente. Guarde a nota do que você aprendeu, não o código.

Código de protótipo geralmente também vai embora, com uma ressalva. Se era só uma maquete que desenha telas, descarte. Se foi feito numa stack de verdade, com banco real, parte pode ser aproveitada. O teste é simples: alguém consegue explicar o que cada pedaço faz e quem é dono dele?

Código de MVP você mantém, senão está mentindo para si mesmo sobre o cronograma. Ele vai ter atalhos, então registre cada um no backlog na mesma semana em que tomou. Atalho sem dono vira a personalidade permanente do produto.

Protótipo que você não pode jogar fora já virou produto, só que um produto ruim.

Como o PO decide o que precisa agora

Parta da sua maior incerteza, não do roadmap. Se a dúvida é técnica, faça spike. Se é se as pessoas entendem ou querem a coisa, faça protótipo. Se é se vão voltar e se compensa operar, faça MVP. Se é como escalar algo que já funciona, você está falando de produto.

No refinamento, eu pergunto quem vai olhar o resultado e o que essa pessoa vai fazer com ele. Se a resposta é "o diretor vai ver e aprovar o orçamento", o que você precisa é de um protótipo. Se é "o cliente vai usar na segunda-feira", já é MVP, e o nível de cuidado muda. Uma pergunta ajuda: que decisão eu tomo quando o resultado chegar? Se a resposta for "nenhuma, vai ser igual", pule a etapa. Tem time que gasta semanas em protótipo de ideia já decidida, e semanas em MVP para uma dúvida que cinco conversas com usuários resolveriam.

Onde a ferramenta muda a conta

O custo das etapas iniciais fazia muita gente pular direto para o desenvolvimento. Hoje dá para descrever o app num chat, em ferramentas como o StarBuild, e receber uma versão full-stack funcionando, com banco de dados e login. Um protótipo com dado real passa a custar horas, não sprints. Isso barateia o protótipo e o primeiro MVP. Não elimina as perguntas: você ainda precisa saber o que está testando e ainda precisa decidir o que apagar.

Então escreva a pergunta no topo do card antes de construir. Escolha a coisa mais barata que a responde e seja honesto sobre qual rótulo ela carrega. A maioria das discussões entre protótipo e MVP é, no fundo, uma discussão sobre o que o time pode prometer ao cliente.