Come Avere Successo in una Fabbrica di Feature Come Product Manager (con Aakash Gupta, Il Guru della Crescita Prodotto)

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Ti preghiamo di perdonare eventuali errori di battitura poiché il bot non è sempre corretto al 100%.

Hannah Clark: Fabbrica di feature: sostantivo. Definizione: un'azienda software che si concentra costantemente sulla costruzione e il rilascio di nuove feature anziché creare un prodotto che gli utenti desiderano davvero. Usato in una frase, "Pensavo di essere stata assunta per guidare il team prodotto verso una nuova direzione audace, ma invece sto solo lavorando a catena in una fabbrica di feature."

Dimmi, la tua foto sarebbe accanto a quella voce del dizionario? Tu e migliaia di altri PM, amico mio. Se questa è la situazione, cosa puoi fare a riguardo?

Il mio ospite di oggi è Aakash Gupta, autore dell’iconica newsletter Product Growth. Prima di dedicarsi a tempo pieno alla newsletter, Aakash ha trascorso gli ultimi 12 anni in ruoli di prodotto senior e executive presso aziende come Epic Games, Affirm e Apollo. Significa che ha sperimentato pressoché ogni livello di influenza che un product manager possa avere.

Come puoi immaginare, Aakash conosce fin troppo bene le circostanze che creano le fabbriche di feature e il suo playbook per gestire da PM in queste organizzazioni è sia ultra pratico che piacevolmente realistico. Questo è un episodio a cui vorrai prestare molta attenzione fino alla fine, quindi iniziamo.

Benvenuti di nuovo al Podcast The CPO Club.

Aakash, grazie mille per aver trovato il tempo di parlare con noi oggi.

Aakash Gupta: Assolutamente. Felice di essere qui. E grazie per l'invito.

Hannah Clark: Sì, è un piacere. Puoi raccontarci un po’ del tuo percorso professionale e di come sei arrivato dove sei oggi?

Aakash Gupta: Sì, quando ho iniziato nel product management circa nel 2008, sentivo che la disciplina non era così sviluppata. Penso che INSPIRED sia stato pubblicato proprio in quel periodo. Credo abbia davvero aiutato molto. Prima di allora, forse c'era il pezzo di Ben Horowitz, tipo good product manager, bad product manager. Ma a parte questo, il campo non era realmente professionalizzato. Di fatto, esisteva soprattutto nelle aziende della Silicon Valley e nelle startup.

Mi ci sono avvicinato perché i fondatori della startup dove lavoravo erano seguaci religiosi di tutto ciò che riguardava Y Combinator. E molte aziende Y Combinator avevano product manager. Così, pur lavorando in una startup di sole sei persone quando sono arrivato, mi hanno assunto come product manager. Fortunatamente, avevo un background da ingegnere, quindi avevo programmato molte app, scritto codice, e mi ero cimentato con Photoshop.

Quando ho iniziato, facevo davvero di tutto. Ho progettato completamente il nostro sito web, ridisegnato grandi parti dell’app anche se ho competenze di design molto limitate. Per il sito, poi, ho gestito il CMS e tutta la tecnologia dietro. In pratica, intervenivo ovunque servisse come product manager nelle prime fasi, mentre scoprivo e imparavo cos’era la gestione del prodotto, ma era proprio quello stile da startup.

Poi ho lavorato alla mia startup, Rap to Beats. Anche lì facevo la stessa cosa, ma con più codice. Costruivo molte più versioni dell’app. Ho quindi un background da builder nella gestione prodotto. Da lì sono passato al vero product management in una società chiamata thredUP, ora quotata in borsa.

Mi sono unito quando era in serie C e ho lasciato in serie E. Insieme abbiamo costruito molti dei primi team di crescita lì. Nel 2014, se ricordi, il programma referral di Uber era molto in voga. Ricordo che quando abbiamo lanciato il nostro programma referral, è stato un grandissimo driver di crescita. Si poteva fare cose semplici così.

Non era nemmeno ottimizzato. Ho iniziato a lanciare prodotti. Ho capito che potevamo davvero cambiare la traiettoria di crescita delle aziende come product manager. È lì che mi sono realmente impegnato nella disciplina del product management. Da allora, sono stato PM in aziende come Google, Affirm, Epic Games e, più recentemente, Apollo.io, dove ero VP of Product. Ora lavoro full time sulla newsletter.

