Jobs-to-be-done, spiegato semplicemente

Il numero di libri e articoli su Jobs-to-be-done (JTBD) è in crescita.

A farci caso, per ogni articolo sulla teoria ce n’è uno sulla pratica. Può essere sfidante comprendere l’essenza di JTBD, per chi vi si approccia per la prima volta.

Questo framework, in effetti, spazia parecchio tra più ambiti: User Research, Product Management e Marketing.

Per chi si sentisse perso tra lunghi articoli e libri, è bene sapere che l’idea alla base di JTBD, di per sé, è estremamente semplice.

Jobs-to-be-done richiede di mettersi nei panni di un detective; ma anziché ricostruire un crimine, dobbiamo ricostruire la storia di qualcuno che ha fatto un acquisto.

“Quando hai realizzato per la prima volta di avere bisogno di questo prodotto?”, “Cosa stavi cercando di fare?”, “Come è andata?”, “Perché l’hai scelto?”, “Cosa cercavi di realizzare compiendo quella scelta?”.

Alcune forze attraggono verso una nuova soluzione, mentre altre scoraggiano il cambiamento. A questo punto abbiamo parlato, in parole semplici, dei concetti di Timeline e di Four Fources, punti chiave della teoria Jobs-to-be-done.

Poi, da non dimenticare: non esiste JTBD senza utenti. Un Designer o Product manager che si trova ad avviare un nuovo progetto, desideroso di mettere in pratica JTBD, può fare un esercizio teorico chiedendosi qui e lì “Qual è il Job dell’utente?”.

Ma se finisce tutto lì, non stiamo realmente facendo JTBD.

Il motivo? Non stiamo parlando con nessuno. JTBD è basato su storie reali; il processo di design può partire da buone ipotesi sui problemi da risolvere, ma Jobs-to-be-done è tutta esperienza, quella degli utenti.

Questo concetto è molto chiaro se riflettiamo sui primi casi di successo legati a questo framework. Io, ad esempio, ho scoperto JTBD dai primi articoli di Intercom, che l’ha applicato ai suoi clienti esistenti.

JTBD consiste nell’intervistare clienti reali che scelgono il tuo prodotto, clienti dei concorrenti o, più in generale, qualcuno che ha il problema da risolvere. JTBD non può esistere “nella teoria”.

C’è una terza situazione: stiamo creando qualcosa che risponde a nostre esigenze.

Jobs-to-be-done può aiutare nel raccogliere informazioni preziose e orientare il lavoro di ricerca e di sviluppo.

È quello che abbiamo fatto con Plann, uno strumento che abbiamo creato per gestire il tempo delle persone sui progetti. Per focalizzare il problema da risolvere e l’obiettivo (il progress, nel gergo JTBD), abbiamo svolto un semplice esercizio:

1) Prima (qual è la situazione di partenza?)
Abbiamo troppi progetti contemporaneamente. Non sappiamo quando li concluderemo e non sappiamo quando potremo prenderne di nuovi e incassare.

2) Dopo (cos’è cambiato, ora?)
I progetti si concludono puntualmente e nel budget, tutti sono contenti e il flusso di cassa è buono.

Questo approccio non menziona il prodotto o le sue funzionalità. In questo modo è più semplice fare attività di ricerca e di sviluppo prodotto andando a verificare che la soluzione pensata sia effettivamente un ponte tra problema e progresso desiderato.

In questo articolo abbiamo chiarito l’essenza di JTBD. In modo molto semplice e non ortodosso, ovviamente. Ma funziona, e può provare chiunque.

Alcune note:

• Pronto ad approfondire JTBD? Leggi Guida pratica a Jobs-to-be-done.
• Poiché JTBD ha diverse interpretazioni, in questo articolo ho utilizzato quella resa popolare da Clayton Christensen, Bob Moesta, Intercom, ecc. Vedi “Jobs-As-Progress”, Know the Two — Very — Different Interpretations of Jobs to be Done | by Alan Klement.
• Noi di Moze abbiamo appreso JTBD, in particolare, grazie a sessioni di formazione dal vivo con Jillian Wells, ex Intercom ora Stripe.
• Abbiamo anche scritto un e-book su JTBD, potete scaricarlo gratuitamente se volete approfondire.