Agosto 1, 2022 - di Andrea Pacchioni
Stimolare la creatività del team nel solution space è davvero fattibile?
Siamo tutti d’accordo sul fatto che i membri del Product Team desiderano contribuire al successo del prodotto e sentirsi partecipi. Bene, io sono convinto che sia compito del Product Manager dare al team una buona ragione per farlo, insieme a tutti gli strumenti utili, ‘adattando’ le metodologie più note al contesto specifico.
Il double diamond framework è sicuramente un modello conosciuto da tutta la community di Product Heroes. Miguel Carruego ha condiviso la sua ricca esperienza a riguardo dando una ampia spiegazione di come si possa evolvere il framework in un processo aziendale rodato.
All’interno del solution space, la fase divergente è quella in cui ogni membro del team sente di poter contribuire in misura maggiore per risolvere il problema. Questi sono i momenti in cui la creatività del team è una delle risorse più preziose. Tuttavia, lavorando fianco a fianco ogni giorno, è inevitabile essere coinvolti emotivamente a tal punto che ci sembra che una idea funzioni meglio di altre.
Ma partiamo da alcune domande:
Sono preoccupazioni e domande legittime su cui cercherò di condividere la mia esperienza.
Partiamo col dire che la creatività non riguarda l’arte, la bellezza o la ‘stranezza’. Questo l’ho capito quando lessi Creativity Inc., la biografia di Ed Catmull, Presidente di Pixar Animation e Disney Animation (ha direttamente supervisionato Toy Story e collaborato con Steve Jobs).
Oxford definisce la creatività come:
Capacità produttiva della ragione o della fantasia, talento creativo, inventiva.
L’arte può essere fine a sé stessa, espressiva o insignificante. L’arte ha la necessità di essere libera, nello spazio e nel tempo, e trovo quindi che sia incompatibile con un contesto aziendale dove scadenze, numeri e soldi sono all’ordine del giorno. La creatività pare quindi essere una capacità di entrambi gli emisferi del cervello e che tutti possediamo. Non serve essere Van Gogh o Lucio Fontana, per dire.
Una seconda caratteristica della creatività è la sua limitatezza, esattamente come le nostre energie quotidiane. Abbiamo tutti quei momenti della giornata in cui ci sentiamo un treno giapponese in corsa mentre altri in cui siamo più lenti dei bradipi. È perfettamente normale, ma in un contesto aziendale e di gruppo è un elemento a cui bisogna pensare.
Infine, non è vero che solo i designer siano creativi. Come detto precedentemente, chiunque ha capacità creative che possono essere più inclini alla ragione o alla fantasia, più logiche o più fantasiose.
Per rispondere a questo ho dovuto fare molte ricerche, perché io stesso non sapevo se l’originalità delle idee fosse sinonimo di qualità o, perlomeno, un segnale positivo. Teoricamente poteva pur esserlo, ma come potevo essere certo con i miei dati? Sono andato come un piccolo nerd a leggere degli studi scientifici (sì, sono matto) che avessero come oggetto la produzione creativa, intesa in un contesto ovviamente aziendale.
In tutti gli studi i soggetti partecipanti erano divisi in gruppi e gli scienziati valutavano come proxy di successo questi parametri:
Tutti gli studi che ho letto dimostrano una correlazione positiva tra numero di idee generate (fluency) e gli altri due parametri (flexibility e originality). In altre parole, maggiore è il numero di idee e più sarà probabile che quelle saranno diverse tra di loro e originali.
ATTENZIONE: è solo più probabile, non è certo e non è un lavoro affatto semplice.
Lato Digital Product Manager, è necessario tanto lavoro su di sé di comunicazione, gestione, empatia e conoscenza individuale dei membri del team. Ancora prima d’imparare tecniche come il Crazy 8, è più importante stabilire quel rapporto umano che ci aiuta a sconfiggere i 3 nemici della creatività.
Vediamoli uno ad uno.
Con stakeholder intendiamo le persone che hanno un interesse a vedere il prodotto finito e funzionante. L’eterogeneità del team è un fattore di successo perché la differenza di background e di processi mentali consente un maggior numero di soluzioni; tuttavia, sebbene la correlazione sia di facile intuizione (più menti = più soluzioni), nella praticità di tutti i giorni sarà complicatissimo per un DPM gestire troppe persone.
Se pensiamo che, idealmente, un team di prodotto è composto da un designer, uno sviluppatore back-end, un front-end, un data analyst e un quality assurance, è ragionevole pensare che ci sia abbastanza diversità. Stereotipando un po’ i ruoli, gli ingegneri hanno un mindset più razionale rispetto ai designer, i quali hanno un maggior occhio estetico e di flusso.
Quindi, come risolviamo il problema degli stakeholder? Limitandoli a quelli davvero rilevanti alla soluzione del problema. Nella pratica significa costruire relazioni quotidiane, anche extra lavorative, e sapere riconoscere il valore e l’apporto che possono effettivamente dare. Ci vorranno tempo e tanti errori di valutazione, ma ‘nessuno nasce imparato’.
Il solutioneering è un bias o una tendenza umana a trovare al più presto la soluzione ad un problema che stiamo affrontando. È semplice istinto di sopravvivenza e, a livello psicologico, si basa sul bisogno di sentirsi utile. Sebbene questo istinto sia più pericoloso quando si opera nel solution space, rimane il rischio che i nostri collaboratori propongano idee senza aver compreso del tutto il problema da risolvere.
È inutile che sprechiate le vostre energie per anticipare questo bias perché è inevitabile. Accettiamo e impariamo a riconoscerlo quando si manifesta nelle idee che vengono proposte semplicemente chiedendoci: questa idea come risolve a livello pratico il problema che vogliamo risolvere?
È la tendenza a limitare la nostra visione di un argomento ai pochi punti di vista che si conoscono.
Questo uccide la creatività. È importante far si che diversi punti di vista si mischino tra di loro, che ci sia libera comunicazione e scambio di opinioni. Non tanto per trovare il compromesso, ma per trovare ispirazione. Un parallelismo che mi ha sempre ispirato è quello con la cucina; i migliori chef sono quelli che viaggiano, provano e capiscono le tecniche ponendosi molte domande. Da lì poi mischiano tecniche, ingredienti, cotture e porzioni per dare sfogo alla loro creatività.
Torniamo per un attimo in classe.
Chi si ricorda delle infinite discussioni con i propri compagni di gruppo per la buona riuscita del progetto? Notate qualche differenza tra quelle riunioni e quelle aziendali?
Queste riunioni sono la criptonite della creatività perché sono figlie del loro tempo. Il brainstorming è nato nel 1938 nel settore pubblicitario americano e il focus group venne coniato nel 1940 da due sociologi per scoprire l’opinione di un gruppo di soggetti su un argomento (come poi questo sia diventata una metodologia per stimolare la creatività rimane un mistero anche per Google). Si capisce bene che sono un pochino anacronistici.
Se non bastasse, ecco giusto un paio di ulteriori ragioni:
Tutte queste sono ottime ragioni per abbandonare immediatamente pratiche come il brainstorming e focus group. Il loro problema di fondo è che non comunicano ai partecipanti delle sessioni la netta distinzione delle fasi di idea generation e idea evaluation. Sono fasi il cui obiettivo è totalmente diverso.
Seguendo il double diamond framework e tenendo a mente i lati negativi del brainstorming e del focus group, ho quindi iniziato a sperimentare diversi approcci per far produrre al mio team il maggior numero di idee possibile nella fase di idea generation.
Per riuscirci ho lavorato sulla mia comunicazione e sulla leadership, traendo vantaggio anche dai contesti più informali (pause caffè, pranzi, walk and chat…). Questo mi ha permesso di trasmettere fiducia nelle capacità del team e di concentrare le forze sulla gestione dei meeting di idea generation.
Per valutare l’efficienza di una riunione si devono considerare 3 aspetti:
Comunicare l’agenda del meeting è la miglior mossa per allineare gli invitati ancora prima che si inizi. Chi partecipa alle sessioni di idea generation deve avere senza ombra di dubbio il contesto e il problema da risolvere così come i tasks e le responsabilità a seguire. Ovviamente, non tutti i contesti aziendali permettono questo tipo di impostazione dal giorno alla notte. Sarà necessario, in questi casi, intraprendere un percorso di miglioramento, a volte estenuante, che coinvolgerà più persone, anche più in alto di voi. È fondamentale dimostrare i benefici raggiunti portando evidenze.
Per poter gestire meglio le sessioni di idea generation, come secondo step, ho tolto quello che non funzionava e ho limitato il tempo. La domanda sorge quindi spontanea; in che misura ho tolto? Con che criterio? Come accennato precedentemente, cerco di portare al tavolo solo le persone che hanno confidenza/competenza del tema/problema e che almeno sappiano la differenza tra problem space e solution space. Non è cattiveria, ma si tratta di essere concreti, pratici e rispettosi del tempo altrui.
A titolo di esempio, chi deve essere necessariamente coinvolto sono gli sviluppatori (QA compresi, non dimentichiamoci di loro), i designer e almeno un altro soggetto. Qualsiasi altro soggetto invitato è a discrezione vostra; solo l’esperienza e il buon senso vi potranno aiutare, anche perché ogni azienda ha le sue politiche interne.
Limitare il tempo, per quanto sembri paradossale, è lo strumento più utile per stimolare la creatività. È scientificamente dimostrato che il nostro cervello abbia le migliori performance creativa e inventiva quando le risorse sono limitate.
Inoltre, qualsiasi strumento tech è BANDITO. Se si tratta di un meeting in remoto, allora chiedo che le notifiche siano silenziate e, se possibile, il telefono in un’altra stanza. Questo mi consente di limitare le distrazioni che possono venire dall’esterno (notifiche di social, mail, Slack etc).
Ho imposto al mio team un paio di regole da osservare fino alla fase di idea evaluation;
Dopo un paio di sessioni, ho raccolto feedback anonimi e le persone coinvolte hanno confermato un loro maggior coinvolgimento, un miglior utilizzo del loro tempo e la sensazione che le proprie idee non fossero condizionate. Al tempo stesso, però, mi hanno condiviso anche una sensazione di “blocco”: sentivano che avrebbero potuto proporre di più, come se gli mancasse l’ispirazione.
A conti fatti questo era vero. In media erano state proposte 3 idee a persona ma, guardandole bene e paragonandole, la media si dimezzava. Ho provato a correggere inserendo una sessione di ideas sharing e un’ulteriore sessione di idea generation due giorni dopo.
Per garantire l’anonimato e mantenere alto il coinvolgimento, nella fase di ideas sharing ho chiesto a tutti i partecipanti di consegnarmi in privato quello che avevano creato. Sarebbe stato compito mio anonimizzare il tutto in un unico file di Miro.
Due motivi delle mie scelte:
Due giorni dopo aver condiviso il file Miro, ho ripetuto la fase di idea generation. I risultati sono stati sbalorditivi; l’originalità delle idee proposte nella seconda sessione di idea generation erano raddoppiate, così come il numero medio di proposte che è passato da 3 a 4.
È facile raccontare i propri successi, ma è dagli errori che si impara di più. Proverò a condividere la mia ultima esperienza con il brainstorming in cui, comunque, nasconderò ogni riferimento a cose e persone.
ATTENZIONE: non è per i deboli di cuore e piangerete lacrime di sangue.
Lavoravo per un’azienda di prodotto i cui clienti sono multinazionali mondiali. Grazie al nostro prodotto erano in grado di automatizzare l’allocazione del budget in maniera ottimale tra e all’interno delle loro operations nazionali, regionali e mondiali. Essendo utenti multinazionali, gli utenti della piattaforma necessitavano di vari livelli di permesso a seconda delle loro responsabilità. Questi livelli di permesso potevano essere dettati da esigenze di tipo geografico (es. LATAM Manager) oppure di tipo operativo (Head of White operation). A complicare le cose, le operation contenevano linee di brand e prodotti che potevano essere in parte o del tutto assenti in paesi o in intere regioni.
Immaginate di avere due organigrammi, uno geografico e uno operativo, e il vostro obiettivo è garantire che gli utenti abbiano accesso solo alle informazioni a loro pertinenti. Insomma, il problema da risolvere era assai complicato.
Questo problema era stato presentato ai sales i quali, come spesso accade, avevano già venduto la soluzione come “in dirittura di arrivo”. La pressione e la fretta hanno fatto pensare al top management che un paio di sessioni di brainstorming sarebbero state sufficienti per disegnare un’interfaccia da consegnare agli sviluppatori (questo era il piano). A queste sessioni partecipavo io come product manager del modulo della piattaforma, il designer del mio team, il product marketing manager, il mio manager e un top manager.
Final outcome:
Prima di vedere insieme gli errori, è giusto che faccia mea culpa: non ho saputo gestire lo stakeholder principale. Gli errori in questa occasione sono stati tantissimi, ma concentriamoci su quelli che hanno ucciso la creatività.
Il problema da risolvere era troppo grande; come ho cercato di spiegare, il problema che si doveva risolvere era troppo articolato. Nonostante l’oggettiva realtà dei fatti, è compito del team indagare a fondo sulle reali cause del problema per risolvere problemi più piccoli. Se il problema da risolvere non è ben compreso e non sono chiari gli ostacoli, si fantastica. La montagna si sposta un sasso alla volta.
Insight: frammenta il problema e definisci un outcome specifico per ogni singolo pezzo. Poi prioritizza i singoli piccoli problemi e agisci di conseguenza.
Alcune persone presenti alle sessioni erano di troppo e altre erano assenti; l’utilità di un product marketing manager in queste sessioni è stata pari all’assenza di figure tecniche. La presenza di quest’ultime, invece, avrebbe elevato il livello e dare a tutti spunti di ispirazione interessanti.
Insight: parla alle persone che ritieni irrilevanti a questi meeting se anche loro hanno la stessa sensazione. Magari la loro motivazione principale è solo quella di rimanere aggiornati, c’è sempre una soluzione alternativa.
C’era un ippopotamo; credo che fosse ben chiaro. Come è possibile proporre le proprie idee se, anche inconsciamente, si è bloccati dalla scala gerarchica?
Insight: proponi un 1-1 con l’ippopotamo per cercare di capire le sue motivazioni e condividere le tue. In questi casi serve diplomazia e capacità di negoziazione, mettersi di traverso non è mai la soluzione giusta.
Si è parlato troppo: disegnare è uno strumento potentissimo, perché azzera la porosità del linguaggio e concretizza l’idea. Lo stesso autore può criticare la sua stessa idea;
Insight: adottate strumenti come Miro chiedendo esplicitamente di disegnare la soluzione, ma tenete presente che carta e penna non li batte nessuno.
Si è manifestato il confirmation bias; è la tendenza a ricercare, anche nella dialettica stessa, ulteriori prove che confermino i propri ragionamenti. Questo azzera la possibilità di un confronto costruttivo;
Insight: anziché argomentare l’idea in sé, rispondete a questa domanda “Cosa è necessario che sia vero perché X possa essere realizzabile?”.
Vi consiglio alcuni dei testi sul tema (forzatevi di leggere in inglese, le traduzioni in italiano non sono un granché):
Se, invece, volete sapere quali sono i migliori libri sul product management secondo Product Heroes, cliccate qui 🙂
E voi, che ne pensate? Fatemi sapere nei commenti quali sono i vostri dubbi e domande sul tema. Sarò ben lieto di rispondervi.
Ti piacerebbe approfondire il tema all’interno di un contesto più ampio e di un percorso formativo di gestione del prodotto a 360°? Dai un occhio al Master in Product Management 🎓 in partenza.
Product Manager of Recruitment @ Wyscout - Hudl. Andrea è Product Manager in Wyscout (Hudl), piattaforma che aiuta i club calcistici nello scouting di talenti emergenti. È stato studente del Master in Product Management in Talent Garden e ha ricoperto lo stesso ruolo a MINT
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management