Jobs to Be Done (JTBD) è un framework che riformula la domanda fondamentale del design di prodotto: invece di chiedere "chi è il mio utente?" chiedi "perché il mio utente sta usando un prodotto?". La differenza è sottile ma cambia radicalmente il modo in cui si progetta.
Il framework è stato reso celebre da Clayton Christensen, professore di Harvard e autore di "The Innovator's Dilemma", attraverso la sua famosa teoria raccontata nel 2007: "Le persone non comprano un trapano. Comprano un buco nel muro. E in realtà nemmeno un buco nel muro — comprano la soddisfazione di avere un quadro appeso". Questa intuizione, apparentemente banale, ha cambiato il modo in cui team di prodotto come Intercom, Basecamp, Spotify e molte startup pensano al loro lavoro.
In questa guida ti spiego cos'è il framework JTBD in termini concreti, come formulare un job statement che ti serve davvero, la differenza tra JTBD e user persona, e come applicarlo con esempi reali di prodotti che lo usano.
Cosa imparerai leggendo:
- Cos'è un "job" nel senso JTBD (e non è un lavoro)
- La struttura di un job statement e come scriverne uno corretto
- La differenza tra JTBD e user persona (complementari, non alternative)
- I tre tipi di job: funzionale, emotivo, sociale
- Come condurre "job interviews" (diverse dalle interviste classiche)
- 5 esempi reali di prodotti che hanno usato JTBD per decisioni strategiche
Cos'è un "Job" nel framework JTBD
Un job nel framework JTBD non è un'occupazione. È un compito che l'utente sta cercando di compiere in una specifica circostanza. Il nome completo è "Job to be Done" perché enfatizza che c'è qualcosa da fare, non qualcuno da essere.
La definizione più rigorosa viene da Tony Ulwick, l'altro padre del framework (Strategyn):
"Un job è un obiettivo fondamentale che la gente cerca di raggiungere, indipendentemente dalle soluzioni disponibili sul mercato in un dato momento."
Tre caratteristiche distinguono un job da un "bisogno" o da una "feature":
- È indipendente dalla soluzione. "Ascoltare musica mentre corro" è un job. "Comprare le AirPods" non lo è — le AirPods sono una possibile soluzione al job.
- È stabile nel tempo. I job restano costanti per decenni. Le soluzioni cambiano: dalle cassette agli MP3 agli streaming. Il job "ascoltare musica mentre mi muovo" è identico dal 1979 (Walkman).
- È contestuale. Lo stesso utente ha job diversi in circostanze diverse. La stessa persona che al mattino "vuole arrivare al lavoro senza stress" la sera "vuole rilassarsi con una serie TV".
Il classico esempio del milkshake
Christensen racconta un caso famoso: una catena di fast food voleva aumentare le vendite di milkshake. Studiando le persona dei clienti (età, genere, reddito) non emergeva niente di utile. Poi qualcuno chiese: "Per quale job gli utenti assumono il milkshake?".
Studiandoli in contesto, scoprirono che il 40% dei milkshake si vendeva al mattino alle 7:30. Il profilo tipico era un pendolare che stava guidando verso il lavoro. Perché comprava proprio un milkshake?
Il "job" era questo: "Voglio qualcosa che mi tenga occupato durante i 30 minuti di viaggio, che mi faccia sentire meno solo nel traffico, che non mi sporchi le mani, che non sia così pesante da farmi addormentare, e che mi soddisfi abbastanza da non avere fame fino alle 11".
Capito il job, la soluzione è cambiata: milkshake più denso (dura più a lungo), con pezzi di frutta (qualcosa da esplorare mentre guidi), porzionato in bicchieri che entrano nel portabibite. Le vendite sono raddoppiate.
Nessuna persona demografica avrebbe portato a quella soluzione. Solo capendo il job nel contesto specifico.
Come si formula un Job Statement
Il job statement è la sintesi scritta di un job to be done. Esistono diverse formule ma quella più diffusa è quella di Tony Ulwick (Strategyn):
Verbo + oggetto del verbo + qualificatore di contesto
Esempi:
- "Minimizzare il tempo speso a organizzare note di riunione" (produttività knowledge worker)
- "Sentirmi meno solo durante le pause lavoro" (app di messaggistica)
- "Trovare un ristorante vicino dove mangiare con amici senza passare ore a cercare" (app di food delivery)
- "Tenere il mio team allineato sugli obiettivi trimestrali" (strumento di project management B2B)
Le 3 regole d'oro di un job statement
- Usa un verbo d'azione (minimizzare, trovare, sentire, capire, evitare). Non aggettivi vaghi come "essere produttivo".
- Nessun riferimento alla soluzione. "Usare Slack per comunicare" è sbagliato. "Comunicare con i colleghi senza interrompere il loro focus" è corretto.
- Stabile nel tempo. Se il job suona come qualcosa che cambierà tra 10 anni, è troppo specifico. Astraggi.
Il "When... I want... So I can..." — la forma estesa
Alan Klement ha proposto una variante narrativa utile quando vuoi contesto più ricco:
Quando [situazione / trigger], voglio [motivazione], così da poter [risultato atteso]
Esempio: "Quando sono in metro verso l'ufficio di mattina, voglio sentirmi informato sulle notizie del giorno, così da poter partecipare alle conversazioni con i colleghi senza sembrare disinformato."
Questa forma narra meglio il perché emotivo del job ed è più utile nei workshop con team non-tecnici.
I 3 tipi di Job
Un job raramente è solo funzionale. Quasi sempre è un mix di tre dimensioni:
1. Job funzionale
Il compito pratico, osservabile, misurabile. "Trasferire denaro a un amico", "Stampare un documento", "Ricordare un appuntamento".
È la parte più facile da capire e misurare. Ma è raramente l'unica cosa che conta.
2. Job emotivo
Come l'utente vuole sentirsi mentre e dopo aver fatto il job. "Sentirsi al sicuro", "Sentirsi organizzato", "Sentirsi esperto davanti ai colleghi".
I job emotivi sono il motivo per cui prodotti "funzionalmente identici" vincono o perdono. Notion vs Evernote fanno (grossolanamente) le stesse cose, ma Notion fa sentire "moderno e creativo", Evernote fa sentire "archivista diligente". Due job emotivi diversi.
3. Job sociale
Come l'utente vuole essere percepito da altri quando fa il job. "Essere visto come innovatore", "Sembrare attento alla famiglia", "Non sembrare avaro".
I job sociali sono potenti in mercati con componente di status: fashion, auto, tecnologia consumer. Una persona non compra un iPhone solo per il job funzionale "telefonare" — c'è anche il job sociale "essere percepito come qualcuno che si tiene al passo".
Un buon job statement cattura tutti e tre i livelli quando rilevanti, non solo il funzionale.
JTBD vs User Persona: non alternative ma complementari
Molti articoli contrappongono i due framework. In realtà sono complementari:
| User Persona | Jobs to Be Done | |
|---|---|---|
| Risponde a | Chi è l'utente? | Cosa sta cercando di fare? |
| Focus | Identità, contesto, demografia | Obiettivo, motivazione, circostanza |
| Output | Profilo narrativo | Job statement |
| Rischio di | Stereotipizzare | Ignorare il contesto umano |
| Forte in | Marketing, allineamento team | Decisioni di prodotto, scoperta di opportunità |
I team più sofisticati usano entrambi:
- User persona per capire chi sono i segmenti di utenti (marketing, copy, visual direction)
- Jobs to Be Done per capire perché usano (feature prioritization, messaging, product strategy)
Per approfondire le user persona leggi la nostra guida completa alle persona.
Come condurre un "Job Interview"
Le interviste JTBD sono diverse dalle interviste UX classiche. Si concentrano meno su opinioni e più su storie di uso reale. La tecnica più usata è quella di Bob Moesta e Chris Spiek (The Rewired Group):
Step 1 — Trova persone che hanno fatto il job di recente
Non "persone interessate a...". Persone che hanno fatto qualcosa di concreto nelle ultime 2-4 settimane: comprato un prodotto, usato un'app, preso una decisione. Il ricordo fresco è critico.
Step 2 — Fatti raccontare il "momento di prima pensata"
"Quando ti è venuta in mente la prima volta l'idea di [azione]? Dov'eri? Cosa stava succedendo?". Ricostruisci il contesto fisico e emotivo, non lascia che l'intervistato ti dia opinioni razionalizzate a posteriori.
Step 3 — Segui il percorso decisionale
"Poi cosa hai fatto? Hai parlato con qualcuno? Hai cercato online? Quali alternative hai considerato?". Ricostruisci ogni passo fino all'adozione della soluzione.
Step 4 — Scava le "forze" che hanno influenzato la decisione
JTBD identifica 4 forze che agiscono su ogni decisione:
- Push (cosa spinge l'utente via dalla situazione attuale)
- Pull (cosa attira verso una nuova soluzione)
- Habit (cosa lo trattiene nell'abitudine corrente)
- Anxiety (cosa lo preoccupa della nuova soluzione)
Una decisione avviene quando Push + Pull > Habit + Anxiety. Le interviste cercano di identificare queste 4 forze per ogni caso.
Step 5 — Sintetizza in un job statement
Dopo 5-10 interviste, cerca i pattern. I job emergono dalla ripetizione, non dai casi singoli.
5 esempi reali di aziende che usano JTBD
1. Intercom
Intercom è famosa per aver pubblicato uno dei primi libri open-source su JTBD ("Intercom on Jobs-to-be-Done", 2016). Ha usato il framework per decidere quali feature costruire basandosi su job ricorrenti: "quando un utente compra, voglio sapere chi è e cosa fa nel prodotto, così da dare supporto contestuale".
2. Basecamp
Basecamp (37signals) usa JTBD come forma mentis per tutte le decisioni di prodotto. Il loro libro "Shape Up" descrive un processo in cui ogni nuova feature parte da un pitch che include esplicitamente il job to be done, non user stories.
3. Spotify Discovery
Spotify ha riformulato la sua Discovery Weekly su un JTBD preciso: "quando sono al lavoro e voglio sentirmi accompagnato senza distrarmi, voglio musica nuova che so che mi piacerà senza dover scegliere". Il risultato è stato una playlist che non ti chiede di scegliere nulla, e che ha generato miliardi di ore di ascolto.
4. Snickers ("You're not you when you're hungry")
Non è UX ma è un esempio perfetto. Per anni Snickers cercava di vendersi come "barretta di cioccolato buona". Poi hanno identificato il job emotivo: "quando ho fame e non posso mangiare niente di serio, voglio qualcosa che mi rimetta a posto senza farmi sentire in colpa per aver mangiato junk food". La campagna "You're not you when you're hungry" (2010) nasce da quel job statement. Vendite globali +15% il primo anno.
5. IKEA — Täby store
IKEA ha studiato i job dei clienti del negozio di Täby (Svezia) e ha scoperto che il 30% dei visitatori aveva il job "passare un pomeriggio di domenica con la famiglia visitando un posto interessante, poi mangiare insieme". Non il job "comprare mobili". Hanno ridisegnato il percorso di visita con più zone di sosta, più area ristorante, più intrattenimento per bambini. Le vendite sono aumentate anche se il tempo medio di permanenza è raddoppiato.
Errori comuni nell'uso di JTBD
- Confondere job e soluzione. "Usare WhatsApp" non è un job. "Mantenersi in contatto con persone care in modo immediato e personale" è un job.
- Job troppo generici. "Essere felice" non è un job utilizzabile. Troppa astrazione = inutile.
- Ignorare il contesto. Lo stesso utente ha job diversi in contesti diversi. Non trattarlo come una singola entità.
- Saltare le interviste. Un job statement scritto a tavolino dal team è spesso l'opposto di quello reale degli utenti.
- Usarlo solo per feature incrementali. JTBD è potente proprio per innovazione disruptive: capire job non ancora serviti dal mercato.
Strumenti e template per JTBD
- Job Statement Template (Strategyn) — disponibile nel libro di Tony Ulwick "Jobs to Be Done: Theory to Practice"
- Forces of Progress canvas (The Rewired Group) — template FigJam gratuito per mappare push/pull/habit/anxiety
- JTBD Playbook — libro di Jim Kalbach (gratuito open source) — uno dei riferimenti più completi per applicare il framework
- Template FigJam — cerca "Jobs to Be Done" nella Figma Community, decine di template gratuiti
- CorsoUX template interno — nel corso completo forniamo il nostro framework con esempi italiani
Domande frequenti
Serve sostituire le user persona con JTBD?
No, i due framework sono complementari. Le persona raccontano chi sono gli utenti (utile per marketing, visual, allineamento team). I JTBD raccontano perché li usano (utile per decisioni di prodotto, feature, strategy). I team senior usano entrambi.
Come convinco il team a usare JTBD?
Partendo da un caso pilota: scegli una feature di cui state discutendo e conduci 5 job interviews su utenti reali. Presenta i risultati in un meeting di 30 minuti. Il team vedrà la differenza tra "decisioni basate su opinioni interne" e "decisioni basate su job reali degli utenti". Da lì, l'adozione è organica.
JTBD funziona anche per prodotti B2B?
Sì, con alcuni aggiustamenti: in B2B i "job" sono spesso legati a ruoli aziendali ("come HR manager, quando devo fare onboarding di un nuovo assunto, voglio evitare errori di setup") e coinvolgono spesso più stakeholder con job leggermente diversi. Il framework è comunque applicabile.
Qual è il libro migliore per iniziare?
"Competing Against Luck" di Clayton Christensen è il classico del framework. Per un approccio più operativo "Jobs to be Done Playbook" di Jim Kalbach è più pratico e applicabile. Entrambi nella nostra selezione di libri UX.
Come collego JTBD a roadmap di prodotto?
Ogni feature della roadmap dovrebbe rispondere esplicitamente alla domanda "quale job stiamo servendo con questa feature?". Se un team di prodotto non sa rispondere, probabilmente la feature non ha fondamento e può essere deprioritizzata. Molti team lo usano come gate: nessuna feature entra in roadmap senza un job statement associato.
Prossimi passi
Jobs to Be Done è uno dei framework più citati ma meno applicati correttamente. I designer che sanno condurre job interviews, scrivere job statement solidi e usarli per guidare decisioni di prodotto sono tra i più richiesti in aziende con cultura product-led nel 2026.
Il corso completo di UX Design di CorsoUX include un modulo su JTBD con esercitazioni pratiche: analisi di casi reali, job interviews simulate, workshop di scrittura di job statement. Esci con una capacità di leggere prodotti attraverso la lente JTBD che pochi junior italiani hanno.
Per approfondire:
- Design Thinking: le 5 fasi — dove JTBD si integra nella fase di Empathize
- Guida alla user research — le tecniche di intervista applicabili anche a JTBD
- User Persona: guida pratica — il complemento naturale di JTBD
- Customer Journey Map — visualizza come il job si sviluppa nel tempo