Hannah Clark: Fantastico. E so che moltissime persone la apprezzano.

Oggi ci concentreremo sulle fabbriche di feature e su come i PM possono sopravvivere in quelle organizzazioni. È quasi diventata una parolaccia nel settore.

Quindi partiamo dall’inizio. Come finiscono le organizzazioni per diventare fabbriche di feature e perché è un risultato così comune?

Aakash Gupta: Penso che tutte le strade portino alla fabbrica di feature. Mettiamo che tu sia in un ambiente davvero cosiddetto empowered. Negli ultimi quattro o cinque anni sono successe due cose.

O, come nel caso di Airbnb, il fondatore ha ripreso il controllo e ha detto “queste sono le cose che voglio costruire”. Oppure, i leader prodotto hanno preso il controllo facendo molti licenziamenti e riorganizzazioni. E spesso usano le riorganizzazioni continue per mettere le persone nei posti e portare avanti prodotti e feature che vogliono costruire.

Quindi alla fine cosa succede? Sia il CEO che i responsabili di prodotto, per le pressioni del contesto recente, hanno detto: non possiamo solo delegare, non possiamo lasciare tutte le decisioni su prodotti che valgono un miliardo di euro a product manager di 26 anni con quattro anni di esperienza.

Così anche negli ambienti apparentemente empowered, persino a Google e Netflix — parlo con persone che ci lavorano — non sono i product manager a decidere al 100% la roadmap.

Molte volte c’è un processo bottom-up e uno top-down che avvengono in parallelo, in modo invisibile. In quello bottom-up, il PM propone idee e le inserisce in pianificazione, ma poi, nella realtà, il risultato finale è roba che i dirigenti hanno dovuto approvare, spesso idee loro.

Quindi, secondo me molte persone rivestono l’ambiente empowered di paroloni come OKR e pianificazione trimestrale, ma il risultato finale resta la fabbrica di feature. for First only a quarter of companies they are really empowered, e poi degradano in fabbriche di feature.

Per l’altro 75% delle aziende, circa il 30% è in fase di trasformazione. Queste aziende capiscono che devono passare all’agile, capiscono che serve dare più potere ai PM. Ma poi, appena il PM lavora con altre funzioni — design, ingegneria, business, sales —, in settori come bancario o sanitario dove la digital transformation è forte, tutti sono ancora abituati al modo da fabbrica di feature, al waterfall working.

Anche se il team prodotto vorrebbe cambiare, ci vuole anni. Marty Cagan mi ha detto che servono tre anni, e lo penso anch’io. È proprio così. Intanto i PM sono responsabili dei metriche ma hanno comunque le feature decise dall’alto. È un limbo.

Poi ci sono ambienti chiaramente waterfall, chiaramente da fabbrica di feature, e tante aziende sono perfettamente a loro agio così. Prendi Apple, gli executive decidono molte delle feature principali, come facevano Jony Ive e Steve Jobs quando c’erano. Questo modello può funzionare, anche se si pensa che non abbia successo. Marty Dice che le migliori aziende sono tutte empowered, ma io vedo che tutte le strade portano alla fabbrica di feature.

Hannah Clark: Capisco, logicamente fila tutto.

Parliamo di alcuni passi che hai delineato nel blog che hai scritto su questo argomento. Se non avete letto l’articolo, è davvero interessante come lo hai suddiviso e come proponi una posizione un po’ controversa su come reagire da PM in una fabbrica di feature. Prima di andare ai passi, puoi dirci dove ti posizioni rispetto, ad esempio, a Melissa Perry?

Aakash Gupta: Sì, credo che ci siano gli idealisti e i realisti. Nel campo idealista, ci sono persone come Marty Cagan, Teresa Torres, John Cutler, tutti e tre li adoro, ammiro e leggo tutto ciò che scrivono. Ma loro credono che, come PM, dovresti cercare di trasformare la tua organizzazione anche se sei in una fabbrica di feature.

Questa è la loro filosofia, usano strumenti e insight che generosamente condividono gratis. Li stimo tantissimo, ma ecco quello in cui credono. Io, Melissa Perry e altre persone come Clair Vaux, Powell Hearn, siamo più realisti. Se non hai otto, dieci anni di esperienza da PM, e almeno un titolo da group PM o superiore, non hai davvero la possibilità o l’influenza per cambiare tutta l’organizzazione.

