Todo time de produto já teve esta conversa. Alguém abre o analytics, aponta para uma funcionalidade que levou um trimestre para ser construída e pergunta por que ninguém a usa. O design foi revisado. O texto foi lapidado. O lançamento saiu no prazo. E, mesmo assim, a adoção não sai do lugar.
A reação de costume é adicionar mais: outro tooltip, outro e-mail, outra linha no changelog. Mas o problema muitas vezes está mais acima. A funcionalidade foi construída para um tipo de usuário, e não para um job que esse usuário estava de fato tentando realizar.
Jobs to Be Done é o framework que fecha essa lacuna. Ele troca a pergunta "quem é o nosso usuário?" por outra mais precisa: que progresso essa pessoa está tentando fazer, e para fazer o que ela nos contratou? Este guia mostra o que significa JTBD, como escrever um job statement, como conduzir as entrevistas, seis exemplos detalhados e (a parte que a maioria dos guias pula) como transformar um job num fluxo de onboarding que realmente o entrega.
Principais pontos
- As pessoas contratam produtos para progredir. Um job é o progresso que alguém quer fazer numa circunstância específica: não é uma funcionalidade, não é uma persona, não é um dado demográfico.
- Todo job tem três dimensões. Funcional (a tarefa), emocional (como a pessoa quer se sentir) e social (como ela quer ser vista). Produtos que resolvem só a dimensão funcional perdem para os que resolvem as três.
- A troca é regida por quatro forças. O empurrão e a atração levam os usuários até você; a ansiedade e o hábito os seguram. O onboarding é, na maior parte, redução de ansiedade, e é por isso que "mais benefícios" raramente conserta uma taxa de ativação fraca.
- Job statements não mencionam solução. "Quando [situação], eu quero [motivação], para que eu possa [resultado]." Se um produto, uma funcionalidade ou uma tecnologia aparece na frase, não é um job statement.
- Entreviste quem trocou, não todo mundo. Converse com pessoas que mudaram algo nos últimos 90 dias e reconstrua a linha do tempo delas de trás para frente. Opiniões não são confiáveis; o comportamento recente é.
- O retorno está no onboarding. Quando você conhece o job, a experiência de primeiro uso deixa de ser um tour de produto pela sua barra de menus e vira o caminho mais curto até uma ocorrência concluída do job.
O que é Jobs to Be Done?
Definição de Jobs to Be Done (JTBD): um framework para entender o comportamento do cliente que descreve as pessoas pelo progresso que estão tentando fazer numa determinada circunstância, e não por quem elas são. No JTBD, os clientes não compram produtos; eles os contratam para fazer um job, e os demitem quando outra coisa faz esse job melhor.
Essa mudança de enquadramento parece pequena. Na prática, ela muda o que você constrói, o que você mede e quem você considera concorrente.
Pense num time construindo uma funcionalidade de relatórios. Enquadrado por persona, o briefing diz: "Gerentes de marketing de empresas de médio porte precisam de dashboards melhores." Enquadrado por job, o mesmo briefing diz: "Quando o meu CEO pergunta como foi o mês passado, eu quero um número defensável em menos de cinco minutos, para que eu não pareça despreparado na reunião de liderança."
O segundo enquadramento revela algo que o primeiro nunca conseguiria: o verdadeiro concorrente não é outra ferramenta de analytics. É uma planilha em que o gerente de marketing já confia, somada à pressão de uma reunião que começa em dez minutos. É por isso que a velocidade até a resposta importa mais do que a variedade de gráficos, e por isso um fluxo de onboarding que começa com "conecte seis fontes de dados" vai perder todas as vezes.
De onde vem a ideia
O framework é mais associado a Clayton Christensen, cujo estudo do "milkshake" descobriu que os compradores de milkshake da manhã numa rede de fast-food não formavam um grupo demográfico; eram pessoas a caminho do trabalho que contratavam uma bebida espessa para tornar mais suportável um trajeto entediante, dirigindo com uma mão só. A concorrência não eram outros milkshakes. Eram bananas, bagels e o tédio.
A inovação orientada a resultados (outcome-driven innovation) de Tony Ulwick e as entrevistas de "switch" de Bob Moesta construíram a engrenagem prática em torno da ideia: como formular um job, como encontrá-lo e como detectar as forças que fazem alguém finalmente mudar. Os times de SaaS modernos costumam usar uma mistura das três abordagens, que é o que este guia descreve.
As três dimensões de um job
Um job nunca é puramente prático. Toda decisão de contratação carrega três camadas, e as camadas ignoradas costumam ser justamente as que decidem se um produto pega ou não.
-
A dimensão funcional: a tarefa
A coisa concreta que precisa acontecer: consolidar três planilhas, conseguir uma assinatura, publicar uma página. É a camada que os times de produto documentam bem e, em geral, a única que chega a um documento de requisitos.
-
A dimensão emocional: como a pessoa quer se sentir
Confiante em vez de exposta. No controle em vez de atrasada. Tranquila numa sexta à tarde em vez de ansiosa. Os jobs emocionais explicam por que um produto tecnicamente inferior, com uma interface que passa segurança, vence com frequência um produto poderoso que faz as pessoas se sentirem burras.
-
A dimensão social: como a pessoa quer ser vista
Competente diante do gestor. Moderna diante do conselho. Prestativa diante do time. É a dimensão que move a defesa interna: os usuários defendem as ferramentas que os fazem parecer bem para as pessoas cuja opinião importa para eles.
Um teste prático: pegue qualquer funcionalidade que esteja hoje no seu roadmap e escreva uma frase para cada dimensão. Se as linhas emocional e social saírem vazias, você está construindo uma capacidade, não resolvendo um job, e a adoção vai depender inteiramente de os usuários descobrirem sozinhos por que deveriam se importar.
Jobs to Be Done vs personas vs user stories
O JTBD é apresentado com frequência como substituto das personas. Não é. Os três artefatos respondem a perguntas diferentes e falham de formas diferentes, e os times maduros mantêm os três, só que com fronteiras mais claras.
| Artefato | Pergunta que responde | Melhor uso | Como falha |
|---|---|---|---|
| Persona | Quem é essa pessoa? | Posicionamento, tom de voz, escolha de canal, qualificação de vendas | Vira ficção: fotos de banco de imagens, hobbies inventados e dados demográficos que nunca mudam uma decisão de produto |
| Job to Be Done | Que progresso a pessoa está tentando fazer, e quando? | Priorização do roadmap, posicionamento frente às alternativas reais, design do onboarding, definição de ativação | Escrito na altitude errada: ou tão amplo que fica inútil ("gerir o meu negócio"), ou tão estreito que é um pedido de funcionalidade disfarçado |
| User story | O que devemos construir na próxima sprint? | Escopo e passagem para a engenharia | Vira um ticket de solução com o prefixo "como usuário", desconectado de qualquer job |
A divisão de trabalho limpa: o job decide o que merece existir, a persona decide como você fala sobre isso e a user story decide o que sai nesta sprint. Os problemas começam quando se pede a uma persona que faça o trabalho do job, e é assim que os times acabam com um roadmap cheio de funcionalidades que combinam com o público e não servem para nada em particular.
Como escrever um job statement (com modelo)
O job statement (a declaração do job) é onde a maior parte do valor é criada ou destruída. É uma frase só, e ela precisa sobreviver ao contato com o seu roadmap durante anos.
O modelo:
Quando [situação: a circunstância que dispara],
eu quero [motivação: o que estou tentando fazer],
para que eu possa [resultado esperado: como a minha vida fica melhor].
As três regras que tornam um job statement utilizável
1. Não mencione nenhuma solução
Nada de nomes de produtos, de funcionalidades ou de tecnologia. "Quando eu preciso fazer o onboarding de um novo cliente, eu quero enviar a ele uma sequência automática de e-mails" não é um job; é uma solução que alguém já escolheu. O job por trás é: "Quando eu assumo um novo cliente, eu quero que ele esteja produtivo na primeira semana sem que eu repita a mesma chamada de configuração, para que eu possa atender mais clientes sem aumentar as minhas horas."
O teste: um concorrente com uma arquitetura completamente diferente conseguiria atender a essa declaração? Se não, você escreveu uma especificação.
2. Ancore numa circunstância, não numa frequência
"Quando estou fazendo o relatório semanal" é um compromisso na agenda. "Quando me pedem um número que eu não tenho em mãos" é uma circunstância; pode acontecer toda semana, ou três vezes numa terça-feira, e diz exatamente quando o seu produto precisa aparecer. As circunstâncias são o que tornam os jobs acionáveis para o onboarding e para os gatilhos in-app, porque uma circunstância pode ser detectada no comportamento dentro do produto.
3. Escreva o resultado na linguagem do usuário, não na sua
"Para que eu possa aumentar a eficiência do time" é uma frase do seu site de marketing. "Para que eu possa deixar de ser o gargalo toda vez que alguém novo entra" é o que uma pessoa realmente diz. Cláusulas de resultado escritas na linguagem do fornecedor são o sinal mais claro de que um job statement foi inventado numa reunião, e não ouvido numa entrevista.
Cuidado com a altitude. Um job colocado alto demais ("fazer o meu negócio crescer") não serve de base para nenhum design. Um job colocado baixo demais ("filtrar a tabela por data") é uma funcionalidade. A altitude que funciona costuma ser a de algo que uma pessoa conseguiria concluir de uma vez só e descreveria como "resolvido"; e, não por acaso, esse também é o tamanho certo para a meta da primeira sessão no onboarding.
As quatro forças: por que os usuários trocam (e por que não trocam)
Um job explica o que alguém quer. As quatro forças explicam por que a pessoa finalmente faz algo a respeito, ou por que continua sem fazer nada a respeito, durante anos, enquanto o seu time de vendas manda follow-ups.
A equação é direta: uma troca só acontece quando empurrão mais atração supera ansiedade mais hábito. O marketing gasta quase toda a sua energia na atração. Vendas acrescenta um pouco de empurrão. Quase ninguém é dono do outro lado da balança, e é do outro lado que vive a maior parte da ativação que você perde.
| Força | Como ela soa | Onde você a trata |
|---|---|---|
| Empurrão | "Não dá para continuar fazendo assim." | Posicionamento, discovery de vendas, conteúdo guiado pelo problema |
| Atração | "Isso resolveria." | Landing page, demo, teste grátis |
| Ansiedade | "E se eu chegar na metade e não funcionar?" | Onboarding: dados de exemplo, desfazer, uma primeira vitória visível, primeiro uso guiado |
| Hábito | "O jeito antigo está bom, sinceramente." | Onboarding + adoção: importadores, integrações e fazer o jeito novo ser mais rápido que o antigo desde o primeiro dia |
Esta é a coisa mais útil que o JTBD oferece a um time de onboarding. Se a sua taxa de conversão de teste para pago está fraca, o instinto é fazer o produto parecer melhor. As quatro forças sugerem olhar, em vez disso, para aquilo de que os usuários têm medo nos primeiros dez minutos, um diagnóstico sobre o qual você pode agir diretamente e que abordamos pelo lado das métricas nos nossos guias de fricção do usuário e de conversão de teste grátis.
Como conduzir uma entrevista de Jobs to Be Done
A pesquisa JTBD não é uma survey e não é uma coleta de pedidos de funcionalidades. É uma tentativa estruturada de reconstruir uma decisão que já aconteceu, para encontrar as forças que a produziram.
Recrute quem trocou recentemente: pessoas que se cadastraram, fizeram upgrade ou cancelaram nos últimos 90 dias
Reconstrua a linha do tempo de trás para frente a partir do momento da decisão
Encontre o primeiro pensamento, a busca passiva, a busca ativa e o gatilho
Mapeie o que você ouviu nas quatro forças
Escreva o job statement e depois valide-o com o comportamento no produto
1. Recrute quem trocou recentemente
A recência importa mais do que o tamanho da amostra. Alguém que se cadastrou há onze meses vai contar uma história arrumada e racionalizada que tem muito pouco a ver com o que realmente aconteceu. Alguém que se cadastrou há três semanas ainda consegue dizer qual aba do navegador estava aberta e o que o colega falou na reunião logo antes.
De oito a doze entrevistas costumam bastar para ver os jobs dominantes se repetirem. Inclua usuários que cancelaram: eles são a fonte de verdade mais barata que você vai ter, e as únicas pessoas que conseguem dizer como era o job depois que você falhou nele.
2. Reconstrua a linha do tempo de trás para frente
Comece no momento da compra ou do cadastro e volte no tempo. "Você criou a conta numa terça à tarde. O que aconteceu naquela manhã?" E continue. A maioria das decisões de troca tem uma pré-história longa e silenciosa: uma primeira insatisfação vaga semanas ou meses antes, uma olhada passiva nas alternativas e, então, um evento que de repente tornou o status quo inaceitável.
3. Procure os quatro momentos
Toda história de troca tem os mesmos tempos. Primeiro pensamento ("isso está ficando irritante"). Busca passiva (ler, reparar, meio que pesquisar, sem intenção de agir). Busca ativa (comparar, ver demos, perguntar a colegas). E o gatilho, o evento concreto que converteu a intenção em ação. O gatilho é a coisa mais valiosa de toda a entrevista, porque diz ao seu marketing exatamente quando aparecer e ao seu onboarding exatamente em que estado o usuário chega.
4. Pergunte sobre comportamento, nunca sobre preferências
"O que deixaria isso melhor?" produz uma lista de desejos. "Me conte passo a passo a última vez que você tentou fazer isso" produz evidências. Boas perguntas de JTBD são quase entediantes de tão concretas: o que você tentou primeiro? Quem mais estava na sala? O que quase o impediu? O que você teve que parar de fazer para abrir espaço para isso?
A única pergunta que vale decorar: "O que quase fez você desistir?" Essa pergunta sozinha revela mais material sobre a força da ansiedade do que uma survey inteira.
5. Valide o job com o comportamento real no produto
As entrevistas dizem qual é o job. Os dados de produto dizem se o seu produto o entrega. Quando tiver um job candidato, defina como é o "job concluído" em forma de evento e verifique que proporção dos novos usuários chega até ele e quanto tempo leva. Se ninguém consegue nomear esse evento, o job ainda está abstrato demais. Os nossos guias de métricas de onboarding de usuários e de time to value mostram como instrumentar isso direito.
6 exemplos de Jobs to Be Done
Job statements abstratos são fáceis de aprovar com a cabeça e difíceis de escrever. Estes seis foram escritos de propósito numa altitude utilizável, com as dimensões funcional, emocional e social separadas.
Job statement: Quando o meu time trabalha em três ferramentas e ninguém sabe o que está travado, eu quero um lugar só que mostre o status real sem que eu precise perguntar, para que eu possa parar de gastar as minhas manhãs coletando atualizações.
- Funcional: ver o status atual de todas as frentes de trabalho sem coleta manual
- Emocional: sentir-se no controle em vez de eternamente atrasado
- Social: ser visto como o gestor que sempre sabe em que pé as coisas estão
Job statement: Quando o dinheiro entra e sai da minha empresa toda semana, eu quero saber quanto realmente devo antes do vencimento, para que eu possa parar de guardar um número aproximado na cabeça e torcer.
- Funcional: um valor de obrigações preciso e atualizado
- Emocional: trocar um medo financeiro constante por certeza
- Social: parecer organizado para um contador, um sócio ou um credor
Job statement: Quando eu preciso da aprovação de quatro pessoas em fusos horários diferentes, eu quero os comentários delas anexados à própria coisa que estão comentando, para que eu possa parar de conciliar feedbacks contraditórios de uma chamada em grupo.
- Funcional: coletar feedback contextual e identificado de forma assíncrona
- Emocional: sentir que é possível avançar sem esperar pelas agendas
- Social: ser a pessoa que entrega sem arrastar todo mundo para uma reunião
Job statement: Quando as mesmas cinco perguntas chegam todos os dias, eu quero que os clientes encontrem a resposta antes de abrir um ticket, para que eu possa dedicar o meu tempo aos problemas que realmente precisam de uma pessoa.
- Funcional: desviar as dúvidas repetitivas para o autoatendimento
- Emocional: sentir que o trabalho tem sentido, em vez de ser mecânico
- Social: mostrar à liderança que o time escala sem aumentar o quadro
Job statement: Quando um novo contratado começa na segunda-feira, eu quero tudo de que ele precisa pronto antes de ele fazer login, para que eu possa parar de pedir desculpas por contas faltando no primeiro dia.
- Funcional: provisionar contas, documentos e tarefas antes da data de início
- Emocional: evitar o constrangimento específico de uma recepção visivelmente desorganizada
- Social: representar uma empresa que tem tudo em ordem
Job statement: Quando alguém da liderança faz uma pergunta que eu não consigo responder de memória, eu quero em poucos minutos um número que eu esteja disposto a defender, para que eu possa contribuir para a decisão em vez de prometer responder depois.
- Funcional: obter rapidamente uma métrica confiável
- Emocional: sentir-se preparado em vez de exposto
- Social: ter credibilidade numa sala em que a credibilidade se acumula
Como aplicar Jobs to Be Done ao onboarding de usuários
É aqui que o JTBD deixa de ser um exercício de pesquisa e começa a se pagar. O onboarding é o momento em que o seu produto ou entrega o job ou pede ao usuário que aprenda uma interface primeiro. Quase todo onboarding ruim é a segunda opção.
1. Defina a ativação como conclusão do job, não como conclusão de etapas
A maioria das definições de ativação são indicadores indiretos de esforço: perfil preenchido, tour concluído, três funcionalidades clicadas. Nada disso é progresso do ponto de vista do usuário. Substitua-os pelo menor evento que signifique que o job foi realmente feito uma vez: um relatório compartilhado, um cliente convidado, uma fatura conciliada.
Essa única mudança costuma revelar que uma taxa de ativação com cara de saudável estava medindo a obediência ao seu tour, e não o valor entregue. O nosso guia sobre como aumentar a ativação de usuários aprofunda a escolha desse evento, e o guia do aha moment mostra como detectá-lo nos seus dados.
2. Corte cada etapa da primeira sessão que não sirva ao job
Pegue o seu fluxo atual de cadastro e de primeiro uso e marque cada etapa: ela leva o usuário a uma ocorrência concluída do job, ou serve ao seu banco de dados? Nomes de time, avatares, seletores de cargo e telas de preferências quase sempre são do segundo tipo. Eles podem esperar; veja o nosso guia de boas práticas de fluxo de cadastro para saber até onde isso pode ir.
3. Dispare a orientação pela circunstância, não pelo calendário
Um job statement nomeia uma circunstância. Circunstâncias são detectáveis: um usuário abre a seção de relatórios pela primeira vez, importa um arquivo, convida um colega ou chega a uma lista vazia. A orientação disparada nesses momentos funciona; a orientação disparada em "dia 1, dia 3, dia 7" em geral não, porque não faz ideia do que o usuário está tentando fazer naquele momento.
Com os tours de produto da Kompassify, você pode associar um tour ou um tooltip ao elemento e à página exatos onde o job realmente começa, e direcioná-lo ao segmento para o qual esse job é real, sem pedir uma release à engenharia.
4. Transforme o job no checklist
Um checklist de onboarding é o lugar mais claro para tornar um job visível, porque ele assume publicamente o que significa "feito". Escreva cada item como uma etapa do job, formulada como um resultado que o usuário reconhece: "Conecte a conta sobre a qual você realmente reporta", e não "Conclua a configuração da integração".
O checklist de onboarding e a barra de progresso da Kompassify existem exatamente para isso: mostrar ao usuário em que ponto do job ele está, e não em que ponto do seu assistente de configuração.
5. Ataque a força da ansiedade de forma explícita
Liste as três coisas de que um novo usuário mais tem medo nos primeiros dez minutos: em geral, "vou importar os dados errados", "vou quebrar algo que o meu time vai ver" e "vou passar uma hora aqui e não chegar a lugar nenhum". Depois desenhe algo que neutralize cada uma: um sandbox, um desfazer visível, um conjunto de dados de exemplo ou um caminho de cinco minutos até um primeiro resultado. A ansiedade é a força que só o onboarding consegue mover.
6. Segmente por job, não só por plano
Dois usuários no mesmo plano de preço podem chegar com jobs completamente diferentes. Uma segmentação informada pelo JTBD permite encaminhar cada um para o fluxo que serve ao job dele, a base de qualquer onboarding personalizado de verdade. Uma pergunta curta no cadastro, do tipo "o que trouxe você aqui hoje?", muitas vezes basta para ramificar, desde que as opções sejam jobs e não cargos.
A versão resumida: encontre o job, defina a ativação como o job feito uma vez, elimine da primeira sessão tudo o que não o serve, dispare a ajuda na circunstância e gaste o esforço restante na ansiedade. Essa sequência é quase tudo o que o JTBD tem a oferecer a um time de onboarding.
Erros comuns de Jobs to Be Done
✅ Faça
- Entreviste pessoas que trocaram nos últimos 90 dias
- Escreva job statements que nomeiem uma circunstância, não uma rotina
- Inclua explicitamente as dimensões emocional e social
- Trate planilhas, processos manuais e "não fazer nada" como concorrentes
- Valide cada job com um evento de produto mensurável
- Mantenha as personas, para posicionamento e canal, não para o roadmap
- Refaça as entrevistas quando o seu mercado ou o seu preço mudar
❌ Evite
- Inventar job statements num workshop sem nenhum contato com clientes
- Escrever um pedido de funcionalidade e chamá-lo de job ("eu quero exportação em massa")
- Colocar o job tão alto que nenhum design consegue partir dele
- Perguntar aos usuários o que eles querem em vez do que eles fizeram
- Supor que um produto tem exatamente um job
- Usar o JTBD para justificar uma decisão que já estava tomada
- Parar na pesquisa; um mapa de jobs que ninguém usa não muda nada
O erro mais caro: fazer as entrevistas, produzir um mapa de jobs lindo e nunca mudar o fluxo de onboarding. Um job que não altera o que um novo usuário vê na primeira sessão custou tempo de pesquisa e não trouxe nada em troca. Escolha um job, reconstrua um fluxo em torno dele e meça a mudança na ativação antes de mapear qualquer outra coisa.
Um plano de 30 dias para colocar o JTBD em prática
Semanas 1–2: encontre o job
- Levante uma lista de usuários que se cadastraram, fizeram upgrade ou cancelaram nos últimos 90 dias
- Faça de 8 a 12 entrevistas de troca, reconstruindo cada linha do tempo de trás para frente
- Classifique cada citação como empurrão, atração, ansiedade ou hábito
- Rascunhe dois ou três job statements candidatos no formato padrão
Semana 3: torne o job mensurável
- Defina o evento único que significa "o job foi feito uma vez"
- Instrumente-o e meça o alcance atual e o tempo até a primeira conclusão
- Audite a primeira sessão atual, etapa por etapa, em relação ao job; veja o nosso guia de auditoria de onboarding
- Liste as três principais ansiedades que apareceram nas entrevistas
Semana 4: reconstrua um fluxo
- Corte cada etapa da primeira sessão que não sirva ao job
- Reescreva o checklist para que cada item seja uma etapa do job
- Troque a orientação baseada em dias por gatilhos baseados em circunstâncias
- Lance um redutor de ansiedade: dados de exemplo, desfazer ou um sandbox
- Compare a taxa de conclusão do job antes e depois
Construa o onboarding em torno do job, não do menu
A Kompassify oferece tours de produto, checklists de onboarding, tooltips, barras de progresso e analytics de produto sem código: tudo de que você precisa para levar os novos usuários a um job concluído já na primeira sessão. Grátis até 100 usuários ativos mensais, em conformidade com o GDPR e hospedado na UE.
Comece grátis →Perguntas frequentes
O que é Jobs to Be Done (JTBD)?
Jobs to Be Done é um framework que explica o comportamento do cliente pelo progresso que uma pessoa está tentando fazer em determinada situação, e não por quem ela é. Em vez de descrever os usuários por dados demográficos ou cargo, o JTBD descreve o job para o qual eles contratam um produto: a tarefa funcional, o estado emocional que querem alcançar e como querem ser vistos pelos outros. A ideia central é que as pessoas não compram produtos: elas os contratam para progredir numa circunstância específica.
Qual é a diferença entre Jobs to Be Done e personas de usuário?
As personas descrevem quem o usuário é: cargo, senioridade, tamanho da empresa, ferramentas, objetivos. O Jobs to Be Done descreve o que o usuário está tentando realizar e em qual circunstância. Os dois respondem a perguntas diferentes e funcionam melhor juntos. Uma persona diz como falar com alguém e qual canal chega até essa pessoa; um job diz o que o seu produto precisa realmente fazer e aonde o seu onboarding precisa levá-la. Duas personas muito diferentes podem ter o mesmo job, e uma persona pode ter vários jobs distintos.
Como escrever um job statement?
O formato padrão é: Quando [situação], eu quero [motivação], para que eu possa [resultado esperado]. Um bom job statement não menciona solução, é estável ao longo do tempo e é específico sobre a circunstância que o dispara. Por exemplo: "Quando um novo colega entra no meio do projeto, eu quero deixá-lo produtivo sem gastar horas do meu próprio tempo, para que eu possa manter as minhas entregas em dia." Repare que nada nessa frase cita um produto, uma funcionalidade ou uma tecnologia; esse é o teste.
Quais são as quatro forças do progresso no JTBD?
As quatro forças explicam por que um cliente troca ou não troca de solução. O empurrão (push) é a frustração com a situação atual. A atração (pull) é o apelo da nova solução. A ansiedade é o medo do que pode dar errado com a nova solução. O hábito é o conforto do jeito atual de fazer as coisas. A troca só acontece quando empurrão mais atração é mais forte do que ansiedade mais hábito. A maior parte do trabalho de onboarding é, na verdade, reduzir a ansiedade e deslocar o hábito, não aumentar a atração.
Como conduzir uma entrevista de Jobs to Be Done?
Entreviste pessoas que trocaram recentemente para o seu produto ou deixaram de usá-lo, de preferência nos últimos 90 dias, enquanto a memória ainda está fresca. Reconstrua uma linha do tempo de trás para frente a partir do momento da compra: quando perceberam pela primeira vez que algo precisava mudar, o que tentaram, o que disparou a busca, o que quase as impediu de se cadastrar. Pergunte sobre eventos e comportamento, nunca sobre opiniões ou desejos de funcionalidades. De oito a doze entrevistas com quem trocou recentemente costumam revelar os jobs dominantes.
Como o Jobs to Be Done melhora o onboarding de usuários?
A maior parte do onboarding falha porque ensina a interface em vez de entregar o job. Quando você conhece o job, pode definir uma primeira sessão que conclui uma ocorrência significativa dele, cortar cada etapa que não o serve e medir a ativação como conclusão do job, e não como etapas finalizadas. Na prática, isso significa um checklist cujos itens correspondem ao job, tours de produto que aparecem no momento do job, e não no primeiro login, e estados vazios que mostram como é o job concluído.
O Jobs to Be Done só é útil para produtos novos?
Não. O JTBD é possivelmente ainda mais útil em produtos maduros, em que a lista de funcionalidades cresceu mais rápido do que a clareza. Ele dá a um time já estabelecido uma forma de decidir o que cortar, qual segmento está realmente sendo atendido e por que uma funcionalidade bem construída não está sendo adotada. Fazer entrevistas JTBD com usuários que cancelaram é uma das formas mais rápidas de descobrir se você os perdeu para um concorrente, para uma solução improvisada interna ou para o desaparecimento do próprio job, uma distinção que o nosso guia de churn de usuários explora em mais detalhes.