Feature de IA sem discovery é hipótese cara disfarçada de roadmap. Antes de construir copiloto interno, escreva o que você acredita, teste com quem sentiria o ganho e mate o que não se sustenta. Entrevista, protótipo e critério de corte cabem em dias — o sprint de modelo não deveria ser o primeiro experimento.

O pedido típico chega pronto: “quero um chat em cima dos nossos documentos”. O que não chega é evidência de que a pessoa vai mudar o fluxo atual (planilha, e-mail, sistema legado). Sem isso, o time gasta engenharia em retrieval, prompt e interface para um hábito que ninguém abandonou.

O que a hipótese de IA precisa declarar

Quatro frases, uma cada:

  • Quem deixa de fazer o quê se o copiloto funcionar.
  • Qual tarefa (não “produtividade”) será medida.
  • Qual evidência mínima (cinco pessoas completando a tarefa no protótipo, ou concierge manual por duas semanas).
  • Qual critério de morte — o que faz vocês não abrir sprint.

IA entra como viabilidade técnica, não como prova de valor. Valor é comportamento. Product discovery para validar hipóteses já descreve o ritmo; este texto recorta o vício de 2026: tratar modelo como feature obrigatória.

Copiloto interno compete com busca, com a pessoa especialista e com o SOP. Se a entrevista mostrar que o gargalo é permissão de acesso ou dado desatualizado, a feature de IA não é o próximo passo — é distração.

Testes baratos antes do modelo

Concierge: um humano responde no mesmo canal que o chat ocuparia. Se ninguém pergunta, o modelo não teria audiência. Protótipo de conversa em papel ou Figma: a pessoa tenta a tarefa; você anota onde ela desiste. Landing interna no intranet: “assine se for usar na rotina” — intenção fraca, mas melhor que zero.

Não use o treino de um piloto caro como discovery. Treino é delivery disfarçado. Validar demanda antes do sprint do MVP vale para produto novo; vale igual para feature de IA em produto existente.

MVP com hipótese escrita é o contrato: demo de modelo não é produto. Se a demo impressiona a diretoria e o usuário segue no Excel, você validou teatro, não demanda.

Quando a hipótese sobrevive — e o que entra no sprint

Só promove para build o que passou no critério. Aí sim: recorte de documentos, dono do dado, recusa de dado sensível no prompt, e um fluxo único — não “IA em tudo”. O sprint deve ter aceite de produto (tarefa concluída) além de aceite técnico (o modelo respondeu).

Times que pulam discovery empilham: alucinação, dado errado, medo de usar e a narrativa de que “IA não funcionou”. Funcionou o que não deveria ter sido construído ainda.

No Startup Studio esse corte é o padrão antes do MVP. Em produto interno, o mesmo ritual evita o copiloto-zumbi: lindo na demo, vazio no dia seguinte.

Como a Tech Coders aplica discovery em feature de IA

No Startup Studio, hipótese escrita e teste barato vêm antes do build. Diagnóstico em 48h e caminho para MVP em até 90 dias não incluem “chat genérico no legado” sem evidência. Matamos a feature de IA cedo quando o usuário não muda o comportamento — e só então discutimos modelo, dado e engenharia.

Perguntas frequentes

Discovery atrasa o copiloto que a diretoria quer?

Atrasa o copiloto errado. Adianta a decisão de não gastar o trimestre no problema errado. Diretoria que quer demo pode ganhar um concierge em uma semana — evidência, não slide.

Preciso de base vetorial para testar a hipótese?

Não. Precisa de tarefa, usuário e um jeito de observar. Retrieval vem depois, se o valor existir.

E se o concorrente já anunciou IA?

Anúncio de concorrente não é evidência do seu usuário. Copiar feature de IA sem discovery é o mesmo erro de copiar tela.

Qual critério de morte é honesto?

Exemplo: menos de X pessoas do segmento-alvo completam a tarefa no protótipo sem ajuda, ou o concierge não recebe perguntas reais em duas semanas. Sem número combinado, a hipótese nunca morre.