---
title: "Jobs to Be Done (JTBD): o que é e como aplicar em UX e produto"
date: 2026-05-22T01:31:30Z
modified: 2026-07-29T01:29:13Z
permalink: "https://camaraux.com.br/jobs-to-be-done-ux/"
type: post
status: publish
excerpt: "O JTBD muda a pergunta do design: não \"quem é o usuário\", mas \"o que ele está tentando realizar\". Veja como aplicar."
wpid: 8202
categories:
  - UX Research & Métodos
tags:
  - UX Research & Métodos
  - Clayton Christensen
  - Design Thinking
  - Discovery de Produto
  - entrevista com usuários
  - framework de produto
  - Gestão de Produto
  - jobs to be done
  - JTBD
  - Pesquisa com Usuários
  - Pesquisa Qualitativa
  - User Persona
  - UX Research
rank_math_title: "Jobs to Be Done UX: o que é e como aplicar "
rank_math_description: Entenda o framework Jobs to Be Done UX, como ele se diferencia de personas e como aplicar JTBD em entrevistas e discovery de produto.
rank_math_focus_keyword: Jobs to Be Done
featured_image: /wp-content/uploads/2026/05/Jobs-to-Be-Done-JTBD-em-UX.webp
featured_image_alt: Pessoa subindo degraus geométricos em tons pastel em paisagem minimalista com nuvens
author: Lucas Camara
timestamp: 2026-07-29T01:29:13Z
---

O texto apresenta o framework Jobs to Be Done em UX, explicando que usuários “contratam” produtos para resolver trabalhos funcionais, emocionais e sociais. Também destaca sua origem com Clayton Christensen, sua diferença em relação a personas e sua utilidade para entender motivação e contexto de uso.

Em seguida, mostra como aplicar JTBD em discovery, com entrevistas baseadas em eventos reais, Timeline de Compra e Job Statements. O conteúdo também aborda integração com mapa de empatia e Design Thinking, além de priorização de roadmap e erros comuns na adoção do framework.



Toda vez que um usuário abre um produto, ele não está procurando uma tela bem desenhada ou uma lista de funcionalidades. Ele tem um objetivo, uma tensão, algo que precisa resolver. O framework Jobs to Be Done UX parte exatamente dessa premissa: o que o usuário está tentando conquistar ao usar o seu produto? Entender essa pergunta com precisão muda a forma como você pesquisa, desenha e toma decisões de produto.

O JTBD não é mais uma metodologia nova para UX Designers guardarem no portfólio. É uma lente estratégica que times de produto bem calibrados usam para sair do loop de “construir features que parecem boas no papel” e passar a resolver problemas que as pessoas realmente têm. Neste artigo, você vai entender o que é o framework, como ele se diferencia de personas, e como aplicá-lo do zero dentro de sessões de discovery UX.

## O que é o framework Jobs to Be Done?

Jobs to Be Done é um framework que parte de uma ideia simples: as pessoas não compram produtos, elas os “contratam” para realizar um trabalho específico em suas vidas. Esse trabalho pode ser prático, como transferir dinheiro entre contas, ou mais complexo, como se sentir organizada financeiramente. A diferença entre as duas formas de encarar o mesmo produto é o que separa um time de produto que itera sem rumo de um time que constrói com foco.

Quando aplicado a UX, o JTBD muda o ponto de partida da pesquisa. Em vez de perguntar “quem é o usuário” e construir uma ficha demográfica, você pergunta “em que situação ele recorreu ao produto e o que estava tentando resolver”. Essa virada é pequena na formulação, mas enorme nas descobertas que ela gera. Times que adotam essa perspectiva relatam que as entrevistas passam a revelar motivações que nenhum questionário de satisfação capturaria.

### Quem criou o JTBD e qual é a origem do framework?

O conceito foi desenvolvido por Clayton Christensen, professor de Harvard e autor do livro “Muito Além da Sorte” (no original, “Competing Against Luck”). Christensen ficou conhecido por sua teoria da inovação disruptiva e, ao estudar por que grandes empresas fracassavam ao lançar produtos, percebeu que o problema não era falta de dados. Era o tipo errado de dados: as empresas sabiam muito sobre seus clientes, mas quase nada sobre o que esses clientes estavam tentando realizar.