Quindi invece di partire subito a cambiare tutto, meglio pensare a un’altra strategia. E perché lo dico? Perché ho visto tantissime persone provare a vivere l’ideale. C’è una storia che racconto sempre: mi piace ordinare per popolarità tutti i post del subreddit product management.

Ancora oggi otto post su dieci sono di PM che scrivono, “Odio il mio lavoro, il mio mondo fa schifo”. E se entri nel dettaglio, sono PM in una fabbrica di feature. Dicono “Ho letto INSPIRED, pensavo di poter decidere la roadmap, invece sono solo un esecutore degli ordini del CEO”. È uno scenario super comune: sono nel 75% delle aziende che sono fabbriche di feature esplicitamente, si sentono infelici e insoddisfatti.

Quindi, per evitare tutto questo, visto che ho tantissimi lettori product manager, dò un consiglio realistico: accettalo. Accetta di essere in una fabbrica. È meglio sapere dove sei. E allora puoi chiederti, “Come operaio in fabbrica, cosa devo fare per sopravvivere e andare avanti?”

Hannah Clark: Sì, è questione di mentalità, su come affrontiamo qualsiasi situazione difficile. Ma non deve essere per forza così difficile.

Quindi parliamo un po’ dei passi che hai fornito nell’articolo, a partire dall’accettare la fabbrica, di cui hai già accennato. Quando ti è scattata questa consapevolezza come fase necessaria del processo?

Aakash Gupta: Credo, in realtà, dopo tentativi di trasformazione falliti. Per esempio, sono stato in ambienti diversi. Molti PM non hanno mai lavorato in un ambiente gaming. Io invece ero a Epic Games su Fortnite. Molti pensano alla fabbrica di feature come solo CEO o Chief Product Officer a comandare. Ma in gaming spesso sono i designer e i creativi che inventano cose nuove da lanciare.

I ragazzini di 14 anni troveranno l’esperienza più “fighissima” di sempre. Così riempiono la stagione successiva di novità. Da product manager per me era ovvio che c’era frutta matura da raccogliere sulle performance, sull’onboarding, sugli update. Se avete provato ad aggiornare Fortnite, ancora oggi è un file da 42 giga, il mio Mac ci mette due ore e poi anche mezz’ora per installare. È un’agonia.

Relaseano update ogni due settimane: ore e ore di frizione. Sullo store di monetizzazione, c’era un mare di frutta matura solo creando più varianti per chi spende anche 3/4k ogni anno. Ma convincere chi era focalizzato sul “cool” non era possibile. Ci ho provato: ho detto che dovevamo puntare agli outcome, non ai feature “fighe”. Ma tutto inutile, nessuno ascoltava. Così ho provato in altri ambienti. Ad esempio in Affirm c’era un’infrastruttura di pianificazione centralizzatissima.

Pensavo: ora che sono GPM, il mio team avrà problemi più vaghi da affrontare. Invece no: durante la pianificazione gli executive ci guardavano e dicevano “Avete lavorato davvero? Gli altri team hanno roadmap super dettagliate, stime al centesimo di impatto su ricavi e profitti”. Sembravamo degli scappati di casa.

Provando e sbagliando, e ora anche da coach di PM che spesso vengono da me perché magari hanno performance basse, facciamo 360 review e spesso trovo che i designer e ingegneri partner dicono “Le sue PRD non erano dettagliate”. Questi PM credono di essere in un ambiente empowered, ma in realtà sono in una fabbrica di feature e lì si pretendono PRD dettagliatissime. Così performano peggio.

In sintesi: bisogna migliorare la performance. E nella mia esperienza reale in questi ambienti, non ho mai visto che puoi cambiare tutto subito. L’unico posto dove ci sono riuscito è al livello di direttore e VP.

Quando ero in thredUP, Affirm, lì davvero il tuo lavoro è far crescere l’organizzazione. E lì puoi lentamente smantellare la fabbrica, ma devi avere intenzionalità e seniority. E va bene che ora possiamo definire cos’è una fabbrica di feature, così puoi affrontare l’anti-pattern poco a poco. Ma come consiglio di carriera: se non sei a quel livello, non provare a sistemare l’anti-pattern.

