Como usar entrevistas com clientes na estratégia de IA

Entrevistas com clientes sobre inteligência artificial funcionam melhor como reconstrução de episódios de trabalho. A conversa deve levantar tarefas reais, fricções, decisões, exceções e consequências antes de discutir qualquer solução.

Se você pergunta cedo demais se o cliente quer IA, recebe preferência por tecnologia. Se pergunta sobre o trabalho que trava, obtém evidências para decidir se IA, produto tradicional, integração ou processo merece investigação.

Comece pela cena de trabalho, não pela pergunta sobre IA

A primeira armadilha de uma pesquisa com clientes para IA é chegar com a solução vestida de pergunta. “Você usaria um assistente de IA para isso?” parece uma pergunta aberta, mas já empurra o cliente para imaginar uma tecnologia, uma interface e uma promessa de valor que talvez não tenham relação com o problema real.

O melhor ponto de partida é uma cena concreta de trabalho. Em vez de “como vocês analisam pedidos?”, pergunte “me conte a última vez em que um pedido demorou mais do que deveria para ser analisado”. A troca força a conversa a sair do processo ideal e entrar no episódio real.

Na primeira formulação, o cliente tende a descrever o processo ideal. Na segunda, ele reconstrói um episódio: quem participou, quais informações faltaram, onde procurou dados, qual sistema precisou abrir, que decisão estava em jogo, quem ficou esperando e o que aconteceu depois.

Essa reconstrução protege a entrevista de duas distorções comuns. A primeira é a resposta aspiracional: o cliente diz que quer modernizar, automatizar ou “usar IA” porque isso soa correto. A segunda é a resposta educada: ele concorda com a ideia apresentada para não frustrar quem pergunta.

Uma boa entrevista de descoberta de produto com IA deve fazer o caminho inverso. Primeiro, observar o trabalho. Depois, entender a fricção. Só então formular hipóteses de solução.

Essa ordem também combina melhor com uma visão responsável de estratégia. A apresentação do relatório DORA 2025 descreve a IA como amplificadora das forças e fraquezas existentes na organização e destaca a importância do sistema organizacional para o retorno do investimento. A implicação prática, para uma empresa de software, é simples: se você não entende o sistema de trabalho do cliente, pode amplificar o atrito errado.

Essa discussão se conecta ao tema mais amplo de como criar uma estratégia de inteligência artificial conectada ao negócio, mas aqui a decisão é mais específica: como conduzir a conversa sem induzir demanda por tecnologia.

Separe tarefa, fricção e solução antes da entrevista

Antes de entrevistar, defina três objetos diferentes de investigação: tarefa, fricção e solução.

Tarefa é o que o cliente precisa concluir. Pode ser aprovar uma solicitação, classificar uma ocorrência, preparar uma resposta, priorizar um chamado, revisar uma informação ou decidir o próximo passo de uma operação.

Fricção é o atrito que atrasa, encarece, aumenta risco, reduz qualidade ou concentra conhecimento em poucas pessoas. A fricção pode aparecer como retrabalho, espera, conferência manual, incerteza, dependência de especialista, troca excessiva de mensagens ou dificuldade de encontrar informação confiável.

Solução é uma forma possível de resolver. Pode envolver inteligência artificial, mas também pode ser uma regra de negócio mais clara, uma integração entre sistemas, uma melhoria de interface, documentação melhor, alteração de processo ou treinamento.

Misturar esses níveis é caro. Quando a entrevista começa por “queremos criar um copiloto para sua equipe”, a solução ocupa o centro da conversa. O cliente passa a opinar sobre o copiloto, não sobre a tarefa. Quando começa por “qual decisão sua equipe precisa tomar quando esse caso chega?”, a conversa produz material estratégico.

Uma frase útil para orientar a equipe antes das entrevistas é esta: IA não entra na pauta como resposta provável. Entra como hipótese posterior, concorrendo com alternativas mais simples.

Essa postura evita dois erros opostos. O primeiro é tratar toda fricção como oportunidade de IA. O segundo é descartar IA porque uma entrevista não trouxe entusiasmo explícito pela tecnologia. O cliente não precisa pedir IA para revelar uma tarefa em que interpretação, busca, classificação ou geração de rascunhos mereçam investigação.

Use perguntas que recuperam fatos, não preferências por tecnologia

Perguntas boas recuperam episódios. Perguntas fracas coletam preferências.

Evite abrir com:

“Você usaria IA para acelerar essa análise?”
“Um chatbot ajudaria sua equipe?”
“Quanto você pagaria por uma automação inteligente?”
“Você acha interessante ter um copiloto nessa etapa?”

Essas perguntas podem ter lugar mais tarde, quando houver protótipo, alternativa clara ou experimento desenhado. Na descoberta inicial, elas contaminam a conversa.

Prefira perguntas como:

“Me conte a última vez em que essa tarefa atrasou.”
“Que informação você precisou conferir manualmente?”
“Quais sistemas, documentos ou pessoas entraram no processo?”
“O que acontece quando a decisão sai errada?”
“Quem percebe primeiro que houve um problema?”
“Com que tipo de caso a equipe mais hesita?”
“Quando o trabalho vai bem, o que foi diferente?”

