Foto: Brands&People / Unsplash
Livros
O que 'Sprint', de Jake Knapp, ensina sobre um problema grande poder ser testado em cinco dias, com mapa, esboços, decisão, protótipo e cinco usuários
Pedro Toledo · 3 de novembro de 2026 · 3 min de leitura
'Sprint', de Jake Knapp, com John Zeratsky e Braden Kowitz, argumenta que um problema grande ou uma ideia nova pode ser testado em cinco dias, com um time pequeno e um roteiro fixo — mapear o problema, esboçar soluções, decidir, construir um protótipo e testá-lo com usuários reais —, antes de a empresa gastar meses construindo algo que ninguém quer. Por que construir primeiro parecer o caminho natural, o que caracteriza o roteiro que o livro descreve, e como aplicar a ideia sem copiar o formato inteiro.
Construir primeiro e testar depois costuma parecer o caminho natural pra quem acredita numa ideia. Jake Knapp, em "Sprint", argumenta que o caminho mais barato é testar a ideia em cinco dias, antes de gastar meses construindo.
O livro argumenta que um problema grande ou uma ideia nova pode ser testado em cinco dias, com um time pequeno e um roteiro fixo, que vai do mapa do problema ao teste de um protótipo com usuários reais.
Por que construir primeiro parece o caminho natural
A equipe acredita na ideia, e o produto pronto parece a forma mais completa de testá-la. A construção, porém, consome meses antes de qualquer cliente real reagir, e o livro argumenta que o aprendizado mais valioso vem de colocar um protótipo diante de pessoas o mais cedo possível, quando mudar de direção ainda é barato.
O que caracteriza o roteiro que o livro descreve
O roteiro tem cinco dias, com uma tarefa por dia, e termina com um teste com cinco usuários. Isso tem relação direta com o que "A Startup Enxuta" acerta, e o que exagera, sobre validar uma ideia — os dois livros convergem na mesma ideia central de que o aprendizado com o cliente deve vir antes do investimento pesado, seja por um ciclo curto de construir, medir e aprender, seja por um sprint que testa um protótipo em uma semana.
Os cinco dias e o time
Segundo os resumos, o sprint começa mapeando o problema, esboça soluções, decide qual testar, constrói um protótipo e o testa com cinco usuários do público-alvo. O livro recomenda um time de sete pessoas, e há uma variante em quatro dias, o Design Sprint 2.0. As buscas que fiz não trouxeram críticas ao método, e é razoável supor que ele exige a dedicação da equipe durante a semana e que cinco testes não substituem dados em escala — ressalvas minhas.
Como aplicar sem copiar o formato inteiro
A forma prática é pegar o princípio: escolher uma pergunta central, fixar um prazo curto, decidir quem decide, construir só o suficiente pra parecer real e testar com poucas pessoas. Mesmo sem uma semana inteira, é possível testar uma oferta com uma página simples e algumas conversas antes de investir no produto completo.
Um exemplo prático
Uma agência quer lançar um serviço de relatórios automáticos, e a equipe pensa em passar três meses construindo a ferramenta. Em vez disso, ela reserva uma semana: mapeia o problema na segunda, esboça telas na terça, escolhe uma na quarta, monta um protótipo clicável na quinta e o mostra a cinco clientes na sexta. Três deles dizem que pagariam, e dois apontam uma informação que a equipe não tinha considerado.
O ponto central do livro
"Sprint" argumenta que uma ideia pode ser testada em cinco dias, antes de ser construída em meses. Antes de começar o desenvolvimento, vale perguntar o que dá pra mostrar a cinco clientes esta semana.
