Skip to main content

L'idea che gli utenti possano "assumere" un prodotto potrebbe suonare un po' strana all'inizio. Questo potrebbe persino averti portato a pensare che il cosiddetto framework Jobs To Be Done sia una specie di battuta interna tra i responsabili di prodotto.

In realtà, però, Jobs To Be Done (noto anche come jobs-to-be-done, JTBD o Jobs Theory) non solo esiste davvero, ma è anche uno dei framework più efficaci e d'impatto che puoi utilizzare per sviluppare i tuoi prodotti.

Da senior product manager con esperienza diretta nell'applicazione della teoria JTBD nella pratica, credimi: imparare a usare questa affascinante metodologia cambierà radicalmente il tuo modo di pensare al prodotto.

Want more from The CPO Club?

Sign up for a free membership to complete reading this article:

Step 1 of 2

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Principi della teoria Jobs To Be Done

Prima di addentrarci nella struttura di questo framework e spiegarti come utilizzarlo, lascia che ti presenti le idee e i principi fondamentali che lo guidano, per aiutarti a comprenderne l'essenza (anziché limitarti a memorizzare i passi dell'implementazione).

Esperti di prodotto e manager sostengono che il primo "modo di pensare" dietro JTBD risalga agli anni '60, quando il celebre professore della Harvard Business School e studioso di marketing Theodore Levitt introdusse il concetto di "risultati desiderati" pronunciando questa famosa frase:

"People don't want a 1/4 inch drill, they want a 1/4 inch hole."

L'intuizione di questo modo di pensare risiede nel modo in cui inizi a concepire lo sviluppo del prodotto.

Spotify voleva entrare nell'industria musicale. Tuttavia, invece di creare un marketplace dove vendere canzoni (come faceva allora iTunes), si rese conto che le persone volevano semplicemente ascoltare musica, non possederla acquistandola.

Così si sono sentiti liberi di costruire qualcosa di radicalmente diverso (e migliore) rispetto ai negozi di musica: un servizio di streaming, capace di equilibrare un modello di business sostenibile con il risultato desiderato dagli utenti di ascoltare musica.

Dalle sue origini negli anni '60, l'approccio focalizzato sui risultati desiderati si è evoluto profondamente, con molti rinomati esperti e studiosi di management che hanno costruito i propri framework e "filosofie" su questo concetto.

Alcune delle tappe più importanti sono state:

L'idea di Disruptive Innovation di Clayton Christensen, illustrata nel suo libro "The Innovator's Dilemma". Clayton osservò che ogni innovazione rivoluzionaria parte dal rispondere ai bisogni di un piccolo gruppo di clienti (ovvero gli Early Adopters), per poi perfezionare la soluzione così da soddisfare anche i bisogni di vaste platee di utenti successivi.

Il punto centrale di questa struttura "partire dalla nicchia e poi espandersi" stava nella capacità dei fondatori e dei product manager di individuare correttamente i bisogni e i risultati desiderati degli utenti della nicchia, per poi replicare lo stesso processo sul pubblico più largo.

L'approccio "struggle-first" di Bob Moesta, esposto nel suo libro "Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress", in cui Bob sostiene che i clienti cercano costantemente di avanzare nella propria vita (sia dal punto di vista finanziario, relazionale o altro) e incontrano numerose difficoltà lungo quel percorso. I grandi leader di prodotto sono capaci di vedere queste difficoltà e proporre prodotti che gli utenti possano "assumere" per superare tali ostacoli.

Il framework Outcome-driven Innovation (ODI) di Tony Ulwick (qui trovi un buon articolo su Harvard Business Review a riguardo). Secondo Tony, il fattore principale che guida il processo decisionale nella mente dei clienti sono i risultati finali che vogliono ottenere utilizzando il tuo prodotto.

L'idea è che, quando ci si trova a scegliere tra diversi prodotti concorrenti, i clienti finiranno per selezionare quello in grado di aiutarli meglio a raggiungere i loro risultati desiderati.

Come funziona JTBD?

Con tutte queste idee e framework nella mente, arriviamo finalmente alla JTBD. Esistono diverse interpretazioni della teoria JTBD (tutte piuttosto valide), ma personalmente prediligo la versione di Tony descritta nel suo libro "Jobs to be Done: Theory to Practice".

Per lui, i clienti devono svolgere un "job" che consenta loro di raggiungere il risultato desiderato. Possono realizzare questo job scegliendo diversi percorsi e soluzioni, inclusa l'"assunzione" di prodotti in grado di farlo al posto loro.

