Il termine “feature factory” è diventato una sorta di parola d’ordine nel settore, spesso usata con un misto di ironia e rassegnazione. Ma cosa significa davvero lavorare in quella che viene chiamata una feature factory, e soprattutto, come possono i product manager non solo sopravvivere ma anche prosperare in questi ambienti?
In questo episodio, Hannah Clark è affiancata da Aakash Gupta—Product Leader & autore della Product Growth Newsletter—per definire un piano d’azione realistico per i PM delle feature factory.
Punti salienti dell’intervista
- Aakash ha rinunciato ad approcci idealistici per trasformare le feature factory dopo aver vissuto insuccessi in diversi ambienti:
- In Epic Games, i designer dettavano le funzionalità in base a ciò che ritenevano fosse cool.
- In un’altra azienda, i dirigenti hanno respinto la sua roadmap perché mancavano funzionalità dettagliate e metriche concrete.
- Molti PM nelle feature factory hanno difficoltà perché non comprendono correttamente l’ambiente. Pensano di essere in un contesto empowered quando invece non lo sono e non si concentrano nel fornire specifiche dettagliate richieste dalla factory.
- Aakash consiglia ai PM nelle feature factory di concentrarsi sull’aumentare le proprie prestazioni all’interno del sistema esistente. Crede che per apportare cambiamenti significativi serva guidare grandi team (livello direttore/VP).
- Valuta il successo della gestione di prodotto nel tuo ambiente:
- Intervista PM di lunga data e quelli recentemente promossi.
- Fai loro domande specifiche sul loro lavoro (es. miglior PRD, dossier per la promozione).
- Costruisci un rapporto con loro prima di chiedere dettagli.
- Definisci ruoli e responsabilità con gli stakeholder:
- Svolgi conversazioni one-to-one con persone chiave (designer, ingegnere, ecc.).
- Sii esplicito su ciò che ti aspetti e su ciò che loro si aspettano da te.
- Comprendi come ciascuno preferisce lavorare (es. PM che fa schizzi vs designer che realizza wireframe).
- Prova e adatta in base ai feedback:
- Osserva quali deliverable sono più apprezzati dagli stakeholder.
- Comprendi le loro preferenze collaborando.
- Raffina continuamente il tuo approccio basandoti su ciò che funziona nello specifico ambiente.
- Ogni lavoro da PM è diverso. Comprendi le aspettative e adatta il tuo approccio per avere successo entro i vincoli della feature factory.
Devi valutare cosa significa avere successo nel product management nel tuo ambiente. Intervista chi è PM da più tempo nella tua azienda e chi è stato appena promosso. Questi sono due ottimi punti di vista da considerare.
Aakash Gupta
- Creare il tuo percorso di promozione in un ambiente Feature Factory [18:07]
- Criteri di promozione non scritti:
- Comprendi quali fattori influenzano le decisioni di promozione oltre al tuo responsabile diretto.
- I comitati di promozione spesso coinvolgono diversi leader con aspettative non dichiarate.
- Costruisci relazioni con altri manager:
- Trova persone che promuovono con successo i membri dei loro team.
- Inizia costruendo amicizie e collaborando su progetti.
- Scopri di più sui comitati di promozione tramite conversazioni informali.
- Focalizzati sul percorso di promozione:
- Dedica tempo extra-lavorativo per creare una rete di contatti e imparare.
- Comprendi i criteri specifici per la promozione nella tua azienda.
- Punta sui tuoi punti di forza:
- Individua le tue competenze più forti come PM (es. scrittura, gestione degli stakeholder).
- Valorizza questi punti di forza per generare un impatto positivo oltre il tuo ruolo immediato.
- Metti in evidenza il tuo lavoro alle persone rilevanti che possono influenzare le decisioni di promozione.
- Criteri di promozione non scritti:
- Affinare le competenze di PM a diversi livelli [22:19]
- Approccio graduale:
- Inizia sperimentando all’interno del tuo team e dimostrando successo.
- Raccogli feedback dagli stakeholder e perfeziona il tuo approccio.
- Passaggi per migliorare nonostante le limitazioni:
- Analisi dei risultati delle feature:
- Analizza perché le feature hanno avuto successo o sono fallite, focalizzandoti sull’impatto per l’utente.
- Utilizza dati e insight degli utenti per raccontare una storia convincente.
- Questo dimostra la tua capacità di misurare il successo e informare le decisioni future (anche in un ambiente orientato alle feature).
- Valutare l’impatto:
- Crea un caso “steel man” con ipotesi ottimistiche per valutare il potenziale impatto delle feature prima di realizzarle.
- Questo aiuta a gestire le aspettative e identificare le feature che difficilmente porteranno ai risultati desiderati.
- Scoperta (Discovery):
- Dopo la valutazione dell’impatto, effettua una corretta ricerca utenti per validare il problema e le possibili soluzioni.
- Utilizza strumenti come Dovetail per condividere in modo efficiente i risultati della ricerca con gli stakeholder.
- Questo dimostra un approccio allo sviluppo prodotto guidato dai dati.
- OKR (per GPM):
- Implementa gli OKR una volta che il tuo team ha dimestichezza con discovery e valutazione dell’impatto. (Vedi anche: roadmap OKR)
- OKR efficaci si basano su dati concreti e sulla corretta identificazione del problema.
- Alberi OKR (per GPM):
- Usa gli alberi OKR per collegare gli OKR a problemi e soluzioni specifici.
- Questo assicura coerenza tra obiettivi e iniziative intraprese per raggiungerli.
- Strategie di prodotto (per GPM):
- Sviluppa strategie di prodotto solo dopo aver ottenuto il controllo sull’intero processo di definizione degli OKR e sulle soluzioni.
- Una vera strategia di prodotto richiede la proprietà della roadmap e la capacità di trasformare i problemi in soluzioni.
- Analisi dei risultati delle feature:
- Punta a costruire solide competenze di product management in modo da dimostrare valore anche in un ambiente feature factory. Con il tempo, guadagna influenza e controllo sul processo di sviluppo prodotto.
- Approccio graduale:
Tutti pensano che il product management riguardi la strategia di prodotto, ma non credo sia possibile scrivere veramente una strategia di prodotto finché non hai il controllo sull’intero albero OKR. Fino ad allora, in pratica, è il CEO che definisce la tua strategia di prodotto. Solo quando sei completamente responsabilizzato allora puoi integrare la strategia di prodotto.
Aakash Gupta
- Costruire una Coalizione e Applicazione nella Vita Reale [28:58]
- Identificare i decisori chiave – Nel caso di Aakash in Epic Games, erano i lead engineer e designer rispettati dal direttore.
- Comprendere le loro priorità e sfide – Gli ingegneri e i designer davano valore al riconoscimento per il loro duro lavoro e desideravano vedere l’impatto dei loro sforzi.
- Adattare il proprio approccio alle loro esigenze – Aakash utilizzava report dei risultati delle funzionalità per mostrare l’impatto delle feature passate e inserire in modo sottile metriche di performance.
- Fornire valore prima di fare richieste – Sottolineando i risultati positivi del loro lavoro, Aakash si è guadagnato la fiducia e la disponibilità a recepire i suoi suggerimenti riguardo ai miglioramenti delle performance.
- Concentrarsi sul costruire relazioni nel tempo – Aakash ha costruito strategicamente nel tempo il rapporto con le persone chiave per influenzare il processo di sviluppo prodotto.
- Errori Comuni negli Ambienti Feature Factory [32:35]
- Inseguire solo metriche di output: concentrati anche su risultati (impatto sugli utenti) oltre che sulle metriche dettate dalla feature factory. Non perdere il buon senso del prodotto.
- Trascurare il debito tecnico: gestisci sia il debito tecnico accidentale (user experience) che quello intenzionale (grande funzionalità). Dai priorità all’affrontare parte di quello accidentale per mantenere la velocità.
- Ignorare i feedback degli utenti: richiedi attivamente feedback agli utenti e itera sui design prima di rilasciare funzioni.
- Lasciare che la FOMO guidi la roadmap: non inseguire tendenze o funzionalità dei competitor. Utilizza la valutazione dell’impatto per stimare il valore potenziale di nuove feature prima di costruirle.
- Sovraccaricare il tuo team: spingi per strumenti, formazione & sviluppo, e team building per mantenere alta la motivazione.
- Perdere di vista il quadro generale: Sviluppa capacità di strategia di prodotto e usale per influenzare la roadmap, anche se in modo limitato. Punta a funzionalità ad alto impatto che apportino benefici significativi all’azienda.
Conosci il nostro ospite
Aakash è passato dal ruolo di PM in una piccola startup B2B SaaS a VP of Product in una Unicorn in 15 anni. Lavorando in realtà come Affirm, Epic Games e Apollo.io, ha maturato una profonda esperienza nella Product Management. Ha anche costruito uno dei più grandi seguiti in assoluto, con oltre 206.000 follower su LinkedIn. Ora scrive a tempo pieno la newsletter Product Growth, dove conduce ricerche approfondite per condividere settimanalmente insight utili per il successo dei PM.