Hannah Clark: Che ci porta al prossimo passo: adattarsi all’ambiente. Tu scrivi che bisogna focalizzarsi su ciò che è davvero il tuo lavoro, fare il vero lavoro. Puoi approfondire e spiegare i sotto-passaggi?

Aakash Gupta: Sì. Trovo sorprendente che, riflettendo sui documenti che producevo come PM e su quelli apprezzati, fossero sempre diversi. In Epic Games erano pitch di feature “cool”.

Rimanevamo in piedi fino alle 2 di notte con qualche “tech designer” a realizzare una demo giocabile. Quello era quello che piaceva. In Affirm, invece, come ho già detto, ciò che funzionava era presentarsi con una roadmap ad alto impatto, piena di dati e modelli d’impatto. Due mondi opposti.

Quindi bisogna capire cosa davvero significa “successo come PM” nel tuo ambiente. Consiglio di intervistare i PM che sono in azienda da più tempo e i più recentemente promossi: due fonti ottime.

Cerca di non fermarti solo alla superficie. Prova a portarli a pranzo, costruire un rapporto personale, offrire qualcosa prima, chiedere — ma solo dopo aver instaurato una relazione vera. Chiedi, ad esempio: scrivi una PRD per ogni feature? Puoi mostrarmi la tua migliore PRD? Puoi mostrarmi il pacchetto per la promozione? Le tue ultime note di one-on-one con il manager? Sono cose molto tattiche ma che puoi chiedere solo a chi hai guadagnato la fiducia.

Direi: fatti amico prima, poi magari anche mentore, ma senza chiedere esplicitamente, perché spesso i leader apprezzano chi ha “gravitas” propria. Diranno: “Questa persona è curiosa, investigativa, ci tiene davvero”.

Fai queste interviste come se stessi esplorando il prodotto: parli con clienti, non clienti, concorrenti ecc. Consiglio anche conversazioni dirette con tech lead, engineering manager, designer, user researcher, analyst e anche con il tuo capo e il capo del capo, per chiarire bene ruoli e responsabilità.

Chiedi in modo esplicito: cosa pensi del PM che fa sketch e wireframe? Molti designer diranno “non tanto”, altri invece “ok, ma non su Figma”. Bisogna conoscere queste sfumature. Capire come lavorare coi propri stakeholder senza dare nulla per scontato.

Perché a volte chi fa le interviste illude che il proprio ruolo sia simile a quello di un altro PM nel team, invece ognuno ha intorno stakeholder molto diversi.

Tutti vorrebbero scalare la montagna fino al VP. Ma per ora concentra tutto su chi hai intorno, crea una specie di contratto e poi testalo, verifica come viene recepito. Magari l’engineering manager non sa che i suoi ingegneri adorano essere invitati ai colloqui con i clienti: lo capirai solo provando.

Devi essere attentissimo al micro-gruppo che lavora con te. Sembra un consiglio banale di carriera, ma il senso è tutto nel capire cosa davvero significa il tuo lavoro di PM. Credo che nessun PM faccia il mestiere identico a un altro.

Hannah Clark: Sento che, in ogni ambiente lavorativo, con le persone più vicine, si crea una “microcultura”. Quindi è importante capirne le sfumature, i linguaggi non verbali, allineare le aspettative reciproche: lo apprezzo molto.

E questo si ricollega al fatto di fare one-to-one con chi ha avuto successo nel ruolo da tanto.

Il prossimo step è crearsi un percorso di promozione. Quelle persone contano molto per questa fase. Ci puoi raccontare la strategia per costruire la roadmap di carriera?

Aakash Gupta: In una fabbrica di feature, i criteri per le promozioni sono spesso costanti, non scritti e spesso fraintesi persino dal tuo manager. Tantissime persone si affidano solo al proprio manager o magari sono pure insistenti su promozioni nelle one-on-one. Ma quello che non capiscono — e io stesso ho dovuto spiegarlo a chi lavorava con me — è che non è solo il tuo manager a decidere.

Per esempio, in Affirm, scrivo un packet su di te che poi va a un comitato promozioni. Lì sono presenti tutti i leader prodotto a pari livello o superiore al mio, e tutti intervengono almeno una volta. Quindi, dopo aver convinto me, devi convincere anche tutti gli altri leader del prodotto.

