Você fez as entrevistas. Ouviu os clientes. Identificou o que eles pediam. Desenvolveu a solução. Lançou. E não funcionou. O problema não estava na resposta. Estava na pergunta.
O que pesquisa de cliente realmente mede
A maioria das empresas faz pesquisa de cliente usando os mesmos métodos: entrevistas abertas, surveys de satisfação, NPS, grupos focais, testes de usabilidade. São ferramentas legítimas, mas capturam um tipo específico de dado: o que o cliente diz que quer.
E o que o cliente diz que quer é diferente do que ele faz quando o problema aparece.
Não porque o cliente mente. Porque ele não tem acesso consciente ao seu próprio comportamento. Quando alguém responde “eu quero um relatório mais visual”, o que essa pessoa está descrevendo é uma preferência declarada, não um comportamento real. O que ela faz quando precisa comunicar resultado para um gestor, como ela monta isso hoje, o que trava esse processo, o que acontece se ela não conseguir: tudo isso fica fora da resposta.
Pesquisa de opinião mede intenção. O problema é que produto não é comprado por intenção. É contratado para resolver algo que já está acontecendo.
O reframing que muda tudo
Jobs to Be Done parte de uma premissa simples: o cliente não compra produto. Ele contrata algo para realizar um job.
Um job é uma situação concreta que acontece na vida da pessoa e cria uma necessidade de progresso. O job existe antes do produto existir. Ele existiria mesmo que a sua solução não existisse.
Um exemplo clássico: pessoas contratam um milk-shake de manhã não porque gostam de milk-shake, mas porque precisam de algo que segure a fome até o almoço e que possam consumir enquanto dirigem. O job é “passar a manhã sem fome sem parar o carro”. O milk-shake é a solução contratada para isso. O concorrente direto não é outro shake: é uma banana, uma barra de cereal, um café com pão. (Caso queira se aprofundar, deixo o link do nosso outro post referente a JTBD: Tudo sobre Jobs to Be Done (JTBD))
Em contexto B2B, o mecanismo é o mesmo. Um software de gestão não é contratado porque a empresa gosta de software. É contratado porque o gestor de compras não consegue justificar para o financeiro por que um contrato está sendo renovado sem histórico de performance. O job é visibilidade para defender uma decisão. O software é a solução contratada.
Quando a pesquisa de cliente pergunta “o que você quer no produto”, ela pula direto para a solução. O JTBD volta duas casas: o que está acontecendo na sua vida que criou essa necessidade?
O arco de perguntas que revela o job
Entrevista JTBD não segue um roteiro de features. Segue o arco do comportamento, da situação que ativa o problema até o gap que nenhuma solução ainda resolve.
- Mapeie o contexto de ativação. O job não existe em abstrato: ele aparece em momentos específicos. Reunião com investidor, fechamento de mês, onboarding de novo colaborador. Saber quando o job aparece define onde o produto precisa estar presente.
- O que está tentando resolver? O cliente descreve o job no próprio vocabulário dele. Não o que o produto faz, mas o que ele precisa conseguir. “Preciso mostrar que a decisão faz sentido.” “Preciso evitar que o projeto atrase.” Essa frase, exatamente como o cliente articula, vale mais do que qualquer pesquisa de feature.
- Como é feito isso? Revela o real concorrente do produto e o nível de dor que a pessoa já aceita como normal. Pode ser uma planilha, um processo manual ou uma ferramenta adaptada para outro fim.
- Como funciona? Fricção no processo atual. O cliente já está fazendo algo, mas algo nesse processo trava, atrasa ou gera retrabalho. Essa dificuldade é o ponto exato onde um produto pode criar valor imediato.
- E depois? Jobs não existem isolados. Resolver um job muitas vezes aciona outro. Essa pergunta revela o job adjacente, que pode ser o próximo produto ou feature com maior tração.
O que muda quando você usa esse enquadramento
A diferença não é só qualitativa. É estrutural.
Com pesquisa de opinião, você coleta uma lista de pedidos. Com entrevista JTBD, você coleta o comportamento por trás dos pedidos. São dados de natureza diferente.
Um pedido pode ser implementado diretamente ou negado diretamente. Um job, quando identificado com clareza, orienta toda uma linha de decisão: o que construir, como precificar, como comunicar, quem é o real decisor de compra e quem é o usuário final.
Times que trabalham com JTBD param de debater “qual feature priorizar” e passam a debater “qual necessidade atacar”. Isso não é só mudança de linguagem. É mudança de critério de decisão.
E quando o critério de decisão muda, as chances de construir algo que o cliente realmente contrata aumentam de forma significativa.
Focus Map
Conduzir entrevistas JTBD é uma coisa. Cruzar o que dez, vinte, cinquenta clientes disseram e identificar os jobs que aparecem com frequência é outra. O Focus Map estrutura o processo de entrevista com cliente, organiza as respostas por job e permite visualizar onde os padrões se repetem entre entrevistados. O resultado não é uma lista de feedbacks: é um mapa de oportunidades com base no comportamento real.
