São as duas faces da mesma moeda. Cada um por si é útil. Juntos são transformadores.
Jobs To Be Done diz-nos que progresso o cliente procura e porque decide mudar. Dá-nos o contexto humano: as frustrações, as aspirações, o Switch Moment. Permite-nos formular a proposta de valor a partir do cliente, não do produto.
Sem JTBD, pode medir outcomes, mas sem entender porque esse job importa, não saberá como comunicá-lo nem como desenhar a experiência em torno dele.
Outcome-Driven Innovation diz-nos o que melhorar primeiro. Converte o job numa lista priorizada de outcomes com pontuações objetivas. Dá-nos o rigor quantitativo: saber que o outcome X tem pontuação 14.2 e o Y tem 11.8 elimina a política do Roadmap.
Sem ODI, JTBD pode ficar numa filosofia interessante mas sem tradução operacional. ODI aterra o framework em decisões de produto concretas.
Toda oportunidade de inovação começa com uma fricção. Bob Moesta chama-lhe o struggle: o momento em que o status quo deixa de ser tolerável e o cliente começa a procurar alternativas. Sem struggle real, não há energia para mudar.
O struggle nem sempre é uma queixa explícita. Muitas vezes é silencioso: o cliente não se queixa, simplesmente inventa uma solução paralela. É aí que aparecem os workarounds — remendos caseiros que assinalam exatamente onde está a lacuna.
A questão-chave antes de qualquer entrevista de utilizador: «O que está o cliente a fazer em torno do seu produto que o seu produto deveria estar a fazer por ele?»
O cliente usa o seu software mas mantém um Excel extra para ter «tudo claro». Sinal: reporting ou visibilidade insuficiente.
Cada semana repete passos que o sistema deveria automatizar. Sinal: lacuna real de automatização.
Liga a sua ferramenta a outras via Zapier ou scripts próprios. Sinal: as integrações nativas não cobrem o seu fluxo real.
Um processo em seis fases que vai desde a compreensão profunda do cliente até ao Roadmap de inovação priorizado.
Para que job contratam os clientes o seu produto? Formulamos o job statement (situação, motivação, resultado) e validamo-lo através de entrevistas de switch.
JTBDIdentificamos o Push (fricções atuais), Pull (promessa nova), Ansiedades e Hábitos. Isto dá-nos o mapa emocional para comunicação e vendas.
JTBD (Moesta)Decompõe o job nas suas 8 fases (Definir, Localizar, Preparar, Confirmar, Executar, Monitorizar, Modificar, Concluir) para encontrar outcomes em cada etapa.
ODI (Ulwick)Geramos a lista exaustiva de outcomes no formato Ulwick: "Minimizar/Maximizar [métrica] de [objeto] quando [contexto]." Normalmente entre 50 e 150 outcomes por job.
ODI (Ulwick)Inquirimos clientes reais medindo a importância e satisfação atual de cada outcome. Calculamos a pontuação ODI e construímos a matriz de oportunidades.
ODI (Ulwick)Com as pontuações em mãos, definimos que Features construir, quais eliminar (mercado sobreatendido) e como comunicar a proposta de valor para o job principal.
JTBD + ODIBob Moesta desenhou a entrevista de timeline para reconstruir cronologicamente a jornada do cliente desde que começa a duvidar até que compra. Não pergunta «porque comprou?». Reconstrói a história para entender que forças atuaram em cada momento.
Quando foi a primeira vez que pensou que poderia precisar de algo diferente? Revela o início do struggle e a faísca que acendeu a procura.
O cliente começa a prestar atenção a alternativas sem urgência. Vê anúncios, lê artigos, ouve colegas. Está aberto mas não age. Esta fase pode durar meses.
Um evento desencadeador gera urgência. O cliente compara opções deliberadamente: demos, testes, conversas com vendedores. O trigger que separa esta fase da anterior é ouro para vendas e marketing.
Que informação foi decisiva? Que ansiedades ficaram por resolver? O que inclinou a balança? Aqui revelam-se os critérios reais de compra — não os declarados.
A diferença entre Little Hire (comprar) e Big Hire (usar de facto). O cliente integrou o produto no seu fluxo? O job foi resolvido? Aqui valida-se ou invalida-se toda a proposta de valor.
«Não pergunte porque compraram. Pergunte quando foi a primeira vez que pensaram que precisavam de algo diferente. É aí que começa a história real.»
Bob Moesta — Demand-Side Sales 101
As empresas acumulam Features defensivamente: por medo de perder clientes ou por responder a pedidos isolados. O resultado é um produto que faz muitas coisas mas que nenhum cliente usa na totalidade.
ODI dá-nos permissão para simplificar. Quando vê que 60% do seu Roadmap corresponde a outcomes com pontuação < 8, a decisão de não os construir deixa de ser subjetiva.
As empresas vendem a sandes completa (toda a proposta de valor), mas o cliente só quer a maionese (o progresso que precisa agora). JTBD identifica exatamente que parte da sandes é a maionese de cada segmento.
Resultado: propostas de valor mais precisas, ciclos de venda mais curtos e menor abandono no onboarding.
O próximo vencedor num mercado sobreatendido raramente é o mais completo. É o mais conveniente. A disrupção chega de produtos mais simples que resolvem melhor os 3-4 outcomes que mais importam.
Identificar esses 3-4 outcomes com ODI e focar-se neles é a estratégia correta para startups que atacam mercados estabelecidos.
"Há uma assimetria fundamental: os clientes não conseguem articular o que querem, mas conseguem dizer-lhe como medem o sucesso. JTBD ajuda-o a ouvir o segundo, e ODI a quantificá-lo."
— Toni Guitart Ventura, Venturae
Imagine um SaaS de gestão de projetos para equipas de engenharia. A equipa de produto leva meses a debater se deve adicionar mais integrações ou melhorar o sistema de notificações.
Com JTBD: Descobrimos que o job principal é "manter toda a equipa alinhada nas prioridades sem ter de fazer reuniões de status". O Switch Moment costuma ser "após um projeto falhado por descooordenação".
Com ODI: Ao inquirir 80 clientes, os outcomes mais críticos revelam-se ser "minimizar o tempo para saber em que está bloqueado cada membro da equipa" (ODI: 16.4) e "maximizar a visibilidade do impacto de cada tarefa no objetivo global" (ODI: 15.1).
Decisão: Nem mais integrações nem melhor sistema de notificações. O Roadmap Q3 foca-se num dashboard de bloqueios em tempo real e na visualização de dependências entre objetivos. É isso que os clientes medem.