Como fazer um spike de produto em uma tarde

Dá para fazer um spike de produto em uma tarde se você testar uma única hipótese, montar só a tela onde ela mora e colocar na frente de cinco pessoas no mesmo dia. O segredo não é a velocidade, é a disciplina de deixar coisa de fora.

O que é spike e o que não é

Spike é um experimento com tempo definido para responder uma pergunta só, de modo que o time pare de chutar. Só isso. Ele entrega aprendizado, não funcionalidade. O código pode ser feio e quase sempre vai para o lixo.

O erro acontece em duas direções. Tem PO que faz uma versão pequena do projeto de verdade, com login, tela de configuração e estado vazio bonitinho. Isso é a primeira sprint fantasiada de spike. E tem quem faça uma reunião com slides. Slide mostra o que a pessoa diz que faria. Spike mostra o que ela faz quando tem a coisa na mão.

Escolha uma hipótese só

Pegue a crença que, se estiver errada, deixa o resto do plano sem sentido. Escreva numa frase que possa se provar falsa. As boas têm uma pessoa, uma ação e uma condição.

• Boa: o responsável pela clínica sobe a planilha de convênios dele sem a gente precisar limpar antes.
• Boa: o cliente que vê uma estimativa de preço antes de agendar continua agendando.
• Ruim: melhorar o onboarding. Não há nada ali que possa falhar.
• Ruim: os usuários vão amar o dashboard. Amor não é um evento observável.
• Ruim: o sistema aguenta dez mil linhas. Isso é pergunta técnica, outro tipo de spike.

Se você tem três hipóteses, tem três spikes. Comece pela mais assustadora. As outras duas podem perder importância quando ela falhar.

Escreva o critério de morte antes de construir

Defina agora qual resultado encerra a ideia. Coloque um número e anote num lugar onde você não consiga editar escondido depois. No caso da planilha: se menos de três das cinco pessoas chegarem à tela de confirmação sem ajuda, a ideia, do jeito que está, morreu.

Por que isso importa? Porque depois de construir você se apega. Sem uma linha traçada antes, duas pessoas que terminaram viram 'promissor' e uma que terminou vira 'bom sinal'. Todo resultado vira vitória. O critério de morte é o que mantém você honesto com aquela versão de você que já gastou três horas nisso.

Spike que não pode falhar é só demonstração.

Construa o mínimo

Descreva só a tela onde a hipótese vive. Num construtor de apps com IA, como o StarBuild, isso é um chat, e a primeira mensagem pode ser assim: crie uma página onde o visitante sobe um CSV de convênios; depois do envio, mostre uma tabela com as linhas que entendemos e uma lista em vermelho com as que não entendemos; grave cada tentativa numa tabela do banco com horário, nome do arquivo e se a pessoa apertou Confirmar.

Repare no que está no pedido: o upload, o resultado ao qual a pessoa precisa reagir e o registro do que ela fez. O registro é o objetivo de tudo, porque é a sua evidência.

Agora o que ficou de fora, de propósito. Sem login, porque cinco pessoas vão usar um link uma vez. Sem tela de configuração. Sem e-mail. Sem se preocupar com layout de celular. Sem lógica de verdade de conciliação se uma versão tosca já deixa a tela crível. Se o participante perguntar do que você pulou, isso é achado, não bug. Anota e segue.

Recrute cinco pessoas rápido

Cinco bastam para enxergar os problemas grandes e, de qualquer jeito, é o que se consegue recrutar numa tarde. Têm que parecer com o cliente, não com o seu time. Alguém do comercial que nunca viu o produto serve mais do que o dev que estava no refinamento.

Comece mandando mensagem para quem você já conhece: 'tô testando uma ideia, leva dez minutos, não precisa se preparar, quero sua confusão sincera mais do que sua opinião.' Chame clientes atuais, conhecidos do time no perfil certo, ou quem responder a um post curto numa comunidade onde seus usuários estão. Ofereça um café ou um favor em troca. Feche os horários antes de terminar de construir, assim você não consegue empurrar o prazo.

Rode as sessões e olhe o que importa

Publique o link, peça para compartilhar a tela se for remoto e dê uma única tarefa: 'você recebeu essa planilha do convênio, coloca na ferramenta.' Depois cale a boca. Essa é a parte difícil para quem é PO. Não explique, não salve a pessoa, não diga 'ah, é ali que clica'.

• Por onde o mouse passeia antes do primeiro clique. Ali a tela está confusa.
• As pausas longas. O silêncio de quem hesita é o melhor dado da sessão.
• O que a pessoa fala em voz alta quando se perde, nas palavras dela e não nas suas.
• Se ela termina a tarefa e de quantas dicas precisou.
• Qualquer coisa que ela tente fazer e que você não construiu. Ela está te mostrando o fluxo real.

Anote fatos crus: 'ficou oito segundos parada no campo de arquivo', 'tentou arrastar o arquivo para a tabela'. Interpretação fica para depois. No final, faça uma pergunta aberta, como o que ela esperava que acontecesse em seguida, e registre a resposta palavra por palavra.

Decida e documente

Compare os resultados com a linha que você traçou. Passou, falhou ou nenhum dos dois. Faça isso na mesma noite, enquanto lembra das pausas. Depois escreva uma nota no item do backlog: a hipótese, o que foi construído, o que aconteceu com cada uma das cinco pessoas e a decisão. Três frases bastam, desde que sejam específicas.

Se passou, você tem motivo para refinar a história com calma, e o protótipo mostra ao time como a tela principal deve ser sentida. Se falhou, poupou uma ou duas sprints, que é todo o valor do exercício. Arquive o protótipo. Se o construtor deixar exportar o código para o Git, guarde num lugar que o time ache, mas não deixe ninguém publicar aquilo só porque existe.

Quando o resultado é ambíguo

Acontece muito. Duas de cinco terminam, bem entre a sua linha de morte e a sua esperança. Não faça média e chame de sim. Primeiro verifique se o problema foi o protótipo: a falha veio da hipótese ou de um rótulo confuso que você corrige em dez minutos? Se foi o rótulo, corrija e rode mais três pessoas na mesma noite ou na manhã seguinte.

Se as falhas foram reais mas variadas, quebre a hipótese. Talvez ela se sustente para quem tem dado organizado e falhe para quem não tem, e isso já é decisão de segmento, não resultado de spike. E se mesmo assim você não souber dizer, o resultado honesto é 'não provado, e isto é o que precisaríamos ver'. Registrar isso é um ótimo spike. Fingir que aprendeu mais do que aprendeu é o único ruim.