Se dovessimo visualizzare questo concetto, apparirebbe così:

the job to be done infographic

Il punto di partenza per i tuoi clienti è lo stato attuale non ideale che non li soddisfa. Ad esempio, per un'operatrice di supporto clienti che lavora da casa, questo stato attuale coincide con il suo soggiorno, dove normalmente svolge il suo lavoro perché nel suo appartamento non c'è uno studio dedicato.

Perché si tratta di uno stato attuale non ideale? Beh, a causa di tutti i rumori di sottofondo generati da cane, bambini e vicini, teme di poter sembrare poco professionale durante le chiamate di assistenza con i clienti.

Quindi, lei ha come risultato desiderato quello di effettuare chiamate di supporto prive di rumori.

Per riuscirci, deve cambiare la propria situazione attuale e fare progressi verso il suo risultato desiderato, riducendo il rumore di fondo. Questo è un compito che deve portare a termine.

Una delle possibilità sarebbe quella di tenere tutti fuori dal soggiorno—ma è difficile farlo per un'intera giornata lavorativa in un piccolo appartamento. Un'altra opzione è trasferirsi in un appartamento nuovo con uno studio insonorizzato, ma ciò comporta molto lavoro, stress e costi a lungo termine. Infine, c’è l’alternativa di "assumere" un software di cancellazione del rumore per eliminare tutti i suoni in tempo reale.

Considerando il costo delle soluzioni alternative, sarebbe più che felice di pagare una dozzina di euro al mese per questo tipo di servizio!

Così, il software di cancellazione del rumore ha portato a termine con successo il compito di eliminare i rumori di fondo dalle sue chiamate e l'ha aiutata a raggiungere il risultato desiderato di effettuare chiamate senza distrazioni.

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Le leggi di JTBD

Nella sua definizione del framework JTBD sul sito della sua società di consulenza Strategyn, Tony presenta un paio di “fatti” interessanti su questi compiti che possono aiutarci a comprendere meglio l’essenza di JTBD.

  1. Un compito rimarrà lo stesso col passare del tempo. In passato si assumevano segretari per prendere appunti durante le riunioni. Ora si impiegano strumenti di sintesi basati su intelligenza artificiale. Soluzioni diverse, stesso compito.
  2. I compiti sono “indipendenti dalla soluzione”. Ciò significa che i clienti possono scegliere diversi tipi di soluzioni per svolgere lo stesso compito. Significa anche che il tuo prodotto non deve necessariamente assomigliare a ciò che offrono i tuoi concorrenti per poter svolgere bene il lavoro.
  3. La soluzione migliore ottiene sempre il compito. Se c’è concorrenza, il vincitore è il prodotto che svolge il compito in modo migliore, più veloce o più economico (o con una combinazione di questi fattori).
  4. Le persone desiderano una sola soluzione per un solo compito. I clienti preferiscono prodotti in grado di coprire l’intero compito dall’inizio alla fine e eviteranno situazioni in cui per svolgere il lavoro sia necessario utilizzare più prodotti.

In sintesi, il framework Jobs To Be Done si basa sull’idea che le persone desiderano davvero ottenere un risultato finale, non tanto lo strumento che utilizzano per ottenerlo.

Però, il processo conta. Per raggiungere i loro obiettivi finali, devono portare a termine determinati compiti (o “jobs”) e sono disposti ad assumere qualcuno o qualcosa (un servizio o un software) che se ne occupi per loro.

Identificando questi compiti e adattando i tuoi prodotti per gestirli in modo fluido, aumenti le probabilità che le persone scelgano di pagare per il tuo prodotto e di continuare a utilizzarlo nel tempo.

Come usare il framework JTBD nello sviluppo prodotto di tutti i giorni

Spero sia chiaro quanto sia importante comprendere l’essenza del framework JTBD prima di imparare a utilizzarlo, perché i passaggi seguenti avranno molto più senso in questo contesto.

Quello che sto per condividere con te non è la versione “classica” di JTBD (che puoi trovare spiegata nei molti libri citati sopra).

Piuttosto, voglio presentarti la variante di JTBD che ho utilizzato con successo nella pratica con alcuni dei miei prodotti.

Ecco un esempio di Jobs To Be Done tratto dalla mia esperienza professionale.

Conoscere i bisogni e i risultati desiderati dei clienti

