Quando si progetta e sviluppa un nuovo prodotto, è essenziale non perdere mai di vista i potenziali clienti: studiarne i comportamenti, parlarci, coinvolgerli nel processo di progettazione aiuta a ridurre sensibilmente il rischio di costruire qualcosa che non corrisponde ai loro bisogni e che quindi non compreranno.
Esistono diversi modi per raccogliere informazioni sui consumatori. Per esempio, la sezione dedicata agli strumenti per la progettazione delle esperienze del sito di Sketchin elenca ben 74 tool utili ad «analizzare e comprendere il comportamento e i bisogni degli utenti». Tra questi, non c’è dubbio che le interviste siano uno dei più efficaci. Tuttavia, condurre un’intervista nel modo corretto richiede molta pratica e diversi tentativi. Quali sono le domande giuste da fare? Come vanno poste? Come vanno analizzate le risposte?
Nelle ultime settimane, ho lavorato con Alessandro Zonnino con l’obiettivo di progettare un modello per insegnare in modo efficace agli innovatori a fare ricerca e calarsi nei panni delle persone a cui sono destinati i prodotti che stanno ideando. Siamo partiti analizzando oltre 200 interviste realizzate dagli studenti del corso di Digital Product Design che tengo all’Università Roma Tre con l’obiettivo di individuare i principali errori compiuti da persone che fanno un’intervista per la prima volta. Quindi, abbiamo passato in rassegna la letteratura sull’argomento, soffermandoci in particolare sui lavori di Clayton Christensen, Alexander Osterwalder, Jake Knapp e dei fondatori di IDEO, i fratelli Tom e David Kelly.
Gli errori comuni tra i non esperti
Iniziamo da quello che abbiamo imparato dai miei studenti. Gli errori più comuni sono essenzialmente due. Il primo consiste nel fare domande che sollecitano le risposte che vorremmo sentire. Capita soprattutto a chi ha un’idea per un nuovo prodotto e va inconsciamente alla ricerca di conferme e rassicurazioni perché ha paura di scoprire che l’idea geniale che ha avuto non è poi così geniale. Questa dinamica è stata spiegata brillantemente da Rob Fitzpatrick nel libro The Mom Test. Ci sono molti modi per ottenere risposte confortevoli. Per esempio, se avessi inventato un’app per ordinare il cocco in spiaggia, potrei sollecitare conferme chiedendo: «hai mai comprato il cocco in spiaggia?», oppure «ti piacerebbe ordinare del cocco direttamente dall’ombrellone?» Se state pensando che solo uno stupido farebbe domande del genere, vi assicuro che sono molto più frequenti di quello che immaginate. Quando parlo con aspiranti imprenditori della loro idea, chiedo sempre se hanno parlato con i loro potenziali clienti. Se mi rispondono «certo e tutti ci hanno detto che lo comprerebbero» vuol dire che hanno (inconsapevolmente) costruito delle interviste per farsi dire che l’idea è bellissima. Alcuni aggiungono: «ne abbiamo anche parlato con l’esperto tal dei tali e ci ha detto che era molto interessato».
Il secondo errore molto comune che ho visto fare da chi si affaccia per la prima volta al mondo delle interviste è di usare delle domande chiuse o, addirittura, di costruire un questionario, trasformando un’intervista qualitativa in un’indagine quantitativa. I due strumenti hanno degli obiettivi completamente diversi: lo scopo di un’intervista in profondità è esplorare un argomento alla scoperta dei fattori che lo caratterizzano. Viceversa, un questionario presuppone che si conoscano le dimensioni da indagare e se ne voglia misurare la frequenza. Quindi, occorre imparare a fare domande aperte che permettano di andare all’esplorazione del mondo dell’intervistato per raccogliere informazioni utili all’attività di progettazione.
Tuttavia non basta. Anche quando si è imparato a evitare le domande confortanti e ad ascoltare i racconti degli utenti, rimane un fondamentale problema: che cosa chiedere? Come si fa a far uscire allo scoperto le informazioni più utili? È possibile seguire un modello? Noi siamo partiti dalla teoria del Job to Be Done di Clayton Christensen.
Job to Be Done
In Competing against luck, Christensen definisce un job come «il progresso che una persona sta cercando di fare in una determinata circostanza». In altri termini, ognuno di noi si pone degli obiettivi e si muove nella direzione che gli permette di raggiungerli. In questo percorso, ingaggia (hire) dei prodotti e dei servizi che gli permettono di fare dei progressi nella direzione auspicata.
Il concetto di Job to Be Done è semanticamente più ricco del più popolare approccio che suggerisce che una persona acquista un prodotto perché rappresenta la soluzione a un problema. Infatti, un job non è necessariamente un problema. Christensen offre molti esempi non ovvi per spiegare la sua teoria. Per esempio, perché i clienti di un fast-food comprano un milkshake? La risposta non è univoca: alla mattina, i pendolari lo comprano perché hanno bisogno di “ciucciare” qualcosa durante un tragitto noioso. Al pomeriggio, i genitori lo comprano come premio per i figli. Lo stesso prodotto svolge due lavori (job) completamente diversi e compete con categorie completamente diverse di alternative. Questa consapevolezza offre tante opportunità per migliorare le caratteristiche del prodotto e la sua desiderabilità verso segmenti specifici di clienti.
Il passaggio dai problemi ai job comporta un cambio sostanziale di prospettiva. Nelle interviste, non si va più alla ricerca di problemi da risolvere (ricerca spesso frustrante) ma dei progressi che le persone stanno cercando di fare in determinate circostanze. Queste ultime hanno un impatto determinante sulla capacità di una persona di conseguire il progresso sotteso al job. Dalle circostanze, infatti, dipendono gli ostacoli e i problemi che si frappongo alla realizzazione di un obiettivo, nonché le aspettative delle persone sui risultati che possono ottenere.
La teoria dei Job to Be Done è stata utilizzata e sintetizzata anche da Alexander Osterwalder nel suo Value Proposition Canvas. Secondo lo studioso svizzero, è utile distinguere tra job funzionali (quando le persone cercano di risolvere un problema pratico, come tagliare l’erba o mangiare in modo salutare), job sociali (quando le persone vogliono apparire positivamente oppure conquistare potere) e job emotivi (quando le persone ricercano una specifica sensazione come sentirsi sicuri). Allo stesso tempo, Osterwalder sottolinea che i job non hanno tutti la stessa importanza e che i consumatori tenderanno a occuparsi prima dei problemi in base alle loro conseguenze negative (pain) o positive (gain).
I pain, o punti dolenti, descrivono tutto ciò che disturba o impedisce di completare un job. Può trattarsi di risultati indesiderati, ostacoli materiali o rischi da correre. Viceversa, i gain, o miglioramenti, descrivono i benefici desiderati e possono essere classificati in indispensabili, attesi, desiderati e inaspettati.
Il Value Proposition Canvas suggerisce che un prodotto desiderabile deve aiutare il cliente a compiere il suo job, minimizzando i pain e massimizzando i gain. Ovviamente, è più facile a dirsi che a farsi.
La teoria dei job ci fornisce un modello utilissimo a impostare l’attività di ricerca sui consumatori e a condurre le interviste in profondità.
Il punto di vista dell’innovatore
Occorre sottolineare che nessuno affronta l’attività di ricerca senza informazioni e opinioni, soprattutto se ha già un’idea per un prodotto. Anzi, il più delle volte, l’idea nasce proprio perché l’innovatore ha sperimentato un problema e ha iniziato a pensare a come risolverlo e quindi ha un’opinione già formata sullo spazio di opportunità.
Avere in testa una soluzione è probabilmente il più grande ostacolo quando si dialoga con i potenziali clienti per due motivi: 1) è la molla cha fa scattare le domande rassicuranti di cui abbiamo parlato prima; 2) porta a esplorare alcune dimensioni a discapito di altre, evidenziando alcune informazioni e sottovalutandone altre.
Steve Portigal in Interviewing users: how to uncover compelling insights suggerisce di “liberare la mente” adottando dei rituali prima di iniziare a progettare e condurre le interviste. Il primo è il brain dump: il team condivide ipotesi, aspettative, credenze, prospettive su quello che accadrà. Dicendolo ad alta voce e scrivendolo su una lavagna (la tecnica è sempre quella dei post-it) si portano questi temi in uno spazio neutro. Questo esercizio può essere utilmente integrato chiedendo a degli esperti qual è il loro punto di visto sull’argomento oggetto dell’indagine. È quanto suggerisce Jake Knapp in Sprint. How to solve big problems and test new ideas in just five days che scrive: «nessun sa tutto. Invece, le informazioni sono distribuite asimmetricamente».
Mettere in campo quello che si sa dell’argomento che vogliamo indagare e raccogliere informazioni da esperti, ci aiuta a fare una valutazione di quanto pensiamo di sapere di un certo argomento e a individuare i temi da indagare. Le interviste che stiamo realizzando in queste settimane per mettere a punto il prodotto “Innovation School of Rome” sono un utile esempio. Sia io che Alessandro partiamo con un certo bagaglio di informazioni e opinioni sul tema: abbiamo letto molta letteratura, abbiamo sperimentato due diversi syllabus per il corso di Digital Product Design all’Università Roma Tre. Io ho diversi anni di esperienza sia come piccolo imprenditore che come mentor in programmi di accelerazione. È il classico caso di chi ha individuato una soluzione facendo leva sulla sua storia professionale e personale. Il rischio dell’auto-refenzialità è dietro l’angolo.
Tutte queste informazioni ci hanno permesso di individuare una serie di temi rilevanti quando si parla di progettare e sviluppare un nuovo prodotto. Tra questi: team, sviluppo del progetto, mentor e coach, raccolta di fondi, e via di seguito.
Per ogni tema, abbiamo identificato una lista di domande utili a condurre l’intervista. Per esempio, nel caso del team, ci interessava sapere come si è formato, se è completo, quali sono le competenze, quali sono le dinamiche tra i membri del team e via di seguito. È importante fare una lista di possibili domande anche se non le useremo tutte: ci aiuteranno a governare la conversazione.
Condurre l’intervista
Una volta identificati i temi da esplorare e dopo aver individuato le domande da porre per esplorare i singoli temi, possiamo iniziare le nostre interviste. Il mondo migliore per farlo è usare delle domande aperte e lasciar parlare l’intervistato: l’obiettivo è costruire un piccolo documentario. Per esempio, le interviste che stiamo facendo per l’Innovation School of Rome agli aspiranti imprenditori iniziano con un semplice «raccontami di te» e proseguono con un «raccontami la tua idea». Dopo queste due domande di riscaldamento, passiamo ad esplorare la storia del progetto e del team: «adesso, vorrei che ripercorressimo insieme i passaggi che avete fatto. Partiamo dall’inizio: come ti è venuta in mente la tua idea?»
Man mano che l’intervistato racconta la sua storia, evidenzia anche i suoi Job to Be Done, ossia gli obiettivi che lo hanno tenuto impegnato, che gli hanno creato delle preoccupazioni o che non è ancora riuscito a raggiungere. Nelle interviste che abbiamo condotto finora per la scuola, per esempio, c’è chi ha posto l’accento sulla necessità di trovare un socio tecnico, chi deve lanciare il prodotto, chi sente il bisogno di ricevere consigli da persone esperte, chi ha bisogno di fondi e via di seguito. In altri termini, il job generale «devo creare una startup» racchiude una serie di job più piccoli, che sono i progressi che gli intervistati stanno cercando di fare per raggiungere l’obiettivo.
Dopo aver individuato un certo numero di job importanti per l’intervistato, possiamo andare in profondità e fare delle domande più mirate, che hanno l’obiettivo di analizzare qual è l’approccio corrente, quali sono i punti dolenti e quali i criteri di successo. Per esempio:
| Tema | Team | |
| Job to Be Done | Ho bisogno di trovare un co-founder tecnico | Ho bisogno di trovare un nuovo programmatore |
| Approccio corrente | Hai detto che stai cercando un co-founder tecnico. Qual è l’ultima cosa che hai fatto per cercarlo? | Hai detto che stai cercando un nuovo programmatore. Come stai facendo? |
| Ho partecipato a uno Startup Weekend a un hackathon, ma è andata piuttosto male. C’erano pochissimi tecnici e la maggior parte erano studenti. | Ho messo degli annunci alla facoltà di informatica, ma finora non mi ha risposto nessuno, | |
| Pain | Raccontami l’esperienza dell’hackathon. Che aspettative avevi? Com’è andata? | Che cosa è andato storto con quello precedente? |
| Ho proposto di sviluppare il mio progetto, ma il programmatore nel team non era competente. Non so come valutare se uno sa fare quello che mi serve. | Non rispettava le scadenze e voleva cambiare il progetto perché diceva che così non funzionava. | |
| Gain | Oltre alla competenza, come ti immagini il tuo co-founder? | Quindi cosa dovrebbe fare il programmatore per soddisfarti? |
| Mi piacerebbe trovare una persona molto precisa, perché non sopporto l’approssimazione. | Dovrebbe fare come dico senza mettersi a discutere qualunque cosa. | |
Stiamo sperimentando diversi template per esplorare le sfaccettature di un job. Quello proposto in questa tabella è una semplificazione del Job Atlas elaborato da Stephen Wunker nel libro Jobs to be done: a roadmap for customer-centered innovation.
Conclusioni
Intervistare decine di persone è un processo lungo e faticoso che non offre molte scorciatoie. In questo articolo, ho descritto un framework di progettazione e conduzione delle interviste basato sulla letteratura specialistica e sulle mie personali esperienze di docente. Inoltre, è un modello che, oltre a essere metodologicamente robusto, dovrebbe essere facile da spiegare a chi non ha mai svolto ricerca sugli utenti.
Ovviamente, questo articolo non esaurisce il tema. Oltre allo sforzo e al tempo per realizzare un’intervista, infatti, occorre considerare anche quello che processare le informazioni in modo strutturato e individuare quelle più utili all’ideazione e progettazione di prodotti. Questo argomento sarà l’oggetto del prossimo scritto.