Jobs to be Done: contrate a IA para um trabalho, não pela moda

Tem uma pergunta que atrasa quase todo projeto de IA que começa errado: onde a gente coloca IA? Ela soa proativa, mas está de cabeça para baixo. Parte da tecnologia e sai procurando um lugar para encaixá-la, o que garante encaixe forçado. O framework Jobs to be Done, popularizado por Clayton Christensen, inverte a ordem e conserta o vício de origem. Em vez de perguntar onde usar IA, ele manda perguntar qual trabalho o seu cliente está tentando fazer, e onde ele trava. A IA entra depois, no atrito real, não no primeiro lugar onde deu para automatizar.

O que Jobs to be Done realmente diz

A tese é simples de enunciar e difícil de praticar: as pessoas não compram produtos, elas contratam produtos para fazer um progresso em uma situação. Christensen usava a metáfora do milkshake. Uma rede de fast food queria vender mais milkshakes e testava sabor, preço, tamanho. Nada movia a agulha. Ao investigar o trabalho, a equipe descobriu que muita gente comprava milkshake de manhã, sozinha, para uma tarefa específica: aguentar um trajeto longo de carro sem fome e sem tédio, com uma mão só no volante. O milkshake foi contratado para esse trabalho, e competia menos com outros milkshakes do que com banana e rosquinha. Mudar o produto sem entender o trabalho era chutar no escuro.

O trabalho tem três dimensões, e é aqui que a maioria dos times de tecnologia tropeça. A funcional é a tarefa objetiva, transportar dado, gerar um relatório, responder um cliente. A emocional é como a pessoa quer se sentir fazendo aquilo, segura, competente, sem ansiedade. A social é como ela quer ser vista pelos outros ao completar o trabalho. Um projeto que resolve só a dimensão funcional costuma ser tecnicamente correto e comercialmente morto: funciona na demo e ninguém adota, porque ignorou o medo de errar ou a vontade de parecer no controle.

O cliente não quer a sua IA. Ele quer o progresso que estava travado. A IA só vale o que reduz do atrito nesse progresso, o resto é demonstração.

Traduzindo o framework para IA em produção

Aplicar JTBD a IA é um roteiro de quatro movimentos, e cada um evita um erro caro.

Primeiro, comece pelo trabalho, não pela funcionalidade. Antes de decidir que vai usar um modelo de linguagem, descreva o progresso que o usuário quer fazer, em uma frase, sem citar tecnologia. Não abrir um chamado mais rápido, e sim voltar a trabalhar sem depender de ninguém. A tecnologia que serve a esse progresso aparece sozinha, e às vezes nem é IA.

Segundo, mapeie a jornada e ache o atrito. Todo trabalho é uma sequência de passos. A pessoa espera, procura, confere, corrige, decide. Em algum ponto ela trava, retrabalha ou desiste. Esse ponto é onde a IA cria valor real. Colocar IA numa etapa que já funcionava é gastar bala em alvo parado. O gargalo do cliente raramente é a etapa mais fácil de automatizar, e é por isso que o encaixe preguiçoso fracassa.

Terceiro, cubra as três dimensões. Se o trabalho tem carga emocional, a IA precisa endereçá-la. Um assistente que dá a resposta certa mas deixa o usuário inseguro sobre confiar nela não completou o trabalho, resolveu o funcional e ignorou o emocional. Mostrar como chegou à resposta, permitir conferência, deixar o humano no controle da decisão final, tudo isso é parte do trabalho, não enfeite.

Quarto, meça pelo trabalho, não pela IA. A régua de sucesso deixa de ser o modelo respondeu bem e vira o trabalho ficou mais fácil, mais rápido ou mais barato de completar. Essa é a métrica que sobrevive à reunião de resultado. Precisão de modelo não paga conta, tempo de trabalho reduzido paga.

Por que isso importa agora

O erro dominante de 2026 não é técnico, é de mira. Muita IA foi colocada em etapas que ninguém queria acelerar, enquanto o gargalo verdadeiro do cliente continuou intocado. Já mostramos aqui que adotar IA não é o mesmo que ver retorno: pilotos que impressionam na demo e não movem nenhum número costumam ter esse defeito de origem, resolveram um trabalho que ninguém precisava.

JTBD conversa com outros fundamentos que já cobrimos. A Opportunity Solution Tree de Teresa Torres parte de uma oportunidade, uma necessidade não atendida, que nada mais é do que um trabalho travado, e liga essa oportunidade às soluções. E a lógica do Lean Startup aplicado à IA só faz sentido se o que você testa é uma hipótese sobre o trabalho do cliente, não sobre a tecnologia. JTBD é a lente que garante que você está testando a coisa certa: um progresso que alguém quer fazer e não consegue.

O ganho final é de disciplina. Quando o time discute onde colocar IA, a conversa vira disputa de opinião sobre tecnologia. Quando discute qual trabalho do cliente está travado, a conversa vira investigação, e a IA aparece como uma das respostas possíveis, avaliada pelo quanto reduz o atrito. Essa inversão, do produto para o trabalho, é a diferença entre uma IA que impressiona por um mês e uma que as pessoas usam porque, pela primeira vez, o trabalho delas ficou mais fácil.

Se você quer parar de procurar onde encaixar IA e começar pelos trabalhos travados dos seus clientes, fale com a AI Boutique no WhatsApp. A gente ajuda a achar o gargalo certo antes de escrever a primeira linha.