🥤 A Teoria do Job e o Caso do Milkshake
Em meados dos anos 1990, Clayton Christensen — professor de Harvard e autor de "O Dilema da Inovacao" — recebeu uma missao incomum: ajudar uma rede de fast food a vender mais milkshakes. A empresa tinha feito tudo certo: pesquisas de mercado, grupos focais, ajustes de sabor. As vendas continuavam estagnadas. O problema era a pergunta errada.
📖 A Descoberta de Christensen
Em vez de perguntar "O que voce acha do milkshake?", a equipe de Christensen passou a perguntar: "Para qual job voce contratou esse milkshake hoje de manha?" O resultado foi revelador: a maioria dos compradores matinais estava sozinha, com pressa, e dirigia um longo trajeto ate o trabalho. Eles nao queriam um milkshake — eles queriam algo que ocupasse as duas maos, durasse o suficiente para acompanhar todo o trajeto, e que os deixasse satisfeitos sem precisar parar para comer.
Clayton Christensen, "Competing Against Luck" (2016) — com Bob Moesta e outros
A conclusao de Christensen foi radical: o verdadeiro concorrente do milkshake matutino nao era outro milk shake — era a banana, o bagel, o donut. Qualquer coisa que o cliente pudesse "contratar" para o mesmo job. Isso mudou como a empresa deveria inovar: tornando o milkshake mais espesso (dura mais), mais conveniente de comprar (autoatendimento), e com menos culpa (versao menor para criancas no fim do dia — um job completamente diferente).
📊 Por que JTBD muda o jogo
- 95% dos novos produtos falham segundo estudo de Harvard (Christensen, 2016) — em geral porque resolvem o produto errado, nao o job certo
- Airbnb: o job nao era "alugar quarto barato" — era "sentir-se em casa, conectado com a cultura local"
- Uber: o job nao era "taxi mais barato" — era "transporte confiavel sem incerteza de chegada"
🔺 Dimensoes do Job: Funcional, Emocional, Social
Todo job tem tres camadas sobrepostas. A maioria das empresas enxerga apenas a dimensao funcional — a tarefa concreta que o usuario quer completar. Mas Bob Moesta, co-criador do framework JTBD junto com Christensen, demonstrou que as dimensoes emocional e social frequentemente sao mais determinantes na decisao de "contratar" ou "demitir" um produto.
Funcional
A tarefa concreta, objetiva, mensuravel
O que o usuario literalmente precisa fazer. "Preciso deslocar do ponto A ao ponto B." "Preciso armazenar meus arquivos." "Preciso comunicar com meu time." E o job mais facil de identificar e tambem o mais comoditizado — quando todos resolvem bem o funcional, as dimensoes emocional e social decidem quem ganha.
Exemplo: "pagar minhas contas sem sair de casa"
Emocional
Como o usuario quer se sentir ao usar
A dimensao interna, pessoal. "Quero me sentir organizado." "Quero sentir que estou no controle." "Quero nao ter medo de errar." Jobs emocionais sao poderosos porque criam lealdade. Quando um produto faz voce se sentir bem consigo mesmo, voce o "recontrata" mesmo quando alternativas mais baratas existem.
Exemplo: "sentir que sou um pai presente"
Social
Como o usuario quer ser percebido pelos outros
A dimensao externa, de status e identidade. "Quero parecer atualizado para meus colegas." "Quero que meus clientes me vejam como profissional." "Quero ser visto como alguem que se preocupa com o meio ambiente." Jobs sociais explicam por que pessoas pagam mais por marcas — a marca e o sinal social que o produto entrega.
Exemplo: "ser visto como um gestor moderno"
🎓 Insight de Bob Moesta
"Quando estudamos o que leva uma familia a comprar uma casa nova, a dimensao funcional — mais espaco — era o pretexto. A dimensao emocional — 'quero ter um quarto so meu' (da mae) — era o gatilho real. A dimensao social — 'nao quero que minha filha compartilhe quarto quando trouxer amigas' — era o bloqueador que impedia a compra ate que fosse resolvida."
Bob Moesta, "Demand-Side Sales 101" (2020)
💡 Dica Pratica
Para todo produto que voce esta desenvolvendo, escreva as tres dimensoes explicitamente: "O usuario precisa [FUNCIONAL]. Ele quer sentir [EMOCIONAL]. Ele quer ser visto como [SOCIAL]." Se voce nao consegue preencher os tres campos, voce nao entende o job ainda.
🔍 Como Descobrir Jobs: Entrevistas, Switch Interview e Timeline
Descobrir o job real nao e intuicao — e metodo. Bob Moesta desenvolveu tecnicas especificas de entrevista que funcionam porque exploram o comportamento passado, nao intenoes futuras. Pessoas mentem (involuntariamente) quando descrevem o que fariam. Quando descrevem o que fizeram, revelam a verdade.
A Switch Interview — Metodo Moesta
Primeira ideia: o primeiro pensamento
Quando voce primeiro pensou em mudar?
Identifica o gatilho inicial — o momento em que o status quo deixou de ser aceitavel. Pode ter sido semanas ou meses antes da compra. Esse e o "primeiro empurrao" (first push): a insatisfacao que comecou a se acumular.
Momento da decisao: o evento catalisador
O que aconteceu no dia em que voce decidiu buscar uma solucao?
Revela o "evento passivo" — o momento especifico que transformou insatisfacao latente em acao. Quase sempre existe um evento concreto: a reuniao que deu errado, a conta que chegou maior do que o esperado, o amigo que mostrou o produto novo.
A busca: como voce procurou
Quais alternativas voce considerou?
Mapeia o espaco de solucao que o cliente ve. Revela concorrentes reais (que frequentemente surpreendem a empresa). Inclui solucoes "nao comprar nada" e workarounds que o cliente ja usava.
A compra: o dia D
Me conta o dia em que voce comprou — do inicio ao fim
Reconstituir a "cena da compra" em detalhes narrativos. Onde estava, com quem, o que levou ao checkout. Revela forcas de atraction (puxao para o novo) e resistencia (ansiedade sobre mudar). O diabo esta nos detalhes desta narrativa.
🎙️ Regras de Ouro da Entrevista JTBD
Perguntas sobre o passado
Nunca "o que voce faria se...". Sempre "o que voce fez quando...".
Narrativa, nao lista
Peca para o entrevistado contar uma historia, nao dar notas de 1 a 10.
Silencio produtivo
Apos uma resposta, espere 5 segundos antes de falar. As melhores respostas vem no silencio.
Siga a emocao
Quando o tom muda, aprofunde. "Voce pareceu hesitar ali — me conta mais."
📝 Job Stories vs User Stories
Alan Klement — um dos principais evangelizadores modernos do JTBD — popularizou o formato Job Story como alternativa as User Stories do desenvolvimento agil. A diferenca parece sutil mas muda completamente o foco da equipe de produto.
User Story (tradicional)
Formato: "Como [persona], eu quero [funcionalidade] para [beneficio]"
"Como Maria, gestora de RH, eu quero ver relatorios de ponto para controlar a frequencia"
- ✗Foca em quem e a persona (ficticia)
- ✗Ja pressupoe a solucao (relatorio)
- ✗Ignora o contexto situacional
- ✗Nao captura o job emocional/social
Job Story (JTBD)
Formato: "Quando [situacao], eu quero [motivacao], para que eu possa [resultado esperado]"
"Quando preciso justificar horas extras para a diretoria, eu quero ter os dados consolidados em segundos, para que eu possa focar na conversa e nao na planilha"
- ✓Foca no contexto situacional real
- ✓Nao pressupoe a solucao
- ✓Inclui motivacao e resultado
- ✓Revela job emocional ("focar na conversa")
🔑 A Estrutura da Job Story em Detalhe
Descreve a situacao — o contexto especifico que dispara o job. E o substituto da persona: em vez de "quem e o usuario", pergunta "em que situacao o usuario esta". Situacoes sao mais stabeis que personas ao longo do tempo.
Descreve a motivacao — o que o usuario esta tentando realizar. Deve ser uma acao ou estado, nao uma funcionalidade. "Ter confianca de que os dados estao corretos" e melhor que "ver um relatorio".
Descreve o resultado desejado — o job de nivel mais alto. Frequentemente revela o job emocional ou social subjacente. "Para que eu possa focar no que importa" e quase sempre o job real.
📐 Outcome-Driven Innovation (Ulwick)
Tony Ulwick chegou a JTBD por um caminho diferente de Christensen. Enquanto Christensen vinha da sociologia e do comportamento, Ulwick era engenheiro e queria um processo repetivel e mensuravel. Ele criou o Outcome-Driven Innovation (ODI) — uma metodologia que transforma o JTBD em processo quantificavel, com mapeamento de "desired outcomes" priorizados por importancia e satisfacao atual.
📖 A Formula de Oportunidade de Ulwick
Oportunidade = Importancia + max(Importancia - Satisfacao, 0)
Onde importancia e satisfacao sao medidas em escala de 0 a 10 pelos clientes
Um outcome com importancia 9 e satisfacao 3 tem oportunidade = 9 + (9-3) = 15. Um outcome com importancia 5 e satisfacao 8 tem oportunidade = 5 + 0 = 5. A formula identifica onde o mercado esta suprido, superatendido ou com lacunas — mapeando o terreno de inovacao de forma objetiva.
🗺️ Os 4 Quadrantes do Opportunity Landscape
Alta Importancia + Baixa Satisfacao
Oportunidade de inovacao prioritaria. O mercado nao esta servindo bem algo que importa muito. Aqui mora o disruption.
Alta Importancia + Alta Satisfacao
Mercado bem atendido. Melhorias incrementais aqui nao criam vantagem competitiva real.
Baixa Importancia + Baixa Satisfacao
Nao vale investir. Mesmo que voce resolva bem, nao importa para o cliente.
Baixa Importancia + Alta Satisfacao
Superatendimento. Voce esta gastando recursos resolvendo algo que o cliente nao valoriza. Corte para simplificar e reduzir custo.
💡 ODI na Pratica
O processo ODI de Ulwick tem 5 passos: (1) Definir o job principal, (2) Identificar os outcomes desejados (geralmente 50-150 por job), (3) Pesquisar importancia e satisfacao com amostra representativa, (4) Calcular oportunidades, (5) Priorizar o roadmap pelo landscape. Empresas como Bosch, J&J e Motorola usaram ODI para gerar inovacoes de alto crescimento com taxa de sucesso acima de 80% (vs. 5% media do mercado).
⚠️ Armadilhas e Exemplos Praticos
JTBD e um framework poderoso mas facilmente mal aplicado. As armadilhas mais comuns nao sao erro de conceito — sao erros de execucao que transformam o framework numa ferramenta de confirmacao do que a equipe ja acreditava. Veja os padroes de fracasso e como evita-los.
⚠ Armadilhas Classicas
- ✗ Job muito generico: "Quero ser mais produtivo" nao e um job acionavel. Jobs uteis sao especificos o suficiente para diferenciar solucoes.
- ✗ Confundir job com solucao: "Quero um app de lembrete" e solucao, nao job. O job e "quero nao esquecer compromissos importantes".
- ✗ Entrevistar os mais entusiastas: seus maiores fas nao sao os mais informativos. Entreviste quem quase comprou mas nao comprou — ou quem deixou de usar.
- ✗ Ignorar o job de nao-consumo: as vezes o concorrente e "fazer nada" ou "conviver com o problema". Nao subestime a inercia como alternativa.
✓ Como Aplicar Bem
- ✓ Faca pelo menos 8-12 switch interviews antes de concluir qualquer coisa sobre o job
- ✓ Grave as entrevistas e transcreva. Patterns emergem de palavras exatas, nao de resumos.
- ✓ Separe o job do contexto: o mesmo job pode ser executado em varios contextos com solucoes diferentes.
- ✓ Mapeie os quatro forcas de Moesta: push (o que empurra para fora), pull (o que atrai para a nova solucao), ansiedade (medos do novo), habito (conforto do atual).
🏆 Exemplos Reais de JTBD bem aplicado
iPod (Apple, 2001)
O job nao era "carregar arquivos MP3". Era "ter minha biblioteca musical inteira no bolso, sem atrito". "1.000 musicas no bolso" e a descricao do job, nao da tecnologia. A concorrencia (Discman, MP3 players existentes) resolvia o funcional mal; o iPod resolveu o emocional (identidade, elegancia) e o social (ser visto com fones brancops era status).
Airbnb (2008)
O job descoberto por Bob Moesta ao estudar os primeiros usuarios do Airbnb: "Quando viajo a lazer, quero sentir que estou vivendo no lugar, nao apenas passando, para que eu possa ter historias autenticas para contar." Hotel resolve o funcional (dormir). Airbnb resolveu o emocional e social — a narrativa de viagem que o hospede leva para casa.
LinkedIn (para recrutadores)
O job nao era "banco de curriculos". Era "quando preciso preencher uma vaga critica, quero encontrar candidatos que eu nao saberia como achar, para que eu possa fechar a vaga sem depender de que bons candidatos me encontrem". A diferenca e sutil mas gerou produto completamente diferente: LinkedIn Premium Recruiter e a solucao do job, nao um buscador de curriculos.
⚠️ A Armadilha do Excesso de Teoria
O maior erro com JTBD e usar o framework para criar documentos lindos em vez de mudar decisoes de produto. Christensen, Moesta e Ulwick concordam num ponto: JTBD so tem valor se a descoberta do job muda o que voce decide construir. Se voce fez 15 entrevistas, produziu um relatorio de 40 slides e o roadmap continuou identico — voce fez JTBD como ritualizacao, nao como ferramenta de decisao.
📋 Resumo do Modulo
Proximo Modulo:
2.6 - OKRs para Inovacao: alinhar ambicao com execucao mensuravel