Il cuore di ogni prodotto di successo è una ricerca utenti eseguita con cura. Considerando quanto il JTBD si basi sull’idea che “le persone vogliono risultati, non strumenti”, si dovrebbe sempre partire dall’identificazione degli utenti e dallo studio di ciò che desiderano.

Non ho un metodo specifico "adattato a JTBD" per questa ricerca. Il mio team di prodotto e io ci affidiamo ai nostri metodi tradizionali e ai tool per comprendere gli utenti. L’unica differenza è che concentriamo le nostre domande sulla scoperta del risultato finale che i nostri utenti desiderano raggiungere.

Lascia che ti racconti un esempio relativo al servizio di notifiche push per il web su cui abbiamo lavorato.

Nota: Questo strumento consente ai siti web di inviare notifiche push ai propri visitatori. Era un nuovo e profittevole canale di marketing che i siti potevano utilizzare per promuovere i propri prodotti.

Per sviluppare le personas di questo servizio, intervistavamo le persone che utilizzavano i prodotti dei nostri concorrenti diretti e indiretti. Quando intervisti un utente di un concorrente, tradizionalmente poni domande come queste:

Quali sono le tre cose che odi di {competitor}?Quali sono le tre cose che ami?Quali fattori o miglioramenti ti farebbero prendere in considerazione il passaggio da {competitor} a una soluzione diversa?

Anche se abbiamo posto queste domande durante le nostre interviste, il nostro focus principale era ottenere risposte a queste:

Perché usi {competitor}? Qual è il risultato finale e il vantaggio che ottieni?Con quale frequenza hai bisogno di ottenere questo risultato?Come misuri il successo o determini se {competitor} soddisfa le tue esigenze?

E c’era un buon motivo se intervistavamo sia concorrenti diretti (ad esempio OneSignal e iZooto) che indiretti (ad esempio Mailchimp e Twilio). Abbiamo già detto che i job e i risultati desiderati sono indipendenti dalla soluzione. Significa che le risposte sugli esiti sarebbero state le stesse (o almeno simili) indipendentemente dallo strumento utilizzato dai nostri intervistati.

Ed è esattamente ciò che abbiamo ottenuto. A quanto pare, il risultato più comune desiderato dal nostro mercato target (che in quel momento erano gli shop eCommerce) era ridurre il numero dei cosiddetti “carrelli abbandonati”—quando le persone aggiungono prodotti al carrello e li lasciano lì per giorni o settimane.

Il compito che sia i servizi di email che di notifiche web push svolgevano per loro era ricordare agli utenti il carrello abbandonato e offrire uno sconto se tornavano a concludere l’acquisto.

Ed è proprio su questo che abbiamo deciso di concentrarci, costruendo un prodotto che fosse in grado di farlo meglio di chiunque altro.

Infografica su Bisogni del Cliente e Risultati Desiderati

L’esempio riportato sopra riguarda le interviste agli utenti, ma non è l’unico modo per scoprire cosa vogliono i tuoi clienti. Puoi anche considerare di:

  • Ricerche di mercato insieme alla definizione di diversi segmenti e demografie di cliente.
  • Sondaggi agli utenti che puoi condurre utilizzando la nostra lista di domande per sondaggio.
  • Focus group, in cui inviti un gruppo selezionato di persone a discutere con te delle loro esigenze ed esperienze.

Ma indipendentemente dal tipo di ricerca clienti che stai conducendo, ricorda sempre di dare priorità alle domande che fanno emergere i risultati finali che i tuoi clienti vogliono ottenere.

Formulare la Job Statement

Come risultato di tutti gli insight raccolti da interviste e sondaggi, dovresti avere una comprensione piuttosto chiara sia dei risultati attesi dai tuoi utenti sia delle attività che solitamente svolgono per raggiungerli.

Ora è il momento di concretizzare queste conoscenze formulando l’elemento principale della metodologia JTBD—una job statement. Ecco come si presenta:

Infografica su come formulare la Job Statement

Questo formato per descrivere i risultati e i job è davvero utile perché contiene informazioni cruciali come:

  • La situazione e l'ambiente in cui il cliente sperimenta un problema. Nel nostro caso, si trattava di persone che abbandonavano il carrello acquisti.
  • Il compito che il cliente deve svolgere per ottenere il risultato desiderato. Per i commercianti eCommerce, si trattava di inviare messaggi di promemoria a chi aveva abbandonato il carrello.
  • Il motivo emotivo e razionale dietro il desiderio del cliente di raggiungere il risultato. Se le persone aggiungono prodotti al carrello e poi se ne dimenticano, per i nostri clienti questo è potenziale fatturato perso e hanno un motivo razionale per ridurre questi casi.
  • Infine, il risultato desiderato. In questo esempio, i titolari dei negozi volevano liberarsi dei carrelli abbandonati.

