Roteiro de entrevistas de discovery: 12 perguntas que validam mercado antes de uma linha de código

A qualidade da entrevista depende mais de quem você convida do que da quantidade de perguntas. O erro mais comum é entrevistar apenas pessoas simpáticas à ideia, porque isso gera validação falsa. Em discovery sério, você precisa misturar perfis que vivem a dor, influenciam a compra e sofrem as consequências da solução, mesmo quando não são os decisores finais. Em B2B, a composição mais útil costuma incluir três camadas. Primeiro, usuários que executam a tarefa no dia a dia. Depois, gestores que aprovam fluxo, orçamento ou operação. Por fim, decisores ou influenciadores que definem prioridade, risco e contratação. Em saúde, indústria, fintech e govtech, essa combinação costuma revelar diferenças importantes entre dor percebida e dor que realmente gera orçamento. Se você está escolhendo entre montar discovery interno, contratar um parceiro ou acelerar com equipe alocada, a lógica muda pouco: a pergunta central continua sendo quem tem informação suficiente para dizer se o problema existe e se a solução faz sentido. Nosso artigo sobre como decidir entre consultoria UX externa, equipe interna ou alocação aprofunda esse trade-off. Já o mapeamento da jornada do usuário corporativo ajuda a identificar os papéis certos para entrevistar em empresas complexas. Uma regra prática que funciona bem: não pare no “usuário ideal”. Inclua pelo menos uma pessoa cética, uma pessoa que opera sob restrição e uma pessoa que compara sua solução com alternativas internas ou concorrentes. É aí que aparecem os sinais de adoção real, orçamento disponível e risco de rejeição.

Um erro comum em discovery é entrevistar até a confiança virar paralisia. A entrevista é um meio de reduzir incerteza, não de eliminá-la completamente. Em produto, sempre haverá risco. A questão é saber se o risco já caiu o suficiente para o próximo experimento. Você pode parar a rodada inicial quando começar a ver repetição consistente nas respostas. Em geral, isso acontece quando os principais padrões se repetem entre perfis diferentes. Se três a cinco entrevistas bem escolhidas já mostram a mesma dor, o mesmo contexto e as mesmas objeções, muitas vezes já existe sinal suficiente para avançar para protótipo ou teste de conceito. Outra condição importante é a clareza da hipótese. Se você já sabe qual problema quer resolver, para quem, com que resultado e sob quais restrições, o próximo passo não é mais conversar indefinidamente. É criar uma representação simples da solução, como um fluxo, um mockup ou um protótipo funcional, e testar reação real. Para essa etapa, o conteúdo sobre Consultoria UX para MVP com IA e o guia decisional de validação de MVP com IA, AR/VR ou IoT ajuda a escolher a forma certa de validação. Em projetos enterprise, prototipar cedo evita um segundo tipo de desperdício: discutir arquitetura antes de provar valor. Se o mercado ainda está fraco, talvez nem exista motivo para decidir entre nuvem, legado, API ou automação. Quando a dor é válida e o problema está claro, aí sim faz sentido avançar para a próxima camada de decisão.

Em um cenário B2B de operações internas, uma equipe pode descobrir que o problema não é “falta de sistema”, mas a dependência de aprovações manuais entre áreas. Nesse caso, a entrevista pode revelar que a dor real está no tempo de espera, não no número de telas. A solução tende a ser um fluxo mais inteligente, com regras, automação parcial e integrações, e não um produto genérico cheio de funcionalidades. Na saúde, entrevistas frequentemente mostram que a urgência nasce de risco operacional e rastreabilidade. O usuário quer menos erro, menos retrabalho e mais segurança, mas o decisor precisa confiar em compliance, auditoria e governança. Por isso, um bom roteiro de discovery deve capturar não só a dor clínica ou administrativa, mas também as restrições de implantação e evidências de confiabilidade. Na indústria, a entrevista costuma revelar que a dor é distribuída entre chão de fábrica, supervisão e engenharia. Um operador pode reclamar de lentidão, enquanto o gestor enxerga perda de produtividade e o time técnico fala em integração com sensores ou IoT. Esse tipo de leitura é importante porque mostra se a solução deve ser um software sob medida, uma automação com IA, uma experiência imersiva para treinamento ou até uma combinação de tudo isso. Quando a empresa já opera com grande complexidade, o discovery precisa conversar com a arquitetura de produto, não só com a interface. É aí que uma equipe experiente como a OrbeSoft costuma entrar com mais profundidade: antes de propor código, mapeia mercado, jornada, restrições e valor. Esse tipo de disciplina ajuda a evitar o clássico erro de construir uma solução tecnicamente elegante para um problema comercial fraco.