Entrevista com usuário parece simples. Você faz perguntas, a pessoa responde, você aprende. Na prática, a maioria das entrevistas gera um conjunto de opiniões do usuário sobre funcionalidades que você já pensou em construir — o que é quase inútil para tomar decisões de produto.

O problema é quase sempre como a entrevista é conduzida, não quem está sendo entrevistado.

O objetivo de uma entrevista com usuário

Entrevista com usuário não serve para validar se uma solução é boa. Serve para entender o problema que o usuário tem — na vida real dele, com o contexto real dele, e com as soluções que ele já usa hoje (mesmo que precárias).

Quando você mostra um protótipo e pergunta "o que você acha?", está recebendo opinião sobre sua solução. Isso tem valor limitado porque usuários são péssimos em prever seu próprio comportamento futuro. O que eles fazem de verdade hoje é muito mais informativo.

Como recrutar participantes

O maior obstáculo para fazer entrevistas é conseguir pessoas para entrevistar. E a solução mais simples é a que menos gente usa: perguntar diretamente.

Para produtos existentes: uma mensagem no app perguntando se alguém toparia uma conversa de 30 minutos com o time de produto geralmente tem taxa de resposta surpreendentemente alta, especialmente entre usuários que já tiveram algum problema recente.

Para produtos em construção: sua rede pessoal, grupos de profissionais da área que você está servindo, e comunidades online. Cinco entrevistas com pessoas que representam seu usuário-alvo são suficientes para um ciclo inicial de discovery. Você não precisa de 50.

Quem entrevistar

Entrevistar usuários satisfeitos te diz o que está funcionando. Entrevistar usuários que pararam de usar te diz o que está quebrando. Para discovery de problema novo, entrevistar pessoas que têm o problema que você quer resolver — mesmo que não usem seu produto ainda — é mais valioso do que entrevistar quem já está na sua base.

As perguntas que funcionam

Perguntas sobre comportamento passado são mais confiáveis do que perguntas sobre intenção futura. "Me conta a última vez que você precisou fazer X. O que aconteceu?" produz dados mais úteis do que "você usaria um produto que fizesse X?"

Perguntas abertas produzem mais do que perguntas fechadas. "Como você faz Y hoje?" produz narrativa. "Você usa Y?" produz sim ou não.

Perguntas de contexto antes de entrar no problema específico. Entender a rotina, os objetivos, as ferramentas que a pessoa já usa cria um contexto que torna tudo que vem depois mais interpretável.

Perguntas para evitar

"Você gostaria de uma funcionalidade que fizesse X?" Usuários dizem sim para quase tudo — e não constroem o que você está perguntando depois. Essa é a pergunta que cria roadmap inflado de features que ninguém usa.

"O que você acha do nosso produto?" genérico demais para gerar aprendizado específico.

"Você não acha que seria melhor se...?" Pergunta indutora que sinaliza qual resposta você quer ouvir.

Como escutar sem influenciar

Silêncio é ferramenta. Quando o usuário para de falar, a tendência é preencher o silêncio com uma pergunta nova. Espere. Frequentemente a pessoa vai continuar — e o que ela diz na segunda parte costuma ser mais revelador do que o que disse na primeira.

Quando ouvir algo que confirma uma hipótese sua, não demonstre entusiasmo. "Interessante, pode me contar mais?" é neutro. "Ah, então você também sente que X é um problema?" está induzindo confirmação.

Tome notas de comportamento e falas diretas, não de interpretações. "Disse que demora 20 minutos para completar essa tarefa toda semana" é um dado. "Parece frustrado com o processo" é interpretação — pode ser verdade, mas anote separado.

O que fazer com o que ouviu

Entrevista sem síntese é conversa sem aprendizado. Logo depois da entrevista — não no dia seguinte, logo depois — escreva os pontos principais: o que a pessoa faz hoje, quais são os pontos de atrito, quais soluções já usa, e o que te surpreendeu.

Depois de cinco entrevistas, procure padrões. O que apareceu em três ou mais conversas? O que apareceu uma vez mas foi tão específico e concreto que parece importante? O que você esperava ouvir e não ouviu?

De entrevista para decisão

A síntese das entrevistas precisa conectar com as decisões que você está tentando tomar. "Cinco de seis entrevistados descreveram o mesmo ponto de atrito no fluxo de relatório, e dois mostraram workarounds em planilhas externas" é síntese que conecta diretamente à pergunta de priorização.

Entrevista com usuário que não informa uma decisão real foi um exercício interessante sem retorno de investimento. Antes de cada rodada de entrevistas, escreva: que decisão estou tentando tomar, e como os dados dessa entrevista vão informar essa decisão? Se você não consegue responder, talvez não seja o momento certo para fazer entrevistas.

O dado qualitativo da entrevista deve sempre ser lido junto com o dado quantitativo. Para entender como usar dados para decisões de produto e como combinar o que você ouviu com o que os números mostram, veja o guia completo sobre dados em produto. E para saber quais métricas de produto acompanhar antes de definir o foco da próxima rodada de entrevistas, veja o guia de métricas.

Entrevistas com usuários são uma das técnicas centrais do discovery — mas não são a única. Para entender como encaixar entrevistas num ciclo de discovery mais amplo, quais outras técnicas usar e como saber se o discovery está gerando aprendizado real, veja o guia sobre como fazer discovery de produto que muda o que você constrói.

Na comunidade mágica, temos sessões de prática de entrevista com usuário — onde você conduz, recebe feedback e melhora o músculo em ambiente seguro antes de usar no trabalho.