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 vivem.
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 banalizadas. Produtos que abordam as três dimensões são muito mais difíceis de substituir.
A melhor investigação JTBD concentra-se 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 retirar prioridade — mesmo que a funcionalidade pareça apelativa.
O JTBD também revela onde está a servir em excesso. 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.