Negli anni 2000 una catena di fast food chiese a Clayton Christensen di capire come vendere più milkshake. Il team aveva già provato di tutto: nuovi gusti, sondaggi sui clienti, milkshake più densi, milkshake più cremosi. Niente spostava le vendite. Christensen ribaltò la domanda. Invece di chiedere “come rendere il milkshake migliore”, chiese: “che lavoro stanno cercando di fare le persone quando comprano un milkshake?”.

La risposta lo sorprese. Quasi metà dei milkshake veniva venduta prima delle nove del mattino, a persone sole, che lo prendevano da asporto. Non lo bevevano per fame né per golosità. Lo “assumevano” per rendere meno noioso un lungo tragitto in auto verso il lavoro. Il milkshake era denso, durava tutto il viaggio, si beveva con una mano sola e non sporcava. Stava battendo concorrenti che nessuno avrebbe mai considerato: la banana, il cornetto, la ciambella, la barretta. Da qui nasce la teoria Jobs to be Done.

Cosa significa Jobs to be Done

La teoria Jobs to be Done (spesso abbreviata in JTBD) parte da un’idea semplice e scomoda: le persone non comprano prodotti, li assumono per svolgere un compito nella loro vita. Quando un bisogno emerge in una situazione concreta, la persona “ingaggia” qualcosa per portarlo a termine. Se quel qualcosa fa bene il lavoro, lo riassume; altrimenti lo licenzia.

C’è una frase che riassume tutto, attribuita a Theodore Levitt e ripresa da generazioni di marketer: nessuno vuole un trapano da un quarto di pollice, vuole un buco da un quarto di pollice. Ma se ci pensi, è ancora incompleta. Nessuno vuole davvero il buco nel muro. Vuole appendere quel quadro per far sentire la casa più sua. Il “job” vero quasi sempre sta un livello più in alto di quanto immaginiamo, ed è lì che si nascondono le opportunità che i competitor non vedono.

Le tre dimensioni di ogni job

Un errore comune è ridurre il job alla sua parte pratica. Ogni compito che una persona cerca di svolgere ha in realtà tre dimensioni che convivono.

• Funzionale: il risultato pratico e misurabile. Spostarmi da A a B, tagliare il documento entro la scadenza, far durare la batteria fino a sera.
• Emotiva: come la persona vuole sentirsi. Sicura di aver scelto bene, tranquilla, sollevata da un’ansia, padrona della situazione.
• Sociale: come la persona vuole essere percepita dagli altri. Competente agli occhi del capo, generosa con gli amici, aggiornata nel proprio settore.

Tornando al milkshake: la dimensione funzionale era riempire un viaggio noioso senza sporcare. Quella emotiva era darsi una piccola coccola all’inizio di una giornata pesante. Un prodotto che colpisce tutte e tre le dimensioni diventa difficilissimo da spodestare. Un prodotto che ne soddisfa solo una è sempre a un passo dall’essere licenziato.

Come si scoprono i job degli utenti

I job non si trovano nei sondaggi a risposta chiusa né nelle dashboard di prodotto. Si scoprono parlando con le persone, ma con un metodo preciso. Le interviste JTBD ricostruiscono la storia di un acquisto reale e recente, partendo dal momento in cui il bisogno è nato.

Le domande giuste

L’obiettivo non è chiedere cosa vorrebbero (la gente è pessima nel prevedere il proprio comportamento futuro) ma ricostruire cosa è successo davvero. Alcune domande che funzionano:

• Quando hai capito per la prima volta che ti serviva qualcosa del genere? Dove eri, cosa stava succedendo?
• Cosa usavi prima e perché hai smesso?
• Quali alternative hai valutato, anche quelle che non c’entrano col mio prodotto?
• Cosa ti ha fatto decidere proprio quel giorno e non una settimana prima?
• Chi altro era coinvolto nella decisione?

