Construir ficou barato. Decidir ficou caro.

Em dois dias, produzimos nove protótipos para o The Ideas Garden: três direções low-fi em 17 de agosto e seis variações no dia seguinte. A V5 Split foi escolhida, virou design system e depois quatro telas hi-fi navegáveis.

Parecia progresso. E, em parte, era.

No dia seguinte, o feedback registrado sobre a divisória foi direto: conceito legal, pouco funcional. A proposta split foi rejeitada. Dark e light viraram modos globais. O layout foi refeito para obedecer ao esboço original e ao trabalho que o produto precisava cumprir.

A IA tinha nos ajudado a construir três direções, seis variações, um design system e quatro telas em pouquíssimo tempo. Mas a pergunta importante continuava a mesma:

O software avançou mais rápido que a resposta.

Construir barato não elimina o custo. Só transfere o custo do código para o julgamento.

Quando o preço do protótipo obrigava você a pensar

Quando uma tentativa consumia uma semana, o custo limitava naturalmente o número de opções. Esse filtro estava longe de ser perfeito: ideias boas morriam cedo e muito debate acontecia sem nada concreto na tela.

A IA removeu esse limite de produção. Ótimo. Eu não quero voltar para a época em que cada tentativa custava uma semana.

O problema aparece quando a quantidade de opções cresce mais rápido que nossa capacidade de revisar, comparar e encerrar escolhas. Cada protótipo barato ainda cobra contexto e uma resposta.

Foi o que Hilary Gridley viu quando liderava produto na Whoop. Com ferramentas capazes de gerar protótipos em uma tarde, o time entrou numa farra de demos. As ideias finalmente saíam dos documentos e apareciam na tela. Só que ninguém tinha um processo consistente para decidir quais eram boas, quais deveriam morrer e o que cada uma precisava ensinar.

Eles estavam construindo mais rápido. Não estavam decidindo melhor.

Um artefato bonito ainda pode ser uma pergunta ruim

A confusão começa porque ver algo funcionando produz uma sensação legítima de avanço. O botão responde. A transição está bonita. A demo impressiona. O artefato existe, então parece que a incerteza diminuiu.

Nem sempre diminuiu.

No nosso novo produto, era possível continuar refinando todas telas. Nada no custo de produção impediria outra rodada de variações.

Mas o objetivo não era fabricar interfaces interessantes. Era permitir uma decisão de gestão em menos de cinco minutos. Diante desse gate, "pouco funcional" era motivo suficiente para não preservar a ideia.

Essa distinção é pequena e brutal:

Se você não consegue nomear a incerteza, provavelmente está construindo uma apresentação. Ela pode gerar entusiasmo, opinião e mais trabalho. Aprendizado, não necessariamente.

Gridley resume isso com uma diferença que vale guardar: um protótipo demonstrado para stakeholders gera opiniões; um protótipo usado por pessoas de fora gera dados. A Whoop criou um grupo beta voluntário com 12 mil membros e passou a observar se as experiências mudavam comportamentos reais, em vez de perguntar qual demo parecia mais promissora.

Para uma empresa pequena, não são necessários 12 mil usuários. Às vezes o usuário real está na mesma sala. No nosso caso, a Olympus é o cliente zero do The Ideas Garden. O teste continua sendo real: o produto precisa atravessar os projetos vivos, encontrar divergências e ajudar a tomar uma decisão.

Aplauso interno não passa nesse gate.

O novo gargalo usa o seu cérebro

Esse problema não está restrito a produto.

A Smartsheet analisou 1,4 milhão de projetos empresariais e encontrou um aumento anual de 55% na intensidade de automação e de 46% na atividade. A produção cresceu, mas a camada de revisão não acompanhou. Oitenta por cento do conteúdo gerado por IA ainda era editado antes de ser finalizado.

A ferramenta acelera o começo. Pessoas continuam responsáveis pelo fim.

Isso explica por que tanta gente está produzindo mais e, ao mesmo tempo, sentindo que o trabalho ficou mais pesado. Há mais tarefas em movimento, mais alternativas plausíveis e mais entregas esperando pelas mesmas poucas pessoas capazes de dizer sim, não ou ainda não.

Quando gerar uma opção custava caro, a produção era o gargalo. Agora qualquer agente produz dez. A escassez mudou de lugar. Contexto, gosto e capacidade de encerrar escolhas passaram a valer mais.

A resposta não é impedir exploração. É parar de tratar toda exploração como candidata automática a produto.

Quatro linhas antes de abrir o editor

Se eu tivesse que transformar o aprendizado dessa rodada em uma regra operacional, usaria quatro linhas antes de qualquer novo protótipo:

PERGUNTA — Qual incerteza este protótipo existe para reduzir?

SINAL — O que alguém precisa fazer, ou deixar de fazer, para mudar nossa crença?

EXPOSIÇÃO — Quem precisa usar isto em um contexto real, em vez de apenas assistir à demo?

DECISÃO — O que vamos manter, mudar ou matar quando o sinal aparecer?

A ordem importa. Começar pela interface é confortável porque a IA responde na hora. Começar pela pergunta exige que você admita o que ainda não sabe.

No caso da divisória do The Ideas Garden, a decisão não foi "qual versão ficou mais bonita?". O critério era funcional: a estrutura aproximava ou afastava o produto de uma revisão clara e rápida? Quando a resposta ficou ruim, preservar o trabalho já feito seria mais caro do que apagar a ideia.

Protótipo não é progresso. É uma pergunta que ainda não foi respondida. Ele só vira progresso quando reduz uma incerteza e força uma decisão.

Isso também muda o que significa velocidade. Quantidade de telas, commits e demos mede produção. O ciclo completo mede outra coisa:

pergunta → protótipo → exposição → sinal → decisão

Se o trabalho para antes da decisão, você não acelerou o aprendizado. Só acumulou opções.

Sua missão para os próximos 7 dias

Pegue um protótipo que já está aberto agora. Não crie outro. Antes da próxima iteração, preencha:

PERGUNTA:  qual incerteza ele reduz?
SINAL:     qual comportamento importa?
EXPOSIÇÃO: quem vai usá-lo de verdade?
DECISÃO:   o que faremos com a resposta?

Depois coloque o protótipo diante dessa pessoa e observe. Não explique cada detalhe. Não defenda a solução. Procure o sinal que você escreveu.

Se você não consegue preencher as quatro linhas, a próxima tarefa não é melhorar a interface. É descobrir por que ela existe.

Conteúdos recomendados

• Drowning in Demos? Here’s a Better Way to Prototype, de Hilary Gridley — o caso da Whoop e a mudança de demos internas para experimentos orientados a comportamento.

• AI Is Making Work Denser, Not Lighter, da Smartsheet — dados sobre como automação aumenta produção antes de aumentar capacidade de decisão.

Forte abraço,
Equipe Olympus