Jobs To Be Done: ridefinire il prodotto attraverso il lavoro

Cosa sono i Jobs To Be Done

Oggi parliamo di Jobs To Be Done, un altro strumento che Product Owner e Product manager possono utilizzare per creare prodotti e servizi di valore.

Jobs To Be Done è un framework che aiuta le aziende a focalizzarsi sui problemi dei clienti e a costruire nuovi prodotti o ottimizzarne di esistenti in risposta a quei bisogni.

Abbiamo già parlato di outcome in passato… JTBD è un approccio outcome-driven perché definisce la finalità – l’outcome – per la quale i clienti acquistano prodotti, soluzioni o servizi specifici.

“Le imprese vogliono pensare in termini di categorie.
I consumatori vogliono che pensiamo in base alle loro esigenze.”

Ideatore di questa teoria è il professor Clayton Christensen della Harvard Business School secondo il quale alla base dell’acquisto sta l’idea di svolgere un lavoro “meglio e ad un costo minore”.

Il marketing tradizionale mette in relazione la scelta di un prodotto ai target, segmenti di utenza caratterizzati da profili socio-demografici comuni; Clayton sostiene invece che per comprendere le reali motivazioni che spingono all’acquisto è necessario focalizzarsi su “tutte le cose che le persone stanno cercando di fare nella loro vita in termini di compiti che tentano di svolgere o completare, di problemi che cercano di risolvere o di bisogni che provano a soddisfare”.
Sono questi i job to be done.

La segmentazione del mercato secondo la teoria JBTD

Pensate: anche il milkshake è un prodotto che aiuta a svolgere un lavoro… quale?
Scopritelo in questa intervista al professor Christensen che con il suo team ha condotto un’analisi per una famosissima catena di fast food.

I jobs to be done perdurano nel tempo

Le persone acquistano prodotti e servizi per portare a termine un determinato lavoro e mentre i prodotti vanno e vengono, il lavoro da svolgere non scompare.

Facciamo un esempio: pensate per un momento a com’è cambiata la fruizione della musica negli anni. Quando ero piccola utilizzavamo mangianastri e vinili, supporti molto diversi rispetto alle possibilità che abbiamo oggi di fare streaming direttamente dal cloud.
I prodotti e i modelli di business si sono evoluti enormemente, ciò che è rimasto costante è il job to be done ovvero ascoltare la musica.

Conducendo un’analisi JTBD è possibile ottenere una comprensione più profonda del modello mentale dietro le decisioni di acquisto e del risultato che un cliente desidera raggiungere. In questo modo si arriva a una definizione della strategia di prodotto più chiara.

E’ possibile applicare il framework JTBD per decostruire i vari lavori in passaggi specifici e mappare le relative esigenze dei clienti per identificare opportunità di crescita.
Invece di focalizzare l’attenzione sui prodotti che diventeranno sicuramente obsoleti, questo approccio suggerisce alle aziende di progettare l’attività intorno ai lavoro da svolgere così da rimanere concentrata sulla creazione di soluzioni valore e garantirsi sostenibilità nel tempo.

La formula standard per descrivere un job to be done

Il lavoro è l’unità di analisi

Questa teoria porta con sé un cambio di paradigma: la vera innovazione non avviene migliorando i prodotti esistenti, bensì trovando modi migliori per portare a termine i lavori.
Si smette di studiare il prodotto per approfondire invece il lavoro che le persone stanno cercando di svolgere.
Il lavoro, non il prodotto, è l’unità di analisi.

Quello che mi sembra particolarmente convincente in questo approccio – così come con lo strumento delle personas – è il cambio di prospettiva: dall’oggetto al punto di vista del soggetto che lo fruisce e ai risultati che desidera raggiungere.

Il mercato viene ridefinito in base ai vari lavori funzionali da svolgere e non più attorno a un prodotto, una tecnologia o una soluzione.
Quando si applica la teoria dei jobs to be done ci si focalizza su due aspetti principali:

  • l’esecutore del lavoro (il soggetto);
  • il lavoro che l’esecutore sta cercando di svolgere.

