Jobs to be done: o que é, exemplos e como aplicar

Jobs to be done é uma forma de olhar para o cliente que troca a pergunta "quem é essa pessoa?" pela pergunta "o que ela está tentando resolver?". A diferença parece pequena e muda tudo: a primeira pergunta produz uma persona de 35 anos que gosta de viajar, a segunda produz uma decisão de produto.

A frase que resume a ideia é de Theodore Levitt, professor de Harvard: as pessoas não querem uma furadeira de meia polegada, querem um furo de meia polegada. Você compra a furadeira, mas o que você contratou foi o furo — e se aparecer uma forma melhor de fazer o furo, a furadeira perde o emprego.

O que é jobs to be done? {#o-que-e}

Jobs to be done (ou JTBD, "trabalhos a serem feitos") é uma teoria que define o consumo como contratação. Segundo ela, toda compra acontece porque alguém tem um problema a resolver — o job — e escolhe um produto para executá-lo. O produto é o funcionário; o job é a vaga.

Três consequências práticas nascem daí:

• O job é estável, o produto é descartável. As pessoas querem se locomover há milênios. O cavalo, o carro e o aplicativo de transporte são candidatos diferentes para o mesmo trabalho.
• Seu concorrente não é quem você acha. Quem concorre com você é qualquer coisa que resolva o mesmo job, mesmo que seja de outra categoria.
• A pessoa não é o job. Dois clientes idênticos no cadastro podem contratar seu produto por motivos opostos.

Vale destrinchar o segundo ponto, porque ele é o mais contraintuitivo. Sabe quando você monta uma análise de concorrência listando as empresas do seu setor? Pela lógica do JTBD, essa lista pode estar quase toda errada. Se o job do seu cliente é "ocupar 20 minutos de espera sem pensar em trabalho", seu concorrente não é o outro app da sua categoria — é o Instagram, o podcast e a conversa com o colega ao lado. A Netflix passou anos dizendo que competia com o sono, e não era piada: era JTBD aplicado.

De onde veio a ideia? {#origem}

A formulação moderna vem de Clayton Christensen, professor da Harvard Business School e autor de O Dilema da Inovação. Ele desenvolveu o conceito ao longo dos anos 2000 e o consolidou no livro Competing Against Luck (2016), escrito com Taddy Hall, Karen Dillon e David Duncan.

A raiz é anterior. Theodore Levitt já ensinava nos anos 1960 que o cliente compra o resultado, não o objeto. E Tony Ulwick desenvolveu em paralelo a Outcome-Driven Innovation, uma versão mais quantitativa da mesma ideia, que mede o quanto cada resultado desejado é importante e o quanto já está satisfeito.

Na prática, o nome importa menos que o deslocamento de foco. O que todas essas escolas dizem é: pare de descrever o cliente e comece a descrever a situação dele.

O caso do milk-shake: o exemplo que explica tudo {#milk-shake}

O exemplo mais conhecido de JTBD é um estudo que Christensen conduziu com Bob Moesta para uma rede de fast-food que queria vender mais milk-shakes.

A rede já tinha feito o dever de casa do jeito tradicional: chamou clientes, perguntou como o milk-shake poderia ser melhor, ouviu "mais cremoso", "mais barato", "mais sabores". Aplicou as sugestões. As vendas não se moveram.

Então a equipe mudou a pergunta. Em vez de perguntar sobre o produto, foi observar quando as pessoas compravam. Descobriu que uma fatia enorme das vendas acontecia de manhã cedo, em compras solitárias, para viagem.

Conversando com essas pessoas, o job apareceu: elas tinham um trajeto longo e chato de carro até o trabalho, uma mão livre e fome que ia durar até o meio da manhã. O milk-shake não estava sendo contratado como sobremesa. Estava sendo contratado como companhia para o trânsito — algo que dura 20 minutos, não suja a mão e não deixa fome às dez.

Isso reposiciona tudo. Contra um milk-shake matinal, o concorrente não é o sorvete: é a banana (acaba rápido demais), a rosquinha (esfarela no colo) e o café (não mata a fome). E as melhorias óbvias ficam absurdas — deixar o milk-shake mais fino seria péssimo, porque a lentidão é justamente o recurso que faz ele durar o trajeto inteiro.

O mesmo produto, à noite, é contratado para outro job: pai que quer dizer sim para o filho depois de passar o dia dizendo não. Job diferente, produto ideal diferente.

Quais são os três tipos de job? {#tipos}

Todo job tem três camadas, e as pessoas quase sempre falam só da primeira:

• Job funcional — a tarefa objetiva. "Preciso que meu site apareça no Google."
• Job emocional — como a pessoa quer se sentir. "Preciso parar de sentir que estou perdendo cliente para o concorrente."
• Job social — como ela quer ser vista. "Preciso mostrar resultado na reunião de diretoria."

A tradução para o dia a dia é direta: se você só atende o funcional, seu conteúdo vira manual. Sabe aquele artigo tecnicamente impecável que ninguém compartilha? Costuma ser um texto que resolveu o job funcional e ignorou os outros dois. Já um material que ajuda a pessoa a defender uma decisão internamente — com números que ela pode levar para a reunião — está resolvendo o job social, e é por isso que ele circula.

Vale um aviso de honestidade: essa divisão em três é um mapa, não uma lei. Ela serve para você não parar no primeiro andar, e não para preencher uma planilha com três colunas.

Job to be done não é persona — qual a diferença? {#versus-persona}

Esse é o ponto onde mais gente confunde, então vale a comparação lado a lado:


| | Persona | Job to be done |
|---|---|---|
| Pergunta central | Quem é essa pessoa? | O que ela quer resolver? |
| Base | Atributos (idade, cargo, gostos) | Situação e progresso desejado |
| Estabilidade | Muda com o mercado | Estável por décadas |
| Saída típica | "Marcela, 34, gerente de marketing" | "Preciso justificar o investimento em conteúdo para o meu chefe" |

A persona diz que Marcela tem 34 anos e gosta de corrida. Nada disso ajuda a decidir o que escrever. O job diz que Marcela precisa justificar orçamento — e agora você sabe que ela precisa de números, benchmarks e um jeito de apresentar.

As duas ferramentas convivem. A persona ajuda no tom e nos canais; o job ajuda na decisão. O erro é usar persona onde é preciso job: aí você acerta a linguagem e erra o conteúdo.

Como descobrir o job dos seus clientes? {#como-descobrir}

JTBD é uma teoria de entrevista antes de ser uma teoria de estratégia. O método clássico investiga uma compra real e recente, reconstruindo a linha do tempo até o momento da decisão. As perguntas que funcionam:

1. Quando você percebeu que precisava resolver isso? Localiza o gatilho.
2. O que você tentou antes? Revela os concorrentes de verdade.
3. O que estava acontecendo no dia em que você decidiu? Traz a situação, que é onde o job mora.
4. Quem mais estava envolvido na decisão? Expõe o job social.
5. O que quase te fez desistir? Mostra as forças que travam a troca.
6. Como você explicou essa escolha para outra pessoa? As palavras dela valem ouro.

Duas observações que economizam tempo. A primeira: não pergunte o que a pessoa quer, pergunte o que ela fez. Opinião sobre produto é o que produziu o milk-shake mais cremoso que ninguém comprou; história de compra é o que revelou o trajeto de carro.

A segunda: você não precisa de cem entrevistas. Cinco a dez conversas com quem comprou de verdade nos últimos três meses já fazem os padrões aparecerem. E se você não tem base para entrevistar ainda, há um substituto surpreendentemente bom — as próprias buscas.

Como aplicar jobs to be done em conteúdo e SEO? {#seo}

Aqui a teoria encontra o nosso terreno, e a conexão é mais direta do que parece: uma busca é um job declarado em voz alta. Quando alguém digita uma pergunta no Google, essa pessoa está descrevendo, com as próprias palavras, o problema que quer resolver naquele instante.

Isso muda três decisões concretas do seu conteúdo:

• A palavra-chave deixa de ser o alvo e vira a pista. O alvo é o job por trás dela. Duas buscas com o mesmo volume podem ter jobs opostos.
• O formato passa a ser consequência do job. Job de decisão pede comparativo e tabela. Job de execução pede passo a passo. Job de justificativa pede número e fonte.
• A conclusão do artigo ganha função. Se você sabe qual é o próximo job da pessoa, sabe para onde ela deve ir depois.

Um exemplo do nosso próprio nicho. As buscas "o que é CTR" e "como aumentar o CTR" têm quase a mesma cara e jobs completamente diferentes: a primeira é de alguém que ouviu a sigla numa reunião e não quer passar vergonha — job social; a segunda é de alguém com uma campanha rodando mal e um chefe cobrando — job funcional com urgência. Servir o mesmo texto para os dois desperdiça os dois.

Na prática, é assim que decidimos a pauta aqui: um artigo como o de taxa de conversão existe para o job "preciso saber se meu site está bom ou ruim", enquanto o de heatmap atende "já sei que está ruim e preciso descobrir onde". Mesmo tema, momentos diferentes, artigos diferentes — e um linkando para o outro, na ordem em que os jobs acontecem.

Esse raciocínio também explica por que a intenção de busca aparece tanto em o que é SEO: intenção de busca é o nome que o SEO deu para job to be done, décadas depois e sem saber. Vale o mesmo para o título da página — escolher entre prometer definição ou prometer solução, como discutimos em como escrever títulos, é uma decisão de job disfarçada de decisão de copy.

Quais erros mais aparecem na aplicação? {#erros}

• Confundir job com desejo genérico. "Ser feliz" não é um job. Job tem situação, gatilho e critério de sucesso.
• Transformar em burocracia. Planilha com trinta jobs catalogados é sintoma de que ninguém vai usar nenhum.
• Perguntar em vez de observar. Cliente é ótimo relatando o problema e péssimo prescrevendo a solução.
• Achar que todo mundo tem o mesmo job. O milk-shake da manhã e o da noite provam o contrário.
• Usar o job como enfeite. Se a conclusão da pesquisa não mudou nenhuma decisão, a pesquisa não aconteceu.

O terceiro erro merece um parágrafo. Sabe quando você manda uma pesquisa perguntando "o que você gostaria de ver no nosso blog?" e recebe respostas educadas e inúteis? É o milk-shake mais cremoso de novo. A pessoa responde o que parece razoável, não o que ela realmente faria. Olhar o que ela buscou, clicou e leu até o fim vale mais que qualquer formulário.

Conclusão {#conclusao}

Jobs to be done não é uma metodologia com certificado — é uma troca de pergunta. Sempre que você estiver decidindo o que escrever, o que construir ou o que priorizar, troque "para quem é isso?" por "que problema essa pessoa está tentando resolver agora?".

O próximo passo é pequeno e cabe hoje: pegue os cinco conteúdos que mais trazem gente ao seu site e escreva, em uma frase, qual job cada um resolve. Se algum deles não tiver resposta clara, você acabou de achar o que corrigir primeiro.