Jobs to be Done: a feature de IA que o cliente contrata

Todo time que coloca IA em produção esbarra na mesma pergunta, e quase sempre na ordem errada: qual feature construir, qual modelo usar, qual demo mostrar. A resposta some porque a pergunta está torta. Jobs to be Done, o framework que Clayton Christensen popularizou e Tony Ulwick sistematizou, inverte o ponto de partida. O cliente não compra um produto, ele contrata uma solução para fazer um progresso numa situação específica. Trocar a pergunta é o que separa a IA que vira hábito da IA que impressiona uma vez e é esquecida.

A ideia, em uma frase e um milk-shake

A metáfora que Christensen usava é famosa. Uma rede de fast-food queria vender mais milk-shakes e testou de tudo: mais sabor, mais cremoso, mais barato. Nada movia a agulha. Só quando pararam de perguntar o que melhorar no milk-shake e começaram a perguntar que job as pessoas contratavam o milk-shake para fazer a coisa mudou. Descobriram que boa parte era comprada de manhã, por gente sozinha no carro, no trânsito, que precisava de algo demorado de tomar e substancioso para aguentar até o almoço. O concorrente do milk-shake não era outro milk-shake, era a banana e a rosquinha. O job era: me faça companhia e me segure a fome numa viagem chata.

A lição atravessa o setor. Ulwick levou isso para o rigor de produto com a Outcome-Driven Innovation, definindo o job como algo estável no tempo, separado das soluções que vão e vêm. O job de ouvir música em movimento é o mesmo há décadas; o walkman, o iPod e o streaming foram só soluções sucessivas. Quem projeta para o job sobrevive à troca de tecnologia. Quem projeta para a solução envelhece com ela.

Por que isso importa ainda mais com IA

A IA amplifica o erro clássico de produto, porque ela é sedutora de demonstrar. É fácil construir um chat que responde qualquer coisa, um agente que faz algo impressionante no palco, um resumo que soa mágico. E é fácil confundir esse brilho com valor. O resultado é a epidemia que a grande mídia já expôs: metade das empresas com IA em produção não consegue provar que ela funciona. Não é que a IA não sirva. É que ninguém perguntou qual job ela foi contratada para fazer, então não há como medir se fez.

JTBD dá o critério que falta. A entrega de uma feature de IA não é a demo, é o progresso do cliente. Um resumo de reunião só vale se o job for decidir sem ler a transcrição inteira. Uma triagem automática de chamados só vale se o job for devolver tempo ao time de suporte. Um agente de aprovação só vale se o job for aprovar com segurança, sem virar passivo. A tecnologia é meio. O job é o fim. E o sucesso se mede no fim.

A pergunta que destrava o projeto não é que modelo usar. É que progresso o cliente está tentando fazer, e o que hoje o impede.

Como aplicar, na pratica

O framework vira operação em quatro passos.

Primeiro, escreva o job antes da feature. Use a forma clássica: quando eu [situação], quero [motivação], para [resultado esperado]. Por exemplo: quando recebo um contrato de 40 páginas, quero entender os riscos sem ler tudo, para responder ao cliente no mesmo dia. Repare que não há IA nessa frase. O job é agnóstico de solução, e é isso que o torna útil: ele julga qualquer solução, com ou sem IA.

Segundo, mapeie a alternativa atual. Todo job já é resolvido de algum jeito, mesmo que mal. A pessoa lê o contrato às pressas, pede para um colega, ou simplesmente demora. A sua feature de IA não compete com o vazio, compete com esse comportamento. Se ela não faz o job melhor que a gambiarra atual, não será contratada, por mais avançada que seja. Esse é o teste que separa novidade de valor.

Terceiro, defina a métrica pelo resultado do job, não pelo uso da IA. Contar quantos tokens você gastou ou quantas chamadas o modelo fez não diz nada sobre progresso. Meça o tempo para responder ao cliente, a taxa de chamado resolvido no primeiro contato, a decisão tomada sem escalar. É a mesma disciplina de amarrar entrega a resultado que sustenta bons OKRs para IA, focados em resultado e não em entrega.

Quarto, descubra o job continuamente, não uma vez. Jobs não se adivinham na sala de reunião, se apuram conversando com quem tem o problema. Essa escuta constante é o coração da descoberta contínua de produto que a Teresa Torres defende: entrevista semanal, hipótese testada, aprendizado que corrige o rumo antes de o código endurecer.

O erro que o framework evita

O maior desperdício em IA não é técnico, é de mira. Times gastam meses afinando um modelo para uma feature que ninguém contratou, porque partiram da tecnologia disponível e não do progresso desejado. JTBD é o antídoto barato. Ele obriga a nomear o job antes de escrever a primeira linha, e a matar a ideia que não faz nenhum job melhor que a alternativa. É mais fácil desligar um projeto sem job na fase de conversa do que depois de seis meses de engenharia.

Há um bônus de foco. Quando o time compartilha o mesmo job, as decisões de escopo ficam óbvias. A funcionalidade que não serve ao job sai da lista sem drama. O modelo escolhido é o mais barato que ainda faz o job, não o mais impressionante. E a demo deixa de ser o objetivo, porque o objetivo virou o progresso do cliente, que é o que ele volta para contratar amanhã.

No fim, Jobs to be Done não é sobre IA, e é justamente por isso que funciona tão bem com IA. Ele mantém a atenção onde o valor sempre esteve, no progresso de quem usa, enquanto a tecnologia por baixo troca de nome a cada trimestre. Construa a feature de IA que faz o job melhor que a alternativa de hoje. O resto é vitrine.

Se o seu time está construindo IA a partir da tecnologia e não do job do cliente, fale com a AI Boutique no WhatsApp. A gente ajuda a mapear os jobs, escolher a feature que faz o progresso e medir pelo resultado, não pela demo.