Serve costruire relazioni con quegli altri manager che “sfornano” promozioni. Trovare queste persone, instaurare un rapporto (prima amicalmente, magari facendo lavori insieme) e poi ascoltare la loro esperienza col comitato promozioni. Per me le intuizioni migliori le ho avute, ad esempio, di persona davanti a una birra dopo il lavoro. Solo lì vedi come funzionano le cose davvero.

C’è chi affronta tutto in modalità 9-17, ma secondo me quelle due ore alla sera valgono molto di più per capire, chiedere, negoziare queste dinamiche. Quando mi chiedono come abbia fatto carriera così velocemente fino a VP, rispondo: ho compreso i veri percorsi di promozione nelle diverse aziende. Ovunque andassi, in un anno o due ero promosso, aumentava il mio team, il mio perimetro. E tutto perché ero focalizzato sul percorso di promozione. Chiedendo in giro, ho notato che molti nemmeno sanno che, ad esempio, c’è un comitato promozioni in Affirm. C’è davvero un enorme gap di conoscenza da colmare.

Poi, una volta colmata la conoscenza, si passa a valutare i punti di forza propri: ogni PM avrà qualche area dove è più debole e altre da valorizzare (magari il feedback di design vale 8/10, la gestione dei “cantankerous stakeholder” 7/10 — allora ci si concentra sui punti forti). Ad esempio, so scrivere bene: come posso creare un aggiornamento settimanale? Come far circolare una strategia prodotto tra più team? Metti i tuoi punti forti a leva, magari condividendo il tuo documento di strategia anche con team vicini, così chi lo legge pensa, “questo PM sta facendo un gran lavoro prodotto”.

Hannah Clark: Questo è così intelligente e pratico. Apprezzo proprio l’approccio concreto.

Il prossimo passo è migliorare singole pratiche isolate. Quando parli di pratiche isolate, a cosa ti riferisci e puoi fare esempi concreti su come affinarle?

Aakash Gupta: Sì, sopra il livello di GPM, le dovresti portare a livello organizzativo. Bisogna fare dei progetti pilota su certi team e dimostrare che funzionano. Sotto il livello GPM, fallo solo nel tuo team. Prima dimostra che sai lavorare secondo quanto richiesto dai partner design, ingegneria, dati. Poi prova a elevare lo standard.

E dovresti anche chiedere feedback e adattare di conseguenza. Ecco, negli ultimi tempi ho sperimentato vari ordini, questo è quello che funziona meglio per cambiare rotta:

1. Report sui risultati delle feature: sono strumenti innocui anche in una fabbrica di feature. Hai consegnato una feature su ordine di Brian Chesky (CEO), ma vuole sapere cosa è successo e perché. E spesso i leader, anche nelle feature factory, vogliono capire il “perché”. Invece che limitarsi a dire “A ha fatto meglio di B, quindi promuovo A”, meglio scrivere “A ha fatto meglio di B perché…” e da lì influenzi anche il dopo, pur restando in una fabbrica. Ti faccio un esempio concreto: ad Airbnb hai creato la visualizzazione “prezzo totale” su ordine di Chesky. Poi gli dici che il conversion rate generale è salito del 4%. Spiega il perché: magari la gente non si fidava dei prezzi sulla mappa e abbiamo risolto un problema di fiducia. Con questa intuizione potrai proporre miglioramenti su altre aree con bassa fiducia (reviews, Airbnb Plus ecc.).

2. Impact sizing: Spesso i PM sono responsabili degli outcome, ma ricevono solo comandi sugli output. Allora, quando ti viene imposto di costruire qualcosa, costruisci il miglior “business case” possibile, con più dati che puoi, su come questa feature performa. Per esempio, il CEO di thredUP voleva che il programma referral aumentasse da 10/10 a 30/30 per un +5% sui ricavi. Ho usato le stime più ottimistiche, ma veniva comunque solo uno 0,1%. Così il CEO ha capito da solo che non serviva.

3. Discovery: tutti tendono a volerla fare per prima, io la metto terza. Dopo i report e l’impact sizing, se ti ordinano di sviluppare qualcosa, dici “ok, grazie per il wireframe, ora facciamo vera discovery e vi portiamo con noi”. Mostra i video delle user interview, magari solo gli highlight. Poi “solution discovery” e anche “problem discovery”.