Avrai notato che abbiamo usato il termine “messaggi di promemoria” invece di “email di promemoria” per le notifiche push. Questo perché ai nostri clienti non interessava realmente quale fosse il canale fisico per inviare il messaggio, basta che servisse a ridurre l’abbandono dei carrelli.

Creare una Job Map

La documentazione di molti dei job-to-be-done e degli outcome statement dei tuoi clienti è già di per sé un risultato. Ma è solo metà dell'opera, perché dovrai trasformare questi job in una solida proposta di valore, in nuovi requisiti di prodotto (compresa una roadmap) e in un'esperienza utente di qualità.

Per questo, possiamo sfruttare un altro deliverable dei JTBD: la job map.

La job map è la rappresentazione visiva dell'intero percorso che i tuoi clienti devono affrontare per completare con successo il loro compito. Funziona come passaggio intermedio tra le job statement e la customer journey map o i requisiti di prodotto che consegnerai al tuo team di ingegneria.

Ecco un esempio di template di job map sviluppato da GitLab.

Job Map Developed By GitLab Screenshot
Fonte: GitLab

La struttura sopra è il frutto del lavoro di Tony Ulwich, che ne ha proposto l'utilizzo per la mappatura dei job nel suo framework Outcome-driven innovation.

Ora, lascia che te lo illustri con l'esempio di Spotify e del job "Cliente che crea una playlist personalizzata in base al proprio stato d'animo".

  • Definire: Gli utenti capiscono di aver bisogno di una playlist personalizzata in base al loro umore.
  • Localizzare: Trovano la funzione di creazione playlist e ci arrivano.
  • Preparare: Gli utenti cercano e selezionano i brani che vogliono aggiungere alla playlist.
  • Confermare: Rivedono la playlist per assicurarsi di aver incluso tutte le canzoni che volevano in base al loro umore.
  • Eseguire: Gli utenti salvano la playlist e le danno un nome.
  • Monitorare: Osservano metriche come il numero di stream e di like per valutare la popolarità della loro playlist.
  • Modificare: Gli utenti integrano i feedback degli altri nelle loro playlist, aggiungendo o rimuovendo canzoni.
  • Concludere: Quando provano l'umore per cui è stata creata quella playlist, la ascoltano e si godono la musica.

A seconda del job che vuoi mappare, potresti considerare di omettere alcuni di questi passaggi se pensi che non ci sia alcuna azione significativa da compiere da parte degli utenti in quella fase.

Creare una soluzione che le persone sceglieranno per quel job

Infine, siamo arrivati al punto in cui puoi realizzare i tuoi soliti deliverable di product management, come PRD, design, user story e altro ancora, sfruttando i tuoi software di product management di tutti i giorni.

Hai già l'elenco dei passaggi che i tuoi utenti svolgono per soddisfare i loro bisogni insoddisfatti, quindi tutto ciò che devi fare è creare funzionalità che coprano le azioni necessarie in ciascun passaggio.

Ad esempio, per la fase "preparare" del job specifico sopra menzionato, dovrai sviluppare una funzione che consenta agli utenti di cercare brani, filtrare le playlist di altri utenti e aggiungere questi brani alla propria playlist.

Oltre a sviluppare funzionalità che affrontano i tuoi job, non dimenticare anche quelle più "amministrative", come la definizione del prezzo e la logica di pagamento, la gestione dell'esperienza cliente per quanto riguarda la gestione dei dati e dell'account e la possibilità di accedere al supporto.

Tutto sta nel rendere il tuo prodotto "assumibile"

Jobs To Be Done è un framework eccezionale e un modo di pensare che ti aiuta a concentrare i tuoi sforzi sulle funzionalità che renderanno il tuo prodotto più attraente agli occhi degli utenti che vogliono "assumerti" per svolgere i loro job.

Non importa che tu sia in una startup o in un colosso tech (come Intercom o Microsoft), ti assicuro che JTBD ti aiuterà a far crescere l'impatto del tuo lavoro di product management. Se ti è piaciuto leggere i miei pensieri sui JTBD, assicurati di iscriverti alla nostra newsletter per ricevere contenuti simili nella tua casella di posta.