Glossário: Job-to-be-done

« retornar para home do glossário

Job-to-be-done (JTBD) é a tarefa (job) funcional, emocional ou social que o cliente está tentando realizar em um contexto específico, com critérios concretos de sucesso. O job é sempre expresso como um progresso que o cliente quer alcançar, não como uma característica ou desejo genérico.

Job-to-be-done (JTBD) também é considerada uma abordagem para compreender as necessidades e desejos dos clientes em relação a um produto ou serviço, oferecendo uma estrutura para:

  • categorizar, definir, capturar e organizar todas as necessidades do cliente; e
  • vincular métricas de desempenho, definidas pelo cliente na forma de declarações de resultados desejados (outcomes), às tarefas (jobs) que precisam ser realizadas (Ulwick, 2017).
Neste ponto é bom comparar JTBD com necessidades do cliente, que descrevem, nas palavras do cliente, quais são os  benefícios que ele espera obter de um produto ou serviço. São estados desejados, carências ou condições que o cliente quer satisfazer. Geralmente aparecem como expressões amplas: segurança, conveniência, redução de esforço, economia de tempo, conforto, status. Podem ser explícitas ou latentes.

Segundo Ulwick (2017), job-to-be-done é a tarefa (job) que um produto ou serviço deve “fazer” para o cliente. Os clientes “contratam” um produto ou serviço pela tarefa que ele executa.

Esse “contratam” pode se referir a diversos tipos de modelos de receita, tais como, comprar um produto; pagar / assinar pelo uso ou pelo resultado obtido; etc.

A Strategyn (2022) define:
“Job-to-be-done é uma perspectiva, uma nova lente, através da qual você pode observar mercados, clientes, necessidades, concorrentes e segmentos de clientes de forma mais perspicaz, resultando em inovações mais predizíveis e lucrativas.”

Já Wunker et al. (2016) descrevem:
“Jobs-to-be-done são as tarefas fundamentais que os clientes estão tentando realizar. Mesmo que o cliente não consiga articular o que quer ou compreender as possibilidades de inovações disruptivas.”

De acordo com Ulwick (2017), ao conhecer todas as necessidades do cliente e identificar quais não estão sendo atendidas, uma empresa pode desenvolver novos conceitos e ofertas.

O que é “job” no contexto do JTBD

As traduções mais comuns para “job” em português são trabalho, emprego, cargo e serviço.

No JTBD, job é a unidade central; os demais elementos (outcomes, job performer/circunstâncias, job map e jornada) existem para descrevê-lo, medi-lo e melhorá-lo.

No contexto da inovação, job deve ser lido como trabalho a realizar (ou objetivo de progresso): o avanço que o cliente busca alcançar em uma circunstância específica, independentemente de qualquer solução existente. Esse trabalho pode incluir dimensões funcionais, emocionais e sociais.

Evite tratar “job” como mera tarefa do processo atual; tarefas descrevem o “como” hoje, enquanto o job descreve o que precisa ser alcançado.

Christensen et al. (2005) afirmam:
“Todo job que as pessoas necessitam ou desejam possui dimensões sociais, funcionais e emocionais… A unidade de análise de um profissional de marketing é o job e não o cliente.”

Mesmo sem usar diretamente a expressão job-to-be-done, Christensen et al. (2005) citam “jobs that customers are trying to get done”, com o mesmo sentido.

 Osterwalder et al. (2014) complementam: “Os jobs descrevem as coisas que seus clientes estão tentando realizar no trabalho ou na vida: 

  • tarefas que buscam executar e concluir, 
  • problemas que querem resolver ou 
  • necessidades que querem satisfazer. 

Certifique-se de ter a perspectiva do cliente ao investigar os jobs; o que você considera importante pode não ser um job que o cliente realmente tenta realizar.”

Um dos princípios centrais do JTBD (Ulwick, 2017b) é que, embora o job principal seja funcional, ele frequentemente possui componentes emocionais e sociais:
“Ao usar um produto para realizar uma tarefa funcional, o cliente muitas vezes quer sentir-se de uma certa maneira e ser percebido de determinada forma por colegas, amigos ou outras pessoas. Esses sentimentos e percepções constituem os jobs emocional e social.”

Tipos de jobs