4. OKR: qui entriamo in territorio GPM. Come Principal PM, ti consiglio di adottare OKR solo se già lo fanno anche gli altri. Come GPM, invece, sono utili solo se la squadra fa già discovery. Molte aziende li fanno male perché saltano passaggi, così i loro OKR sono “aria fritta” e sono sempre disattesi.

Poi si sale tra OKR, OKPS tree (collegano OKR a problemi/soluzioni), fino alla strategia prodotto. Ma la strategia vera la puoi scrivere solo quando controlli tutto l’OKPS tree. Di solito, la scrive il CEO, finché non sei abbastanza senior e empowered.

Hannah Clark: Il punto successivo: creare la tua coalizione. Abbiamo già parlato di relazioni con design/prodotti/engineering. Hai una storia diretta da raccontare?

Aakash Gupta: Sì, torniamo a Epic Games, come detto prima. In quei contesti, era tutto sulle relazioni. Volevo migliorare le performance di Fortnite. È un gioco di altissimo livello, alcuni ci stanno sopra 2.000 ore l’anno — come un lavoro full time. Ma se hai latenze alte o poca potenza, limiti il tuo skill cap e smetti prima. Nei dati, chi aveva performance basse mollava dopo 1–2k ore; chi aveva performance buone restava anche oltre 10 mila ore.

Ma non potevo solo dire questa intuizione. Dovevo convincere i designer e tecnici chiave. Jason, creatore di Call of Duty e boss di Fortnite, influenzava tutte le decisioni. Lui stimava molto gli ingegneri e designer più stakanovisti (settore gaming = orari da investment banking). Quindi dovevo entrarci in sintonia.

La mia occasione: quelli lavoravano troppo, nessuno raccontava loro i risultati delle proprie feature. Così ho iniziato a consegnare report dettagliati: “Patch 6.4 di Season 4 ha comportato… Sniper usati +8%, kill -6%, nei livelli bassi succede X…”. Si gasavano. E in mezzo ci infilavo qualche dato sulle performance (“i giocatori con ping sopra i 200 ms stanno abbandonando a tassi record”). Così hanno iniziato a prendersi a cuore quei temi e abbiamo migliorato parecchio le performance. In sintesi, serve pensare strategicamente a chi può essere nella tua coalizione e costruire la relazione sulle basi di utilità concreta.

Hannah Clark: È intelligente su molti livelli. Costruisci fiducia, acquisti influenza quasi senza sforzo. Geniale.

Prima di chiudere: quali errori comuni fanno i PM nelle feature factory? A parte non accorgersi di esserci dentro, quali altri errori possiamo elencare?

Aakash Gupta: Ce ne sono sei che voglio segnalare. Primo: si inseguono solo metriche di output. Hanno sentito il mio consiglio di “arrenditi alla fabbrica”, quindi ottimizzano solo per velocità delle story point in Jira, numero di feature consegnate puntuali, ecc. Ma è un errore: bisogna sempre guardare anche gli outcome delle feature. Non devi solo obbedire alla fabbrica: mantieni comunque il senso del product.

Sui margini, prendi le decisioni giuste sull’allocazione delle risorse dove puoi. Così continui a tenere alta la tua curva d’apprendimento; molti entrano in una fabbrica e si “appiattiscono”, tornano peggiori di come erano a Google. Succede davvero! Tieni alto il livello e osserva sempre metriche, impatto per l’utente di tutto ciò che lanci.

Secondo errore: perché si corre tanto sulle feature, spesso si trascura il debito tecnico. Si accumula, l’esperienza dev si impoverisce (build time da tre ore, una giornata per una semplice fix), ma si va avanti dritti perché “deve uscire la nuova stagione”. Accade spesso.

Distinguere tra “debito tecnico accidentale” (dovuto alla UX, da minimizzare e correggere) e quello “intenzionale” (sali sulle feature e vai avanti, ma poi se la feature diventa chiave, bisogna tornare a sistemare il debito che hai lasciato).

