Antes de tudo, é preciso esclarecer que essa metodologia de pesquisa foi criada por um consultor de produto e tecnologia renomado no mercado, chamado Tom Ulwick. Ela é uma parte da sua abordagem chamada “Outcome Driven Innovation”, embora a nomenclatura também seja usada por outra escola de produto iniciada pelo professor de Harvard Clayton M. Christensen.
O que é um job-to-be-done: segundo o professor de Harvard Clayton M. Christensen, quando uma pessoa contrata um produto ou serviço, seja lá qual for ele, ela não está transacionando uma compra. Ela está contratando aquilo para executar um job. Um exemplo: quando você compra uma furadeira, você está contratando ela para que ela faça um serviço para você. Cabe você entender que tipo de serviço é esse. Você pode dizer que ela está sendo contratada para fazer um furo na parede. Mas isso é simples demais. Ninguém sai por aí fazendo furos nas paredes a esmo. Por que se faz um furo na parede? Para pendurar um quadro. OK, aí estamos chegando em um algum lugar. Mas é possível ir além. Por que se pendura um quadro? Para preservar memórias, para estilizar a casa. Esse enquadramento nos permite ver quem são os concorrentes, que problema precisa ser resolvido, posicionamento de marketing, etc.
Se você já tem uma noção do ambiente no qual você quer explorar problemas e soluções, comece por mapeá-lo. Com esse mapa dentro do framework, você vai conseguir visualizar quais jobs os usuários envolvidos executam para extrair valor de uma solução de mercado, os “desired outcomes”. Tudo isso é uma suposição, mas vai te ajudar a elaborar as perguntas para entrevistas futuras. Na medida em que você conversa com o usuário real, você vai entender
Com isso em mãos, a ideação vai se tornar muito mais assertiva.
Comece pelo Job Executor
Quem de fato executa o trabalho? Não o comprador, não o aprovador de orçamento, quem coloca a mão na massa. É com essa pessoa que você precisa começar.
O job funcional principal é estável no tempo. Ele não muda mesmo quando a tecnologia muda. "Gerenciar o fluxo de caixa da empresa" é um job. "Usar uma planilha" não é.
A partir daí, desmembre esse job nas etapas de execução: Definir → Localizar → Preparar → Confirmar → Executar → Monitorar → Modificar → Concluir. Para cada etapa existem desired outcomes, ou seja, as métricas que o cliente usa para avaliar se a etapa foi bem executada. Um cliente típico tem mais de 100 outcomes. Seu trabalho é descobrir quais estão subatendidos.
Consumption Chain Jobs
O que o cliente precisa fazer antes e depois de usar sua solução (comprar, instalar, aprender, manter, descartar)
Outros trabalhos que ele tenta executar em paralelo
Como ele quer se sentir (ou não sentir) ao longo do processo, exemplo: para quê uma pessoa usa o instagram? Para compatilhar fotos? Não, para manter seu status social, para se manter perto da família, etc.
Purchase Decision Maker e Financial Metrics
Quem decide a compra raramente é quem executa o job. Mapear os dois separadamente evita construir um produto ótimo que nunca passa pelo orçamento.
Não pergunte o que o cliente quer. Peça para ele contar a última vez que tentou executar aquele job (do começo ao fim). Onde travou? O que improvisou? O que considerou "missão cumprida"?
Os insights estão nos detalhes dessas histórias. Segundo Ulwick, produtos que resolvem o job 20% melhor do que as alternativas atuais têm altíssima probabilidade de vencer no mercado. Esse é o número que você está buscando quando mapeia os outcomes subatendidos.
Baixe a roda, use as camadas como roteiro de entrevista e, antes de definir qualquer solução, certifique-se de que você realmente conhece o job.
