Quando l’User Story incontra il Job to be Done

In qualsiasi contesto in cui lavoriamo, c’è un elemento che non cambierà mai e che è sempre stato cruciale per garantire una riuscita di successo: la comprensione delle esigenze del nostro cliente o utente.

Nel nostro ultimo meetup di 2024, il 10 dicembre da Talent Garden Torino, abbiamo chiuso in bellezza con il nostro buon Stefano Marello che ha portato ai partecipanti un mix and match di due approcci chiave che sono le User Stories e il framework Jobs to Be Done (JTBD). 

Il primo passo per comprendere questi approcci è analizzare la triade fondamentale:

Utente + Bisogno + Outcome

Ricordiamoci che ogni prodotto servizio che creiamo (o aiutiamo a creare) ha la responsabilità di soddisfare un bisogno specifico. Ma qui entra una discussione importante: quanto è cruciale mettere in evidenza (e perciò approfondire) l’utente? Quanto questo elemento, che abbiamo già stabilito essere cruciale, può variare a seconda della complessità del contesto e degli attori coinvolti? 

Già nel 2010, alcune aziende come Intercom hanno sollevato dubbi sull’utilizzo delle User Stories e sul fatto che mettere l’utente di riferimento al centro del requisito non portasse vantaggi concreti.

Sebbene le Personas siano strumenti utili per rappresentare gli utenti, esse creano profili immaginari piuttosto che reali. Ed è qui il punto che vogliamo focalizzare perché questo ci porta a interrogarci sul legame tra le personas e gli utenti reali.

 

Non sempre le sfumature delle Personas influenzano direttamente i bisogni fondamentali degli utenti. 

L’esempio che abbiamo utilizzato all’inizio era la necessità di proteggere un account. Il bisogno di base rimane costante, ma le modalità di soddisfacimento possono variare. Ma il bisogno è sempre quello, indipendentemente a quale Personas ci rivolgiamo.

Proviamo ora a guardare da un’altra prospettiva, evidenziando un secondo framework: Jobs to Be Done (JTBD), sviluppato da Clayton Christensen e approfondito da Alan Klement. Il JTBD si concentra sul contesto (sul contesto!) in cui si trova l’utente e sulle motivazioni che lo spingono ad utilizzare un prodotto o un servizio per soddisfare un bisogno specifico. In questo modo, il focus si sposta dalla persona all’attività da svolgere.

 

Quindi, perché non mettere tutti gli ingredienti in pentola per avere una visione molto più pratica dell’utente?

Ed è qui che nascono le Job Stories: una forma alternativa delle User Stories che incorporano elementi chiave del JTBD.  La struttura tipica di una Job Story è: “Quando [situazione], voglio [motivazione], così posso [risultato]”. Questo approccio consente di esplorare le esigenze degli utenti in modo più profondo e contestualizzato.

 

Quando Utilizzare User Stories o Job Stories

La scelta tra User Stories e Job Stories dipende dal contesto del progetto:

• User Stories: Utili quando gli utenti hanno bisogni distinti e variabili. Queste storie iniziano con “Come utente…” per mettere in risalto chi sta compiendo l’azione.
• Job Stories: Preferibili quando i bisogni degli utenti non differiscono significativamente. Qui, il focus è sul compito da svolgere piuttosto che sull’identità dell’utente.

 

E quindi, che approccio mi conviene utilizzare?

Immagina di mescolare User Stories e Job Stories all’interno dello stesso backlog di prodotto. Questo ti permette di avere una visione più completa delle esigenze dei tuoi utenti.

È come avere il meglio di entrambi i mondi.

La cosa bella è che sia le User Stories che le Job Stories sono progettate per migliorare la comunicazione tra i team di sviluppo e gli utenti. Così, puoi essere sicuro che i prodotti finali rispondano davvero ai bisogni di chi li utilizza.

Si crea la possibilità di innovare in modo significativo e rispondere alle esigenze dei clienti in modo efficace. In sintesi, non sottovalutare il potere di queste tecniche, soprattutto quando messe insieme. Lascia che ti sorprendano!

Per visualizzare la presentazione completa, clicca qui.