Errore tre: ignorare i feedback utenti. Ho detto che a molti sembra tanto anche solo mostrare il wireframe: ma non dovrebbe esserlo. Quando chiedo: “Per la tua ultima grande feature, a quanti utenti hai mostrato le final design?” — metà delle volte la risposta è “a nessuno, dovevamo sbrigare e basta”. È un errore enorme: la tua carriera dipende da ciò che lanci il team.

Quindi anche se ti impongono la feature, rendila la migliore versione possibile di quell’idea sbagliata.

Quarto errore: lasciarsi guidare dal FOMO nella roadmap. Il classico motivo della fabbrica di feature è “HubSpot ha rilasciato un CRM, allora serva anche a noi!”. “Tweet Hunter fa anche post su LinkedIn, allora pure noi”… Si rincorrono funzioni per non perdere presunti clienti. È sbagliato. Il modo di arginare questo è usare l’impact sizing e mostrare che “l’ultimo prodotto nuovo è usato solo dallo 0,2% degli utenti: ne vale la pena davvero investire in una nuova cosa con la stessa adozione?” Ogni volta che vedi FOMO tra chi dirige la fabbrica, è il momento di sollevare dubbi.

Errore cinque: bruciare il team. Tantissimi, anche nei team empowered, spingono sull’acceleratore e si rischia burnout. Ma anche se la rapidità è importante, un team sano produce i migliori risultati. La crescita vera la fa una squadra motivata. Quindi da PM chiedi strumenti migliori, budget formazione, un team offsite per celebrare risultati. Come ai vecchi tempi, portare leccornie ai dev, fare high five ai designer… piccole cose che fanno la differenza nel benessere del team, anche perché non sono solo i PM a faticare nelle feature factory. Anche gli altri ruoli sono spesso frustrati.

Errore sei: perdere di vista il quadro generale. Siamo sempre assorbiti dal “what”, e ci dimentichiamo il “why”. Prima ho parlato del “why” nei metriche, nei problemi utente, ma vale anche per la strategia prodotto. Anche se la strategia formale la scrive il CEO, bisogna tenere viva la competenza e la mentalità. Oggi il settore si sta comprimendo, i posti da PM sono meno, mentre product design e product engineer crescono.

Per riuscire, serve quindi impattare anche sulla strategia. Anche in fabbrica, hai pur sempre un 10–15% di roadmap che puoi influenzare, un 10–15% dello sprint in cui puoi inserire le tue idee. Anche se sei in fabbrica, se ti è stato ordinato tutto, assicurati che la tua feature sia quanto più strategica e “game changer” possibile. Vi faccio due esempi: un PM ad Epic Games e uno ad Affirm che ancora sono lì. Anche se fanno poche feature “proprie”, quelle cambiano davvero la traiettoria dell’azienda. Ad Affirm, un PM ha lanciato il machine learning per ordinare i prestiti da rimborsare, migliorando i tassi di rimborso del 15%, con effetto enorme sul valore aziendale e sulle azioni. Questo è l’obiettivo: anche se ascoltiamo Aakash e Hannah parlare di fabbrica di feature, il vero colpo di genio si infila dove e quando puoi.

Hannah Clark: Questo è il momento “mic drop”! Aakash, grazie davvero per aver dedicato tempo a questa chiacchierata. Per i cinque che ancora non ti seguono, dove possono trovarti online?

Aakash Gupta: L’ideale è la newsletter. Sono su Substack. So che c’è il pop-up fastidioso, ma potete ignorarlo e leggere comunque. Ormai ogni mio pezzo nasce da almeno 10+ interviste. L’ultima volta ho avuto un co-autore, entrambi abbiamo intervistato 10 persone, cercato insight reali. Non aspettatevi i contenuti generici da LinkedIn o X: sono vere ricerche fatte con veri protagonisti. Per la ricerca lavoro in ambito product leadership, intervistiamo chi ha davvero ottenuto un ruolo da VP o da direttore, parliamo con veri recruiter. Sto cercando di portare dati e insight veri. Se vi interessa quello, è lì che mi trovate e su cui lavoro ora.

Hannah Clark: Fantastico. Vi aspettiamo lì. E ancora grazie per questa chiacchierata.

Aakash Gupta: Grazie mille, è stato un piacere.

Hannah Clark: Grazie per l’ascolto! Per altri approfondimenti, guide pratiche e recensioni di tool, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altre conversazioni come questa iscrivendoti a The CPO Club ovunque ascolti podcast.