In quest’ottica i genitori che cercano di trasmettere lezioni di vita ai propri figli rappresentano un mercato. I genitori sono gli esecutori e trasmettere le lezioni di vita è il loro compito primario.
Definire un mercato in questo modo apre la porta a un diverso tipo di ricerca poiché l’obiettivo diventa analizzare il lavoro per scoprire dove gli esecutori fanno fatica a portarlo a termine piuttosto che analizzare i prodotti che usano a tale scopo.

Vi faccio un altro esempio: un cliente vuole comprare una macchina più grande. Qual è la finalità che lo guida? Quale il suo contesto? Ha una famiglia numerosa o gli serve un’auto spaziosa perché ama sciare e viaggia spesso con l’attrezzatura sportiva al seguito? La risposta a queste domande apre scenari del tutto differenti.

Quando i clienti eseguono un lavoro hanno in mente una serie di criteri che ne definiscono la corretta esecuzione. Quei criteri, che corrispondono alle metriche con cui misurano il raggiungimento dell’obiettivo, sono intuizioni preziosissime per la creazione di prodotti e servizi di valore.

Un unico prodotto per l’intero job to be done

Una volta mappate tutte le esigenze del cliente si arriva a comprendere quali non sono soddisfatte dalle soluzioni esistenti.
Teniamo a mente che il nostro scopo come Product Owner è aiutare i clienti a portare a termine l’intero lavoro.
Da una parte dobbiamo considerare quali aspetti non sono ancora appagati dai prodotti attuali, dall’altra – quando lo sono – di quanti prodotti gli esecutori hanno bisogno.

Questo è spesso un aspetto sottovalutato e merita particolare attenzione.
E’ molto frequente che i clienti debbano mettere insieme diverse soluzioni per completare l’intero lavoro. Questo è una scomodità perché le persone non vogliono “doversi sbattere” con più prodotti per raggiungere i propri obiettivi; vogliono qualcosa che consenta loro di fare tutto il “job”.

La chiave del successo è capire, dal punto di vista del cliente, qual è l’intero lavoro e fare di quel lavoro il punto focale della creazione di valore.

La differenza tra un approccio orientato al prodotto e uno orientato al job to be done

Conclusioni

Jobs To Be Done è una tecnica potente che può essere applicata ogni volta che si desidera identificare opportunità di innovazione in relazione allo sviluppo del prodotto, all’eccellenza operativa o al miglioramento della relazione con il cliente finale.

Dal mio punto di vista questo approccio è particolarmente interessante perché:

  1. si focalizza su ciò che il cliente vuole ottenere
  2. motiva la scelta di prodotto in base all’outcome desiderato
  3. migliora la customer experience grazie ad una maggiore comprensione dell’utente

Nel prossimo post approfondiremo i vari tipi di job to be done con esempi specifici (ne esistono 3) e prenderemo familiarità con il template del framework.
A presto!

Output e outcome: qual è la differenza?

Il prodotto non è il risultato…

Nel mondo Agile è molto frequente il riferimento ai termini inglesi output e outcome, ma qual è esattamente il loro significato e quali le differenze tra i due?
Partiamo innanzi tutto dalla traduzione: l’output è ciò che viene creato alla fine di un’attività; potrebbe essere ad esempio una funzionalità, un prodotto o un servizio. L’outcome invece è il risultato finale, ovvero l’effetto che quella funzionalità, quel prodotto o quel servizio generano.

I risultati sono ciò che l’azienda vuole o deve ottenere (ricordate quando abbiamo parlato di vision e mission così come di obiettivi strategici?). Gli output sono le azioni o i deliverable che contribuiscono al raggiungimento di quel determinato risultato.

Crediti Crisp’s Blog

Soffermiamoci un attimo a considerare le differenze tra i due.
Gli output sono spesso tangibili e facili da misurare. Non sono le ragioni per cui viene avviato un progetto, bensì mezzi per un fine.
Di norma possono essere controllati da chi gestisce il progetto o il prodotto e, una volta rilasciati in produzione, non ci forniscono una vera misura di efficacia.

