O modelo tradicional de discovery é pontual: no início de um projeto, você faz uma rodada de pesquisa, gera insights, e esses insights guiam o desenvolvimento por meses. O problema é que o usuário muda, o mercado muda, e o contexto que gerou aqueles insights pode não ser mais válido quando a feature finalmente chega.
Continuous Discovery, termo popularizado por Teresa Torres, é uma prática diferente: manter contato regular e sistemático com usuários de forma que o aprendizado aconteça continuamente, não pontualmente.
O princípio central
A ideia principal é simples: pelo menos uma conversa com um cliente ou usuário por semana, todo time de produto. Não precisa ser uma entrevista formal. Pode ser uma conversa de 20 minutos por videochamada. O que importa é a cadência e a consistência.
Times que conversam com usuários toda semana têm uma relação diferente com o problema que estão resolvendo. As decisões de priorização são mais bem fundamentadas. Os debates internos sobre o que o usuário quer têm menos achismo e mais dado. Para entender como conduzir essas conversas de forma eficaz, veja o guia sobre como conduzir entrevistas com usuários.
Como implementar a cadência
O maior obstáculo para continuous discovery não é falta de vontade — é logística. Recrutar usuários toda semana é trabalhoso. A solução é criar uma automação de recrutamento: um processo onde usuários que se encaixam no perfil são automaticamente convidados para uma conversa semanal.
Ferramentas como Calendly com formulário de triagem, integração com o produto (popup para usuários que completaram determinada ação), ou mesmo uma lista de usuários dispostos a conversar regularmente são formas práticas de garantir que o recrutamento não seja o gargalo.
Quem participa das conversas
No Continuous Discovery, o ideal é que PM, designer e tech lead participem das conversas — não só o PM. Quando todo o time de trio (PM, design, engenharia) está em contato direto com usuários, as decisões de discovery têm mais adesão: não é o PM dizendo o que o usuário quer, é o time inteiro que ouviu diretamente.
O que fazer com o que você aprende
O risco do Continuous Discovery é coletar muito dado sem sintetizar. Para evitar isso, Teresa Torres propõe uma estrutura chamada Opportunity Solution Tree: uma árvore que começa com o outcome desejado (a North Star Metric ou o OKR do período), mapeia as oportunidades identificadas nas conversas com usuários, e conecta soluções às oportunidades.
A síntese semanal não precisa ser formal. Pode ser uma nota compartilhada no Slack com os dois ou três insights mais relevantes da conversa. O que importa é que o aprendizado flua para o time, não fique só na cabeça do PM que fez a entrevista.
Continuous Discovery e backlog
O backlog de discovery — as hipóteses e oportunidades que estão sendo investigadas — deve refletir o que está sendo aprendido nas conversas. Quando uma conversa revela uma oportunidade nova, ela entra no backlog de discovery para ser explorada. Quando uma hipótese é confirmada ou refutada, ela sai.
Isso significa que o backlog de discovery nunca está "pronto". É um artefato vivo que muda conforme o time aprende. Para entender como discovery alimenta o delivery, veja o artigo sobre discovery e delivery em produto.
Começando de onde você está
Se seu time não tem nenhuma cadência de discovery hoje, não tente implementar tudo de uma vez. Comece com uma conversa de usuário por semana. Uma. Faça isso por quatro semanas e observe o que muda na forma como o time conversa sobre problemas. A cadência começa a criar cultura antes de qualquer processo formal.
