Personas nel product management
Il product management riguarda le decisioni. Decisioni su quali opportunità cogliere, quali problemi vale la pena risolvere, quali feature forniranno il maggior valore, quali sono i migliori compromessi in termini di time-to-market e quali clienti sono i più importanti. Anche se non si prenderà mai il 100% delle decisioni giuste, nella maggior parte delle decisioni bisogna avere ragione affinché il prodotto possa avere successo.
Personas (profili utente) come strumento
Uno dei miei strumenti preferiti per le decisioni difficili sono le Personas (dette anche profili utente). Per chi non sa cosa sono le Personas: è una tecnica per raccogliere, identificare e comprendere le informazioni più importanti dalle interviste con utenti e clienti, e per capire chi sono le diverse persone che utilizzeranno il nostro prodotto. Le Personas descrivono un utente immaginario ma estremamente plausibile e le sue caratteristiche – in particolare i suoi comportamenti, le sue convinzioni e opinioni e i suoi obiettivi.
Questo strumento è stato menzionato per la prima volta nel 1998 in uno dei miei libri preferiti, The Inmates are Running the Asylum di Alan Cooper. Se non hai ancora letto questo libro, dovresti farlo. È un classico per product manager, designer e sviluppatori.
Personas in diversi ambiti
È possibile che i tuoi designer utilizzino già le Personas nel loro processo di design. La community del design sembra aver adottato questa tecnica, poiché la maggior parte dei team di design che ho conosciuto lavora con questo strumento. Ogni team ha le proprie idee su cosa rende buone le Personas e quanto formale debba essere il processo di creazione, ma a mio avviso va benissimo così.
Forse anche il tuo dipartimento marketing lavora già con le Personas. L'utilizzo delle Personas è molto simile in entrambi i casi ed entrambi hanno senso, ma non sono completamente identici, poiché vengono utilizzati per due scopi molto diversi. Il team di marketing vuole scoprire come raggiungere al meglio il pubblico target e fare leva sulle loro emozioni nascoste. I designer sono più interessati agli obiettivi degli utenti e al loro comportamento online.
Per un product manager, questo dovrebbe essere particolarmente utile.
L'uso corretto delle Personas
Ma nonostante questo sia uno strumento molto potente, le Personas vengono spesso utilizzate troppo tardi nel processo di definizione/Discovery del prodotto, perché frequentemente sono i designer a guidare tutto e vengono per lo più coinvolti troppo tardi nel processo.
Per sfruttare il vero potenziale delle Personas, i product manager devono essere fortemente coinvolti nella creazione e nella prioritizzazione delle Personas e soprattutto nelle interviste con gli utenti e nel lavoro di ricerca necessario. La creazione delle Personas dovrebbe avvenire in collaborazione tra il product manager e l'Interaction Designer – e se hai la fortuna di averne uno – anche con il tuo team di User Research. Ma qualunque cosa tu faccia, non delegare questo compito. Per lo stesso motivo per cui il product manager deve essere presente a ogni test di usabilità, deve essere presente anche a ogni intervista con gli utenti. Il product manager ha bisogno di una profonda comprensione del pubblico target, che nasce solo quando si parla con il maggior numero possibile di utenti e clienti.
Per questo cerco di spingere i product manager a partecipare attivamente alla creazione delle Personas e ad assicurarsi di completarle il prima possibile nel corso del processo.
La community del design ha già scritto così tanto sulle Personas che non voglio ripetere tutto qui. Tuttavia, vorrei menzionare alcuni punti specifici, poiché sono particolarmente rilevanti per i product manager.
Le Personas come strumento per il product management hanno diversi vantaggi:
Le Personas aiutano a dare priorità a ciò che è importante. Se, ad esempio, hai deciso di rendere "Mary" l'obiettivo di questa release, e un determinato feature è importante per "Mary", allora dovresti implementarlo. Se il feature fosse per "Sam", non verrebbe implementato. Come vedi, è importante non solo decidere a chi è destinata questa release, ma anche a chi non è destinata. È un errore molto comune voler soddisfare tutti con un prodotto e alla fine non soddisfare nessuno. Questo processo può aiutare a evitare esattamente questo.
Uno degli errori più comuni dei team di prodotto è confondersi con i clienti. Ho già scritto su questo argomento, ma ciò che apprezzo davvero delle Personas è che ci aiutano ad affrontare questo problema molto diffuso.
La maggior parte dei prodotti ha utenti molto diversi – diversi utenti finali, manager, amministratori ecc. e rapidamente si presume che basti implementare qualche feature per tutte queste persone, il che però porta solo a un enorme caos. In parte è un problema di design, ma le Personas possono anche aiutare a prioritizzare l'importanza di questi diversi utenti e a capire dove potrebbe servire una User Experience separata.
Le Personas sono davvero adatte a spiegare all'intero team di prodotto per chi è pensato il prodotto, come questi utenti lo utilizzeranno e perché è importante per loro.
Fondamentalmente, le Personas (come i principi del Manifesto/prodotto) hanno il grande vantaggio di riunire il team attorno a una visione comune. Ci sono letteralmente migliaia di dettagli che devono essere chiariti lungo il percorso verso la release del prodotto. Il product manager (o designer) non può gestirli tutti. Se tutti i manager, designer, sviluppatori, tester ecc. hanno davvero interiorizzato i principi del prodotto e le Personas, possono prendere molto più facilmente la decisione giusta quando si trovano di fronte a una questione aperta.
Insidie delle Personas a cui prestare attenzione
Alcuni team creano le Personas ma non fanno il passo successivo, ovvero prendere la difficile decisione di quali Personas abbiano la priorità. Non è positivo dire che un prodotto è pensato per tutti. In questo modo ci si prende in giro. Anche se per la maggior parte dei product manager è estremamente difficile, cerco davvero di spingere i product manager a orientare ogni Release su un'unica Persona. Non è che questa release non possa portare benefici anche ad altre persone, ma il tuo focus dovrebbe essere fare un buon lavoro per questo specifico tipo di utente.
A volte i team creano Personas basate su supposizioni e stereotipi riguardo gli utenti, ma non si prendono il tempo di parlare con utenti reali e verificare se questi utenti teorici esistono davvero. Mi sono trovato spesso di fronte a sorprese. Così spesso che ho imparato a considerare le mie prime impressioni solo come teorie e a formarmi un'opinione vera solo dopo aver effettivamente parlato con gli utenti.
Una domanda frequente è se si debbano testare i prototipi solo con le Personas principali. Naturalmente dovresti assicurarti che il tuo prodotto sia un prodotto eccellente per coloro a cui è destinato. Tuttavia, dovresti anche far testare alcune persone al di fuori delle Personas principali, poiché probabilmente non avrai la fortuna che solo queste persone utilizzeranno il tuo prodotto. Per il testing dei prototipi dovresti quindi avere sempre a disposizione un'intera gamma di possibili utenti.
Se non l'hai ancora fatto, dovresti pensare di creare una Persona che descriva un utente tipico del tuo pubblico principale per la prossima release, e poi valutare se questo strumento non possa aiutarti a prendere tutte le decisioni difficili.
Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano.
Requisiti non funzionali
=> Come trasformi i requisiti non funzionali in User Stories?
Vantaggio competitivo tempo
=> Come ti offre Scrum un vantaggio competitivo?