L’outcome invece è per lo più qualcosa di intangibile e difficile da misurare. Il risultato finale che si vuole ottenere è esattamente il motivo per cui viene avviato un progetto o creato un prodotto.
Non è possibile controllare direttamente il risultato, quanto piuttosto influenzarlo con una serie di attività e misurarlo a posteriori con parametri di efficienza ed efficacia.
L’outcome dal mio punto di vista è esattamente ciò che viene definito un impatto nell’Impact Mapping.

Esempi di output e outcome

Facciamo qualche esempio pratico per essere sicuri di avere chiare le differenze.

Prendiamo il caso di una catena di fast food che produce hamburger.
L’hamburger è l’output, ciò che viene creato alla fine del processo. Il numero di hamburger prodotti o di persone servite ci fornisce un’indicazione sulle performance del ciclo di produzione ma non ci dice niente sulla risposta dei clienti e su come questi siano stati influenzati.
Due outcome possibili sono ad esempio la percezione di qualità da parte dei consumatori o la capacità del prodotto di eliminare la fame.

Altro scenario. Un bambino di 6 anni invita i suoi compagni di scuola per festeggiare il suo compleanno. Il culmine della festa è la torta a tema Spider Man ordinata con tanta cura dai genitori.
La torta è l’output in questo caso. Ma cosa succede se il dolce tanto atteso arriva con la scritta “Tanti Auguri Camilla”? O se ha il disegno di Peppa Pig al posto di Spider Man?
Sono certa che qualunque genitore o chiunque abbia avuto a che fare con bambini di quell’età sappia perfettamente che il risultato finale (nonostante la consegna della torta) sarebbe disastroso.
Certo! Perché l’outcome atteso qui è una festa di compleanno ben riuscita e una masnada di bambini felici, non semplicemente mettere un dolce sul tavolo.

Infine consideriamo un ultimo esempio ripreso dal mondo no profit.
Parliamo di un’associazione di volontariato per la prevenzione e la lotta all’AIDS.
In questo caso un possibile output sono gli incontri di approfondimento, le lezioni e i workshop che l’ente tiene periodicamente per sensibilizzare i cittadini sul tema.
Il numero di questi eventi ci fornisce un’indicazione di performance rispetto all’output, ma l’outcome vero e proprio è la maggiore conoscenza e consapevolezza delle persone su questa tematica e l’acquisizione di comportamenti adeguati. Un risultato questo tutt’altro che semplice da monitorare.

E’ chiara la differenza adesso? Il cosa non è il perché: gli output sono le cose che produciamo – fisiche o virtuali che siano – per un certo tipo di cliente, gli outcome sono la differenza che queste cose fanno (qui ne parlo anche in relazione agli impatti).
Se acquisto un seggiolino per auto quale risultato mi aspetto? Cosa è realmente importante per me? Che il bambino sia al sicuro durante gli spostamenti; questa è l’unica cosa che conta davvero!

Perché come Product Owner devi focalizzarti sull’outcome

Personalmente nel corso degli anni ho sperimentato entrambi i modelli di gestione dei progetti: per output e per outcome (i primi – ahimè – molto più frequenti dei secondi).
Prima di scoprire l’Agile seguivo progetti focalizzati sul rilascio di funzionalità piuttosto che sull’indicazione del risultato atteso.
Al team di lavoro veniva richiesto di creare una serie di feature seguendo requisiti di dettaglio.
Cosa veniva misurato al termine del progetto? Tempi, costi e – a volte – aderenza alle specifiche iniziali (l’ambito o scope per i project manager), tutti indicatori che dicevano poco o nulla del successo di un prodotto.

Questo è un punto che ho sottolineato in tanti post: non basta arrivare a rilasciare un prodotto in produzione per avere successo se ciò che abbiamo realizzato non interessa a nessuno.
L’outcome è proprio il vantaggio che i clienti ricevono dalle soluzioni che offriamo perché ci siamo presi il tempo di comprenderne a pieno le esigenze.
L’outcome è il vero valore per il cliente finale, ecco perché dev’essere il focus primario di un Product Owner!