Osterwalder et al.(2014), no se livro “Value proposition design: How to create products and services customers want” definem os seguintes tipos de job-to-be-done, ou seja, jobs, que precisam ser realizados:

  • jobs funcionais: quando os clientes tentam executar ou completar uma tarefa específica ou resolver um problema específico. Por exemplo, editar e publicar textos na web usando um computador ou celular.
  • jobs sociais: quando os clientes desejam possuir visibilidade, obter poder ou ganhar status. Esses jobs descrevem como os clientes desejam ser percebidos por outros. Por exemplo, utilizar roupas da moda para obter um status social em alguns ambientes.
  • jobs pessoais / emocionais: quando os clientes buscam um estado emocional específico, tais como se sentir bem ou seguros. Por exemplo, sentir-se seguro ao comprar um automóvel com recursos de segurança avançados.
  • jobs de apoio (supporting jobs): os clientes também desempenham jobs de apoio no contexto de compras ou consumo, tanto como consumidores quanto profissionais. Esses jobs advém de três papéis:
  • job de apoio – papel 1 – comprador de valor: como comparar ofertas, decidir quais produtos comprar, ficar na fila do caixa, concluir uma compra ou receber a entrega de um produto ou serviço.
  • job de apoio – papel 2 – cocriador de valor: como postar análises e feedback de produtos ou até mesmo participar do design de um produto ou serviço.
  • job de apoio – papel 3 – transferir valor: relacionado ao fim do ciclo de vida de uma proposta de valor, como cancelar uma assinatura, descartar um produto, transferi-lo para outros ou revendê-lo. 

ODI Ecosystem (Mosaic, 2025) 

Essa estrutura é uma simplificação da metodologia original, ODI – outcome-driven innovation, da Strategyn (Ulwick, 2017). Os principais conceitos / artefatos são:

  • Struggling moments são disfunções da situação atual para realizar o job.
  • Outcomes medem o sucesso do job.
  • Job performer é quem executa o job.
  • Circunstâncias são o contexto em que o job ocorre (gatilhos, restrições, ambiente). 
  • Job map representa o fluxo ideal do trabalho (agnóstico de solução).
  • Job story é uma forma simplificada e narrativa de representar o JTBD.
  • Job statement é um enunciado curto, solução-agnóstico, que nomeia o trabalho central a realizar e seu contexto.
Esses conceitos (artefatos)  são complementares:
– struggling moments indicam disfunções;
– outcomes quantificam;
– circunstâncias contextualizam:
– job map revela oportunidades
– Job story representa o JTBD por meio de uma narrativa;
– Job statement é um enunciado curto do JTBD.

Struggling moments (momentos de dificuldade)

São situações concretas em que o cliente encontra disfunções da Situação Atual (as-is.) ao tentar realizar o job (trabalho/tarefa a realizar). Tornam explícitas as dificuldades do (as-is). 

Como registrar (3 linhas):

  • Contexto (onde/quando ocorre):  “primeiro comissionamento em campo, 2G instável”.
  • Disfunção observável (o que trava na situação atual — as-is): o que impede/atrapalha — “assistente exige login contínuo e falha”.
  • Impacto: (por que importa): “aumenta retrabalho e atrasa o início da produção”.

Cada struggling moment deve ser convertido em outcome mensurável.

Exemplos (de uma bomba centrífuga):
– “Conectividade cai durante a configuração e o assistente reinicia.” → Outcome: reduzir dependência de conexão contínua no comissionamento (tempo/erros).
– “Parâmetros críticos não são validados em linha com alta vibração.” → Outcome: reduzir erros de parametrização em ambiente vibrante (precisão no FTF:  First Time Right — acerto na 1ª tentativa).

Como expressamos o sucesso do job? – Outcomes (resultados esperados)

O sucesso de um job é descrito por meio de outcomes, isto é, resultados que o executor deseja alcançar ao realizar seu trabalho. Um outcome representa uma melhoria desejada e deve ser formulado de forma objetiva e mensurável.

Os outcomes descrevem o que o executor deseja melhorar, independentemente da solução utilizada. Posteriormente, podem ser utilizados para comparar soluções existentes, identificar oportunidades de inovação e orientar o design da proposta de valor.

Recomenda-se registrar outcomes no formato:
direção da melhoria + atributo mensurável + objeto de controle + clarificador
Os atributos mensuráveis podem envolver, por exemplo: tempo, esforço, probabilidade de erro, variabilidade, precisão, risco, custo, frequência, consumo ou disponibilidade.

