Clayton Christensen costumava contar uma história sobre uma cadeia de fast food que queria vender mais milk-shakes. Entrevistaram clientes sobre preferências de sabor, níveis de doçura e tamanho do copo. Nada do que mudaram mexeu nas vendas. Então um investigador tentou uma abordagem diferente: ficou num parque de estacionamento a observar pessoas a comprarem milk-shakes. Fez uma única pergunta — "o que estava a tentar fazer quando decidiu tomar um milk-shake esta manhã?"
A resposta: a maioria dos compradores de milk-shake de manhã tinha uma longa e tediosa viagem pela frente. Queriam algo que os mantivesse ocupados e que não os deixasse com fome antes do almoço. O milk-shake fazia isso melhor do que uma banana (demasiado rápida), um bagel (demasiado sujo) ou um café (demasiado pequeno). O produto com que competiam não eram 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. Contratam-nos para fazer um trabalho nas suas vidas.
Na terminologia do JTBD, um "trabalho" é o progresso que uma pessoa está a tentar fazer numa circunstância particular. Não é uma tarefa ("preciso de enviar um ficheiro"). Não é um objetivo ("quero ser mais produtivo"). É o progresso específico que uma pessoa específica está a tentar fazer numa situação específica — com todo o contexto, as restrições e as emoções que rodeiam 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á a tentar alcançar) e um resultado (a definição de sucesso na perspetiva 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 despedido.
Escrever declarações formais de JTBD força clareza sobre qual trabalho o seu produto está realmente a ser contratado para fazer — e revela lacunas entre o que acha que é o trabalho e o que os utilizadores realmente vivenciam.
Note 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 na perspetiva do utilizador. Nada disto apareceria num inquérito a perguntar "que funcionalidades quer?"
Todo o trabalho tem três dimensões, e os produtos que abordam apenas a funcional deixam valor real na mesa.
O Slack não cresceu porque era melhor do que o e-mail a enviar mensagens (funcional). Cresceu porque fez as equipas sentirem-se mais ligadas e vivas (emocional) e fez os indivíduos sentirem-se 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 investigação JTBD foca no momento da contratação — a decisão de começar a usar um produto — e no momento do despedimento — a decisão de parar. Ambos os momentos são ricos em sinal.
Para a entrevista de contratação, pergunte: "Recorde a última vez que decidiu usar [produto]. O que estava a acontecer? O que estava a tentar alcançar? O que mais tentou primeiro?" Para a entrevista de despedimento: "Quando parou de usar [produto]? O que estava a fazer imediatamente antes de decidir mudar? O que a alternativa fazia de diferente?"
As respostas vão quase sempre surpreendê-lo. Os utilizadores descreverão situações, frustrações e motivações que a sua equipa nunca antecipou. Esse é o ponto. A investigação JTBD não é investigação de validação — é investigação de descoberta. Não está a testar os seus pressupostos; está a substituí-los por evidências.
Depois de identificados os principais trabalhos para os quais o seu produto é contratado, use-os como filtro para cada decisão significativa de produto. Para qualquer funcionalidade proposta, pergunte: que trabalho específico ajuda os utilizadores a fazer progresso? Se a resposta for "nenhum dos nossos trabalhos principais", é um forte sinal para despriorizar — mesmo que a funcionalidade pareça apelativa.
O JTBD também revela onde está a servir demais. Se os utilizadores têm um trabalho que já está a ser 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 utilizadores com trabalhos diferentes. A lente dos trabalhos mostra onde investir e onde parar.