A origem prática do framework costuma ser ilustrada com um estudo sobre milk-shakes em uma rede de fast food. A rede queria aumentar as vendas. Pesquisas convencionais identificaram perfis demográficos, horários de compra, preferências de sabor. Nada funcionou. Quando a equipe de Christensen passou a observar e entrevistar as pessoas no momento da compra, descobriu que a maioria comprava o milk-shake de manhã, sozinha, e o levava para o carro. O “job” não era matar a fome: era ter algo para segurar durante o trânsito e que durasse até chegar ao trabalho. Essa descoberta mudou completamente as decisões de produto da rede.

### O que significa “contratar” um produto?

A metáfora da “contratação” é central para entender o JTBD. Quando um usuário abre um aplicativo de banco para fazer uma transferência antes de dormir, ele não contratou o app para “acessar serviços bancários”. Ele contratou o app para não precisar lembrar disso amanhã. O contexto e a motivação por trás da ação importam tanto quanto a ação em si.

Isso tem implicações diretas no design. Se você sabe que o job real é “aliviar a tensão de uma tarefa financeira pendente”, você vai desenhar um fluxo de confirmação que transmita segurança e completude, não apenas um fluxo que funcione. A diferença está em saber o que o usuário está contratando. Sem essa clareza, você otimiza telas que tecnicamente funcionam mas emocionalmente não entregam o que o usuário precisa.

## Quais são os três tipos de Jobs no JTBD?

Um erro frequente ao introduzir o JTBD em times de produto é tratar o “job” apenas como uma tarefa funcional, algo do tipo “o usuário quer transferir dinheiro” ou “o usuário quer agendar uma consulta”. Isso é uma simplificação que reduz o framework a uma lista de user stories mais elaboradas. Na prática, os Jobs têm três dimensões que precisam ser identificadas separadamente para que o framework entregue valor real nas sessões de discovery.

Entender os três tipos de Jobs ajuda a distinguir o que o produto precisa fazer (função), como ele precisa fazer o usuário se sentir (emoção) e que mensagem ele comunica ao mundo sobre quem usa ele (social). Um produto que acerta apenas a dimensão funcional pode ser usado, mas dificilmente será amado ou indicado. Produtos que resolvem os três Jobs de forma integrada têm vantagem competitiva difícil de copiar.

### Jobs funcionais: o que o usuário precisa realizar

Os Jobs funcionais são os mais óbvios e os primeiros que qualquer time de produto consegue mapear. São as tarefas concretas que o usuário quer completar, o “o que” do framework. “Quero agendar uma consulta médica”, “quero aprovar um pagamento”, “quero enviar um relatório antes do fim do dia”.

A tentação é parar aqui. O problema é que dois produtos podem resolver o mesmo job funcional de formas completamente diferentes, e o que vai definir qual o usuário prefere é quase sempre o que está nas outras duas dimensões. Os Jobs funcionais são a porta de entrada, não o destino.

### Jobs emocionais: como o usuário quer se sentir

Os Jobs emocionais descrevem o estado interno que o usuário quer alcançar ou evitar ao usar o produto. “Quero me sentir no controle da minha saúde financeira”, “quero evitar a sensação de estar atrasada nas minhas responsabilidades”, “quero terminar o dia sem pendências abertas”.

Esses Jobs raramente aparecem de forma explícita nas entrevistas. Nenhum usuário vai dizer “eu uso esse app porque ele me faz sentir organizada”. Mas quando você analisa as histórias que ele conta, os momentos de frustração que ele descreve e as comparações que ele faz com outras soluções, os Jobs emocionais se tornam visíveis. É aí que o UX Research bem conduzido faz a diferença.

### Jobs sociais: como o usuário quer ser visto

Os Jobs sociais são os menos discutidos no contexto de produtos digitais, mas estão presentes com mais frequência do que parece. Eles descrevem como o usuário quer ser percebido por outras pessoas ao usar o produto, seja por colegas, clientes, família ou qualquer outro grupo de referência.

Um profissional de UX sênior que adota uma ferramenta de pesquisa mais sofisticada pode estar contratando aquela ferramenta, em parte, para sinalizar para o time e para a liderança que ele opera em um nível mais estratégico. Esse não é um detalhe periférico: é um dado de produto que pode orientar decisões sobre posicionamento, onboarding e até sobre quais integrações priorizar no roadmap.

## Jobs to Be Done vs. User Persona: qual a diferença?

Esta é uma das perguntas mais recorrentes de designers e PMs que estão conhecendo o framework. A resposta curta é: persona e JTBD não competem, eles se complementam. Mas para entender como usá-los juntos, é preciso ter clareza sobre o que cada um resolve.