Exemplos

  • Reduzir (direção) o tempo necessário (atributo mensurável) para configurar o equipamento (objeto de controle) no primeiro uso em campo por técnicos iniciantes (clarificador), de 30 para 10 minutos (meta).
  • Reduzir (direção) o erro percentual (atributo mensurável) na leitura da vazão (objeto de controle) em linhas sujeitas à vibração (clarificador), de ±3% para ±1% (meta).

Quem faz e em qual contexto? – Job performer e circunstâncias

Identificar papéis e condições evita confundir necessidades do trabalho com perfis demográficos.

Descreva quem executa o trabalho e em quais condições, detalhando:

  • Gatilhos: p. ex., falha recorrente da bomba; auditoria próxima; SLA prestes a vencer.
  • Ambiente: p. ex., campo com poeira/chuva; linha com vibração; sala limpa; área classificada.
  • Restrições: p. ex., janela de manutenção de 30 minutos; conectividade 2G/offline; normas NR-10/NR-12; homologação Anvisa/INMETRO.

Use dados demográficos apenas quando forem requisitos reais (e explícitos), como: faixa etária mínima por regulação; exigência de CNH D para operar; antropometria para EPI.

Priorize circunstâncias e papéis:

  • B2B (exemplo): técnico de manutenção (executor), operador do turno (beneficiário), gerente de operações (decisor), compras/financeiro (pagador).
  • B2C (exemplo): paciente (executor/beneficiário), médico (decisor/prescritor), plano de saúde (pagador).

Como representamos o trabalho e a experiência? – Job map

O job map decompõe o trabalho de forma solução-agnóstica (estado desejado e critérios de êxito) e orienta a descoberta de oportunidades.

Solução-agnóstica significa que algo é definido ou analisado sem referência a uma solução específica. No caso do JTBD, um job map solução-agnóstica descreve o trabalho que o cliente precisa realizar em termos de etapas e critérios de sucesso, independente de produto, serviço ou tecnologia existente. Isso permite descobrir oportunidades amplas, antes de cair na armadilha de apenas otimizar o “como se faz hoje”.
Exemplo: “reduzir o tempo para configurar um equipamento em campo” é solução-agnóstico; “instalar software X em 5 cliques” já é dependente de uma solução específica.

Não confunda job map com o mapa da jornada que retrata a experiência atual para diagnóstico e otimização do “as is”. São complementares, com propósitos distintos.

Job story

É  uma forma simplificada e narrativa de representar o JTBD. Ela não substitui o job statement nem os outcomes mensuráveis; serve para alinhamento rápido e para orientar ideação/backlog.

Formato usual:
– When… = circunstâncias (gatilhos/ambiente/restrições).
– I want to… = job (trabalho a realizar / progresso), descrito de modo solução-agnóstico.
– So I can… = outcome desejado (benefício/critério de sucesso). Os valores-alvo (“de 30 para 10 min”) ficam como clarificador/aceite.
Exemplo: When estou instalando a bomba em campo com conexão limitada (circunstâncias), I want to configurá-la ponta a ponta sem notebook (job, solução-agnóstico), so I can iniciar a produção na primeira tentativa em ≤10 minutos (outcome + clarificador).

Diretriz prática: use a job story para comunicar contexto e intenção; para priorizar portfólio e medir impacto, converta em outcomes (variável + direção) e, se preciso, em um job statement enxuto (“configurar equipamento em campo…”) e no job map.

Job statement 

É um enunciado curto, solução-agnóstico, que nomeia o trabalho central a realizar e seu contexto. Ele serve como âncora para outcomes (como medir sucesso) e para o job map (como o trabalho se desdobra).

Estrutura: [verbo de ação] + [objeto do trabalho] + [contexto/circunstâncias] (+ opcional: [quem executa]).
Exemplo: Configurar a bomba centrífuga no primeiro uso em campo com conectividade limitada (por técnicos iniciantes). 

Job story versus Job statement

A job story (“When… I want to… so I can…”) é narrativa; o job statement é o “título operacional” do job, mais estável e direto.

Um job statement pode desdobrar várias job stories (por circunstância ou cenário). Em ambos os casos, meça o sucesso com outcomes; mantenha um statement por job e um conjunto curado de job stories por cenário para evitar redundância.

