Times pulam discovery e fecham o escopo do primeiro sprint. Constroem a coisa errada em três semanas, e recuar três meses de código custa mais do que duas semanas de conversa com clientes.
Enquadrar o problema
Comece pela dor: escreva o problema em uma frase, com quem sofre, em que momento e qual prejuízo ele gera. Sem cliente nomeado e sem frequência, você tem palpite. Steve Blank e Bob Dorf descrevem o método em The Startup Owner's Manual (K&S Ranch, 2012): o time sai do prédio e testa a hipótese antes de construir.
Faça 12 a 15 entrevistas em duas semanas. Pergunte sobre o comportamento que a pessoa já vive hoje. Perguntar o que ela faria no futuro gera sim educado. Perguntar como resolve hoje e quanto gasta por mês gera dado.
Do problema para a primeira versão
Vire cada dor em hipótese: registre a hipótese, o sinal que a confirma e a data do teste. Marty Cagan trata discovery contínuo como trabalho permanente de produto em Inspired (Wiley, 2017). Engenharia entra nessa conversa para apontar o menor caminho possível.
Pare quando tiver clareza para escolher a menor versão que responde a pergunta. Eric Ries chama essa versão de MVP em The Lean Startup (Crown Business, 2011). Cada tela que não ajuda a responder sai da primeira entrega.
