Ideia principal

Uma maquete já permite iterar: você olha uma tela, segue um percurso, percebe que um botão não está no lugar certo ou que falta uma informação. O que ela mostra é uma intenção, e as objeções que ela provoca são sobre a intenção.

Um produto que funciona dá outra coisa. Você não olha para ele, você o usa: espera uma lista carregar, repete três vezes o mesmo gesto, descobre que um filtro não serve para nada porque o dado real não tem o formato previsto. Esses atritos não são falhas de representação, são propriedades do produto, e nenhuma maquete consegue produzi-los, já que ela não contém nem os dados reais, nem os tempos reais, nem a repetição do uso.

A virada é gradual e passa quase despercebida: a coisa primeiro parece uma maquete, depois começa a funcionar, depois você a mostra, depois pedem evoluções, depois perguntam quando vai dar para usar.

Por que isso importa

Isso muda o que você constrói primeiro. Enquanto produzir uma versão utilizável custava muito mais caro do que produzir uma representação, a maquete era o único ponto de entrada razoável numa iteração. Quando um product manager monta em quatro dias telas, APIs internas e alterações de dados, a representação deixa de ser a etapa econômica.

Isso também desloca o momento do retorno do usuário: ele não chega mais sobre o que você planeja fazer, mas sobre o que existe — portanto sobre objeções que nenhuma releitura de especificação teria feito aparecer.

Nuances e limites

A vantagem vem do realismo, não do fato de ser código. Um produto alimentado por um conjunto de dados de teste não mostra mais atritos reais do que uma maquete: mostra menos, porque dá a impressão de já ter sido posto à prova.

E a maquete mantém um uso que o produto não assume: explorar várias direções sem pagar por nenhuma. Um produto que roda torna uma direção difícil de abandonar, justamente porque ela existe.

Questões em aberto

• A partir de que nível de risco o custo de abandonar uma versão utilizável supera o ganho de tê-la construído em vez de desenhado?