L’output invece – più facile da misurare – è spesso oggetto degli indicatori aziendali.
Ma se monitoriamo solo il raggiungimento di quest’ultimo senza misurare i risultati da un punto di vista più strategico, si produce il cosiddetto “effetto anguria”.
Tutti i report e le dashboard a prima vista si presentano con KPI positivi, ma quando si approfondiscono gli indicatori dei risultati attesi (quelli che misurano il raggiungimento dell’obiettivo) i numeri sono in rosso.
Ed è chiaro il motivo: hai creato un COSA senza un PERCHE’ (un punto-chiave sul quale Simon Sinek ha detto tutto ciò che c’era da dire in “Start with Why“).

Quindi perché dovresti preferire progetti outcome-driven piuttosto che output-driven?
Per evitare di produrre waste (spreco). Per deliziare i clienti, non fare più cose. Per fare la differenza e non creare solo “roba”.

Quando ho avuto l’occasione di lavorare su progetti gestiti per risultati (outcome-driven) la musica è cambiata e di molto! In quel caso gli stakeholder in azienda ci hanno lasciato “carta bianca”.
Sono stati più sfidanti e più difficili, hanno richiesto un lavoro di discovery molto più approfondito e tanta sperimentazione con il cliente finale ma alla fine raggiungere l’obiettivo ha avuto tutt’altro sapore.
E aggiungo anche un’altra cosa: sono questi i progetti dove i team di lavoro fanno davvero un salto in termini di crescita e di consapevolezza nella gestione del prodotto.
Talvolta è un’esperienza per stomaci forti, ma ne vale davvero la pena.

Crediti businessillustrator.com

Perché la gestione per risultati è merce rara

Sempre in tema di outcome qualche tempo fa ho visto in rete un intervento di Teresa Torres al Business of Software (BoS) che mi ha colpito. Trovo che faccia delle riflessioni interessanti e particolarmente acute sul perché sia così difficile applicare la gestione per risultati e, dato il tema trattato nel post, ho deciso di condividervi qui una sintesi.

Questo è lo scenario che incontra più di frequente nella sua attività di Product Coach: “nonostante si parli di gestione in base ai risultati da anni, i manager hanno spesso ancora difficoltà a concedere ai team la flessibilità e la libertà per esplorare il percorso migliore al raggiungimento degli stessi. Si continuano a dettare le azioni che i team devono intraprendere per raggiungere tali obiettivi e si ricade quindi negli output.”

Perché succede questo? Secondo la Torres c’è un sostanziale problema di fiducia.
Da una parte i manager non credono del tutto che i team possano raggiungere i risultati da soli, cadono spesso nel micro-management e concentrano i feedback sui dettagli piuttosto che nel comunicare la visione strategica; dall’altra non tutti i team hanno la seniority necessaria per avere successo con questo tipo di gestione e anche i più maturi dimostrano scarsa capacità di comunicare i progressi verso i risultati. Sono abituati a concentrarsi sulle conclusioni dei loro ragionamenti – le funzionalità che implementeranno, i progetti che eseguiranno e le iniziative che forniranno – senza condividere i motivi che li hanno portato a quelle scelte.
Focus sui dettagli e micro-management sono due facce della medesima medaglia.

Affinché questo circolo vizioso si spezzi sono necessarie due cose secondo l’opinione della Torres: insegnare ai team come comunicare i loro progressi verso un risultato ed insegnare ai manager come fornire feedback migliori.

Concordo con la sua visione. Ma mi piace l’idea di condividere qualche suggerimento pratico che possa fare la differenza da subito nella vita di tutti i giorni.
La raccomandazione è questa: quando vi viene richiesto di produrre qualcosa chiedete perché e cercate di capire la necessità che sta dietro la richiesta.
In questo modo state portando la conversazione ad un livello più alto e state educando anche il vostro interlocutore a ragionare sull’outcome.
Sembra una cosa da nulla ma è in realtà una rivoluzione più grande di quanto possiate immaginare!

Quale valore per gli stakeholder?

