Principi di Gestione del Prodotto, Spiegati
Alcuni dei migliori PM che conosco prendono decisioni basandosi sui primi principi. Un primo principio è una “proposizione o assunzione di base e fondamentale che non può essere dedotta da nessun’altra proposizione o assunzione.”.
Un esempio che utilizziamo per il nostro team della piattaforma di sviluppo è che “tutte le funzionalità della piattaforma dovrebbero essere come i mattoncini Lego”, il che significa che gli sviluppatori dovrebbero poter usare qualsiasi combinazione di funzionalità quando costruiscono un’app. Le funzionalità dovrebbero essere interoperabili, proprio come i Lego.
Il pensiero basato sui primi principi aiuta i PM perché, con la crescita delle aziende, comunicare il ragionamento dietro decisioni storiche, attuali e future può essere semplificato in modo che il loro team e gli stakeholder possano farvi riferimento. Questo permette alle persone intorno al PM di muoversi rapidamente nella stessa direzione, separarsi quando serve e prendere decisioni intelligenti anche senza la sua presenza.
Vuoi di più da The CPO Club?
Iscriviti gratuitamente per completare la lettura di questo articolo:
Have an account? Log In
Lettura correlata: Come la gestione dei feature flag aiuta a gestire il prodotto in crescita
E per quanto riguarda i primi principi dell’arte del Product Management?
Se i primi principi possono aiutare un PM ad allineare il proprio team su ciò che è più importante in un prodotto, credo che possano anche supportare i PM nel riflettere sulla vera e propria arte del product management stessa.
Ed è proprio di questo che parla questo post: quali sono le proposizioni e assunzioni fondamentali del product management che non possono essere dedotte?
Lato Sinistro, Lato Destro
I primi principi del Product Management possono essere ridotti a:
A. Massimizzare l’impatto sulla missione: sviluppare una strategia di prodotto che massimizzi l’impatto sulla missione dell’organizzazione dati determinati input.
B. Realizzare ogni cosa tramite gli altri: i PM non costruiscono o gestiscono direttamente il prodotto, ma rendono gli altri nelle loro vicinanze più capaci di farlo meglio.
Questi due principi rappresentano il lato sinistro e destro del cervello. Il sinistro è definito da logica, ricerca e rigore. Il destro è definito da creatività, intuizione ed empatia.
I grandi product manager fondono questi due principi in tutte le loro decisioni e tutto ciò che fanno dovrebbe derivare da essi.
Col senno di poi, la maggior parte dei miei post precedenti sono semplici derivazioni di questi due principi. Prendere buone decisioni come PM riguarda il principio A, Prioritizzazione senza pietà e Applicare la leva come PM riguardavano il principio B. MVPM è un po’ di entrambi. Avrei voluto scrivere questo per primo, ma sinceramente dovevo ancora impararlo. Andiamo a fondo.
Principio A: Massimizzare l’impatto sulla missione
L’obiettivo di ogni dipendente di un’azienda dovrebbe essere quello di realizzare la missione aziendale, sia che questa sia guadagnare miliardi, creare impatto sociale, o entrambi.
A tal fine, la stragrande maggioranza delle persone in azienda lavora direttamente per offrire un prodotto/servizio ai clienti: costruiscono il prodotto (ingegneri e designer), lo portano sul mercato (marketing e vendite), o supportano i clienti esistenti (supporto).
Il product management non fa nulla per costruire o gestire direttamente il prodotto per i clienti. Invece, la sua responsabilità principale è guardare avanti e informare i costruttori/gestori del prodotto su quale sia la strada giusta per raggiungere l’obiettivo. Quella strada è anche chiamata strategia di prodotto, e le migliori sono quelle che massimizzano l’impatto sulla missione.
Definire la strategia di prodotto è una responsabilità enorme... come fa un PM a farlo? Guardando a tre input:
- Qual è l’obiettivo?
- Cosa segnala l’ambiente circostante?
- Quali vincoli di persone, budget e tempo esistono?
I PM utilizzano questi input per formarsi un'opinione su quale percorso porterà alla realizzazione della missione.
1. Qual è l’obiettivo?
Tutto parte dall’obiettivo. Se non sai dove devi andare, non dovresti nemmeno muoverti perché potresti finire ancora più lontano.
Uno dei maggiori problemi che vedo nei PM è che non si prendono il tempo per capire davvero l’obiettivo. Forse sanno recitare la missione, ma ne comprendono veramente le basi? Parlo delle ipotesi sui clienti che l’hanno generata, dei confini morali/etici/di design che l’azienda vuole rispettare per conseguirla e della visione futura del mondo in cui essa deve vivere.
I migliori product manager pongono incessantemente domande difficili alla leadership per comprendere le sfumature — i principi fondamentali — che hanno portato a definire la missione che stanno seguendo. Più a fondo riescono a comprenderla, più preciso sarà il loro percorso verso l'obiettivo.
I PM devono anche sapere come gli altri team stanno contribuendo allo sforzo complessivo. Soprattutto nelle grandi aziende, l'allineamento tra tutti i team assicura che le collisioni vengano evitate e — ancora meglio — si colgano opportunità per unire gli sforzi e accelerare i progressi.
Solo quando un PM è certo di conoscere l'obiettivo della propria azienda e quelli degli altri team che lo circondano, è pronto a definire efficacemente gli obiettivi del proprio team: questi devono essere chiaramente coerenti con la missione più ampia.
2. Cosa sta segnalando l'ambiente?
La maggior parte dei piani parte come una linea retta verso l'obiettivo, ma il percorso non finisce mai davvero così. È impossibile vedere tutti gli ostacoli che ci aspettano e, a volte, l'obiettivo è così lontano che non si può capire se si sta deviando dal percorso. Per evitare questo, i PM devono ascoltare l'ambiente per rilevare, anticipare e correggere la rotta.
Ci sono due principali tipi di segnali ambientali da cercare:
Segnali dai clienti sono i dati qualitativi e quantitativi che raccogli su come i clienti utilizzano il prodotto. Questi dati sono il “ping” dall'obiettivo, e quando senti che il ping si fa più forte, sai che non ti stai allontanando dal percorso.
Segnali di mercato sono gli “allarmi asteroidi” che rappresentano i cambiamenti nel mondo che influenzeranno il tuo percorso. Sono i cambiamenti nei contesti competitivo, politico ed economico-sociale che impattano la tua azienda e i tuoi clienti.
Ascoltare costantemente il mondo fuori dalle mura della propria azienda è un input cruciale per un'eccellente gestione del prodotto. E ciò che senti dai clienti rappresenta la validazione finale del raggiungimento dell'obiettivo.
3. Quali vincoli di persone, budget e tempo esistono?
Quanto lontano può andare una navicella spaziale è limitato dal carburante che contiene, dalla qualità dell'equipaggio e dalla capacità, limitata dal tempo, di sfruttare i voli gravitazionali di altri corpi celesti come Giove. Allo stesso modo, i team di prodotto sono vincolati da soldi, persone e tempo a disposizione per lanciare un prodotto. In ogni missione, un team di prodotto si troverà limitato da tutti e tre questi fattori.
Le persone in un team di prodotto spesso rappresentano il vincolo maggiore. Troppo spesso, questo vincolo viene considerato solo come il numero di persone che lavora su un prodotto (e può esserlo), ma sono molto più importanti le reali competenze e i livelli di esperienza dei membri del team.
Così come non metteresti mai la classe dei nuovi assunti della NASA alla loro prima missione su Marte, ci sono ambiti di prodotto che vanno oltre le capacità di alcuni team. Non è colpa loro, né dice nulla sulle loro capacità future, ma è qualcosa che i PM devono assolutamente capire per pianificare il percorso. Per essere chiari, questo vale anche per gli stessi PM. Devono avere autoconsapevolezza per capire quando stanno prendendo troppo. Parleremo molto di più delle persone più avanti in questo post.
I soldi sono un vincolo che riguarda la capacità di un team di assumere le persone giuste (stipendi), permettere loro di lavorare (costi fissi come gli uffici), gestire il prodotto (server e supporto), e distribuirlo (marketing).
Sarebbe assurdo spendere tutto il budget in stipendi per assumere il miglior team possibile, ma poi non avere un ufficio dove lavorare, o non avere di che pagare il marketing e quindi far sì che solo pochi clienti trovino il prodotto.
La maggior parte delle aziende ha reso invisibili ai PM le complessità dei costi amministrativi, operativi e di marketing (in modo che possano concentrarsi sul prodotto e la distribuzione), ma è importante che i PM comprendano che il capitale non è infinito. In mancanza di questi lussi, i PM devono comunque tener conto di tutti gli impatti economici quando costruiscono la loro strategia.
Il tempo è il vincolo definitivo, perché a differenza degli altri due, una volta esaurito non se ne può ottenere di più. Il tempo rappresenta la realtà. È la realtà che i prodotti che non sono ancora stati lanciati non hanno ancora prodotto valore. È la realtà che i concorrenti conquistano quote di mercato ogni giorno. È la realtà che la tua azienda finirà i soldi il mese prossimo.
I PM devono gestire il tempo. Devono assicurarsi che non si perdano grandi finestre di opportunità, prendere i compromessi giusti e utilizzare il tempo come leva sana per favorire l'esecuzione nel proprio team.
La strada giusta (strategia di prodotto) si trova all’intersezione degli input
Quando i PM conoscono l'obiettivo, comprendono l'ambiente e tengono conto dei vincoli, hanno gli input necessari per costruire una grande strategia di prodotto, che si trova da qualche parte nell’intersezione di questi input.
La mia analogia riduzionista potrebbe far pensare che sia facile, ma voglio essere chiaro: arrivare a una buona strategia è molto, molto difficile. Infatti, nonostante sia abbastanza sicuro da scrivere questo post, non sono certo di trovare sempre la strategia giusta nella pratica. È davvero una cosa tremendamente complessa.
L'altra dimensione che spero emerga da questa sezione è che i PM hanno bisogno di un'incredibile ampiezza per sintetizzare efficacemente questi input in una strategia. Sapere abbastanza di ingegneria, UX, dati, finanza, design organizzativo, operations, ricerca, marketing, ecc. rende la tua capacità di sintetizzare questi input più efficace, e di conseguenza la tua strategia avrà una probabilità maggiore di successo.
Sento che molti PM si sentono intimiditi da questa realtà e reagiscono specializzandosi in un dominio e/o delegando il pensiero relativo a un dominio a un altro team (per esempio: “il marketing capirà come distribuire il prodotto”). Penso davvero che questo tipo di mentalità sia controproducente e limiterà il tuo potenziale. Per quanto possa sembrare spaventoso, è davvero importante che tu cerchi di imparare tutto. Sii consapevole che, allo stesso tempo, è impossibile sapere ogni cosa.
Principio B: Raggiungere tutto attraverso gli altri
Nell'analogia della navicella spaziale, chi pensavi fosse il PM? Era la persona che piantava la bandiera sul pianeta Obiettivo, o era uno degli astronauti sull’astronave?
La risposta è nessuno dei due. Il PM in realtà era il Centro di Controllo Missione sulla Terra. Il loro compito era supportare gli astronauti che rischiavano davvero la vita per la missione (ok, costruire prodotti non è così serio, ma hai colto il punto). Come PM, non puoi — assolutamente non puoi — dimenticare che raggiungi tutto tramite gli altri.
Mi dispiace. Non sei nemmeno sull’astronave 🚀.
Aspetta, perché così tanti articoli sui PM promuovono l’idea che i PM debbano essere "tuttofare, e fare tutto il necessario, compreso programmare, fare marketing e design"?
Avere una mentalità "fare tutto il necessario" non ti rende un buon product manager, ti rende un buon dipendente. Quando un PM programma, scrive documenti di supporto o progetta il prodotto, (presumibilmente) lo fa perché sta bloccando il percorso critico per il rilascio. Sta agendo secondo i valori di impiegato dell’azienda, non come PM.
Tutti — non solo i PM — dovrebbero aspirare ad avere questa mentalità. Se un ingegnere è anche bravo nel marketing e quello è il blocco del team, dovrebbe intervenire e aiutare. Ma questo non lo rende un miglior ingegnere. Il motivo per cui i PM si trovano spesso a "costruire un sacco di cose" è che, essendo l’unico membro del team che in teoria non dovrebbe costruire, è logico che siano i primi a offrirsi quando le cose vanno a rilento, ma questo è molto diverso dal dire che fa parte del loro lavoro come PM.
Raggiungere tutto attraverso gli altri è un principio primo irrinunciabile del product management, quindi per approfondirlo cambieremo completamente analogia.
I Product Manager sono come allenatori di una squadra sportiva
Non esiste analogia migliore di come un PM dovrebbe considerare il proprio ruolo rispetto all’allenatore di uno sport di squadra come il basket, la pallavolo, il calcio, ecc. Ecco perché i parallelismi sono così forti…
Gli allenatori non giocano
Un allenatore non gioca. Viene assunto per supportare la squadra, e lo fa aiutandola a far crescere il proprio potenziale individuale e collettivo. Sono valutati – sia dalla squadra che dai proprietari – in base alle vittorie. Di solito, se una squadra non vince, viene licenziato l’allenatore, non i giocatori.
Un PM non costruisce, non fa marketing, non fornisce supporto a nulla. Veniamo assunti per supportare la squadra nel raggiungimento degli obiettivi aziendali. Lo facciamo permettendo al team di massimizzare il proprio potenziale individuale e collettivo, allineando tutti su una strategia di prodotto (principio A) e favorendo una dinamica di team sana. Di solito, se il team non costruisce qualcosa di eccellente, è il product manager che dovrebbe essere licenziato, non il team.
Lo stile di un allenatore dipende dalla competenza relativa di allenatore e giocatori
Quando ho scritto per la prima volta che i PM sono come allenatori sportivi, cosa hai visualizzato?
Vedi l’allenatore come un genitore e la squadra come dei bambini? Oppure i giocatori sono come Lebron, che dicono all’allenatore cosa fare? O magari gli assistenti che fasciavano i polsi?
Ad esempio, se sei un PM appena uscito dall’università e ti unisci a un team di ingegneri esperti, perché mai dovresti avere un ruolo di leadership? Non dovresti — non hai l’esperienza per poterlo fare. Ma questo non significa che tu non possa essere utile.
I PM devono avere una forte autoconsapevolezza per riconoscere quando guidare, collaborare o supportare il loro team.
Nello schema sopra, "competenza" è un modo abbreviato per indicare la somma di abilità, esperienza, risultati e impegno delle persone. Ecco come l’ho applicato nella mia carriera:
Quando sono il PM di un team di neolaureati, adotto un approccio di leadership molto diretto. Definisco i framework, gli obiettivi e anche l’organizzazione dell’esecuzione del progetto. Ha senso: io ho già concluso progetti, loro no.
Quando lavoro con un team con competenze pari alle mie, tendo a collaborare su tutte le decisioni chiave e cerco il consenso di tutti sulla strategia e l’esecuzione. Per essere chiari, un PM dovrebbe aspirare a collaborare in ogni caso, ma questa dinamica di competenze relative lo richiede maggiormente.
Infine, quando lavoro con un team che ha più esperienza e competenze di me, adotto un approccio da assistente allenatore o trainer. Mi chiedo: come posso essere d’aiuto? Quali attività a basso valore posso togliervi dal tavolo? Assumo un ruolo di puro supporto. Per esempio, inizio chiedendo al team esperto qual è la loro visione, e poi continuo con tante domande per arrivare ai loro principi fondamentali e alla strategia. Successivamente, sintetizzo tutte queste informazioni in un documento e mi assicuro, insieme a loro, che rappresenti la loro visione. A quel punto, sono libero di allineare l’azienda a questa strategia come se l’avessi sviluppata io stesso. Posso comunque svolgere il mio lavoro.
Nota che in tutti i casi il PM è comunque responsabile dello sviluppo della strategia di prodotto, ma il modo in cui ci arriva può essere molto diverso.
Senza dubbio, non comprendere questa dinamica di abilità relative tra il team e il PM è la principale ragione per cui i PM falliscono. Sbagliano la valutazione della situazione, cadono nella trappola di pensare che PM significhi automaticamente essere un mini-CEO, e perdono immediatamente la fiducia del team, che richiederà dieci volte tanto per essere riconquistata.
Quando vince la squadra, i giocatori sono celebrati, non l’allenatore
Raramente si parla dell’allenatore quando una squadra vince. Dovrebbe essere lo stesso anche per i team di prodotto. Se il tuo team fa un lavoro incredibile, è giusto che sia sotto i riflettori — non rubare loro la scena.
Gli allenatori devono conoscere cosa fa ogni giocatore per essere efficaci
Nessuno può allenare una squadra se non sa nemmeno come si gioca. Bisogna avere empatia e rispetto per tutto il lavoro che i singoli membri del team svolgono.
Questo è più utile che semplicemente capire cosa sia facile o difficile da realizzare. Si tratta anche di capire cosa è divertente e stimolante dal punto di vista intellettuale, rispetto a ciò che è monotono e ripetitivo. Nessuna squadra si ispira a fare sempre lo stesso tipo di lavoro che ha già fatto in passato. A quel punto il lavoro diventa solo una questione di stipendio, e di conseguenza il lavoro stesso risulta meno creativo e ispirato.
Per un PM, rispettare questo significa creare le condizioni progettuali che permettano alle persone del team di crescere e raggiungere la missione aziendale. Quando crei queste condizioni, il risultato è una profonda responsabilizzazione e un coinvolgimento emotivo di tutti.
Quando emerge un capitano, gli allenatori fanno un passo indietro e lasciano guidare lui
Per un membro del team, è un conto sentirsi dire dal coach che non sta eseguendo bene, è tutt’altra cosa sentirlo da qualcuno che lavora al tuo fianco. Come allenatore, quando un giocatore del tuo team emerge come leader; una persona che responsabilizza gli altri e li spinge a migliorarsi, hai le basi per il team con le migliori performance.
Nei team di prodotto, questa persona è di solito un lead engineering o un responsabile UX. Quando accade, ringrazia la fortuna e lavora per aumentare ulteriormente la sua influenza sul team. Fallo diventare anche un coach e un tuo co-fondatore.
Tipicamente, in questa dinamica i PM continueranno a guidare la strategia, mentre il capitano si occupa dell’esecuzione; tuttavia, i PM dovrebbero essere anche aperti a "cedere" la strategia se questo mantiene il capitano coinvolto e gli fa sentire una vera responsabilità. Qui bisogna mettere da parte l’ego. È davvero raro trovare persone che desiderano essere leader, quindi se il capitano emerge, fai tutto quel che puoi per sfruttare questa situazione (ma assicurati anche di mantenere la sua responsabilità).
Gli allenatori assicurano che il team si alleni e sia in uno stato di massima performance
Gli allenatori non passano tutto il tempo a guardare replay di video e a fare strategia con la squadra; si assicurano anche che la squadra si alleni regolarmente per poter raggiungere la massima prestazione.
L’equivalente per i team di prodotto sono i processi di sviluppo del prodotto. Che tu sia un seguace rigoroso di Agile/Scrum, “senza processo” (nota: un processo esiste, che tu scelga di riconoscerlo oppure no) o ti trovi in una via di mezzo — il coach è responsabile di assicurarsi che il team segua un processo che gli permetta di dare il meglio. Nota che il processo ottimale sarà diverso per ogni team e ogni dinamica tra coach e team.
Gli allenatori coltivano i livelli di energia e lo stato mentale del team
Questo è un concetto di responsabilità difficile da accettare per molti PM, ma quando vedo un team che non sembra entusiasta del lavoro o sembra esausto, sprono il PM a creare una dinamica più sana.
Chiaramente non è facile, perché le persone sono complesse. Siamo tutti motivati a dare il meglio da fattori diversi: qualcuno ha bisogno di incoraggiamento, qualcun altro di essere sfidato, altri ancora di un amico, e qualcuno può aver bisogno di tutte e tre le cose in momenti differenti. I PM devono trovare il modo di capire cosa fa scattare ogni membro del team, i principi fondamentali della loro personalità — e poi costruire significato e coinvolgimento nel lavoro a partire da quei principi.
Questo concetto può sembrare autocelebrativo (esci dalla mia testa, PM!!!), ma è quello giusto per chi fa l’allenatore o il PM. Creare un team energico e coinvolto è fondamentale per il successo, e riuscirci in modo costante rappresenta il massimo della leadership e della professionalità in ambito PM.
Il punto sui primi principi è che a lungo termine nient’altro conta
Esplorare i primi principi del Product Management rivela che esso richiede uno sforzo uguale sia dal lato sinistro che dal lato destro del cervello. È in parte arte e in parte scienza. È in egual misura iper-razionale e iper-emotivo.
È la polarità di questi due modi di pensare che rende il mestiere del product manager complesso, entusiasmante e frustrante allo stesso tempo.
Il successo per i PM significa rispettare entrambi questi principi in egual misura. Elabora una strategia di prodotto che massimizzi l’impatto sulla missione e adotta una mentalità da coach per realizzare quella missione attraverso le persone che ti circondano.
Questo articolo, di Brandon Chu, è stato pubblicato originariamente su Medium.
