Como conduzir Product Discovery em produtos de IA

Em projetos de inteligência artificial, é comum a conversa começar pela solução: “Vamos criar um chatbot”, “Podemos usar um agente de IA?” ou “Qual LLM devemos escolher?”. O problema é que a tecnologia costuma entrar na discussão antes mesmo de entendermos o que precisa ser resolvido.

Product Discovery em produtos de IA continua tendo a mesma essência: compreender pessoas, problemas e oportunidades antes de decidir o que construir. Mas acrescenta desafios próprios. Precisamos investigar a qualidade dos dados, as incertezas das respostas, os riscos de automação, a confiança do usuário e o custo para manter a solução funcionando.

O primeiro passo não é escolher um modelo. É descobrir se existe um problema relevante e se a IA realmente é uma boa forma de resolvê-lo.

1. Comece pelo problema, não pela tecnologia

Converse com quem vive o problema. Em vez de perguntar “Você usaria um assistente de IA?”, pergunte sobre a última vez em que a pessoa tentou realizar aquela tarefa. O que ela precisava fazer? Onde perdeu tempo? Que decisões tomou? O que aconteceu quando algo deu errado?

Observe o processo atual, identifique tarefas repetitivas e separe sintomas de causas. Registre quem é afetado, a frequência, o impacto e as alternativas utilizadas hoje.

Ao final, a equipe deve conseguir descrever o problema em uma frase que não mencione IA. Se a definição só faz sentido quando inclui “chatbot”, provavelmente ainda estamos discutindo solução.

2. Questione se a IA é necessária

Nem todo problema precisa de IA generativa. Um formulário bem desenhado, uma regra de negócio ou uma busca convencional podem resolver a necessidade com menos custo e mais previsibilidade.

Avalie as alternativas:

• Quando há regras fixas e resultados determinísticos, automação tradicional costuma ser suficiente.
• Quando é necessário interpretar linguagem natural, resumir conteúdos ou lidar com informações menos estruturadas, a IA pode gerar valor.
• Quando a resposta depende de conhecimento institucional, talvez seja necessário RAG.
• Quando o sistema precisa agir em ferramentas, entram questões adicionais de permissões e supervisão em agentes.

A pergunta certa não é “dá para fazer com IA?”, mas “usar IA melhora o resultado o bastante para justificar sua complexidade?”.

3. Transforme a oportunidade em hipóteses testáveis

Antes de desenhar o MVP, formule hipóteses sobre quatro dimensões: valor para a pessoa usuária, possibilidade técnica, viabilidade econômica e confiança e risco.

Exemplo de hipótese: “Se oferecermos respostas apoiadas em uma base de conhecimento validada, pessoas que hoje consultam documentos e dependem de atendimento humano poderão resolver dúvidas recorrentes com menos esforço, sem aumento de respostas incorretas.”

Isso permite escolher indicadores de impacto: tempo para concluir a tarefa, retrabalho, resolução sem intervenção, satisfação, custo por atendimento e taxa de encaminhamento humano. Defina a linha de base e os limites aceitáveis de erro antes de testar. Metas não devem ser inventadas nem copiadas de outro produto.

4. Mapeie a jornada, os dados e os momentos de intervenção humana

Em produtos de IA, a jornada precisa contemplar tanto o caminho ideal quanto as exceções: o que o sistema recebe, que informações consulta, de onde vêm os dados, quem pode acessá-los, o que faz quando encontra documentos contraditórios e quando deve responder “não sei” ou transferir para uma pessoa.

O Discovery também deve investigar a qualidade, a atualização e a legitimidade de uso dos dados. Um protótipo pode parecer excelente com documentos selecionados e falhar quando encontra conteúdos desatualizados, permissões inadequadas ou perguntas ambíguas.

Pense também em transparência: o usuário entende que está interagindo com IA? Consegue corrigir informações? Sabe quando a resposta é apenas uma sugestão?

5. Prototipe a experiência antes de construir a arquitetura inteira

É possível testar parte do valor com um protótipo simples, um fluxo simulado ou um atendimento apoiado por uma pessoa nos bastidores. Isso ajuda a descobrir o que as pessoas realmente precisam antes de investir em uma arquitetura complexa.

Valide principalmente o fluxo completo: o usuário consegue formular seu pedido? A resposta ajuda a tomar uma decisão ou concluir uma tarefa? A pessoa identifica erros? Sabe como pedir ajuda?

Teste com situações reais, devidamente anonimizadas ou autorizadas. Uma demonstração bonita não é evidência suficiente de valor.

6. Faça Discovery também da qualidade da IA

Uma diferença importante dos produtos com LLMs é que a mesma entrada pode produzir respostas diferentes. Por isso, “parece que funcionou” não é critério de sucesso.

Construa um pequeno conjunto de casos representativos da operação, incluindo perguntas comuns, exceções, ambiguidades, temas fora do escopo e situações em que o correto é não responder. Especialistas do domínio devem ajudar a definir o que caracteriza uma boa resposta.

Avalie dimensões separadas: utilidade da resposta, correção factual, completude, uso das fontes, segurança, latência e custo. Se houver RAG, avalie também se a informação certa foi recuperada antes de julgar o texto gerado. Esse cuidado é detalhado em RAG não é um chatbot que lê PDF.

Os critérios de aceite para respostas de IA precisam cobrir o comportamento esperado e os modos de falha. É melhor descobrir cedo que o sistema responde com confiança quando não sabe do que perceber isso depois do lançamento.

7. Defina um MVP pequeno e mensurável

Um MVP de IA não precisa responder a tudo. Comece por uma tarefa frequente, bem delimitada e com dados confiáveis. Deixe claros os assuntos que o produto atende, os que não atende e as condições de encaminhamento humano.

Exemplo ilustrativo: em vez de lançar um assistente que promete resolver qualquer solicitação de uma instituição de ensino, comece com um conjunto específico de dúvidas recorrentes, observe o uso, acompanhe a qualidade e amplie o escopo quando houver evidências.

O objetivo do MVP é aprender com segurança, não impressionar pela quantidade de funcionalidades.

8. Continue o Discovery depois da primeira entrega

Depois de colocar o produto em uso, acompanhe o que as pessoas realmente fazem. Quais perguntas se repetem? Onde abandonam a jornada? Que respostas são corrigidas por humanos? Quando o custo cresce sem aumento proporcional de valor?

Combine conversas frequentes com usuários, observação, avaliações contínuas e dados de operação. Faça novas hipóteses. Ajuste conhecimento, experiência, fluxos e limites da automação. Discovery em IA não termina quando o modelo está integrado.

Conclusão

Conduzir Product Discovery em produtos de IA não é acrescentar uma etapa de prompt engineering ao processo de produto. É investigar, ao mesmo tempo, o valor que queremos entregar e as condições para que a inteligência artificial entregue esse valor de forma confiável.

Um bom Discovery pode terminar com a decisão de construir um produto de IA. Mas também pode mostrar que uma solução mais simples é melhor. Nos dois casos, cumpriu seu papel: ajudar a equipe a investir no problema certo.