La domanda sulle alternative è quella che apre più porte. Scopri che il tuo vero concorrente non è l’app simile alla tua, ma un foglio Excel, un’abitudine consolidata o il “non fare niente”. Quello è il momento in cui la teoria smette di essere accademica e diventa una mappa per la roadmap.

Come JTBD cambia la roadmap e l’innovazione

Quando definisci il mercato in termini di job e non di prodotto, l’innovazione cambia direzione. Smetti di rincorrere le feature dei competitor e inizi a chiederti se stai facendo bene il lavoro che le persone ti hanno affidato. Il fast food del milkshake, una volta capito il job del mattino, poteva renderlo ancora più denso e venderlo in distributori automatici per saltare la coda. Soluzioni invisibili finché si ragionava per gusto e calorie.

Per un Product Manager questo significa una roadmap costruita attorno ai progressi che l’utente vuole ottenere, non attorno a una lista di richieste isolate. Le feature diventano mezzi, non fini. E quando un job è ben capito, anche dire di no a una richiesta diventa facile: se non aiuta l’utente a fare meglio il suo lavoro, non entra.

JTBD non è la buyer persona

Qui si annida la confusione più frequente. La buyer persona descrive chi è l’utente: età, ruolo, abitudini, “Marco, 34 anni, manager con poco tempo”. Il job descrive cosa sta cercando di ottenere in una situazione specifica. Sono complementari, ma rispondono a domande diverse.

Il problema delle persona usate da sole è che persone molto diverse possono condividere lo stesso job, e la stessa persona può avere job opposti in momenti diversi della giornata. Marco da solo in auto alle 7 del mattino ha un job; Marco che porta i figli al parco la domenica ne ha un altro, anche se è sempre lo stesso “Marco, 34 anni”. La persona ti dice a chi parlare. Il job ti dice cosa costruire.

Gli errori più comuni

La teoria è semplice da capire e facile da applicare male. Tre trappole ricorrenti:

• Confondere il job con la soluzione. “Il job dell’utente è usare il nostro filtro avanzato” non è un job, è una feature. Il job sta sempre nel risultato che la persona vuole nella sua vita.
• Definirlo troppo in alto o troppo in basso. “Essere felice” è inutilizzabile, “cliccare il bottone blu” è troppo stretto. Il livello giusto è quello che fa emergere alternative inaspettate.
• Ignorare le dimensioni emotiva e sociale. Concentrarsi solo sul funzionale porta a prodotti corretti ma freddi, che funzionano e nessuno ama.

Domande frequenti

Qual è la differenza tra Jobs to be Done e una user story?

La user story descrive un requisito dal punto di vista dell’utente (“come utente voglio X per ottenere Y”) ed è uno strumento di backlog. Il job è più a monte: è il motivo profondo per cui l’utente ricorre al tuo prodotto. Una buona comprensione del job genera user story migliori, ma le due cose lavorano a livelli diversi del processo.

Servono molte interviste per individuare un job?

Meno di quanto si pensi. Già con sei o otto interviste ben condotte sugli stessi acquisti reali iniziano a emergere pattern ricorrenti. La qualità della conversazione conta molto più del numero: una storia raccontata in dettaglio vale più di cento sondaggi superficiali.

Jobs to be Done funziona solo per prodotti fisici?

No, anzi. Nasce dall’analisi di prodotti di consumo ma si applica al software, ai servizi B2B e perfino alle decisioni interne. Ogni volta che qualcuno “assume” qualcosa per fare progressi, c’è un job da capire.

Il valore della teoria Jobs to be Done non sta nel framework in sé, ma nell’abitudine mentale che impone: smettere di partire dal prodotto e partire dalla vita della persona. È esattamente questo a separare un Product Manager che costruisce con intenzione da uno che copia le feature dei competitor sperando che funzionino. Il primo sa quale lavoro sta cercando di fare il suo utente. Il secondo spera solo di indovinare.