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. Se aparecer uma forma melhor de fazer o furo, a furadeira perde o emprego.
O que é jobs to be done?
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 é um dos mais contraintuitivos. Quem monta uma análise de concorrência listando as empresas do próprio setor costuma terminar com uma lista que, pela lógica do JTBD, está 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. Reed Hastings, então presidente-executivo da Netflix, disse na teleconferência de resultados do primeiro trimestre de 2017 que a empresa estava competindo com o sono, na margem. Não era piada: era JTBD aplicado.
De onde veio a ideia?
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
O exemplo clássico de JTBD é uma pesquisa conduzida por Bob Moesta para uma rede de fast-food que queria vender mais milk-shakes, relatada depois por Clayton Christensen em Competing Against Luck (2016).
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 perto da metade das vendas de milk-shake acontecia antes das 8h30, em compras solitárias, para viagem (Christensen et al., Competing Against Luck, 2016).
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?
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. O 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.
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?
Esse é um dos pontos 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" |
O que isso muda na pauta | Define o tom e o canal do texto | Define o formato: números, benchmarks e um jeito de apresentar |
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. 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?
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:
- Quando você percebeu que precisava resolver isso? Localiza o gatilho.
- O que você tentou antes? Revela os concorrentes de verdade.
- O que estava acontecendo no dia em que você decidiu? Traz a situação, que é onde o job mora.
- Quem mais estava envolvido na decisão? Expõe o job social.
- O que quase te fez desistir? Mostra as forças que travam a troca.
- 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. Na prática, entre cinco e dez conversas com quem comprou de verdade nos últimos três meses já costumam ser suficientes para os padrões aparecerem (é uma regra de bolso de quem aplica o método, não um número medido por alguém). 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?
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. O mesmo se aplica ao 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?
- 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
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.