A persona responde à pergunta “quem é o usuário”. Ela reúne características demográficas, comportamentais, motivações e frustrações em um perfil narrativo que ajuda o time a construir empatia. A [user persona](/como-criar-user-persona-ux-design/) é excelente para criar alinhamento interno, facilitar conversas com stakeholders e dar rosto a uma base de usuários que, sem ela, se tornaria uma abstração. O problema da persona usada isoladamente é que ela descreve o usuário, mas não o contexto e a força que o levou a agir.

O JTBD responde à pergunta “por que o usuário recorreu ao produto em um momento específico”. Ele não descreve quem é a pessoa, mas a situação que a colocou em movimento. Isso é especialmente valioso no discovery porque duas pessoas com perfis de persona completamente diferentes podem ter exatamente o mesmo Job. Uma executiva de 45 anos e um estudante de 22 podem contratar o mesmo aplicativo de finanças pelo mesmo Job emocional: não se sentir sobrecarregado com decisões financeiras no fim do dia.

A estratégia mais robusta é usar a persona para definir os perfis que o produto deve atender, e o JTBD para entender quais Jobs esses perfis estão tentando realizar. Personas geram empatia. JTBD gera insight de produto. Juntos, eles cobrem tanto o “quem” quanto o “porquê”.



Vídeo da [NNGroup](https://www.nngroup.com/videos/jobs-be-done-vs-personas/) falando sobre Jobs-to-Be-Done versus Personas ## Como aplicar Jobs to Be Done UX na prática

Entender o framework na teoria é só o primeiro passo. A dificuldade real aparece quando é hora de sentar com usuários e extrair Jobs que vão de fato orientar decisões de produto. Nesta seção, você vai ver como fazer isso de forma estruturada, desde a condução das entrevistas até a formatação dos Jobs e a integração com outros artefatos de UX Research.

O ponto de partida é ter clareza sobre o que você está buscando. Você não está fazendo uma pesquisa de satisfação e não está validando uma hipótese de feature. Você está tentando reconstruir o momento em que o usuário percebeu que precisava de uma solução, o que ele tentou antes, o que não funcionou e o que o fez escolher o produto atual. Esse processo narrativo é o coração da descoberta de Jobs.

### Como conduzir entrevistas para capturar Jobs?

A entrevista orientada a JTBD tem uma lógica diferente da [entrevista com usuários](/entrevista-com-usuarios/) convencional. Você não está perguntando sobre o produto. Você está pedindo para o usuário recontar a história de uma decisão, do momento em que o problema apareceu até o momento em que ele encontrou (ou criou) uma solução.

O ponto de entrada mais eficaz é sempre um evento específico: “Me conta como foi da última vez que você precisou resolver X”. A partir dessa âncora narrativa, você navega para trás e para frente na linha do tempo. Para trás: o que aconteceu antes? Qual foi o gatilho? O que a situação estava custando? Para frente: o que você tentou antes? O que não funcionou? Quando você decidiu buscar uma solução diferente?

#### A técnica da Timeline de Compra

A Timeline de Compra, desenvolvida por Bob Moesta, um dos principais colaboradores do JTBD com Christensen, é uma das ferramentas mais práticas para estruturar essas entrevistas. Ela divide a jornada do usuário em quatro momentos: o primeiro pensamento (quando o Job apareceu), o evento passivo (algo externo que reforçou a tensão), o evento ativo (o momento de decisão de buscar uma solução) e a escolha final.

Ao reconstruir esses quatro momentos com o usuário, você passa a entender não só o que ele contratou, mas quais forças estavam agindo sobre ele: as forças de empurrar em direção à mudança, as forças de atrair para a nova solução, as ansiedades que quase o fizeram desistir e os hábitos que o prendiam à situação anterior. Esse mapa de forças é um insumo de produto muito mais rico do que qualquer Net Promoter Score.

#### As perguntas certas para revelar o Job

Algumas perguntas são especialmente eficazes em entrevistas JTBD e podem ser adaptadas a qualquer contexto de produto. “O que você estava fazendo logo antes de decidir buscar essa solução?” revela o gatilho. “O que você tentou antes?” revela Jobs mal resolvidos e concorrentes reais, que muitas vezes não são os que o time de produto imagina. “Se esse produto sumisse do mercado, o que você usaria no lugar?” revela a verdadeira âncora do Job.

Evite perguntas sobre o futuro (“o que você gostaria que o produto tivesse”) e sobre generalidades (“como você costuma usar o produto”). Jobs não aparecem em abstrações, eles aparecem em histórias específicas de momentos específicos. Quanto mais concreta for a âncora temporal da entrevista, mais preciso será o Job que você vai encontrar.

### Como formatar o Job Statement?

Um Job Statement bem escrito segue uma estrutura simples: verbo de ação + objeto + contexto. Ele deve descrever o que o usuário está tentando realizar, não como ele quer que o produto funcione. Isso é importante porque um bom Job Statement permanece relevante mesmo que a solução tecnológica mude completamente.

O formato mais usado é: “Quando \[situação\], quero \[motivação/job\], para que eu possa \[resultado esperado\]”. Por exemplo: “Quando estou finalizando um projeto e o prazo está chegando, quero ter certeza de que nenhuma tarefa importante ficou para trás, para que eu não precise explicar atrasos para o cliente”. Perceba que esse Job Statement não menciona nenhuma funcionalidade específica. Ele descreve uma tensão real, e essa tensão pode ser resolvida de dezenas de formas diferentes.

### Como integrar JTBD ao mapa de empatia?

O [mapa de empatia](/mapa-de-empatia/) e o JTBD são artefatos que se alimentam mutuamente quando usados em sequência correta. O mapa de empatia organiza o que o usuário pensa, sente, fala e faz em um determinado contexto. O JTBD vai uma camada abaixo e tenta explicar a força motivacional que está por trás desse comportamento.

Uma forma prática de integrar os dois é usar o mapa de empatia como artefato de síntese da primeira rodada de entrevistas, e o JTBD como framework de segunda passagem. Você olha para o quadrante “o que o usuário quer/precisa” do mapa de empatia e pergunta: qual é o Job que está gerando esse desejo? Essa pergunta transforma observações de comportamento em hipóteses de Job que podem ser testadas em entrevistas subsequentes.

## JTBD no discovery de produto: do insight à decisão

O discovery é a fase do processo de produto em que o time sai de hipóteses e vai buscar evidências sobre problemas reais. É também a fase em que o JTBD entrega seu maior retorno. Quando você começa um ciclo de discovery com Jobs bem mapeados, você tem uma bússola para avaliar se uma solução que o time está considerando realmente resolve o problema ou apenas adiciona complexidade ao produto.

A [UX Research para tomada de decisão de produto](/ux-research-para-tomada-de-decisao-de-produto/) se torna muito mais eficaz quando orientada por Jobs. Em vez de perguntar “os usuários gostaram do protótipo”, você pergunta “esse protótipo resolve o Job que identificamos?”. Essa mudança de pergunta muda o tipo de dado que você coleta e, consequentemente, a qualidade das decisões que o time consegue tomar ao final do ciclo de discovery.

### Como priorizar features com base nos Jobs?

Um dos maiores desafios de times de produto é a priorização de roadmap. O JTBD oferece um critério objetivo para essa conversa: qual feature desbloqueia mais Jobs, com mais frequência, para mais usuários? Isso é diferente de perguntar qual feature tem mais votos no backlog ou qual foi pedida por mais clientes no último trimestre.

A metodologia de Outcome-Driven Innovation, desenvolvida por Anthony Ulwick e que influenciou diretamente o JTBD, propõe mapear Jobs como “oportunidades de inovação” e cruzá-los com dois fatores: a importância do Job para o usuário e o grau de satisfação atual com as soluções disponíveis. Jobs importantes e mal resolvidos são as maiores oportunidades. Essa matriz transforma a conversa de priorização de uma disputa de opiniões em uma análise de evidências.

### Como conectar JTBD ao Design Thinking?

O [Design Thinking](/design-thinking/) e o JTBD são complementares em termos de processo. O Design Thinking fornece a estrutura iterativa (empatia, definição, ideação, prototipagem, teste). O JTBD aprofunda a fase de empatia e torna a fase de definição muito mais precisa.

Quando você entra na fase de definição do Design Thinking com Jobs mapeados, o ponto de vista que você redige deixa de ser uma suposição e passa a ser uma síntese de evidências. Em vez de “o usuário precisa de um jeito mais rápido de fazer X”, você tem “quando o usuário está em contexto Y, ele está tentando resolver Z, mas as soluções atuais falham porque…”. Essa precisão muda o nível de foco da fase de ideação e reduz o desperdício de ciclos de prototipagem em direções que o discovery não suporta.

## Erros comuns ao aplicar JTBD em times de produto

O primeiro erro é tratar o JTBD como um exercício de workshop, algo que o time faz em um dia, preenche um template e arquiva no Notion. Jobs não são descobertos em workshops. Eles são identificados em entrevistas individuais bem conduzidas, com usuários que passaram por uma decisão real, e validados ao longo de múltiplos ciclos de pesquisa. Times que tentam atalhar esse processo acabam com Jobs genéricos que não orientam nenhuma decisão prática.

O segundo erro é confundir o Job com a solução. “O usuário quer uma notificação de lembrete” não é um Job. É uma hipótese de solução. O Job por trás disso pode ser “não quero perder compromissos importantes que prejudiquem minha reputação profissional”, e esse Job pode ser resolvido de formas muito diferentes. Misturar Job com solução elimina o principal benefício do framework: a abertura para pensar em soluções que ainda não existem.

O terceiro erro, mais frequente em times de UX, é usar o JTBD como substituto de personas em vez de complemento. Pesquisadores que abandonam personas inteiramente em nome do JTBD perdem o poder de comunicação e alinhamento que a persona oferece dentro de organizações com muitos stakeholders. A combinação dos dois artefatos é o que gera o melhor resultado, tanto para a pesquisa quanto para a tomada de decisão de produto.

Um quarto erro que aparece em times mais avançados é mapear Jobs muito granulares, no nível de micro-tarefas, em vez de Jobs de nível estratégico. Um Job bem calibrado é específico o suficiente para orientar uma decisão de produto, mas amplo o suficiente para permanecer relevante mesmo que a tecnologia ou o contexto mude. Encontrar esse equilíbrio é uma habilidade que se desenvolve com prática e com a revisão constante dos Jobs à luz de evidências novas.

## Perguntas Frequentes sobre Jobs to Be Done (JTBD)

### O que é Jobs to Be Done em UX?

Jobs to Be Done é um framework que propõe que usuários não compram produtos, mas os “contratam” para realizar um trabalho específico em suas vidas. Em UX, ele orienta a pesquisa para entender a motivação real por trás das ações do usuário, além das tarefas superficiais.





### Qual a diferença entre JTBD e User Persona?

A persona descreve quem é o usuário (perfil, características, comportamentos). O JTBD descreve por que e em que situação o usuário recorreu ao produto. Os dois são complementares: personas geram empatia, JTBD gera insight de produto.





### Como conduzir entrevistas para capturar Jobs to Be Done?

A entrevista JTBD parte de um evento específico: peça ao usuário que reconte a história de quando ele buscou uma solução para o problema. Use a técnica da Timeline de Compra para mapear o gatilho, a decisão e as forças que influenciaram a escolha.





### Como formatar um Job Statement?

O formato mais usado é: “Quando \[situação\], quero \[motivação/job\], para que eu possa \[resultado esperado\]”. O Job Statement deve descrever a tensão do usuário, não uma funcionalidade do produto.









## Conclusão

Jobs to Be Done UX não é um framework para aprender e aplicar mecanicamente. É uma forma de treinar o olhar para o que realmente importa na relação entre usuário e produto: o momento de tensão, a decisão de mudar, o trabalho que ele está contratando uma solução para realizar. Quando esse olhar está presente nas entrevistas, nos artefatos de research e nas discussões de roadmap, as decisões de produto ficam mais fundamentadas e os ciclos de discovery ficam mais eficientes.

Se você trabalha com descoberta de produto e quer integrar o JTBD ao seu processo de pesquisa de forma estruturada, incluindo a condução de entrevistas, a síntese de Jobs e a conexão com decisões de roadmap, a CamaraUX oferece consultoria especializada em UX Research para times e empresas que querem sair da intuição e começar a decidir com base em evidências reais.

[Entre em contato e saiba como posso ajudar o seu time.](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/page/contato.md)

## Topics

**Categorias:** [UX Research & Métodos](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/category/ux-research-metodos.md)

**Tags:** [Clayton Christensen](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/clayton-christensen.md), [Design Thinking](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/design-thinking.md), [Discovery de Produto](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/discovery-de-produto.md), [entrevista com usuários](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/entrevista-com-usuarios.md), [framework de produto](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/framework-de-produto.md), [Gestão de Produto](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/gestao-de-produto.md), [jobs to be done](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/jobs-to-be-done.md), [JTBD](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/jtbd.md), [Pesquisa com Usuários](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/pesquisa-com-usuarios.md), [Pesquisa Qualitativa](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/pesquisa-qualitativa.md), [User Persona](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/user-persona.md), [UX Research](https://camaraux.com.br/wp-content/uploads/wp-mfa-exports/taxonomy/post_tag/ux-research.md)