Essas perguntas não provam demanda por IA. Elas ajudam a formar hipóteses melhores.

A diferença é crítica. Entrevistas não são plebiscito sobre tecnologia. Elas são uma forma de reduzir incerteza sobre tarefas do cliente, fricções operacionais e consequências. A decisão sobre construir, comprar, integrar ou abandonar uma hipótese vem depois.

A atualização da METR sobre limites da medição de produtividade considera os novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades como seleção de participantes e tarefas, além de desafios para medir tempo com agentes concorrentes. Esse cuidado reforça um ponto de método deste artigo: não trate uma preferência declarada em entrevista como evidência suficiente de ganho operacional.

Se a entrevista sugere que uma tarefa parece promissora, o próximo passo é desenhar uma comparação pequena e mensurável, não prometer produtividade.

Identifique sinais de oportunidade para IA sem forçar automação

Depois das entrevistas, alguns padrões podem indicar que uma hipótese de IA merece investigação. Eles não obrigam a adoção de IA, mas ajudam a separar curiosidade tecnológica de oportunidade concreta.

Sinais favoráveis costumam aparecer quando a tarefa envolve:

interpretação de textos, mensagens, descrições ou documentos;
classificação de casos com critérios parcialmente subjetivos;
busca em conhecimento disperso;
comparação de alternativas com muitos elementos contextuais;
geração de rascunhos que serão revisados por alguém;
detecção de exceções em fluxos repetidos;
apoio a decisões recorrentes, com critérios conhecidos e revisão possível.

Mesmo nesses casos, automatizar tudo pode ser a resposta errada. Muitas oportunidades melhores começam como apoio ao julgamento humano: destacar trechos, sugerir prioridades, resumir contexto, apontar inconsistências ou preparar uma primeira versão.

Também existem sinais contrários. Como critério prático, IA tende a ser uma hipótese fraca quando a fricção vem de uma regra simples ainda não implementada, de falta de integração entre sistemas, de campos mal desenhados, de autorização lenta, de governança confusa ou de baixo volume de casos. Nesses cenários, um software tradicional ou uma mudança de processo pode resolver com menos risco.

Outro sinal de cautela é custo alto do erro sem revisão humana bem definida. Se uma recomendação errada pode afetar uma operação crítica, a pergunta não é apenas “o modelo acerta?”. A pergunta é: quem revisa, em que momento, com quais critérios e com qual informação disponível?

A revisão humana precisa aparecer no desenho do fluxo: ponto de revisão, responsável, critério e informação disponível.

Essa distinção também ajuda na priorização de portfólio. Um inventário de oportunidades, como o discutido em roadmap de IA, fica mais forte quando cada oportunidade nasce de uma tarefa observada e não de uma lista de tecnologias desejadas.

Registre evidências em linguagem de decisão

A entrevista perde valor quando as notas viram uma coleção de frases soltas. Para transformar conversa em estratégia de IA em software, registre cada achado em três campos separados: evidência observada, interpretação da equipe e hipótese de produto.

Exemplo fictício: uma empresa de software para operação de assistência técnica entrevista clientes sobre atrasos na priorização de chamados. Em vez de perguntar se eles querem IA para classificar tickets, a equipe pergunta sobre o último chamado que ficou parado mais tempo do que deveria.

A conversa revela que alguns atendentes precisam abrir histórico do equipamento, mensagens anteriores, contrato de suporte e comentários de campo antes de decidir se o caso deve subir de prioridade. Em alguns episódios, a dúvida não está na regra formal, mas na interpretação do contexto.

O registro poderia ficar assim, em linguagem simples:

Evidência: clientes relataram que a priorização de determinados chamados exige consultar histórico do equipamento, mensagens anteriores e observações de campo antes de decidir o próximo encaminhamento.
Interpretação: a fricção parece estar na reunião e interpretação de contexto, não apenas na falta de uma fila automatizada.
Hipótese: um recurso de triagem poderia reunir sinais relevantes e sugerir prioridade para revisão humana.
Alternativa sem IA: melhorar a tela do chamado, padronizar campos de entrada ou criar uma regra de escalonamento mais visível pode resolver parte do atrito.
Incerteza a medir: se a triagem reduz etapas manuais sem piorar a qualidade percebida por quem revisa.

Perceba o cuidado: o exemplo não afirma resultado. Ele formula uma hipótese a ser testada.

Esse formato impede que a equipe transforme entrevista em justificativa retroativa para uma ideia que já queria construir. Também ajuda a liderança a comparar oportunidades com menos ruído. Em vez de discutir “vamos ter IA no produto?”, a conversa passa a ser “qual fricção merece experimento e qual solução compete melhor?”.

Compare oportunidades por atrito, risco e capacidade de aprendizagem

Nem todo achado merece virar experimento. Depois de algumas entrevistas, a equipe precisa comparar oportunidades com critérios explícitos.

Um critério prático pode considerar:

