Ottobre 3, 2022 - di Simone Vignati
Crescere come Product Manager nella scale-up Qonto
- Qonto: da idea a prodotto
- L’approccio di Qonto
- Il ruolo e l’approccio del Product Manager
- Il Product Manager non è il Project Manager
- Il Product Manager come corrispettivo del Chief Engineer
- I compiti del Product Manager: dalla UX research al QA Plan
- La fase di onboarding per un Product Manager
- La scelta di lavorare per l’headquarter francese
- Consigli per chi decide di diventare un Product Manager oggi
Il post è abbastanza lungo, ma altrettanto interessante. Se sei di fretta puoi scaricarlo in PDF e leggerlo con calma quando vuoi.
Qonto: da idea a prodotto
La cosa che mi ha impressionato di più quando sono entrato a far parte di Qonto, è Il modo vincente che ha di approcciare al Product Management, sin dalla prima fase di onboarding. Nata nel 2016 e lanciata nel 2017 in Francia, si è trasformata in pochissimi anni da startup innovativa a scale-up di successo e poi unicorno, ed è oggi la soluzione di gestione finanziaria aziendale leader in Europa.
Per capire meglio l’approccio di Qonto allo sviluppo di prodotto e il ruolo del Product Manager in una realtà di questo tipo, partiamo da come è nata l’idea.
Alexandre Prot e Steve Anavi, i due founder che avevano avuto già precedenti esperienze imprenditoriali, hanno vissuto in prima persona la frustrazione nel rapporto con le banche tradizionali data da una user experience poco intuitiva e digitalizzata e dalla scarsa efficienza degli strumenti a disposizione, che causano difficoltà per le imprese e soprattutto per quelle che muovono i primi passi sul mercato.
Sei imprenditore, devi trovare l’idea vincente, fare recruiting delle persone, costruire il primo MVP del prodotto e lanciarlo, mentre ti ritrovi a perdere tantissimo tempo in attività a scarso valore aggiunto come la gestione di cassa, la parte contabile, l’apertura del conto, eccetera.
“C’è bisogno di mettere sul mercato il prodotto bancario che avremmo voluto avere noi quando abbiamo lanciato le nostre società!”, hanno detto Alex e Steve.
E così hanno fatto! Sono partiti in Francia con una roadmap ambiziosa, puntando a un target d’imprenditori digitali e startup che hanno percepito il valore sin da subito. In Francia, i conti bancari tradizionali per le PMI sono molto costosi e poco digitali. Il bisogno era quindi così sentito, che è stato subito un gran successo!
Crescere come Product Manager: l’approccio di Qonto
Un’azienda ha bisogno di scegliere il metodo più adatto per sviluppare i propri prodotti e per farlo deve tenere in considerazione molti elementi, come i valori aziendali e la fase di crescita in cui si trova. Come vedremo, Qonto, ha delineato un vero e proprio “manifesto” che riflette il metodo attraverso cui si svolgono tutti i processi interni e anche la cultura aziendale.
L’Agile non basta più
Sappiamo tutti che fino a pochi anni fa si sviluppava solo con il metodo Waterfall. Si faceva tutta l’analisi di come sarebbe dovuto essere il prodotto, poi si entrava in un lungo ciclo di sviluppo che poteva durare da qualche mese a qualche anno. A fine sviluppo, ecco che si vedevano i risultati e ovviamente i problemi. E chiaramente erano problemi giganteschi, perché li scoprivi alla fine della corsa!
É nato quindi il metodo Agile (nel 2001 con la pubblicazione del Manifesto per lo Sviluppo Agile del Software), che ha rivoluzionato il mondo del software.
I 12 principi dell’Agile, che hanno spostato il focus sul saper rispondere al cambiamento piuttosto che sapersi adattare al piano, sono stati e sono tuttora adottati da moltissimi imprenditori. Oggi, per lanciare qualsiasi servizio/prodotto innovativo, alla base c’è il cosiddetto concetto di MVP (costruisco, lancio, raccolgo i feedback, miglioro e itero fino a raggiungere una versione più soddisfacente). Così sono nate e stanno nascendo tantissime startup.
In Qonto, abbiamo deciso di non adottare questa strada. Perché non abbiamo creduto nell’Agile? Non sto dicendo che l’Agile sia fallito, ma che si adatta meglio a certi contesti piuttosto che ad altri, e NON al nostro. Nel mondo del Product Management la flessibilità che ha portato l’Agile rischia di far diventare il team di prodotto una fabbrica di feature. Tutti gli stakeholder pensano che sia facilissimo aggiungere/fare cose, e ti chiedono miglioramenti per qualsiasi dipartimento: operation, customer support, marketing. Idem il management, che pensa sia facilissimo portare miglioramenti il più velocemente possibile senza che ci sia una fase dedicata al pensiero.
Viene fatto tanto e tutto velocemente, in maniera agile, ma senza pensare a sufficienza. É stato un po’ rimosso l’engineering thinking, che è alla base del successo dei prodotti tecnologici. Gli Engineer diventano degli operai che devono deliverare il prima possibile per smaltire il backlog, ma nella metodologia Agile non c’è del tempo allocato per il corretto engineering thinking che un prodotto richiede. Non c’è tempo sufficiente affinché gli Engineer facciano bene il loro lavoro. La qualità, piuttosto che con l’Engineering Thinking, viene ricercata con la Peer Review, che è super inefficiente. Se faccio una cosa, la faccio veloce, poi prendo i feedback dai miei user e dai miei colleghi che fanno i test per sistemarla e dopo che succede? Rework, rework, rework!
La cultura Lean e il Toyota Production System
La filosofia Lean ha l’obiettivo di permettere alle aziende di crescere in maniera sostenibile e massimizzare il valore. Si concentra sul creare valore per l’utente finale ed evitare/minimizzare gli sprechi (lean significa letteralmente ‘pensiero snello’).
Le origini della metodologia Lean risalgono al 1948 quando, a opera di Eiji Toyoda e Taiichi Ohno, viene sviluppato in un lasso di quasi 30 anni, il Toyota Production System (TPS), che è alla base della Lean production.
L’approccio Lean presuppone due elementi centrali:
- Il primo è il porre sempre il cliente al centro di qualsiasi cosa si faccia;
- Il secondo è una cultura orientata al problem solving.
Il Toyota Production System come chiave del successo
Complice della ‘scalata’ di Qonto, è stato proprio il sapersi ispirare efficacemente alla filosofia Lean e sapere adattare il learning di Toyota al mondo dello sviluppo software.
É proprio sulle orme del “Toyota Way” che nasce “The Qonto Way”, il nostro manifesto aziendale (di cui parleremo in seguito), la strada che Qonto ha scelto e sulla quali poggia le sue basi in termini di modus operandi e cultura aziendale.
É un’impostazione orientata all’apprendimento, dove la curiosità da parte di chi è una nuova leva e la voglia di trasmettere il suo know-how da parte di chi è già inserito in azienda, creano un’unione perfetta e un motore incredibile, che stimola l’operatività e il proprio contributo dal giorno zero. Questo è uno dei segreti che ha permesso a Qonto di crescere velocemente, diventando una scale-up che oggi può contare su un team di 900 persone, ed è stata scelta da 300 mila clienti ed è presente in Italia, Francia, Germania e Spagna.
The Qonto Way
Il manifesto aziendale di Qonto si chiama “The Qonto Way” non a caso. Così come i principi del Toyota Way si basano sul concetto di continuous improvement e di rispetto per le persone, così Qonto ha scelto un’identità e una cultura aziendale dello stesso tipo. Il motto è: Good thinking, Good products. Tutto nasce dal mettere le persone nelle condizioni di “pensare bene”, PM compreso.
L’obiettivo della Qonto Way è quello di rappresentare il sistema (l’azienda) esattamente come dovrebbe funzionare in condizioni normali e l’insieme delle tecniche per riportarlo alle condizioni normali quando le cose non funzionano, oltre a una serie di principi che possano creare una cultura aziendale solida e condivisa. In altre parole, rappresenta il modus operandi sul posto di lavoro e i valori aziendali. Questo sistema rappresenta la chiave di volta (provo a spiegarvelo con più chiarezza andando avanti).
Il Right First Time vs Rework
Come nel Toyota Production System, noi perseguiamo il right first time, ovvero investiamo tanto tempo nell’engineering thinking di una soluzione ed evitiamo di fare rework. Così come nel TPS si lavorava per azzerare i difetti di produzione, allo stesso modo qui non devono esistere bug. Il prodotto deve essere ‘giusto’. Come? Dedicandoci il giusto tempo di pensiero a monte.
Se spendo tutte le mie energie sulla roadmap di prodotto, e la mia diventa una battaglia politica tra stakeholder diversi, alla fine cosa ottengo? Che ho fatto tantissima fatica a gestire tutti gli stakeholder, e non ho probabilmente accontentato il mio utente finale. Non è frustrante?
La missione è il customer
Se guardate l’immagine sopra, il tetto della casa rappresenta ciò su cui Qonto focalizza la sua attenzione: il Customer. La Value Analysis e il Value Engineering rappresentano il nocciolo del processo di sviluppo del prodotto per portare valore all’utente finale.
Il Value Analysis, ci permette di identificare il valore: il What.
Il Value Engineering, come portare qualità nel più breve tempo possibile: l’How.
Just-in-time
Una prima domanda sorge spontanea. Ma come ci si avvicina a lavorare su quello che le persone vogliono esattamente con il giusto timing?
- Facendo attenzione alla velocità di sviluppo e mantenendo sempre attivo il flusso di produzione → Continuous Flow;
- Coordinando l’effort del team e minimizzando i tempi di attesa o il sovraccarico → Pull-System.
Right-first-time
La seconda domanda da farsi invece è: come si raggiunge un’alta qualità?
Si è in grado di produrre senza ‘difetti’ anche grazie a un processo di auto controllo (Auto-Quality). In Qonto, una persona è ritenuta “accountable” per il progetto di cui si sta occupando, dall’inizio alla fine. Questo perché partiamo dall’idea che la persona che sta creando del valore, è la stessa capace di riscontrare dei problemi, anche senza la supervisione del proprio Manager.
Stability & Trust
A favorire un approccio di questo tipo è la stabilità e la credibilità del management, che ha come primo obiettivo quello di migliorare le condizioni di lavoro per permettere al team di essere sempre più performante. La parte bassa della casa/sistema, mira a creare un ambiente di-stabilità per far sì che tutto diventi Just-in-Time e Right-First-Time (le due colonne portanti).
Come?
- In ogni momento so a che punto sono della creazione del valore, del flusso di produzione e dei problemi che sto incontrando → Visual Management;
- Risolvo il problema quando occorre → Problem Solving. (PDCA è il metodo che viene applicato, che ti spiegherò meglio più avanti);
- Costruisco con l’ottica di massimizzare il valore e non cadere in vicoli ciechi (practical re-usable knowledge) → Standard.
Un’autonomia condivisa
Alla base di questo approccio, è il paradigma dell’autonomia condivisa delle persone, la lente d’ingrandimento attraverso la quale si guarda e si pensa a ogni cosa. Che cosa ne consegue?
- trasparenza assoluta;
- chiarezza sullo scopo;
- auto organizzazione;
- lavoro in logica pull e non in logica push;
- nessun tipo di coercizione;
- miglioramento continuo;
- no blame policy.
Proverò a farti degli esempi più concreti tra poco. So che a un primo impatto sembra tutto molto complesso, ma dammi fiducia e seguimi fino alla fine.
One Piece Flow come chiave di volta
Noi crediamo e diamo spazio all’engineer thinking, avendo un flusso di lavoro che comporta la delivery di una cosa alla volta: One Piece Flow. A tal proposito, ti condivido un video qui di seguito, sul concetto di One Piece Flow. Dura meno di un minuto, ed è super esplicativo.
Ti sarà facile capire ora perché non abbiamo un backlog di più di 2 cose. Perché per noi quello è MUDA (Muda è una parola Giapponese che indica lo spreco e descrive tutte le attività che non aggiungono valore).
Se come PM mi metto a scrivere user story per 40 feature, quando nella realtà il team Engineering riesce a lavorare solo su 2 o 3 feature alla volta, sto ‘creando tanti problemi’. Uso il mio tempo in maniera sbagliata, creo obsolescenza.
Per non considerare il timing. La feature che ho pensato a gennaio, con buona probabilità ‘sarà già vecchia’ quando il team Tech la prenderà in carico. Stessa cosa se ho un backlog di 40 feature e il team Engineering sente la pressione di queste 40 feature addosso. Lo spazio per il pensiero è azzerato.
Noi ci fermiamo, approfondiamo il contesto che sta attorno a un problema reale dell’utente e disegniamo la soluzione tutti insieme.
No alla blaming culture, sì ai processi di verifica e all’apprendimento
In Qonto non esiste il concetto di blaming culture e nessuno ti darà mai la colpa di un problema anche grave che è passato dalle tue mani. Esiste una procedura, ispirata sempre al sistema Toyota, per identificare i difetti.
A livello di prodotto, si innesca un sistema di lavoro operativo (operative system), che prevede una serie di fasi per passare dalla vision di prodotto, alla prioritizzazione delle feature; dalla scelta delle feature su cui voglio lavorare, al disegno (Value Analysis della feature che ho scelto); dal disegno (scrittura delle specifiche, Value Engineering e scrittura delle specifiche), allo sviluppo vero e proprio; dai test fino al rilascio in produzione.
È tutto molto standardizzato. Gli standard però, non sono dei diktat a cui ti devi attenere con il paraocchi, ma sono delle bellissime guide che si adattano al tuo contesto e ti permettono di sapere se stai deliverando qualità o qualcosa di difettoso.
Il nostro obiettivo è cercare di replicare il concetto della catena di montaggio applicandolo allo sviluppo del prodotto. Consideriamo come ‘User’ la persona che ci segue nel flusso di lavoro. Il collega (lo user) riceve quello che abbiamo costruito noi e aggiunge ulteriore valore (il pezzo successivo). Questo è il mindset, fino a quando non si arriva all’utente finale vero e proprio.
Puntiamo alla qualità di quello che viene prodotto, e se ci accorgiamo che qualcosa non funziona come dovrebbe, avvisiamo subito che c’è un difetto di produzione. Mettiamo il componente difettoso, in un “red bin”, che in Toyota era un vero e proprio cestino rosso fisico in cui venivano messi i pezzi difettosi come i carburatori. Subito dopo segue un momento di riflessione con il team, si prende il pezzo difettoso e si fa un’analisi rispetto a quelle che sono le cause primarie (root causes) che hanno portato a quel problema.
Non si incolpa nessuno, ma si dice: quella persona non ha ricevuto le istruzioni necessarie per fare quella cosa bene. Perché non ha ricevuto il training necessario? Forse non abbiamo pensato a un processo di onboarding corretto?
Come affrontiamo le difficoltà
Quello che vi ho descritto è un ambiente di lavoro che mi piace tantissimo, dove le sfide giornaliere non mancano. Per esempio, gestire le aspettative del management. Provo a farti un esempio.
In Qonto c’è una forte adesione a tutti i livelli e una forte coesione. Se nella fase di analisi (Value Analysis), ti figuri una soluzione che credi semplice e di veloce implementazione, e quando passi nella fase successiva (Value Engineering) ti accorgi di aver bisogno di più tempo, devi darne subito comunicazione. Nell’ultima feature a cui ho lavorato, per esempio, ci si aspettava che fosse pronta entro una data molto serrata. Quando abbiamo finito di fare la pianificazione con il team, ci siamo accorti che saremmo andati parecchio più lunghi. Quindi?
Stop and Fix (Andon)
Sappiamo bene che non è facile comunicare questo tipo di notizie alle persone coinvolte e che hanno un’aspettativa diversa. In questi casi cosa succede in Qonto? Facciamo affidamento alla ‘way of working’, ovvero alla procedura (sempre ispirata alla Toyota) che si chiama Stop and Fix o Andon. Ti spiego.
Quando un componente del team si rende conto che da solo non riesce a risolvere un determinato problema, si preme questo grande pulsante. Si fa suonare questo Andon e si chiede aiuto. Chiedere aiuto è normale, e non è un problema. Non sei stupido se ti sei trovato in una situazione che non sai gestire, capita a tutti.
Una volta che viene chiamato un Andon, tutto si ferma. Si riuniscono i lead delle varie funzioni coinvolte e tutti insieme si cerca di trovare una soluzione. Ci si chiede: “Vale ancora la pena investire del tempo per costruire questa feature?”, oppure “costa di più rispetto a quanto avevamo preventivato”, e ancora “vale la pena riconsiderarla completamente o non svilupparla più? Se continuiamo, c’è un modo per ridurre il tempo che ci mettiamo?”.
Abbiamo un target cost (tempi di sviluppo) da rispettare, ma quello che rilasciamo deve essere sempre di qualità.
Ti starai chiedendo come si è chiuso il problema che ho incontrato sul tempo di sviluppo legato alla feature di cui ti ho accennato prima. Bene, dalla deadline prefissata, siamo riusciti a far slittare il rilascio, ma senza ritardare eccessivamente e creare ostacoli particolari. Questo grazie all’analisi affrontata insieme e allo sforzo di tutti. Quindi sì, mi è capitato di ‘sudare freddo’, ma è stata l’ennesima occasione per capire che sono parte di un’azienda dove il problema stesso diventa il seme per costruire il successo di domani.
Il processo chiave di apprendimento: PDCA
L’Andon serve a prevenire i problemi, ma questo non è sempre possibile. Quando un problema si verifica effettivamente, come dicevamo poco sopra, “mettiamo il pezzo difettoso in un red bin” e inneschiamo il processo di apprendimento che chiamiamo PDCA (Plan Do Check Act): impariamo dagli errori.
- Plan: ti interroghi su quelle che sono le root causes e ti immagini una possibile soluzione non contestuale, ma che vada a risolvere la route cause affinché quel problema non si ripeta;
- Do: implementi la soluzione di prova e la vai a testare;
- Check: controlli i risultati;
- Act: costruisci un nuovo standard se i risultati sono positivi.
È in questo processo di miglioramento continuo che sta il segreto. Come Product Manager, devi essere in grado di guidare il team in questo tipo di analisi e miglioramento continuo.
Il ruolo e l’approccio del Product Manager
Una delle figure chiave del Toyota Production System è quella del Chief Engineer, la persona che ha la fiducia del CEO nel prendere decisioni di prodotto, perché lo conosce a 360° gradi in tutti i suoi aspetti.
Il Product Manager non è il Project Manager
In un contesto di ‘fabbrica di feature’, il Product Manager viene visto spesso come il Project Manager che viene buttato nell’arena e in un modo o nell’altro deve far in modo di smaltire il backlog. Da una parte deve rimpolparlo per far vedere che ha tantissime idee, dall’altra deve essere veloce a smaltirlo. E in tutto questo non c’è spazio per il continuo sviluppo delle sue competenze di design del prodotto e sulla parte tech. Il risultato dell’Agile quindi è che spesso i Product Manager lavorano sulla superficie, e rischiano di essere più dei Project Manager che dei veri PM.
Noi preferiamo andare a fondo in tutto quello che facciamo!
Il Product Manager come corrispettivo del Chief Engineer
Nel nostro approccio, quello che ci si aspetta dal Product Manager è che sia l’equivalente del Chief Engineer in Toyota. Il PM non deve essere un produttore seriale di feature, cosa che invece viene più o meno consapevolmente incentivata dalla metodologia Agile.
L’agilità porta i vari stakeholder a chiedere miglioramenti senza che ci sia soffermati a lungo sul problema. Si sviluppa il prodotto velocemente, lo si testa, si lancia l’MVP, si raccolgono i feedback dei clienti, eccetera).
I compiti del Product Manager: dalla UX research al QA Plan
Il Product Manager, così come il Chief Engineer, deve imparare nel tempo a coprire tutti gli aspetti e le fasi legate al prodotto, perché è responsabile della qualità finale di quello che produce. Mi spiego meglio.
In Qonto la UX research è fatta dal PM, con l’aiuto dei Product Designer e del Product Marketing Manager, ed è una parte fondamentale nella costruzione della sua conoscenza intorno al prodotto. E’ il team di prodotto che intervista i clienti, che struttura le interviste, che cerca di capire i loro bisogni nel quotidiano.
Stessa cosa quando si costruisce un QA Plan (Quality Assurance). In teoria nel mondo dello sviluppo software c’è la figura del QA Engineer che si occupa di scrivere i test e di effettuarli (check fondamentale per capire se hai pensato a tutto di quella feature che stai sviluppando).
Seguiamo quindi tutte le fasi, dai test funzionali a quelli di UX, fino al rilascio in produzione. Dopo che hai finito di costruire una feature, sei davvero il CEO di quella funzionalità, nel senso che nessuno al mondo ne sa più di te!
La fase di onboarding per un Product Manager
Approdare in Qonto con il ruolo di Product Manager, è stata per me un’esperienza arricchente, affascinante e diversa da quello a cui ero stato abituato prima. Le prime due settimane sono state dedicate al solo full-onboarding, senza avere nessun altro tipo d’impegno. Il mio compito è stato quello di capire i processi interni, conoscere le persone e i flussi di lavoro ed entrare rapidamente nelle dinamiche aziendali.
Ho avuto accesso a un sistema fantastico di knowledge management, iper trasparente, che tutti utilizzano e dove puoi capire gli standard, leggere le procedure e avere chiara l’organizzazione dei vari team. Dopo due settimane di ‘scoperta’ così intense, sai perfettamente ‘dove ti trovi’ e con chi avrai bisogno di collaborare. Hai tutte le informazioni che ti servono per partire!
La scelta di lavorare per l’headquarter francese
Qonto ha attualmente sedi in cinque Paesi e dipendenti che lavorano da remoto in tutta Europa. Io ho scelto di lavorare nella sede centrale, a Parigi. La mia scelta è stata dettata dall’esigenza di capire meglio il contesto nel quale tutto ha avuto origine per assorbire la cultura dell’azienda. Per un PM il contesto è un elemento chiave! Entrare in empatia con le persone e stringere rapporti a livello umano nel luogo dove tutto è nato, è stato per me fondamentale.
L’empatia come elemento chiave per un Product Manager
Il nostro è un lavoro in cui l’empatia gioca un ruolo chiave, e su Product Heroes è stato ampiamente sottolineato nell’articolo Product Manager Hard Skill vs Soft Skill. Da una parte hai il team, con mille sfumature e interessi diversi, che collabora per creare valore e raggiungere un obiettivo comune. Dall’altra ci sei tu PM, coordinatore e animatore di questo gruppo di persone, che devi supportare, aiutare a stare bene e a comunicare.
Lavorare divertendosi è il mio motto. Senza empatia, non ce la fai. Nel nostro lavoro, la parte umana viene prima di quella professionale e tecnica. È il buon senso la north star di ogni team.
Consigli per chi decide di diventare un Product Manager oggi
Avere coraggio
Se decidi di diventare PM oggi il mio consiglio è: non avere paura d’iniziare in qualsiasi punto del percorso ti trovi.
Tutti noi PM non abbiamo un background accademico specifico e nessuno ci ha insegnato a fare questo mestiere. Siamo tutti partiti da background diversi e disparati; io, per esempio, ho studiato Environmental Economics. Ho iniziato a ‘sporcarmi le mani’ in azienda, in una grossa corporate, sulle tematiche di business. Ed è il business che mi ha acceso la lampadina! In Qonto tanti vengono dal mondo dell’Engineering, dal Design e da mille altri settori.
Darsi tempo
Se esci dall’università e vuoi fare il PM, non avere paura di fare prima qualcos’altro. È un percorso lungo a cui si arriva con il tempo e al quale ci si arriva con il buon senso (arma principale nella vita quotidiana).
Non cedere alla sindrome dell’impostore
Non bisogna farsi intimorire dalla sindrome dell’impostore, che abbiamo in particolare noi PM. È vero che non siamo esperti di qualcosa in particolare, ma ci interfacciamo continuamente con esperti. Io personalmente mi interfaccio con Designer e Engineer che ne sanno molto più di me! Il rischio che non dobbiamo correre è di pensare di non essere all’altezza e di non servire a nulla.
Avere sempre ben chiara la Vision
Quello che devi fare è avere chiarissima la visione del prodotto, perché tutti gli altri lavorano solo su un pezzettino. Tu devi avere la visione di prodotto più alta, la helicopter view. Rappresenti gli interessi dell’utente finale e quelli dell’azienda per cui lavori. Le due cose devono andare insieme (se l’azienda è sana)!
Avere equilibrio
Bisogna essere sempre in grado di trovare punti di equilibrio, e come dicevamo prima, fondamentale è essere in grado di creare un ambiente di lavoro sereno, felice, divertente e spensierato. Mettere le persone nelle condizioni di dire: non stiamo salvando vite umane. Dobbiamo avere sempre il senso delle proporzioni, perché ti aiuta ad abbassare i livelli di stress.
- Diventare pian piano degli esperti: imparare;
- Collegare i puntini tra cose apparentemente molto diverse tra loro;
- Lavorare come mediatore culturale. Essere in grado di far parlare persone con background diversissimi per risolvere un problema comune;
- Semplificare sempre. Avere quella nitidezza di pensiero e portare la semplicità in contesti per definizione super complessi.
Se l’articolo ti è piaciuto e vuoi rimanere aggiornato sui prossimi contenuti, iscriviti alla nostra Newsletter 📩