Questo post nasce da una riflessione su un lavoro di riprogettazione di una sezione di un sito e-commerce.
Il cliente ritiene che non si stiano cogliendo a pieno le opportunità della presenza online e decide di avviare una revisione dell’architettura informativa e dei contenuti.
Mi metto al lavoro ed il primo passo del processo è individuare il reale valore di questo intervento per gli stakeholder, quindi sia per il cliente interno sia per il cliente finale.

Il valore per i clienti interni

Dopo un veloce assessment della sezione in questione mi organizzo per alcune interviste.
I primi stakeholder sono i colleghi che lavorano in quell’area e per cui il sito e-commerce rappresenta il principale canale di vendita del prodotto.

Nel corso dei colloqui questi interlocutori tendono a focalizzarsi per lo più su cosa non funziona dal loro punto di vista (che non è detto coincida con quello del cliente finale) e a proporre soluzioni sulla base delle loro competenze digitali.

E’ perfettamente normale che accada questo, ma il mio compito come Product Owner è esplorare lo scenario a 360 gradi, prendermi tutto il tempo che serve per focalizzarmi sui problemi e tollerare in questa fase di non sapere (come diceva Einstein?).

Il mio obiettivo è fare esplicitare agli stakeholder quali sono le loro aspettative rispetto al lavoro che ci apprestiamo a fare, come sperano che cambi la loro attività quotidiana e quale risposta si attendono dai clienti in seguito a questi interventi.
Sto chiedendo loro di proiettarsi nel futuro, nello scenario in cui la riprogettazione è già avvenuta e di descrivere cosa è cambiato e come.

Ora vi sembrerà banale chiedere in anticipo “Cosa è cambiato per te?”, “Come è migliorata la tua giornata di lavoro dopo questo rilascio?”, “Cosa fanno di diverso i clienti?”. In verità le risposte a queste domande sono tutt’altro che scontate e mi permettono di cogliere una varietà di prospettive.

Nel mio caso è andata proprio così: 4 persone mi hanno dato 4 risposte affini mettendo però l’accento su aspetti differenti.
Il CEO misurerà l’efficacia in base alla crescita del venduto; il responsabile della business unit si aspetta un aumento della marginalità e un incremento del Net Promoter Score; il responsabile scientifico auspica, oltre a maggiori ricavi, un più ampio riconoscimento del brand quale leader nel settore; il marketing specialist vuole costruire pagine e campagne con maggiore flessibilità.

Come vedete è interessante raccogliere queste prospettive durante la fase di discovery per 3 motivi: da esse riusciamo a individuare una serie di problemi che non erano emersi nelle riunioni iniziali sulla riprogettazione, abbiamo la possibilità di gestire le aspettative degli stakeholder (perché adesso le conosciamo!) e sappiamo come il nostro lavoro verrà misurato in azienda.

Il valore per il cliente finale

Questo è ovviamente il punto cardinale di tutto il lavoro di riprogettazione.
Per essere certi di andare nella giusta direzione dobbiamo intervistare i clienti – possibilmente vari segmenti di clientela – così da cogliere i diversi bisogni e necessità.

Ricordate: se abbiamo individuato il valore per l’azienda ma non siamo in grado di definire quali sono i vantaggi per il cliente finale abbiamo un enorme problema. Significa che stiamo rilasciando funzionalità, ma non stiamo risolvendo problemi. In una parola: waste! Spreco.

Questo è il motivo per cui affianco sempre l’indagine all’interno dell’azienda con interviste sul campo a clienti veri e potenziali.
Negli anni ho imparato a non dare per scontato che gli esperti di settore abbiano davvero il polso del cliente (spesso è così, ma è opportuno verificare in ogni caso); preferisco sempre toccare con mano cosa significa essere nei panni dell’utente finale.
Anche qui potremmo scoprire una certa varietà di opinioni su come un prodotto, un servizio o una certa funzionalità sia in grado di migliorare la vita del cliente.

Tornando al mio caso dopo poche interviste sul campo ho raccolto alcune suggestioni su ciò che è potenzialmente di valore per il cliente finale: un’ampia scelta di contenuti, strumenti per individuare velocemente l’offerta giusta, una comparazione visuale degli item nella medesima fascia di prezzo e un processo di acquisto semplificato.