Intensidade da fricção: o problema gera atraso, retrabalho, erro, espera ou custo de coordenação relevante?
Frequência da tarefa: a tarefa acontece com recorrência suficiente para justificar investigação?
Custo do erro: uma sugestão ruim causa incômodo leve, retrabalho moderado ou risco operacional significativo?
Dados e conhecimento de domínio: existem exemplos, documentos, critérios ou especialistas capazes de orientar a solução?
Facilidade de medir melhoria: é possível comparar tempo de triagem, etapas manuais, retrabalho, qualidade percebida por revisor ou exceções identificadas?
Necessidade de revisão humana: quem precisa validar a saída e em que ponto do fluxo?
Alternativa mais simples: regra de negócio, interface, integração ou processo resolveriam com menos complexidade?

Essa comparação obriga a equipe a escolher a incerteza inicial. A pergunta deixa de ser “qual ideia de IA parece mais atraente?” e passa a ser “qual incerteza vale testar primeiro?”.

A Microsoft Research descreve sua plataforma de experimentação como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos. A fonte não significa que todo feedback retreina automaticamente um modelo, nem que todo produto precisa de uma plataforma desse tipo. O ponto aplicável é outro: hipóteses precisam ser formuladas de modo que possam ser observadas, comparadas e revisadas.

Em IA, isso é ainda mais relevante porque uma demonstração pode parecer convincente sem resolver o trabalho real. Um resumo bonito, uma resposta fluida ou uma classificação aparentemente correta não bastam. O experimento precisa mostrar se a capacidade ajuda alguém a decidir, agir ou revisar melhor dentro do fluxo real.

Essa é uma diferença relevante em relação à maturidade. Uma empresa pode integrar modelos de terceiros em produtos maduros, desde que conheça a tarefa, desenhe revisão, cuide dos dados, meça efeitos e sustente a operação. Maturidade em IA não exige necessariamente modelo próprio. Exige capacidade de decidir onde a inteligência entra e onde não entra.

Para aprofundar o ponto de partida organizacional, vale conectar essa discussão ao diagnóstico de maturidade em IA.

Feche a entrevista sem vender a solução

O encerramento da entrevista também influencia a qualidade da pesquisa. Se a equipe fecha dizendo “então vamos construir uma IA para resolver isso”, o cliente pode sair achando que aprovou uma funcionalidade. Pior: pode ajustar respostas futuras para agradar a direção já sugerida.

Um fechamento melhor valida o entendimento sem vender a solução.

Você pode dizer algo como: “Quero confirmar se entendi. A tarefa é priorizar chamados com contexto incompleto. A fricção aparece quando a equipe precisa buscar histórico em lugares diferentes e decidir se o caso deve subir de prioridade. Ainda vamos comparar hipóteses, inclusive melhorias de processo e produto. Se possível, gostaríamos de analisar mais exemplos desse tipo de caso.”

Esse tipo de fechamento preserva confiança. O cliente entende que ajudou a explicar o trabalho, não que assumiu compromisso com uma tecnologia.

Também abre espaço para evidências adicionais: exemplos de entradas reais, telas, documentos, critérios de decisão, casos fáceis e difíceis, exceções, responsáveis e consequências. Quando esses materiais não puderem ser compartilhados, a equipe ainda pode pedir descrições mais precisas dos episódios.

A entrevista termina bem quando deixa três coisas claras: qual tarefa foi compreendida, qual fricção parece relevante e qual incerteza precisa ser investigada. A solução continua em aberto.

Roteiro de revisão para entrevistas sobre IA sem induzir demanda por tecnologia

Use este roteiro antes de montar as perguntas, durante a conversa e ao revisar as notas.

A pergunta começa pelo trabalho real? Troque perguntas sobre IA por perguntas sobre a última ocorrência da tarefa, os envolvidos, os insumos usados e a decisão tomada.
A fricção foi descrita como perda observável? Procure atraso, retrabalho, espera, erro, dependência de especialista, custo de coordenação ou incerteza. Evite aceitar “seria mais moderno” como evidência.
A equipe separou fato, interpretação e hipótese? Registre o que o cliente relatou, o que a equipe concluiu e qual hipótese de produto surgiu. Não misture os três campos.
Existe uma consequência clara quando a tarefa falha? Priorize tarefas em que erro, demora ou baixa qualidade afetam receita, operação, risco, experiência do usuário ou capacidade de escala.
A solução precisa mesmo de IA? Antes de propor inteligência artificial, verifique se regra de negócio, melhoria de interface, integração, documentação ou mudança de processo resolveria melhor.
Há como medir um experimento pequeno? Defina uma métrica de comparação antes de construir: tempo de triagem, taxa de retrabalho, qualidade percebida por revisor, número de exceções identificadas ou redução de etapas manuais.
O julgamento humano foi desenhado desde o início? Quando o custo do erro for relevante, defina quem revisa, quando revisa e com quais critérios. Não trate revisão humana como correção tardia.

Antes da próxima rodada, o produto da entrevista deve ser um mapa de tarefas, fricções e critérios de solução: quais tarefas serão investigadas, quais perguntas recuperarão episódios reais e quais critérios separarão IA de soluções mais simples.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

Para continuar esta leitura

Como registrar o aprendizado comercial de projetos de IA

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.