Exemplo:

Job Statement (âncora)
Configurar a bomba centrífuga no primeiro uso em campo, em locais com conectividade limitada e janelas de manutenção curtas.

Desdobramentos em Job Stories (exemplos por circunstância)

  • Quando estou no primeiro comissionamento em campo, com internet intermitente e janela de 30 min, eu quero concluir a configuração da bomba centrífuga sem depender de conexão contínua, para que eu possa iniciar a operação na primeira tentativa em ≤10 min.
  • Quando realizo o primeiro comissionamento em campo como técnico iniciante, eu quero seguir um passo a passo que previna erros críticos, para que eu possa alcançar ≥95% de acerto no teste inicial.
  • Quando faço o primeiro comissionamento em uma linha com alta vibração (vibração do ambiente/instalação), eu quero validar automaticamente parâmetros sensíveis, para que eu possa reduzir retrabalho e tempo de ajuste de 45 para 15 min.
  • Quando preciso de rastreabilidade para auditoria no primeiro comissionamento, eu quero registrar parâmetros e validações no ato, para que eu possa gerar evidências de conformidade em ≤2 min por bomba.
  • Quando há risco de cavitação por NPSH baixo (cavitação = formação/implosão de bolhas que danifica o impulsor; NPSH = altura líquida positiva de sucção), eu quero ajustar setpoints às condições locais, para que eu possa manter vibração ≤ 1,8 mm/s RMS (RMS = valor médio quadrático da velocidade de vibração).

Embora a estrutura proposta por Ulwick (2017) seja a base conceitual do Outcome-Driven Innovation (ODI), versões mais recentes — como o ODI Ecosystem descrito no Mosaic Toolkit (2025) — apresentam uma organização mais clara dos elementos. Não se trata de modelos concorrentes, mas de uma evolução na forma de visualizar e aplicar a teoria dos jobs-to-be-done.

Estrutura proposta por Ulwick (2017)

O framework original proposto por Ulwick (2017) para job-to-be-done incluía: 

  • a principal tarefa  funcional a ser realizada (JTBD);
  • os resultados desejados vinculados à JTBD;
  • tarefas (jobs) relacionadas;
  • tarefas (jobs) emocionais e sociais;
  • tarefas (jobs) da cadeia de consumo, e
  • os resultados financeiros desejados pelo comprador (cliente / usuário).
Origem e difusão: O conceito de job-to-be-done foi desenvolvido de forma independente por vários pensadores de negócios, incluindo Anthony Ulwick (Strategyn), Rick Pedi, Bob Moesta e Denise Nitterhouse (DePaul University). Foi popularizado por Clayton Christensen (Innosight) e pela própria Strategyn.

Christensen, C. M., Cook, S., & Hall, T. (2005). Marketing malpractice: the cause and the cure. Harvard Business Review, 83(12), 74–83, 152. http://www.ncbi.nlm.nih.gov/pubmed/16334583 

Mosaic. (2025). Jobs to be Done Toolkit (Versão 2.2). Mosaic.

Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). Value proposition design: How to create products and services customers want. John Wiley & Sons.

Strategyn (2022)  Jobs-To-Be-Done Playbook Disponível em: https://strategyn.com/jobs-to-be-done/jobs-to-be-done-playbook/what-is-jobs-to-be-done/ Acesso em: 25/11/2022

Ulwick, A. W. (2017). Outcome-Driven Innovation®(ODI): Jobs-to-be-Done Theory in Practice. Strategyn, LLC Whitepaper.

Ulwick, A. W. (2017b). The Core Tenets of Jobs-to-be-Done Theory. Disponível em: https://jobs-to-be-done.com/the-5-tenets-of-jobs-to-be-done-theory-ba58c3a093c1 Acesso em: 12/11/2023

Wunker, S., Wattman, J., & Farber, D. (2016). Jobs to be done: a roadmap for customer-centered innovation. Amacom.

« retornar para home do glossário
#printfriendly a { color: blue !important; text-decoration: underline !important; } #printfriendly i, #printfriendly em { color: purple !important; } @media print { .break-page-before { page-break-before: always !important; } h1 { page-break-before: always !important; font-size: 32px !important; } div.no-page-break-before h1, div.no-break-page-before h1 { page-break-before: avoid !important; } }