Aprile 24, 2022 - di Redazione
Abbiamo parlato di Double Diamond approach, al primo Meetup di Product Heroes al Talent Garden di Milano insieme a tantissimi eroi e a un ospite d’eccezione: Miguel Carruego. Consigli, best practice, sessione di Q&A, momenti di confronto, networking e tante risate. Non è mancato davvero nulla, e non vediamo l’ora di organizzare il prossimo! (Ci sarai, vero?!)
A quasi tre settimane dall’evento, possiamo orgogliosamente ammettere che è stato veramente fantastico e abbiamo così pensato di condividere con voi i punti salienti spiegati da Miguel durante l’incontro, partendo dai pillar della Product Discovery.
Se ti sei perso l’evento (o se vuoi rinfrescarti un po’ la memoria), ti consigliamo di continuare a leggere. Troverai di seguito il discorso tenuto da Miguel e le slide nella pagina dedicata all’evento.
Leggi cos’è il Double Diamond: dalla Product Discovery alla fase di Deliver.
Miguel: “È molto bello vedere le persone dal vivo per la prima volta dopo due anni e mezzo. Come ha anticipato Marco, il mio nome è Miguel, e sono VP Product in ProntoPro. Sono nato a Buenos Aires nel 1984, e ho lavorato per tantissime aziende, sia come designer, che come sviluppatore, lavorando anche in ambito IT. Ho iniziato il mio percorso in Tiendanube, dove inspiegabilmente ho incontrato la parte oscura e sono diventato Product Manager, e di lì a poco Head of Product. Ho poi lasciato Tiendanube, che recentemente è diventata una unicorno, e sono così arrivato a Milano per lavorare per ProntoPro tre anni fa, e il prossimo mese sono tre anni esatti”.
Miguel: “Marco mi ha invitato a parlare di Product Discovery. E la domanda è: perché parlare di Product Discovery? Perché fondamentalmente la Product Discovery è il nostro lavoro.
Se mi chiedete qual è la differenza tra un Project Manager e un Product Manager, per me è la capacità di fare Product Discovery. Se mi chiedete qual è la differenza tra un Designer e un Product Designer, bene, per me è la capacità di un designer di fare Product Discovery. In altre parole è quello che fa la differenza tra l’essere dei Product Heroes o della gente che fa prodotto.
Per andare dritto al punto, Product Discovery significa fare qualcosa per le persone reali e non per le persone che sono nella tua testa o nella tua azienda. E fare qualcosa per le persone reali significa, saper arrivare a una soluzione del problema, e fare in modo che questa soluzione sia usabile, utile e naturalmente fattibile”.
First, you need to discover whether there are real users out there that want this product. Second, you need to discover a product solution to this problem that is usable, useful, and feasible. – Marty Cagan
Quindi qual è il punto oggi? L’obiettivo di oggi per me è quello di fare un passo indietro e partire dall’inizio. Spero di dirvi qualcosa di nuovo o d’incuriosirvi al punto tale da essere voi i primi a farvi delle domande. Mi piacerebbe che mettiate in discussione alcuni vostri credo, alcuni vostri processi alcune vostre cerimonie, alcune vostre abitudini.
Oggi parleremo di Product Cycle e del Double Diamond“.
Miguel: “Il Product Cycle è un ciclo di lavoro che ha una cadenza ben precisa. È molto importante distinguere un product cycle da un delivery cycle o da uno sprint. Non è uno sprint, ma pensate a un product cycle formato da 6 + 2 settimane: 6 settimane di shaping & building e 2 settimane di cooldown & commitment (planning).
Se tu sommi queste settimane, hai quello che in ProntoPro noi chiamiamo Product Cycle. Proverò a dirvi come funziona questo processo molto velocemente”.
Miguel: “Quello che noi facciamo per prima cosa è focalizzarci sul definire i problemi – shape the bets – , e dare forma alle soluzioni che vogliamo implementare nei cicli seguenti. E quello che noi chiamiamo processo di Shaping.
When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite – Basecamp.com
Quindi per prima cosa partiamo col dare forma alle scommesse. Le chiamiamo scommesse e non progetti, perché non sappiamo se quello che faremo risolverà concretamente i problemi, sono ipotesi. Ci concentriamo su queste scommesse per sei settimane e le discutiamo su quello che noi chiamiamo il tavolo delle scommesse.
Durante questa riunione prepariamo una lista, un documento comprensivo di tutti i commitment che saranno presenti all’interno del ciclo. Ci diciamo quindi che nelle prossime sei settimane questo è quello che andremo a fare, e quindi procediamo con la fase di Build. Nello stesso tempo ci concentriamo sulla nuova fase di Shaping per il ciclo successivo. Questo è per noi il Product Cycle, ed è naturalmente un ciclo continuo.
Ora non voglio parlare dei pro e dei contro del Product Cycle (vedi slide 28), ma vorrei che vi concentraste sul pensare al ciclo del prodotto come processo di Continuous Discovery by design. Questo è il punto centrale: che l’intero team di sviluppo del prodotto, quindi non solo i Brand Manager, ma anche i Designer, i Ricercatori e gli Sviluppatori sono TUTTI coinvolti nel processo di Discovery.
Il processo di Shaping è quindi mandatorio, e vale anche per tutte le cose che si definiscono super tecniche. Noi cerchiamo infatti di avere Product Manager ovunque, e tutti procedono con lo stesso processo di shaping per raggiungere gli obiettivi”.
Miguel: “Ora parliamo del Double Diamond Model. Che cosa è?
Il Double Diamond (il diamante doppio), è fondamentalmente un framework o appunto un umbrella process che aiuta a risolvere problemi. E’ un percorso strutturato, che ti conduce dalla sfida iniziale challenge – il problema che hai identificato -, verso la soluzione – l’outcome desiderato -, sia essa un cambiamento nel comportamento dei tuoi utenti, un KPI di business, qualsiasi cosa tu voglia impattare e cambiare.
Molte aziende lo utilizzano già, ma inconsapevolmente, altre invece sono consapevoli e magari lo hanno riadattato per la loro specifica realtà. Quella che vi mostro io, è una versione intermedia del Double Diamond, ed è anche quella che mi piace di più, perchè la più semplice. Alcune aziende seguono il processo con tre diamanti, perché usano il terzo diamante per la parte di testing del prototipo.
Questa versione è presa dal Norman Nielsen Group, che ha sua volta si basa sul design process model divulgato dal British Design Council nel 2005, e che ha sua volta ha adattato il modello di divergenza-convergenza proposto nel 1996 da Béla H. Bánáthy (vedi slide 30), linguista ungherese-americano e Professore alla San Jose State University in California.
Bene, partiamo!”
Miguel: “All’interno del processo, l’aspetto che ritengo essere fondamentale è il semplice fatto di poter separare il problema (fase di Discover e Define) dalla soluzione ( fase di Develop e Deliver). Ed è super importante, perché ti obbliga a passare attraverso il problema. Questo è tutto! Potremmo anche smettere di parlare qui e andare a berci un drink, ma dobbiamo entrare nel merito di ogni fase. Non potresti mai iniziare dalla fase di Develop o dalla fase di Design, ma devi sempre iniziare partendo da sinistra, quindi dalla Discover e procedere verso destra fino ad arrivare alla fase di Deliver.”
Miguel: “Un altro aspetto importante nel processo, e che dà il nome al processo stesso, è la forma del doppio diamante, per rappresentare a livello visivo e trasmettere in modo chiaro l’idea di separare il pensiero di divergenza, dal pensiero di convergenza.
Qui il punto centrale è come le persone vengono coinvolte e come si comportano.”
Miguel: “Come potete vedere dall’immagine, quando si parte dal problema si inizia dal pensiero di divergenza. Ma cosa significa divergenza? Significa fondamentalmente CREARE OPZIONI. Questo è il punto nevralgico, dove parti dalla sfida, individui il problema che vuoi risolvere, e metti sul tavolo tutti i problemi connessi al tuo problema principale e le tue intuizioni portandole all’attenzione di tutti. Questo è il momento di spingere sulla creatività del team, di fare brainstorming, di pensare fuori dagli schemi.”
Miguel: “Poi c’è il processo di conversione, che è esattamente l’opposto. Qui il punto centrale non è creare opzioni, ma RIDURRE LE SCELTE. E questo è il momento in cui il Product Manager entra a gamba tesa sulla scena e tutti lo odiano. Perché è un momento dove il PM dice – OK, è tutto molto interessante, le vostre idee sono fantastiche, ma oggi dobbiamo cercare di capire con un metodo scientifico quali sono i problemi più rilevanti e quali sono le soluzioni migliori per risolvere questi problemi. Arriva quindi il momento di capire dove vogliamo andare, e in questa parte del processo NON ci sono opinioni, NON ci sono pareri.
Un importante aspetto in questa fase è il processo di prioritizzazione, e potremmo parlare per ore e ore dei vari metodi di prioritizzazione. Ma il punto centrale qui è il mindset delle persone coinvolte.
Nella fase di diverging, tutte le persone contribuiscono e portano idee, si ascoltano tutti, si parla col marketing, con gli sviluppatori, ed è un momento felice. Ma poi nella fase di converging dobbiamo distinguere quelle che sono opinioni da quelli che sono dei fatti concreti. Bene, se ci sono dei dati a supporto, perché adesso è ora di dare una priorità e concentrarsi sulla cosa più importante. La bellezza di questo processo è che vi ritroverete a divergere nuovamente per poi convergere ancora, perché ricordatevi che siete nel problem space. Tutti si sentono motivati durante la fase di divergenza, ma ti odiano quando si passa alla fase di convergenza, quando tu dici NO, non procederemo a fare questo, perché non c’è la capacità per farlo, perché non impatta sul business, etc. Quindi questa è la parte che tutti odiano di più”.
Miguel: “Bene, ora è il momento di calare questo processo all’interno del Product Cycle. L’unica regola è quella di non saltare le fasi che abbiamo appena visto. Se la tua sfida richiederà più tempo e un effort maggiore, allora potrai pensare di fermarti per due, tre, quattro Product Cycles (ricorda che un product cycle dura 2 mesi per noi). Se invece la tua sfida è semplice e richiede meno sforzo, potrai esaurirla all’interno di un solo ciclo. Il numero di cicli nel prodotto che dovrai sostenere per affrontare la sfida, sono quindi legati alla dimensione della sfida stessa.
Ora analizziamo le fasi una per una”.
Miguel: “La prima fase è chiamata Discover. L’obiettivo qui è portare più problemi possibili sul tavolo. Ci sono infiniti modi di fare Discovery, ma quello che noi facciamo internamente sono le interviste. Quindi abbandoniamo le nostre scrivanie e andiamo a parlare con le persone vere. In ProntoPro, abbiamo un team di Ricercatori che solitamente svolgono questo lavoro, ma io spingo anche i Designer e i Developer a farlo.
Ci sono diversi modi di fare le interviste, e dipende molto dalla sfida che hai di fronte. A volte ha senso concentrarsi sui Job To Be Done o su i 5 Whys, a volte ha senso fare ricerche di mercato e quindi benchmarking, per capire meglio se il problema è già stato affrontato da altre aziende, e se si, come. Naturalmente facciamo anche sondaggi e poll rivolti sia alla domanda (il cliente finale) che all’offerta (nel nostro caso il professionista)”.
Miguel: “Nella fase di Discover è fondamentale rispondere a quattro domande, quattro fondamentali domande. La prima è quella di distinguere quello che le persone fanno da quello che le persone dicono e di capire entrambe. Alcune aziende che sono magari ossessionate dai dati, non parlano con le persone e non indagano sul perché. È invece molto importante andare e parlare alle persone e capire che cosa non le soddisfa e perchè. Quindi è sempre importante integrare la ricerca comportamentale con la ricerca attitudinale (vedi slide 31) e naturalmente fare una ricerca quantitativa (how much/how many) e qualitativa (why). Sembra super ovvio ma è importante sottolinearlo.
È importante capire i perchè e le storie di ogni utente che sta usando il nostro prodotto, ma è anche importante raccogliere i dati, e capire se c’è una correlazione tra il comportamento degli utenti e quello che succede effettivamente. Una volta che riesci a rispondere a queste quattro domande puoi passare alla fase successiva”.
Miguel: “Quindi adesso che sai che cosa fanno i tuoi utenti, che cosa dicono, di cosa hanno bisogno e ogni quanto, e soprattutto quanto è importante il problema, puoi passare alla fase di Define.
In questa fase devi cercare di convergere al problema più importante, e lo puoi fare con diverse modalità:
Miguel:“ Quello che è realmente importante in questa fase è la segmentazione. La segmentazione degli utenti è la chiave del successo. Ci sono tantissimi modi per segmentare gli utenti e i loro bisogni, ma quello che spingiamo di più in ProntoPro è la behavioral segmentation.
Ma lasciatemi dire qualche parola in più sulla segmentazione e le personas. Quello che capita spesso di vedere riguardo alle personas, sono tantissimi dati demografici che però non dicono niente del comportamento dell’utente. Se vogliamo vedere il comportamento e segmentare il comportamento, perché parliamo solo di demografica? Questo non è a mio avviso fare Product Management, ma significa limitarsi a fare statistica. I dati statistici sono utili per fare delle correlazioni, ma io penso che le personas andrebbero costruite intorno a un mindsest o un particolare comportamento, magari con dei Jobs To Be Done, o quello che volete, ma non certo con la demografica. Per favore non scrivete in un documento che siccome gli utenti sono donne, allora ameranno fare shopping. Questo ragionamento è davvero limitato, perchè i dati demo non dicono davvero nulla del comportamento e dell’utente.
Penso al Principe Charles e a Ozzy Osbourne. Probabilmente hanno un comportamento all’acquisto diverso. Non credete? Chi lo sa! Magari si, magari no”.
Miguel:“ Adesso, se abbiamo completato la fase che riguarda il problema, arriviamo a un punto critico del processo che a mio avviso è molto importante, e che è il momento in cui ci si può fermare, l’unico momento in cui ci si può fermare. Questo è infatti il momento in cui, se sei fortunato, capisci che questo non è il problema che sarebbe bene risolvere per il business, per quel particolare momento, per qualsiasi altro motivo. E’ un punto critico, perché la risposta che bisogna darsi è: andiamo avanti con la sfida o ci fermiamo qui? E se ci fermiamo qui non è un fallimento, ma è fondamentalmente una vittoria per il Product Team“.
Miguel: “Adesso, se decidi di proseguire e di costruire, perchè il problema è realmente importante, devi pensare alla soluzione. E per farlo inizierai una nuova fase di diverging, ma nella fase dedicata alla costruzione della soluzione, che è una delle fasi più divertenti, perchè è il momento in cui Sviluppatori e Designer sono propositivi e cose che pensavi fossero impossibili da fare, si fanno! Ma tieni a mente che ogni cosa che fai è una scommessa.
Adesso che hai segmentato i tuoi utenti, dovresti avere una lista di persone delle quali conosci i comportamenti, sai cosa fanno e che problemi hanno. Attraverso la tecnica del Mind Mapping o di quello che preferisci, dovresti ricavare un buona fotografia di quelle che sono le soluzioni per ogni use case. Inizi quindi a costruire il prototipo sulla base della tua ipotesi, e inizi a fare User Testing. Questo è il modo migliore di sapere se la soluzione che hai nella testa è realmente fattibile e possibile. Quindi è il momento di fare Prototyping e User Testing“.
Miguel: “Altra cosa super importante, è scoprire la value proposition. Ogni tanto si tende a non pensarci, ed è un problema. Lo facciamo a livello alto di prodotto, ma anche quando costruiamo una feature, perchè non dedichiamo sufficiente attenzione a capire se effettivamente quel tipo di feature può avere o non avere valore per l’utente e ci limitiamo a ripetere una ricetta che abbiamo già visto. Ma avrà senso davvero usare quella stessa ricetta in quella specifico momento? Pensateci!”.
Miguel: “Ora che hai individuato le possibili soluzioni, hai bisogno di convergere nuovamente, di prioritizzare, e di trovare la soluzione sulla quale punterai. È la fase dello Scope Hammering (ti focalizzi solo sulle cose che hai veramente necessità di fare) e che i Designer odiano, perché è dove i Product Manager bocciano quasi tutte le proposte. Ma è inevitabile.
È anche il momento per fare un A/B test per vedere se la nuova soluzione è migliore dell’attuale. Puoi fare un A/A test, un PD test, qualsiasi test ti piaccia fare. Magari un Rollout Progressivo, perchè non sei sicuro. Inizi quindi a deliverare la nuova soluzione solo al 10% del tuo pubblico per vedere cosa succede, per poi andare avanti. È il momento giusto per farlo. Questo è il Double Diamond“.
📚 Libri consigliati da Miguel:
Ora che conosci il Double Diamond, non ti resta che sperimentarlo, e tieni presente che è un processo circolare e non lineare, che ti permette di tornare indietro e di provare nuove soluzioni, laddove quella scelta non produca l’outcome desiderato. Imparare e reiterare saranno quindi il tuo pane quotidiano. Buon esperimento!
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management
2 replies on “Il Double Diamond: dalla Product Discovery alla fase di Deliver”
Diego
Grazie per questo interessantissimo articolo! Ogni tanto quando mi trovo bloccato su dei problemi e mi arrivano queste risorse e idee che mi aiutano a rimettere tutto in discussione e migliorare i miei processi mentali, mi sento fortunato! Mi sarebbe davvero piaciuto esserci.
Valentina Lanesi
Ciao Diego, grazie per il feedback! Tieni d’occhio la newsletter e la pagina eventi, perché abbiamo altre date in programma e sempre in presenza. Appena siamo pronti, ve lo comunichiamo 😉