Quase toda ideia chega como uma solução: um botão novo, uma tela a mais, uma notificação. Antes de colocar qualquer uma delas no backlog, eu reescrevo a ideia como uma hipótese.
O modelo
Uso sempre a mesma frase:
Acreditamos que [mudança] para [quem] vai resultar em [comportamento]. Saberemos que deu certo quando [métrica] chegar a [valor] em [prazo].
Se não consigo preencher algum dos campos, a ideia ainda não está pronta para ser priorizada. Normalmente o campo que falta é o da métrica.
Por que funciona
A frase obriga a conversa a sair da solução e ir para o resultado. Quando alguém propõe “colocar um tutorial no primeiro acesso”, a pergunta deixa de ser se o tutorial é bom e passa a ser qual comportamento queremos mudar e quanto.
Também facilita comparar ideias diferentes. Duas propostas que mexem na mesma métrica podem ser avaliadas lado a lado, com o mesmo critério.
Um exemplo
Em um app de finanças, a ideia era pedir menos dados no cadastro. A hipótese ficou assim:
Acreditamos que pedir o comprovante de renda só depois do primeiro uso, para quem está se cadastrando pelo celular, vai resultar em mais cadastros concluídos. Saberemos que deu certo quando a conclusão do cadastro subir de 41% para 55% em quatro semanas.
Com isso, o time sabia o que medir desde o primeiro dia, e a revisão depois da entrega levou quinze minutos.
O que eu faço depois
- Registro a hipótese no próprio item do backlog.
- Combino com o time onde o dado vai aparecer antes de começar a construir.
- Marco na agenda a data de revisão, mesmo que o resultado ainda pareça óbvio.
Quando o número não se mexe, a hipótese escrita ajuda a entender o que estava errado: a mudança, o público ou a expectativa.