Conectar a IA ao contexto do produto (sem vazar nada)
O contexto do produto mora em três lugares diferentes, o backlog, o analytics e a pesquisa, e cada um pede um caminho técnico distinto. Conectar errado embaralha os três; conectar sem checagem de segurança vaza dado de usuário real.
Você pergunta pra IA por que a ativação da sua feature nova está baixa, esperando que ela cruze o board de bugs reportados com o funil de analytics e com o que os usuários disseram na última pesquisa. Ela devolve uma resposta segura, mas embaralhou tudo: tratou o board como se fosse texto pra buscar por significado, o funil como se precisasse de busca semântica, e a transcrição da pesquisa como planilha. O motivo real da baixa ativação estava numa frase específica de uma entrevista, que ela nunca leu como texto de verdade.
Você pergunta para a IA qual foi a sua margem de contribuição no último trimestre. Ela responde com uma análise impecável, cheia de termo bonito de finanças. E inventada. A IA nunca abriu o seu ERP nem o seu fechamento, então ela chuta um número plausível.
Você pede para a IA revisar a cláusula de multa de um contrato de prestação de serviço. Ela devolve "a multa de dois por cento está dentro do limite legal", segura, redonda, pronta para o cliente. O limite do seu caso era outro, a IA chutou o número e ninguém conferiu na fonte.
Você pede pra IA dizer qual campanha teve o melhor ROI, cruzando o painel de mídia paga, que é estruturado, com as respostas da pesquisa de marca, que é texto corrido. Ela devolve um número bonito, mas tratou o painel como texto pra buscar por significado e a pesquisa como planilha, perdendo o padrão real que só aparecia nas respostas abertas.
Você pede pra IA cruzar o índice de turnover, que mora estruturado no sistema de folha, com a política de desligamento, que é texto corrido em PDF. Ela devolve uma resposta com jargão de gestão de pessoas, mas tratou a política como se fosse planilha e a folha como se precisasse de busca por significado.
Você quer entender por que a ativação da feature nova está abaixo do esperado, e pede pra IA cruzar três fontes numa tacada só: o board de tickets no Linear, o funil de ativação no Amplitude e as transcrições da última rodada de entrevista no Dovetail. Ela devolve uma resposta segura e bem escrita, mas embaralhou as três: tratou o funil estruturado como se precisasse de busca semântica, tratou o board de tickets como texto solto perdendo o status e o label de cada um, e tratou a transcrição da entrevista, texto corrido cheio de nuance, como se fosse uma planilha de números. O motivo real da baixa ativação estava numa frase específica que uma usuária disse na entrevista, "eu não sabia que existia esse botão", e a IA nunca chegou perto de ler aquilo como texto de verdade. Formato errado, causa raiz errada: funil pede raciocínio sobre schema, backlog pede leitura estruturada de ticket, entrevista pede busca por significado.
Você pede pra IA explicar onde o pipeline mais trava, cruzando o export do CRM, que é linha e coluna, com o relatório de win-loss em PDF que o time de vendas monta todo trimestre. Ela devolve uma resposta de consultor, mas tratou o CRM como texto pra buscar por significado e o PDF como planilha simples, perdendo a tabela de conversão por etapa.
Você pede pra IA achar onde o SLA mais estoura, cruzando o sistema de tempo por etapa, que é dado estruturado, com o relatório de qualidade em PDF cheio de gráfico. Ela devolve uma resposta com jargão de eficiência, mas tratou o PDF como texto corrido, perdendo a tabela de tempos.
Você pede pra IA listar quais controles internos estão mais expostos, cruzando a matriz de risco, que é linha e coluna, com a política de tratamento de dado, que é texto corrido. Ela devolve uma lista genérica, mas embaralhou as duas fontes, tratando a matriz como texto e a política como planilha.
Você pede pra IA achar qual serviço mais causa incidente, cruzando o log estruturado do monitoramento com o relatório de postmortem em PDF cheio de gráfico de latência. Ela devolve um palpite com ar de quem entende de infra, mas tratou o log como texto pra buscar por significado e o PDF como planilha, perdendo o gráfico.
Você pede pra IA achar onde o usuário mais abandona o fluxo, cruzando os dados de funil, que são estruturados, com o relatório de pesquisa em PDF cheio de gráfico de calor. Ela devolve um clichê de UX, mas tratou o funil como texto corrido e o PDF como planilha, perdendo o mapa de calor que mostrava o ponto real de fricção.
Você pergunta pra IA qual concorrente ganha participação de mercado mais rápido, juntando o relatório de win-loss em PDF, cheio de gráfico, com a planilha de vendas por trimestre numa tacada só. Ela devolve uma resposta bonita, mas embaralhou os dois: tratou o PDF com gráfico como texto corrido e perdeu a tabela, e tratou a planilha como se precisasse de busca por significado, não o contrário.
Putz, repara numa coisa: o problema quase nunca é a IA ser ruim de analisar. O problema é que ela está respondendo de cabeça, sem nunca ter aberto o SEU produto de verdade. É como contratar o melhor PM do mercado, sentar ele na sua mesa e nunca dar acesso ao seu Linear, ao seu Amplitude, ao seu Dovetail. Ele vai falar bonito e vai errar feio, porque está adivinhando. Conectar a IA ao contexto do seu produto é exatamente o que tira ela do genérico. Só que conectar errado é pior: ou embaralha os formatos e erra o diagnóstico, ou vaza dado de usuário que não podia sair.
A ideia central desta aula. O contexto do seu produto mora em três naturezas diferentes, e cada uma pede um caminho técnico próprio. O backlog (Linear, Jira) é estruturado mas cheio de texto curto e status: a IA raciocina sobre os campos, não precisa de busca vetorial pesada. O analytics (Amplitude e afins) é dado estruturado de eventos: a IA raciocina sobre o schema, o funil, as estatísticas. A pesquisa (Dovetail e afins) é transcrição de texto corrido: pede busca por significado, RAG de verdade. Misturar os três caminhos é o erro número um. E antes de conectar qualquer um, vem a pergunta de segurança: esse dado de usuário pode sair da empresa, ou precisa de anonimização primeiro?
Por que tratar a transcrição de uma entrevista de pesquisa como se fosse dado estruturado costuma perder o insight mais valioso?
Não conta nota. É para você ver o que já pensa — a aula responde logo abaixo.
01O contexto do produto mora em três lugares, e cada um tem uma natureza
A primeira coisa que muda tudo é parar de tratar "o contexto do meu produto" como uma coisa só. O que existe são três fontes de natureza diferente, e a natureza dita o caminho.
O backlog vive no Linear ou no Jira: cada ticket tem campos estruturados (status, prioridade, label, responsável) e um corpo de texto curto descrevendo o problema. O analytics vive no Amplitude ou equivalente: eventos, funis, coortes, tudo em linha e coluna, puro dado estruturado. A pesquisa vive no Dovetail ou equivalente: transcrição de entrevista, nota de campo, texto corrido cheio de nuance, a fala real de uma pessoa real. Três naturezas, três caminhos.
02Analytics: a IA raciocina sobre o schema, quase nunca precisa de vetorial
O painel do Amplitude é dado estruturado: eventos com nome, propriedade, timestamp, usuário. Pra responder "onde o usuário mais abandona o funil de ativação", a IA não precisa transformar cada evento em coordenada de significado. Ela precisa entender a ESTRUTURA: quais são os eventos, o que cada um significa, como calcular a taxa de conversão entre dois passos, qual coorte comparar com qual.
Em vez de buscar trechos parecidos, ela raciocina sobre o schema, sobre a estatística (taxa de conversão, tamanho de coorte, mediana de tempo entre eventos) e sobre uma amostra representativa. É mais barato em token, mais exato e sem o risco de a busca semântica trazer o evento errado. Antes de montar qualquer coisa mais sofisticada em cima do analytics, pergunte se o dado já não está estruturado o bastante pra IA simplesmente calcular.
03Backlog: ticket estruturado, não texto solto
O Linear ou o Jira parecem, à primeira vista, um monte de texto. Mas cada ticket carrega estrutura: status, label, prioridade, sprint, responsável, e só depois o corpo descritivo. O erro comum é jogar tudo isso numa busca por significado e perder justamente a estrutura que responde a pergunta mais útil: "quantos tickets de bug estão abertos há mais de trinta dias na label de checkout?".
Essa pergunta é contagem e filtro sobre campo estruturado, não busca semântica. A IA que lê o backlog direto na API do Linear ou do Jira, respeitando os campos, responde isso com exatidão. A que trata tudo como texto corrido pode até acertar por sorte, mas perde a precisão que o board de verdade tem pra oferecer.
04Pesquisa: aqui sim, RAG de verdade
A transcrição de entrevista do Dovetail é o território natural do RAG, o mesmo território de qualquer documento de texto corrido. A pergunta "os usuários mencionam dificuldade em achar o botão de exportar?" não se resolve contando campo nenhum: se resolve buscando por significado dentro das falas, mesmo quando o usuário disse "não consegui tirar o relatório" em vez da palavra "exportar".
É aqui que mora a armadilha mais cara do produto: tratar a transcrição como se fosse dado estruturado, resumindo rápido demais e perdendo a frase específica que carregava o insight. A pesquisa existe justamente pra capturar a divergência e a nuance que nenhuma média resume bem. Se você deixa a IA resumir a entrevista inteira num parágrafo genérico sem te permitir voltar à fala original, você perdeu o motivo de ter feito a pesquisa.
05Segurança: dado de usuário real pede checagem antes de sair
Tudo até aqui foi sobre acertar. Agora o ponto que, em produto, pode te derrubar: o que sai da empresa. Transcrição de entrevista carrega fala de gente real, às vezes com nome, e-mail, detalhe de conta que identifica a pessoa. Enviar isso sem pensar pra um modelo na nuvem não é otimização, é vazamento.
A camada de proteção que você aplica antes de conectar qualquer coisa é simples: anonimizar o que identifica (trocar nome por código, tirar e-mail e dado de conta), decidir onde a análise roda (modelo em ambiente da empresa versus nuvem pública, conforme a sensibilidade), e manter o registro de que fonte entrou em qual análise. Não é burocracia. É a diferença entre "conectei a IA à minha pesquisa" e "vazei a fala de um usuário real pra um terceiro sem perceber".
Saiba mais: por que resumir cedo demais mata o insight
Um erro sutil e comum: pedir pra IA resumir a transcrição inteira antes mesmo de você formular a pergunta. Isso parece eficiente e é o oposto. O resumo já decidiu, por você, o que era importante, e frequentemente joga fora a frase estranha que não se encaixava no padrão, que é exatamente onde mora o insight raro. O caminho mais seguro é manter a transcrição como fonte viva de busca (RAG) e só resumir DEPOIS de você já ter feito a pergunta certa e visto as falas originais que a sustentam. Resuma no fim da investigação, nunca no começo.
Faça agora
Pegue um caso real do seu produto onde você precisou de uma resposta que dependia de mais de uma fonte, a sua tarefa real ou outro (por que uma feature não pegou, onde o usuário trava, o que priorizar).
- Liste as fontes que teriam a resposta: o board de tickets, o painel de analytics, a transcrição de pesquisa.
- Para cada fonte, classifique a natureza: estruturado (backlog, analytics) ou texto corrido (pesquisa).
- Marque o caminho de cada uma: backlog e analytics levam a raciocínio sobre campo e schema; pesquisa leva a busca por significado.
- Faça a checagem de segurança: essa fonte tem dado que identifica um usuário real? Precisa anonimizar antes de qualquer análise sair da empresa?
Você acabou de desenhar a conexão do seu contexto de produto com a IA pelo caminho certo, e com o cuidado de segurança no lugar.
Pratique
1. Você quer saber 'onde o usuário mais abandona o funil de ativação' a partir do painel do Amplitude. Qual é o caminho mais indicado?
Para o quadro
Sobre os três lugaresanalytics, backlog e pesquisa têm naturezas diferentes. Tratar os três igual é o erro comum.
Sobre analyticsfunil já é estruturado. A IA raciocina sobre os eventos, não precisa de busca vetorial.
Sobre pesquisaa entrevista existe para capturar a exceção que a média não resume. Resumir cedo demais joga fora o motivo de tê-la feito.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.