Jobs to Be Done: quais tarefas você deve dar para a IA

A maioria dos projetos de IA que naufraga não morre por falta de tecnologia. Morre por começar pela pergunta errada. O time olha para o que o modelo consegue fazer, resumir, classificar, gerar, conversar, e sai caçando lugares para encaixar essas capacidades. O resultado é uma coleção de recursos impressionantes que ninguém usa. Jobs to Be Done, o framework popularizado por Clayton Christensen, existe justamente para corrigir esse ponto de partida.

O que é Jobs to Be Done

A ideia central é quase provocadora de tão simples: as pessoas não compram produtos, elas os contratam para fazer um trabalho. A imagem clássica, que Christensen tomou emprestada de Theodore Levitt, é a da furadeira. Ninguém quer uma furadeira de um quarto de polegada. As pessoas querem um furo de um quarto de polegada na parede. A furadeira é só o meio contratado para o trabalho. Se aparecer uma forma melhor de fazer o furo, a furadeira é demitida sem cerimônia.

O trabalho, ou job, tem sempre uma dimensão funcional, o que precisa ser feito, e quase sempre uma dimensão emocional e social, como a pessoa quer se sentir e ser vista ao fazer. Christensen ilustrava isso com o caso de um milk-shake que era contratado, no fim das contas, para tornar suportável um trajeto de carro longo e entediante. Entender o job de verdade explica escolhas que a pesquisa tradicional de produto não capta, porque a pergunta deixa de ser sobre o cliente ou sobre o produto e passa a ser sobre a situação e o progresso que a pessoa busca.

A inversão que o framework faz na IA

Aplicar Jobs to Be Done a IA é, antes de tudo, trocar a pergunta de partida. A pergunta viciada é: o que este modelo consegue fazer e onde eu ponho isso? A pergunta útil é: que trabalho meu usuário está tentando concluir, e a IA faz esse trabalho melhor que a alternativa que ele já contrata hoje?

Parece uma diferença sutil. Não é. A primeira pergunta produz o chatbot que a diretoria adora na demo e que os usuários ignoram na segunda semana, porque ele não faz nenhum trabalho que eles precisavam fazer. A segunda pergunta produz o recurso discreto que economiza quinze minutos de uma tarefa que a pessoa já odiava, e que ela passa a contratar todo dia. Uma nasce da capacidade e procura problema. A outra nasce do problema e escolhe a capacidade.

A IA não é o job. É um candidato a ser contratado para um job. Ela só fica com a vaga se faz o trabalho melhor que a solução que a pessoa usa hoje, incluindo a solução de não fazer nada.

Esse enquadramento derruba de imediato uma categoria inteira de projetos ruins: a feature de IA que existe porque dava para fazer, não porque alguém a contrataria. Se você não consegue nomear o job, quem o faz hoje e por que a pessoa trocaria, você não tem um caso de uso, tem uma demonstração.

Como usar isso na prática

O primeiro passo é mapear os jobs antes de falar em modelo. Converse com quem faz o trabalho e descreva a situação: o que a pessoa está tentando concluir, com qual solução atual, com quanta fricção e insatisfação. Bob Moesta, um dos desenvolvedores do método, defende a entrevista de troca, reconstruir a história do momento em que alguém trocou de solução, para descobrir as forças reais que empurram e seguram uma decisão. O produto dessa etapa é uma lista de trabalhos com dor mensurável, não uma lista de ideias de IA.

O segundo passo é qualificar cada job por dois eixos: o quanto ele é importante e o quanto a solução atual deixa a pessoa insatisfeita. Tony Ulwick, com a abordagem de inovação orientada a resultados, sistematizou essa leitura: os jobs importantes e mal atendidos são o terreno fértil. É lá que uma solução nova, de IA ou não, tem espaço para ser contratada. Job importante e já bem resolvido não vale o esforço. Job irrelevante não vale, e ponto.

O terceiro passo é onde Jobs to Be Done encontra a disciplina de operação que defendemos aqui. Uma vez escolhido o job, ele vira o seu critério de aptidão. A pergunta "a minha IA serve para alguma coisa?" só tem resposta contra um trabalho específico: serve para fazer este job melhor que a alternativa, sim ou não. É a mesma lógica do Fit for Purpose, o job define o que "bom o suficiente" significa, e sem esse critério escrito antes você não consegue nem dizer se o piloto deu certo. Não por acaso, tantos pilotos de IA não viram produção: eles nunca foram amarrados a um job real, então nunca houve como declarar vitória.

Há um cuidado final que o framework impõe e que a euforia da IA costuma atropelar. A alternativa que a pessoa contrata hoje inclui não fazer nada, ou fazer do jeito velho que já funciona. A IA compete contra isso também. Um recurso que faz o job só um pouco melhor, mas exige que a pessoa mude o hábito, aprenda uma tela nova e confie numa resposta que às vezes erra, muitas vezes perde para o status quo. Jobs to Be Done obriga você a medir o ganho contra a solução real, e não contra um cenário idealizado onde a IA não tem concorrência. É esse realismo que separa o caso de uso que escala do que impressiona na demonstração e some depois.

Quem começa pela capacidade do modelo acaba com uma vitrine de features órfãs. Quem começa pelo job entrega menos coisas, e todas contratadas. A IA não muda a regra mais antiga de produto, ela só aumenta a tentação de esquecê-la.

Se o seu time está listando o que a IA consegue fazer antes de saber que trabalho o usuário contrata, chame a gente no WhatsApp para mapear os jobs e escolher onde a IA cria valor de verdade.