Clayton Christensen costumava contar uma história sobre uma rede de fast food que queria vender mais milk-shakes. Eles entrevistaram clientes sobre preferências de sabor, níveis de doçura e tamanho do copo. Nada do que mudaram moveu as vendas. Então um pesquisador tentou uma abordagem diferente: ficou em um estacionamento observando pessoas comprarem milk-shakes. Fez uma única pergunta — "o que você estava tentando fazer quando decidiu tomar um milk-shake esta manhã?"
A resposta: a maioria dos compradores de milk-shake pela manhã tinha um longo e tedioso trajeto pela frente. Queriam algo que os mantivesse ocupados e não os deixasse com fome antes do almoço. O milk-shake fazia isso melhor do que uma banana (muito rápida), um bagel (muito sujo) ou um café (muito pequeno). O produto com o qual competiam não era outros milk-shakes — eram o tédio e a fome.
Essa história é a essência do Jobs-to-be-Done. As pessoas não compram produtos. Elas os contratam para fazer um trabalho em suas vidas.
Na terminologia do JTBD, um "trabalho" é o progresso que uma pessoa está tentando fazer em uma circunstância particular. Não é uma tarefa ("preciso enviar um arquivo"). Não é um objetivo ("quero ser mais produtivo"). É o progresso específico que uma pessoa específica está tentando fazer em uma situação específica — com todo o contexto, as restrições e as emoções que cercam aquele momento.
O trabalho tem três componentes: uma situação (o gatilho que cria a necessidade), uma motivação (o que a pessoa está tentando alcançar) e um resultado (a definição de sucesso da perspectiva dela). Os três importam. Um produto que acerta na motivação mas ignora a situação será usado nos momentos errados. Um produto que acerta na situação mas ignora o resultado será contratado e rapidamente demitido.
Escrever declarações formais de JTBD força clareza sobre qual trabalho seu produto está realmente sendo contratado para fazer — e revela lacunas entre o que você acha que é o trabalho e o que os usuários realmente vivenciam.
Observe como cada declaração revela algo que uma lista de funcionalidades nunca revelaria: as apostas emocionais, o contexto de forças concorrentes e a definição de sucesso da perspectiva do usuário. Nada disso apareceria numa pesquisa perguntando "quais funcionalidades você quer?"
Todo trabalho tem três dimensões, e produtos que abordam apenas a funcional deixam valor real na mesa.
O Slack não cresceu porque era melhor do que o e-mail para enviar mensagens (funcional). Cresceu porque fez os times se sentirem mais conectados e vivos (emocional) e fez os indivíduos se sentirem parte de uma conversa em tempo real em vez de uma fila de caixa de entrada (social). Funcionalidades que abordam apenas o trabalho funcional são facilmente comoditizadas. Produtos que abordam as três dimensões são muito mais difíceis de substituir.
A melhor pesquisa JTBD foca no momento da contratação — a decisão de começar a usar um produto — e no momento da demissão — a decisão de parar. Ambos os momentos são ricos em sinal.
Para a entrevista de contratação, pergunte: "Pense na última vez que decidiu usar [produto]. O que estava acontecendo? O que você estava tentando realizar? O que mais você tentou primeiro?" Para a entrevista de demissão: "Quando você parou de usar [produto]? O que você estava fazendo logo antes de decidir mudar? O que a alternativa fazia de diferente?"
As respostas quase sempre vão surpreender você. Os usuários descreverão situações, frustrações e motivações que sua equipe nunca antecipou. Esse é o ponto. A pesquisa JTBD não é pesquisa de validação — é pesquisa de descoberta. Você não está testando suas suposições; está substituindo-as por evidências.
Uma vez identificados os principais trabalhos para os quais seu produto é contratado, use-os como filtro para cada decisão significativa de produto. Para qualquer funcionalidade proposta, pergunte: qual trabalho específico isso ajuda os usuários a fazerem progresso? Se a resposta for "nenhum dos nossos trabalhos principais", isso é um forte sinal para despriorizar — mesmo que a funcionalidade pareça atraente.
O JTBD também revela onde você está servindo demais. Se os usuários têm um trabalho que já está sendo feito bem o suficiente, adicionar mais funcionalidades nessa área oferece retornos decrescentes — e potencialmente adiciona complexidade que torna o produto mais difícil de usar para usuários com trabalhos diferentes. A lente dos trabalhos mostra onde investir e onde parar.