User Story e Jobs To Be Done (per brevità US e JTBD) sono due modi diversi per descrivere nuove opportunità partendo dal punto di vista dell’utente. Meglio ancora: partendo dai bisogni e problemi degli utenti.
In Product Management si enfatizza sempre la necessità di dedicare sufficiente tempo a comprendere il problema prima di iniziare a discutere le soluzioni. US e JTBD aiutano a mantenere questo focus e a inquadrare gli esiti in maniera astratta – a concentrarsi sul perché prima di spostarsi sul come.
Tuttavia US e JTBD non coincidono. È normale domandarsi quale sia lo strumento migliore o quali siano le differenze.
User Story
Le User Story hanno un formato standard: come [tipo di utente] voglio [azione da svolgere] così da [esito desiderato].
Prendiamo l’esempio di un sito che permette di ordinare cibo online. Durante la discovery abbia scoperto che per i clienti è fondamentale considerare le valutazioni degli altri utenti quando scelgono un ristorante. Un esempio di User Story potrebbe essere:
Come cliente voglio poter filtrare i ristoranti in base alle valutazioni degli altri utenti così da poter usare questa informazione quando ordino del cibo
L’idea è connettere un tipo di utente a un’azione o compito. L’esito chiarisce il perché, la motivazione che spinge l’utente a voler compiere l’azione specificata. L’azione (“filtrare i ristoranti”) viene abilitata o facilitata dalla funzionalità da implementare.
Jobs To Be Done
I JTBD hanno un formato più flessibile e si trovano in diverse forme. Il più comune tuttavia è il seguente: quando [contesto] voglio [motivazione] così da [esito].
Un JTBD non descrive un’azione o un compito: nell’essenza dovrebbe descrivere un contesto in cui l’utente, in virtù di qualcosa, ottiene un progresso – progresso intesto come miglioramento della situazione dell’utente. Nel modo di teorizzarli di Alan Klement, il “voglio” è una motivazione e non un compito concreto, come nelle user story: costituisce dunque una sorta di obiettivo di primo livello, che contribuisce all’obiettivo più profondo esplicitato con l’esito.
Se riprendiamo l’esempio del ristorante utilizzato in precedenza, un JTBD potrebbe essere il seguente:
Quando sono alla ricerca di un posto dove ordinare voglio poter utilizzare le valutazioni degli altri clienti per confrontare i ristoranti così da poter aiutarmi con le loro esperienze per prendere una decisione
I JTBD enfatizzano il contesto, che può essere descritto tanto estesamente quanto necessario. Un buon JTBD è agnostico rispetto alle soluzioni ed è relativamente stabile nel tempo.
Nell’ambito di prodotti rivolti a diversi segmenti di utenza è possibile, per utilità pratica, specificare gli attori (“moderatore”, “utente”, “amministratore”, …). Tuttavia, solitamente non ci si focalizza sullo user persona quanto sui contesti e le motivazioni.
Svantaggi dei due framework
I JTBD sono più recenti rispetto alle US e, in parte, sono stati sviluppati in risposta ad alcune loro limitazioni. Una delle critiche alle US è che contengono troppi assunti impliciti. Mancano di esplicitare la causalità tra azione e motivazione, limitandosi a mettere i due in connessione.
L’altro assunto di una US è che l’azione esplicitata sia la migliore possibile per arrivare all’esito desiderato. Infine, viene dato un peso eccessivo all’user persona (quel che sopra ho definito, in maniera imperfetta, “tipo di utente”) senza che questa informazione aggiunga davvero qualcosa. I proponenti di JTBD sostengono che l’informazione sia superflua e impedisca di enfatizzare ciò che conta davvero: il contesto.
I JTBD non sono esenti da critica: in particolare, tendono ad astrarre molto e a favorire l’enfasi sulle motivazioni dell’utente, a discapito della chiarezza rispetto al campo potenziale delle soluzioni. Questa attenzione (eccessiva?) alle motivazioni può rendere difficile utilizzare il framework in maniera operativa per aspetti quali l’UX o l’estetica delle soluzioni.
Dunque, quale usare?
Per quanto anti-climatica sia la risposta, User Story e Jobs To Be Done non sono mutualmente esclusivi. Consideriamo nuovamente i due esempi precedenti:
US: "Come cliente voglio poter filtrare i ristoranti in base alle valutazioni degli altri utenti così da poter usare questa informazione quando ordino del cibo". JTBD: "Quando sono alla ricerca di un posto dove ordinare voglio poter utilizzare le valutazioni degli altri clienti per confrontare i ristoranti così da poter aiutarmi con le loro esperienze per prendere una decisione".
La US, si potrebbe obiettare, è mal scritta perché isola una soluzione specifica (aggiungere un filtro). Il JTBD è più astratto e permette di aggiungere informazioni aggiuntive, in particolare sul contesto. Potrei fornire dettagli (“Quando sono alla ricerca di un posto dove ordinare spesso non conosco i ristoranti listati […]”) o rendere esplicite le ragioni emotive della motivazione (“[…] e le informazioni provviste sul profilo non bastano a darmi fiducia“).
Questo non significa che i JTBD siano automaticamente migliori. Personalmente, penso che sia possibile utilizzare entrambi, benché ciascuno è più utile in determinati contesti. Gli esempi forniti potrebbero tornare entrambi utili se utilizzati per lo scopo corretto.
Le User Story sono utili per contestualizzare le specifiche di prodotto al livello delle singole funzionalità. Sono un buono strumento di comunicazione con gli sviluppatori in quanto creano un ponte tra le specifiche di prodotto e le intenzioni dell’utente. Nello scrivere una PRD, per esempio, sono un buon modo per fornire descrizioni sintetiche delle singole Epic pur mantenendo la prospettiva degli utenti.
I Jobs To Be Done sono migliori per descrivere iniziative e opportunità di portata più ampia, soprattutto quando vi è un certo grado di ambiguità. Ad esempio, possono essere utilizzate per descrivere le iniziative di una roadmap o di un opportunity backlog, o per creare delle problem map al termine di un processo di discovery.
Usati con sufficiente flessibilità, entrambi gli strumenti sono utili per svolgere una funzione essenziale: ricordarci che i nostri prodotti servono a rispondere a esigenze concrete, e ricordarci quali siano queste esigenze.
