Fundamentos de produto · Iniciante

O menor protótipo que prova alguma coisa

Em uma linha: Um protótipo existe para responder a uma pergunta perigosa, não para demonstrar um produto — por isso pode ser feio, manual e incompleto.

Como achar a pergunta perigosa

Pergunte: o que é aquilo que, se descobrirmos daqui a seis meses, vamos lamentar não ter verificado na primeira semana? A resposta quase sempre cai em uma de três: é tecnicamente possível, os dados existem e estão acessíveis, e alguém vai usar.

Se a pergunta perigosa for dados ou adoção, não construa nada esta semana. Verifique os dados, ou coloque uma pessoa fazendo o trabalho manualmente nos bastidores e veja se há demanda.

Três níveis, em ordem de custo

Totalmente manual. Uma pessoa presta o serviço sem que o usuário saiba. Em dois dias você descobre se há demanda e reúne dezenas de exemplos reais.

Planilha e coluna de conferência. Cinquenta casos reais, o mesmo processo para todos e uma coluna em que alguém marca se o resultado serve. Sem interface, sem banco de dados.

Protótipo conectado. Só se os dois anteriores deram positivo: interface mínima, uma fonte de dados real, um grupo pequeno de usuários.

O limite definido antes

A decisão mais importante é tomada antes de ver resultados: qual é a régua acima da qual seguimos. Se ela for definida depois dos números, sempre aparece uma explicação de por que 62 por cento é, na verdade, promissor.

Defina também um piso para parar. Um projeto interrompido na terceira semana é um acerto de processo, não um fracasso.

Indo mais fundo

No protótipo dá para abrir mão de design, login, velocidade e tratamento de erros. Não dá para abrir mão de dados reais e de medição. Um protótipo rodando sobre três exemplos inventados no escritório não ensina nada: eles foram escolhidos, sem querer, para funcionar.