Anche se lanciare in fretta è importante, credo che un team ben motivato e in salute tenda a produrre i risultati migliori.
Aakash Gupta
Risorse da questo episodio:
- Iscriviti a The CPO Club newsletter
- Collegati con Aakash su LinkedIn e X
- Dai un’occhiata al sito web di Aakash
- Scopri The Product Growth Newsletter
Articoli e podcast correlati:
- Informazioni sul Podcast The CPO Club
- Come i Product Leader ostacolano involontariamente la crescita aziendale
- Perché la Product Management è importante?
- 12 strategie di successo per il lancio di prodotto (+Esempi)
- Presentazione di Aakash Gupta, The Product Growth Guy [00:23]
- Aakash ha iniziato la sua carriera nel product management nel 2008 quando il settore non era ancora ben definito.
- Ha imparato il product management in una startup svolgendo vari compiti tra cui design, programmazione e gestione del CMS.
- Aakash ha poi co-fondato la propria startup dove ha continuato a programmare sul prodotto.
- Dopo di ciò, è entrato in thredUP come product manager e ha contribuito a costruire il team di crescita.
- Da allora, Aakash ha ricoperto ruoli di product management presso Google, Affirm, Epic Games e Apollo.io.
- Sopravvivere alla Feature Factory: Comprendere e Adattarsi [03:29]
- 3 motivi principali per cui le organizzazioni degenerano in feature factory:
- Ambienti empowered – i dirigenti o i leader di prodotto riprendono il controllo della roadmap perché non si fidano dei product manager con la piena responsabilità decisionale.
- Fase di trasformazione – le aziende faticano a implementare metodologie Agile perché gli altri dipartimenti sono abituati all’approccio a cascata.
- Ambienti waterfall – tradizionalmente alcune aziende hanno una gestione di prodotto top-down dove i dirigenti impongono le funzionalità.
- Anche in ambienti empowered, i product manager potrebbero non avere il 100% del controllo sulla roadmap. Le negoziazioni e i compromessi avvengono dietro le quinte.
- I modelli di feature factory possono comunque avere successo in alcune aziende come Apple, dove una leadership forte prende decisioni chiave sul prodotto.
- 3 motivi principali per cui le organizzazioni degenerano in feature factory:
- Strategie realistiche per i PM nelle Feature Factory [07:07]
- Aakash identifica due visioni opposte su come i product manager dovrebbero affrontare le feature factory:
- Idealisti – credono che i PM dovrebbero cercare di trasformare l’organizzazione.
- Realisti – ritengono che la maggior parte dei PM non abbia l’esperienza per trasformare l’organizzazione.
- Molti PM nelle feature factory sono insoddisfatti perché le loro aspettative idealistiche non corrispondono alla realtà.
- I PM nelle feature factory dovrebbero accettare la situazione e concentrarsi sul successo all’interno dei vincoli esistenti.
- Aakash identifica due visioni opposte su come i product manager dovrebbero affrontare le feature factory:
- Adattarsi alla Feature Factory: Guida di un Realista [09:51]
- Aakash ha rinunciato ad approcci idealistici per trasformare le feature factory dopo aver vissuto insuccessi in diversi ambienti:
- In Epic Games, i designer dettavano le funzionalità in base a ciò che ritenevano fosse cool.
- In un’altra azienda, i dirigenti hanno respinto la sua roadmap perché mancavano funzionalità dettagliate e metriche concrete.
- Molti PM nelle feature factory hanno difficoltà perché non comprendono correttamente l’ambiente. Pensano di essere in un contesto empowered quando invece non lo sono e non si concentrano nel fornire specifiche dettagliate richieste dalla factory.
- Aakash consiglia ai PM nelle feature factory di concentrarsi sull’aumentare le proprie prestazioni all’interno del sistema esistente. Crede che per apportare cambiamenti significativi serva guidare grandi team (livello direttore/VP).
- Valuta il successo della gestione di prodotto nel tuo ambiente:
- Intervista PM di lunga data e quelli recentemente promossi.
- Fai loro domande specifiche sul loro lavoro (es. miglior PRD, dossier per la promozione).
- Costruisci un rapporto con loro prima di chiedere dettagli.
- Definisci ruoli e responsabilità con gli stakeholder:
- Svolgi conversazioni one-to-one con persone chiave (designer, ingegnere, ecc.).
- Sii esplicito su ciò che ti aspetti e su ciò che loro si aspettano da te.
- Comprendi come ciascuno preferisce lavorare (es. PM che fa schizzi vs designer che realizza wireframe).
- Prova e adatta in base ai feedback:
- Osserva quali deliverable sono più apprezzati dagli stakeholder.
- Comprendi le loro preferenze collaborando.
- Raffina continuamente il tuo approccio basandoti su ciò che funziona nello specifico ambiente.
- Ogni lavoro da PM è diverso. Comprendi le aspettative e adatta il tuo approccio per avere successo entro i vincoli della feature factory.
Devi valutare cosa significa avere successo nel product management nel tuo ambiente. Intervista chi è PM da più tempo nella tua azienda e chi è stato appena promosso. Questi sono due ottimi punti di vista da considerare.
Aakash Gupta- Creare il tuo percorso di promozione in un ambiente Feature Factory [18:07]
- Criteri di promozione non scritti:
- Comprendi quali fattori influenzano le decisioni di promozione oltre al tuo responsabile diretto.
- I comitati di promozione spesso coinvolgono diversi leader con aspettative non dichiarate.
- Costruisci relazioni con altri manager:
- Trova persone che promuovono con successo i membri dei loro team.
- Inizia costruendo amicizie e collaborando su progetti.
- Scopri di più sui comitati di promozione tramite conversazioni informali.
- Focalizzati sul percorso di promozione:
- Dedica tempo extra-lavorativo per creare una rete di contatti e imparare.
- Comprendi i criteri specifici per la promozione nella tua azienda.
- Punta sui tuoi punti di forza:
- Individua le tue competenze più forti come PM (es. scrittura, gestione degli stakeholder).
- Valorizza questi punti di forza per generare un impatto positivo oltre il tuo ruolo immediato.
- Metti in evidenza il tuo lavoro alle persone rilevanti che possono influenzare le decisioni di promozione.
- Criteri di promozione non scritti:
- Affinare le competenze di PM a diversi livelli [22:19]
- Approccio graduale:
- Inizia sperimentando all’interno del tuo team e dimostrando successo.
- Raccogli feedback dagli stakeholder e perfeziona il tuo approccio.
- Passaggi per migliorare nonostante le limitazioni:
- Analisi dei risultati delle feature:
- Analizza perché le feature hanno avuto successo o sono fallite, focalizzandoti sull’impatto per l’utente.
- Utilizza dati e insight degli utenti per raccontare una storia convincente.
- Questo dimostra la tua capacità di misurare il successo e informare le decisioni future (anche in un ambiente orientato alle feature).
- Valutare l’impatto:
- Crea un caso “steel man” con ipotesi ottimistiche per valutare il potenziale impatto delle feature prima di realizzarle.
- Questo aiuta a gestire le aspettative e identificare le feature che difficilmente porteranno ai risultati desiderati.
- Scoperta (Discovery):
- Dopo la valutazione dell’impatto, effettua una corretta ricerca utenti per validare il problema e le possibili soluzioni.
- Utilizza strumenti come Dovetail per condividere in modo efficiente i risultati della ricerca con gli stakeholder.
- Questo dimostra un approccio allo sviluppo prodotto guidato dai dati.
- OKR (per GPM):
- Implementa gli OKR una volta che il tuo team ha dimestichezza con discovery e valutazione dell’impatto. (Vedi anche: roadmap OKR)
- OKR efficaci si basano su dati concreti e sulla corretta identificazione del problema.
- Alberi OKR (per GPM):
- Usa gli alberi OKR per collegare gli OKR a problemi e soluzioni specifici.
- Questo assicura coerenza tra obiettivi e iniziative intraprese per raggiungerli.
- Strategie di prodotto (per GPM):
- Sviluppa strategie di prodotto solo dopo aver ottenuto il controllo sull’intero processo di definizione degli OKR e sulle soluzioni.
- Una vera strategia di prodotto richiede la proprietà della roadmap e la capacità di trasformare i problemi in soluzioni.
- Analisi dei risultati delle feature:
- Punta a costruire solide competenze di product management in modo da dimostrare valore anche in un ambiente feature factory. Con il tempo, guadagna influenza e controllo sul processo di sviluppo prodotto.
- Approccio graduale:
Tutti pensano che il product management riguardi la strategia di prodotto, ma non credo sia possibile scrivere veramente una strategia di prodotto finché non hai il controllo sull’intero albero OKR. Fino ad allora, in pratica, è il CEO che definisce la tua strategia di prodotto. Solo quando sei completamente responsabilizzato allora puoi integrare la strategia di prodotto.
Aakash Gupta- Costruire una Coalizione e Applicazione nella Vita Reale [28:58]
- Identificare i decisori chiave – Nel caso di Aakash in Epic Games, erano i lead engineer e designer rispettati dal direttore.
- Comprendere le loro priorità e sfide – Gli ingegneri e i designer davano valore al riconoscimento per il loro duro lavoro e desideravano vedere l’impatto dei loro sforzi.
- Adattare il proprio approccio alle loro esigenze – Aakash utilizzava report dei risultati delle funzionalità per mostrare l’impatto delle feature passate e inserire in modo sottile metriche di performance.
- Fornire valore prima di fare richieste – Sottolineando i risultati positivi del loro lavoro, Aakash si è guadagnato la fiducia e la disponibilità a recepire i suoi suggerimenti riguardo ai miglioramenti delle performance.
- Concentrarsi sul costruire relazioni nel tempo – Aakash ha costruito strategicamente nel tempo il rapporto con le persone chiave per influenzare il processo di sviluppo prodotto.
- Errori Comuni negli Ambienti Feature Factory [32:35]
- Inseguire solo metriche di output: concentrati anche su risultati (impatto sugli utenti) oltre che sulle metriche dettate dalla feature factory. Non perdere il buon senso del prodotto.
- Trascurare il debito tecnico: gestisci sia il debito tecnico accidentale (user experience) che quello intenzionale (grande funzionalità). Dai priorità all’affrontare parte di quello accidentale per mantenere la velocità.
- Ignorare i feedback degli utenti: richiedi attivamente feedback agli utenti e itera sui design prima di rilasciare funzioni.
- Lasciare che la FOMO guidi la roadmap: non inseguire tendenze o funzionalità dei competitor. Utilizza la valutazione dell’impatto per stimare il valore potenziale di nuove feature prima di costruirle.
- Sovraccaricare il tuo team: spingi per strumenti, formazione & sviluppo, e team building per mantenere alta la motivazione.
- Perdere di vista il quadro generale: Sviluppa capacità di strategia di prodotto e usale per influenzare la roadmap, anche se in modo limitato. Punta a funzionalità ad alto impatto che apportino benefici significativi all’azienda.
Conosci il nostro ospite
Aakash è passato dal ruolo di PM in una piccola startup B2B SaaS a VP of Product in una Unicorn in 15 anni. Lavorando in realtà come Affirm, Epic Games e Apollo.io, ha maturato una profonda esperienza nella Product Management. Ha anche costruito uno dei più grandi seguiti in assoluto, con oltre 206.000 follower su LinkedIn. Ora scrive a tempo pieno la newsletter Product Growth, dove conduce ricerche approfondite per condividere settimanalmente insight utili per il successo dei PM.

Anche se lanciare in fretta è importante, credo che un team ben motivato e in salute tenda a produrre i risultati migliori.
Aakash GuptaRisorse da questo episodio:
- Iscriviti a The CPO Club newsletter
- Collegati con Aakash su LinkedIn e X
- Dai un’occhiata al sito web di Aakash
- Scopri The Product Growth Newsletter
Articoli e podcast correlati:
- Aakash ha rinunciato ad approcci idealistici per trasformare le feature factory dopo aver vissuto insuccessi in diversi ambienti:
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.