Con questa comprensione posso ora muovermi per ridisegnare l’esperienza utente, l’architettura dell’intera sezione e le funzionalità presenti nelle singole pagine.

Gli step per la creazione di valore

Adesso che ho una mappatura chiara delle aspettative interne ed esterne non mi resta che seguire alcuni semplici passi:

  1. mappare il percorso del valore
  2. riprogettare la sezione di conseguenza
  3. portare alla luce ciò che prima non c’era o era nascosto.

Mappare il percorso del valore

Per fare questo utilizzo un semplice foglio di lavoro online.
Ricostruisco il percorso dell’utente a partire dal bisogno iniziale: la ricerca della soluzione, l’atterraggio sul sito, la ricerca interna, la selezione dell’offerta, il processo di acquisto e tutto ciò che viene dopo.
Ogni casella dello spreadsheet è uno step del journey dell’utente e per ognuna di esse vado a specificare i bisogni, i problemi incontrati, le opportunità che non stiamo cogliendo, ecc.
Questo documento è la spina dorsale del lavoro di riprogettazione vera e propria.

Riprogettare la sezione del sito

Tenendo a mente i bisogni, i problemi e le opportunità vado a ridisegnare l’esperienza utente.
Personalmente amo partire da carta e matita. Uno scketch veloce della struttura e delle principali funzionalità prima di partire a costruire il wireframe con i software di prototipazione (Axure o Adobe XD).

Una volta pronto il prototipo – per quanto scarno e privo di grafica – mi piace sottoporlo agli interlocutori iniziali così da verificare se risolve effettivamente i problemi riscontrati (particolarmente rilevante è l’opinione dei reali utilizzatori del sito).
L’ultimo passo sarà la creazione del visual design e di tutti i template UI.

Portare alla luce il valore

Tutto ciò che ho individuato come rilevante dentro e fuori dall’azienda deve ora diventare visibile. Si tratta di dare risposta ai problemi e alle necessità che sono emerse.

Questo è per me un lavoro di team.
Mi piace confrontarmi con UX specialist, designers ed il tech team per capire insieme se abbiamo davvero indirizzato tutti i problemi, se siamo riusciti a rispondere correttamente alle aspettative.

A volte il lavoro di riprogettazione è anche solo questo: non sono necessarie nuove funzionalità, ma è opportuno rendere più visibile o più semplice ciò che già era presente.
Il nostro lavoro – quando è fatto bene – è per lo più un lavoro di semplificazione. A togliere.
Scusate, oggi sono in vena di citazioni…

Misurare il valore

Siamo arrivati al termine del nostro lavoro, abbiamo rilasciato la nuova versione della sezione. Come facciamo a capire se questo cambio ha avuto successo?
Io questa domanda la faccio prima, a tutti. Voglio capire sin dall’inizio sulla base di quali criteri sarà valutato il lavoro del team (in passato abbiamo già parlato dell’importanza della definizione dei criteri di successo).

Da cosa riconosceremo che questa riprogettazione è stata un successo?”, “Quale criterio di misurazione adotteremo?“.
Spesso vedo facce stranite… evidentemente sono domande inusuali!
Devo dire la verità: nei contesti in cui non c’è una cultura data-driven è normale che le persone facciano fatica ad articolare una risposta a una domanda così a bruciapelo.

Possiamo insistere provando a riformulare in altro modo: “Cosa faranno di più i clienti? Cosa di meno? Cosa diversamente?”, “Cosa inizieranno o smetteranno di fare?“.
Se ci pensate sono esattamente le stesse domande che stanno alla base della definizione degli impatti nell’Impact Mapping.
E infatti è proprio lì che vogliamo arrivare: a condividere degli impatti – ovvero le modificazioni nei comportamenti – e a formulare sulla base di questi le metriche più adatte.

I Key Performance Index corretti ci consentiranno di rispondere con dati quantitativi alla mano alle aspettative degli stakeholder interni e di misurare realmente se e come abbiamo influenzato gli stakeholder esterni.
Le stesse metriche le utilizzo per creare report mensili che condivido con il management team per monitorare l’andamento delle performance di prodotto. E così il ciclo si chiude!