In questo episodio, analizziamo il fenomeno della "feature factory", ovvero quando le aziende si concentrano maggiormente sul rilascio rapido di prodotti e funzionalità invece di dare priorità alla qualità o alle reali esigenze degli utenti. John Cutler ha coniato questo termine, che descrive perfettamente la sensazione che vivono molti team: lanciare funzionalità senza una chiara comprensione di chi siano destinate o di come impattino sull’azienda. Se ti ritrovi in questa situazione, continua ad ascoltare mentre esploriamo come uscire da questo ciclo.
Nella nostra tavola rotonda, ascoltiamo tre leader di prodotto—Aakash Gupta, Andrea Saez e Paweł Huryn—che condividono le loro idee su come passare da uno sviluppo prodotto orientato all’output a uno guidato dagli outcome. Propongono strutture pratiche per mantenere il focus strategico, affrontare le pressioni del mercato mid-market e favorire una cultura che valorizzi risultati significativi invece del semplice volume di funzionalità. Che tu stia espandendo un’azienda o cercando di riaccendere la creatività del tuo team, questa conversazione offre consigli pratici per abbandonare la mentalità della feature factory.
Punti salienti dell’intervista
- Sezione 1: Perché le Feature Factory Sono Diffuse [02:21]
- Non esiste un solo percorso che porta al problema della "feature factory"—i fattori che contribuiscono sono molteplici.
- Le cause includono la pressione per chiudere le vendite, una scarsa leadership di prodotto, l’influenza del "hippo" (l’opinione della persona più pagata) o il continuo inseguimento di nuove mode.
- Il problema alla radice è spesso la mancanza di un’influenza strategica da parte di un forte product leader.
- I leader di prodotto devono guidare la strategia, gestire i compromessi e negoziare le priorità.
- A volte i compromessi sono necessari (es. realizzare funzionalità per generare ricavi), ma è fondamentale riallinearsi con la strategia di prodotto subito dopo.
- Evitare una feature factory non è una questione di bianco o nero—si tratta di mantenere un focus strategico a lungo termine nonostante le inevitabili concessioni.
- Spesso si idealizzano le grandi aziende tech (es. Google, Meta) come esempi perfetti di gestione prodotto.
- In realtà, le funzionalità di maggiore impatto in queste aziende sono di solito guidate dai top manager, non scoperte dai PM.
- Un continuo processo di scoperta prodotto da parte dei PM è raro in questi ambienti.
- Molte delle migliori aziende lavorano più come feature factory di quanto si pensi.
- Anche aziende come Apple e Snapchat hanno uno sviluppo delle funzionalità dall’alto verso il basso.
- I PM dovrebbero imparare a navigare ed essere efficaci in situazioni da feature factory, che sono comuni almeno in parte del tempo.
- Le grandi aziende tech possono permettersi di correre rischi e "rilasciare per imparare" grazie ai loro ingenti budget.
- La maggior parte delle aziende non ha questo privilegio e non può assorbire lo stesso livello di rischio.
- Imitare il mindset "move fast and break things" può essere dannoso per le aziende più piccole o con meno risorse.
- Cercare di operare come Google o Facebook senza averne le risorse è irrealistico.
- Le aziende più piccole devono essere più caute e strategiche nelle decisioni di prodotto.
Ci sono negoziazioni e concessioni che devono essere fatte, ma la cosa importante è avere un product leader in grado di dire: "Ok, lo abbiamo fatto. Ora riportiamoci alla nostra strategia, a ciò che realmente vogliamo fare e risolvere."
Andrea Saez
- Essere una Feature Factory è sempre sbagliato? [07:21]
- Essere una feature factory non è intrinsecamente negativo—può avere senso a seconda del modello di business.
- Non tutte le richieste di funzionalità richiedono una profonda attività di discovery; alcune sono ovvie (es. integrazione Stripe).
- Gli stakeholder spesso hanno informazioni preziose che i PM non dovrebbero ignorare.
- È uno spreco non valorizzare la conoscenza già presente in azienda quando arrivano nuovi PM.
- In alcuni modelli (es. cliente-fornitore), realizzare le funzionalità richieste è un modo legittimo di fare business.
- Se il modello aziendale si basa su questo, è meglio accettarlo o cambiare azienda, piuttosto che provare a modificarlo.
- Sezione 2: Strade per uscire dalla Feature Factory [09:15]
- Segnali di perdita di product-market fit includono feedback negativi, alto tasso di abbandono e cicli di vendita più lunghi.
- Queste pressioni spesso portano a decisioni affrettate sulle funzionalità mirate a salvare contratti o clienti.
- Questo approccio reattivo può compromettere la coerenza del prodotto.
- Le funzionalità possono diventare sconnesse e la UX ne risente—Andrea critica ironicamente strumenti come Jira come esempi.
- La causa principale è spesso un indebolimento del product-market fit che innesca uno sviluppo guidato dal panico.
Se i team non sono allineati su come creiamo valore, a quali clienti vogliamo rivolgerci, quali problemi vogliamo affrontare e cosa distingue quello che stiamo costruendo, allora potrebbe essere estremamente difficile generare valore tra i vari team.
Paweł Huryn
- Intervento precoce nel Product Management [10:35]
- Inizia con un chiaro allineamento strategico in tutta l’organizzazione: definisci come viene creato il valore, chi sono i clienti target e quali problemi si stanno risolvendo.
- Assicurati che tutti comprendano l’approccio unico dell’azienda e il contesto strategico ("contesto, non controllo" secondo Netflix).
- Allinea gli obiettivi di team e dipartimenti con le principali priorità dell’organizzazione.
- Responsabilizza i team dando loro problemi significativi da risolvere e risultati desiderati, invece di prescrivere soluzioni.
- Fornisci coaching se necessario per aiutare i team ad adottare pratiche di continua scoperta di prodotto.
- "Feature factory" (fabbrica di funzionalità) è un termine negativo, ma è importante individuare e affrontare gli elementi distruttivi che comporta.
- Focalizza i dirigenti sulle aree di business giuste, sulle metriche e sui problemi degli utenti per creare il massimo impatto.
- Porta ai dirigenti le giuste informazioni, inclusi insight sugli utenti (ad es. replay di sessioni, analisi) e dati basati su metriche oggettive (ad es. opportunità di crescita).
- Questi insight aiutano a guidare l’attenzione sulle metriche e sui problemi importanti, in allineamento con la strategia complessiva.
- Permetti ai team (designer, PM) di iterare e adattarsi in base al feedback degli utenti, invece di seguire rigidamente i piani dei dirigenti.
- Implementa checkpoint e riunioni di revisione prodotto per tenere i dirigenti coinvolti nel processo ed evitare il problema del "passaggio di consegne" in cui un loro design non viene poi accettato.
- Allineare il team è fondamentale: assicurati che l'allineamento sia reale, non solo un accordo superficiale.
- L’allineamento con i dirigenti è essenziale; tutti devono essere sulla stessa linea su cosa viene fatto, perché, come e per chi.
- La disallineamento spesso si verifica sul cliente target (ICP), perché i team possono cercare di vendere a pubblici differenti.
- Questa disallineamento può portare ad aggiungere funzionalità che in realtà non rientrano nel prodotto o nel pubblico principale.
La cosa più importante che puoi fare in un’azienda non è focalizzarti sulla parte giusta del business. Si tratta di riuscire a far concentrare il tuo team dirigenziale sulle parti, le metriche e i problemi degli utenti che contano davvero. Si tratta di portare informazioni che stabiliscono la tua credibilità nel processo.
Aakash Gupta
- Rilascio di funzionalità imperfette [17:02]
- A volte le aziende rilasciano funzionalità imperfette con l’intento di migliorarle in seguito, ma rimangono bloccate in un ciclo da "feature factory", senza mai tornare a perfezionare quelle funzionalità.
- Paweł ritiene che rilasciare funzionalità imperfette (ad esempio che risolvono il 70-80% del problema) sia spesso l’approccio giusto.
- Rilasciare in anticipo permette di ottenere feedback preziosi dagli utenti e la possibilità di migliorare in base a dati reali, invece che su supposizioni.
- Anche dopo aver testato i design, l’interazione reale degli utenti può fornire insight diversi, rendendo importanti i rilasci iterativi.
- Rilasciare con intenzione è importante: non tutto deve essere perfetto.
- Un problema comune è rilasciare funzionalità "incomplete" e non tornare più a migliorarle, cadendo così nella trappola delle feature.
- I team possono concentrarsi solo sulle nuove funzionalità senza affrontare le basi di usabilità o migliorare quelle esistenti.
- Si tende a pensare che gli utenti capiranno da soli funzionalità non terminate, invece di perfezionarle.
- Il problema della "feature factory" consiste nel rilasciare funzionalità incomplete e non tornarci mai sopra a causa della "sindrome del nuovo oggetto".
- Per uscire da questo circolo vizioso, porta ai dirigenti insight sugli utenti (ad es. bassa retention, bassa adozione) e dati guidati dalle metriche (ad es. replay delle sessioni, tassi di retention).
- Mettere in evidenza problemi come una scarsa adozione può aiutare ad ottenere supporto per iterare sulle funzionalità o affrontare problemi di retention.
- In certi casi è meglio eliminare funzionalità che non soddisfano le esigenze fondamentali degli utenti.
- Soprattutto nel B2B, concentrarsi sul prodotto principale è spesso più efficace che cercare di espandere troppo presto su più prodotti.
- Sezione 3: Siamo in modalità fabbrica, e ora? [21:31]
- Come leader di prodotto (ad esempio, VP di Prodotto o CPO), il ruolo è identificare e affrontare le carenze organizzative, non solo celebrare i successi.
- Il lavoro prevede la valutazione delle prestazioni passate, l’analisi delle funzionalità lanciate e la determinazione se abbiano avuto successo o meno.
- Se il 75% delle funzionalità ha fallito, è essenziale ripensare l’approccio e adattare la strategia per il futuro.
- I grandi leader di prodotto parlano il linguaggio degli stakeholder, utilizzando dati e approfondimenti per influenzare le decisioni, non solo la teoria.
- La mancanza di una forte leadership di prodotto può contribuire al problema della feature factory.
- In situazioni difficili con founder o CEO poco collaborativi, può essere necessario valutare il passaggio a un nuovo ruolo per la crescita professionale.
- Un CPO o VP di Prodotto ha bisogno del supporto e dell’allineamento del CEO e dei dirigenti C-level per essere efficace.
- Senza allineamento C-level, è difficile fare progressi e uno sviluppo guidato dalle vendite può indebolire la leadership di prodotto.
- Concentrarsi su comportamenti degli utenti misurabili è fondamentale; le funzionalità dovrebbero incentivare azioni ripetibili, scalabili e di valore.
- Molte funzionalità vengono rilasciate solo per consegnare, senza considerare se risolvono davvero i problemi degli utenti o aggiungono valore.
- Esiste anche una considerazione etica su come le nuove funzionalità impattano la vita e i flussi di lavoro degli utenti.
- I product manager senza grande influenza possono comunque promuovere cambiamenti all’interno dei loro team, anche se non possono cambiare l’intera organizzazione.
- In un ruolo passato, Paweł ha guidato un’iniziativa che si è allontanata dal rigido framework Agile safe (che considera simile al modello a cascata), evidenziando i problemi dell’approccio esistente.
- Hanno proposto esperimenti e lavorato con un team principale e collaboratori usando un metodo più Agile, che si è rivelato efficace per la loro iniziativa.
- Anche se l’intera organizzazione non è cambiata, l’approccio ha funzionato bene per la specifica iniziativa.
- Andrea riconosce il duro lavoro necessario per portare il cambiamento in un’organizzazione, come menzionato da Paweł.
- Esprime ammirazione per lo sforzo richiesto per implementare le trasformazioni e per il costo emotivo che ciò può avere sul benessere e sulla salute mentale.
- Nonostante le difficoltà, Andrea crede che una trasformazione di successo offra grandi opportunità di apprendimento una volta raggiunta.
- Sessione Domande & Risposte [28:28]
- Dal Feature Factory alla Creazione Continua di Valore [28:36]
- Passare da una feature factory alla creazione continua di valore per il cliente richiede di concentrarsi sul valore per il cliente insieme alla strategia di prodotto.
- Andrea sottolinea l’importanza di individuare, monitorare e focalizzarsi sul valore per il cliente, collaborando con stakeholder chiave come vendite, customer success e supporto.
- Il template del Piano di Creazione di Valore di Prodotto (VCP) aiuta ad allineare i team e a garantire una visione condivisa del valore.
- Le decisioni di prodotto non dovrebbero essere prese in isolamento; la collaborazione tra team è fondamentale per offrire valore.
- Favorire Discussioni Strategiche e Allineamento [29:53]
- Per promuovere l’allineamento attorno a un obiettivo di prodotto, inizia domandandoti se l’attuale obiettivo sia quello giusto e crea un processo collaborativo.
- Collabora con un analista o una terza parte per raccogliere dati e insight, assicurando che tutte le parti possano apprendere e discutere assieme.
- Utilizza strumenti come Miro per sessioni di brainstorming da remoto per valutare diverse metriche e obiettivi, discutendo vantaggi e svantaggi di ciascuno.
- Documenta le opzioni e i feedback durante le discussioni, coinvolgendo team chiave come data science, PM, designer e ingegneri.
- Concludi con una riunione finale per decidere l’obiettivo, assicurando che tutti possano contribuire e concordare, anche se richiede più tempo.
- Affrontare la Disconnessione tra Insight e Funzionalità [32:02]
- La situazione riguarda insight non collegati e un product manager che propone velocemente funzionalità senza una corretta validazione.
- Paweł suggerisce di fare un reverse engineering del problema che le funzionalità dovrebbero risolvere e di validare tali ipotesi.
- Raccomanda di assicurarsi che il problema sia in linea con gli obiettivi e le strategie più ampie dell’organizzazione.
- Un membro del team, diverso dal product manager, dovrebbe esaminare le incongruenze tra i dati di analytics e le funzionalità in fase di sviluppo.
- Andrea è d’accordo con Paweł, sottolineando due domande chiave: "Quale problema stiamo cercando di risolvere e perché?" e "Per chi lo stiamo risolvendo?"
- Condivide la sua esperienza con un team di prodotto focalizzato sulla velocità di rilascio senza una chiara motivazione.
- Andrea suggerisce di chiedere al team di spiegare il problema e il processo decisionale per comprendere meglio il valore.
- Usando un outline sul problema di prodotto, incoraggia i team a considerare l’impatto sul business, il valore per il cliente e lo scopo delle loro azioni.
- Feature Factory in Tutte le Fasi Aziendali [34:47]
- Aakash suggerisce che le feature factory possono esistere in qualsiasi fase del ciclo di vita aziendale, anche in grandi aziende di successo.
- Le aziende in fase iniziale possono sentire la necessità di copiare prodotti di successo, portando a comportamenti simili a una feature factory.
- La questione chiave è se la feature factory sta impedendo il ROI; i PM dovrebbero valutare se il loro lavoro genera abbastanza valore per l’azienda.
- Tendenze da feature factory possono essere presenti sia in piccole startup che in grandi aziende come Meta o OpenAI.
- Valore del Background Ibrido Business & Tecnico del PM [37:23]
- Andrea ritiene che i product manager con un background ibrido business e tecnico abbiano una migliore comprensione del ROI e dell’impatto sulle vendite.
- I PM esclusivamente tecnici possono focalizzarsi di più sugli aspetti tecnologici e trascurare aspetti di business come il modo in cui le funzionalità vengano vendute o il loro impatto sul ROI.
- Un esempio chiave è considerare come una funzionalità sarà venduta e a quale segmento di clientela (ad esempio, enterprise vs. individuale), aspetto che i PM tecnici spesso trascurano.
- I PM con orientamento business tendono a integrare già in partenza la prospettiva tecnica e di vendita.
- Aakash suggerisce di valorizzare il background business focalizzandosi su impatto e modelli di crescita.
- I PM con background business dovrebbero mettere in risalto i propri punti di forza, come la stesura di ottime descrizioni di funzionalità o l’analisi dell’impatto.
- I PM tecnici possono acquisire competenze di business nel tempo, quindi è meglio concentrarsi sui punti di forza personali piuttosto che confrontarsi con gli altri.
- Il ruolo di PM permette flessibilità per adattarsi e sfruttare i propri punti di forza, come utilizzare Excel per l’analisi dati se questo è un punto di forza.
- Dall’Insight agli Item di Backlog [40:10]
- Paweł sottolinea l’importanza di sfruttare insight provenienti da diverse fonti, come interviste ai clienti, stakeholder, ricerche di mercato e data analytics.
- Evita di aggiungere storie utente o funzionalità al backlog prematuramente, preferendo completare la fase di discovery e testare le ipotesi prima.
- Gli insight vengono organizzati in un backlog separato o in un tool (come Miro), collegandoli ai bisogni degli utenti prima di trasformarli in user story.
- Gli item in backlog da più di 12 mesi vengono archiviati per mantenere il backlog gestibile; gli elementi importanti torneranno a galla se necessario.
- Dal Feature Factory alla Creazione Continua di Valore [28:36]
Incontra i nostri ospiti
Aakash Gupta è un esperto leader di prodotto con oltre 15 anni di esperienza, avendo ricoperto ruoli chiave come VP of Product presso Apollo.io, dove ha contribuito alla crescita dell'azienda fino a una valutazione di 1,2 miliardi di dollari. Ha inoltre guidato le funzioni di crescita prodotto in aziende come thredUP, Affirm ed Epic Games. Aakash è l’autore della newsletter "Product Growth", una delle più grandi al mondo nel suo settore, offrendo approfondimenti su product management, leadership e sviluppo di carriera a oltre 160.000 iscritti. È anche autore di "The Ultimate Guide to Getting a PM Job", che fornisce strategie complete per aspiranti product manager. Aakash partecipa attivamente alla comunità del product management attraverso interventi, podcast e corsi online, condividendo la sua ampia conoscenza per aiutare gli altri a raggiungere il successo nel settore.
Se sei il VP of Product, il Chief Product Officer, o qualunque sia il tuo titolo, e sei la persona al vertice, fondamentalmente, se svolgi bene il tuo lavoro, stai sempre segnalando tutte le carenze nella tua organizzazione e tutti i problemi che devono essere risolti. Questo è in realtà il lavoro.
Aakash Gupta
Paweł Huryn è il fondatore e autore di The Product Compass, una newsletter ampiamente apprezzata che fornisce approfondimenti e risorse pratiche a oltre 105.000 product manager in tutto il mondo. Con più di 15 anni nel settore tecnologico, di cui cinque come Chief Product Officer e oltre un decennio nel product management, Paweł si è affermato come una delle voci principali del settore. La sua esperienza comprende product discovery, strategia e integrazione dell’IA nel product management. Oltre alla scrittura, Paweł si impegna nella comunità attraverso conferenze, corsi online e una partecipazione attiva su piattaforme come LinkedIn e YouTube. Il suo impegno nel semplificare temi complessi e fornire indicazioni pratiche lo ha reso un mentore affidabile sia per aspiranti sia per esperti product manager.
Puoi anche influenzare molte cose all'interno del tuo team. Quindi, non limitarti a chiedere il permesso: inizia a collaborare con i tuoi designer e invita i tuoi ingegneri a partecipare al brainstorming sulle soluzioni, invece di preparare tutto in anticipo e parlare da solo con i clienti.
Paweł Huryn
Andrea Saez è una professionista esperta di product marketing con oltre un decennio di esperienza nell’unire sviluppo prodotto e coinvolgimento dei clienti. Ha ricoperto ruoli di rilievo in startup e scale-up come ProdPad, airfocus e Trint, dove si è concentrata su strategia, posizionamento e collaborazione tra team. Andrea è coautrice di "The Product Momentum Gap", un libro che esplora l’allineamento della strategia prodotto con il valore per il cliente. È anche una speaker e autrice attiva nella comunità del product management.
Puoi essere il miglior CPO, il miglior VP of Product, puoi cercare di fare tutto nel modo giusto, ma se non hai il supporto del tuo CEO e del resto dei dirigenti di livello C, non arriverai da nessuna parte.
Andrea Saez
Risorse da questo episodio:
- Iscriviti alla newsletter di The CPO Club
- Connettiti con Aakash, Paweł e Andrea su LinkedIn
- Scopri la Product Growth Newsletter, la Product Compass Newsletter e The Product Momentum Gap
Articoli e podcast correlati:
Leggi la trascrizione:
Stiamo testando la trascrizione dei nostri podcast tramite un programma software. Per favore perdona eventuali errori di battitura, dato che il bot non è corretto al 100% delle volte.
Hannah Clark: Fabbrica delle funzionalità—sostantivo; un’azienda che rilascia costantemente prodotti, funzionalità e miglioramenti, ma si concentra principalmente sulla quantità piuttosto che sulla qualità. Origine, John Cutler. Usato in una frase: “Abbiamo lanciato tre nuove funzionalità questo trimestre, e non so a chi siano destinate. Sta iniziando a sembrare una fabbrica delle funzionalità.” Se questa definizione ti sembra familiare, continua ad ascoltare.
Durante il nostro recente evento panel, “Tutte le strade portano alla Fabbrica delle Funzionalità?”, abbiamo riunito tre leader di prodotto che hanno osservato questo fenomeno da diverse prospettive. Aakash Gupta—già VP of Product presso un unicorno, attualmente autore di ‘The Product Growth Newsletter’, Andrea Saez—leader nel marketing di prodotto e autrice di ‘The Product Momentum Gap’, e Paweł Huryn—autore di ‘The Product Compass Newsletter’.
Condividono la scomoda verità sul riconoscimento del pensiero orientato all’output anziché all’outcome, presentano modelli pratici per mantenere il focus strategico e gestire le pressioni del mid-market, e framework concreti per trasformare il team da realizzatore di funzionalità a creatore di valore sui risultati.
Che tu stia cercando di crescere oltre i cento milioni di ARR o semplicemente di ridare slancio innovativo al tuo team, considera questa conversazione il tuo pass per uscire dalla mentalità da fabbrica delle funzionalità. Partiamo subito.
A proposito, teniamo discussioni come questa ogni settimana, quindi se ti sembra interessante, perché non iscriverti? Bene, iniziamo davvero.
Cominciamo ora la nostra discussione guardando alcuni risultati preliminari dei sondaggi. Sembra che ci sia una divisione piuttosto equa tra chi considera la propria organizzazione una fabbrica delle funzionalità e chi non ne è così sicuro. Affronteremo questo aspetto dando una definizione precisa.
Penso che sia utile per tutti allinearci sul significato di “fabbrica delle funzionalità”. Secondo la definizione utilizzata, credo coniata da John Cutler. Una fabbrica delle funzionalità è un’azienda che rilascia costantemente prodotti, funzionalità, miglioramenti, ecc., ma si concentra principalmente sulla quantità piuttosto che sulla qualità.
Quindi, si presta attenzione all’output più che all’outcome. Quello che suggeriamo è che siamo in una situazione in cui lanciamo molte funzionalità, ma non è sempre chiaro se queste abbiano un vero valore di business o se risuonino davvero con i nostri utenti.
Ovviamente, questo può portare a diversi problemi. Affronteremo tutto questo in tre sezioni. Sezione uno, perché la fabbrica delle funzionalità è così diffusa. Sezione due, le strade che ci portano fuori dalla fabbrica delle funzionalità. E sezione tre, siamo in modalità fabbrica: e ora?
Iniziamo con la sezione uno. Prima domanda, la passo ad Andrea. Come fanno organizzazioni ben intenzionate a diventare fabbriche delle funzionalità? Come può svilupparsi questa situazione?
Andrea Saez: Essere onesti, non esiste un solo percorso. Me lo chiedono spesso: come si può prevenire? Ci sono molte strade per arrivare lì.
Tutto parte dal voler chiudere una vendita, dalla mancanza di un buon leader di prodotto, o di un Head of Product, o VP di prodotto. Potrebbe essere un effetto “HIPPO”, o la sindrome dell’oggetto luccicante. Ci sono molte ragioni, ma la problematica di fondo è spesso la mancanza di influenza da parte del leader di prodotto, che dovrebbe essere in grado di definire una strategia e dire: ecco cosa facciamo e perché.
Devi anche essere capace di negoziare quando occorre rilasciare una funzionalità per determinate ragioni, riuscendo però a riportare poi il team sulla strategia. La realtà è che, per quanto mi piacerebbe affermare il contrario, è impossibile evitare sempre la fabbrica delle funzionalità.
Capiterà a tutti nella carriera e nel percorso aziendale di dover accettare dei compromessi e dire: va bene, costruiamo questa funzione perché ci serve il fatturato. Quindi non è una situazione sempre bianca o nera.
Ci sono negoziazioni e compromessi, ma la cosa importante è avere un leader di prodotto che sia in grado di dire: ok, l’abbiamo fatto, ora torniamo alla nostra strategia e alle vere problematiche che vogliamo risolvere.
Hannah Clark: Aakash, vuoi aggiungere qualcosa? Ricordo che una tua considerazione mi ha ispirata, sembra quasi che tutte le strade portino davvero alla fabbrica delle funzionalità. Qual è la tua esperienza?
Aakash Gupta: Credo che spesso pensiamo: ci sono aziende straordinarie là fuori, nella Silicon Valley, come Google, Netflix, Meta, che fanno prodotto nel modo giusto. Se lo facciamo come loro, risolveremo tutti i nostri problemi. Ma parlando con PM di queste aziende, chiedo: qual è la funzionalità più importante realizzata l’ultimo trimestre?
Rispondono: X o Y. Ma come sono nate queste funzioni? Chi le ha decise? In quelle aziende, tutte le funzionalità d’impatto sono decise dal team esecutivo, dopo mesi di dibattiti. Non c’è una vera discovery continua dal basso in cui il PM parla con gli utenti ogni due settimane e tira fuori soluzioni innovative che nessuno a Google o Meta aveva mai pensato.
Non succede. Quindi tendiamo a sovrastimare cosa accade in queste aziende; anche posti come Apple, o Snapchat, dove il CEO, Evan Spiegel, e pochi designer decidono tutto.
È una pura fabbrica delle funzionalità. Quindi molte strade portano a un ambiente simile. Anche se non sempre, come diceva Andrea. A volte c’è una richiesta di vendita, o del customer success, o altro.
Dobbiamo imparare a gestire la situazione quando ci troviamo nella fabbrica delle funzionalità.
Andrea Saez: Possiamo essere un po’ controversi? Sono d’accordo con Aakash, ma credo sia importante sottolineare che le aziende che lui ha citato hanno budget tali da poter assorbire il rischio.
Possono permettersi di rilasciare solo per imparare. La maggior parte invece non può: se operano come Google o Apple, e adottano il “Basta rilasciare”, per la maggior parte è un errore, come il famoso “Move fast and break things” di Facebook. La cosa peggiore, perché non siete Facebook. Anzi, la maggior parte non lavora nemmeno nei “FANG” e comunque possono permetterselo. Io no. Devo muovermi in modo più intelligente.
Hannah Clark: Ora abbiamo una panoramica su come nascono queste situazioni e chi può permettersele.
Se pensiamo a una scala tra buono e cattivo, essere una fabbrica delle funzionalità è sempre negativo? O può funzionare in certi casi? Esistono alternative realistiche?
Paweł Huryn: Non sono del tutto d’accordo sul fatto che si debbano sempre fare concessioni quando si parla con gli stakeholder o si esaminano le richieste di funzionalità degli utenti. In certi casi è lampante, come integrare Stripe perché richiesto. Possiamo tentare di razionalizzare, ma a volte l’esplorazione del problema è superflua. In altri casi, gli stakeholder hanno intuizioni che un PM può perdere.
Non mi piace scartare del tutto le loro idee. Ho visto PM che, appena arrivati, iniziano subito a sentire gli utenti, ignorando però conoscenze già acquisite all’interno.
Alla fine, le aziende devono guadagnare: a volte fare ciò che i clienti chiedono, anche se ai team di prodotto non piace, è un modo legittimo per fare business. In quei casi, possiamo sempre decidere di cambiare azienda invece di provare a cambiarla.
Hannah Clark: Altra faccia della medaglia: se tiene in piedi il business, a volte si deve accettare.
Rivolgiamoci di nuovo ad Andrea. Passiamo alla sezione due: le strade che portano fuori dalla fabbrica delle funzionalità. Abbandoniamo il giudizio e passiamo a valutare se un’organizzazione sta sovrainvestendo sul breve termine a discapito del valore di lungo periodo. Come trovare l’equilibrio?
Andrea Saez: I primi segnali sono tanti feedback negativi, alto churn, cicli di vendita più lunghi. Sono indicatori che il product market fit sta vacillando. È di solito questo il momento in cui si decide di lanciare funzioni per salvare clienti o chiudere contratti—e da lì si perde il controllo.
Poi iniziano a spuntare strumenti vari, Jira, mille funzionalità… hanno senso? Sono adatte al pubblico? La UX è sensata? Può la gente usare facilmente l’interfaccia? Ma generalmente questi segnali arrivano quando il product market fit inizia a disperdersi.
Hannah Clark: Passiamo alla prevenzione. Se notiamo segni di deriva, quali bilanciamenti e controlli possiamo introdurre per restare focalizzati sul valore e la vision? Assumendo che si abbia qualche influenza sul percorso, cosa fare in concreto?
Paweł, cominci tu?
Paweł Huryn: Inizierei allineando tutta l’organizzazione sulla strategia. Se i team non sono allineati su come creiamo valore, quali clienti/vogliamo servire, che problemi vogliamo risolvere, cosa ci differenzia… sarà difficile dare valore.
Quindi prima di tutto l’allineamento strategico; ognuno deve conoscere il contesto. Netflix lo chiama “contesto, non controllo”. Poi, allineare i team sugli obiettivi chiave, in modo che possano legarsi alle priorità aziendali di trimestre o anno. Serve empowering dei team, a volte con coaching su discovery continua.
In sostanza: vogliamo dare ai team problemi significativi da risolvere, outcome chiari da raggiungere, così da scoprire come dare valore ai clienti—e quindi all’azienda.
Hannah Clark: Aggiungo che a Duolingo, ad esempio, hanno aree “intoccabili” concordate e usate come bussola decisionale. Può essere una strategia interessante.
Paweł Huryn: Questi sono punti essenziali. Non solo priorità, ma anche cosa non fare, clienti non serviti, strategie escluse—così tutti possono evitarle.
Hannah Clark: Qualche altro input dai panelist su controlli o prevenzioni per evitare la fabbrica delle funzionalità?
Aakash Gupta: Fabbrica delle funzionalità ormai ha accezione negativa. Ma il vero elemento dannoso è non concentrarsi su ciò che conta davvero.
Lato executive team, serve concentrarsi su metriche e problemi-utente che fanno davvero la differenza; portare insight mirati aiuta a costruire credibilità. In particolare, distinguo tra insight su utenti (session replay, analytics, dati, registrazioni di chiamate) e insight su dati (modello di crescita, opportunità economiche: “il 16% dei clienti non fa Y, se riusciamo a coinvolgerne il 50% ricaviamo X milioni”). Portando questi due tipi di insight, puoi orientare il focus dell’executive team.
Secondo, permette ai team (designer, PM) di iterare e cambiare direzione rispetto alle idee dei manager, coinvolgendoli in review periodiche. Così restano parte del processo e accettano i cambiamenti, piuttosto che imporre soluzioni sbagliate senza confronto utente.
Hannah Clark: Qualcun altro vuole aggiungere?
Andrea Saez: Totalmente d’accordo. L’unica cosa che aggiungerei: allineamento reale, davvero. Ho visto tanti team fallire perché si dice “siamo allineati” e una settimana dopo ognuno fa per conto suo. L’allineamento esecutivo deve partire dall’alto: tutti devono essere allineati su cosa, come, perché e soprattutto per chi lo stanno facendo. Spesso il “chi” è fonte di discordia e genera funzionalità fuori target.
Hannah Clark: Sulla domanda n.2: è anche vero che a volte le aziende rilasciano funzioni scollegate dalla visione nella speranza di tornare a migliorarle poi? Ma una volta partiti in modalità fabbrica, spesso non si torna più sulle funzioni lasciate a metà (“feature debt”). Commenti?
Paweł Huryn: Credo che lanciare funzioni non perfette sia esattamente ciò che si dovrebbe fare. Rilasciare qualcosa che copre l’80% dei casi principali e poi raccogliere feedback. In molte aziende il ciclo è: idea—rilascio—feedback—miglioria, spesso correggendo intuizioni iniziali. I dati di produzione veri possono essere diversi dai test teorici. Sono totalmente favorevole al rilascio iterativo di funzioni.
Hannah Clark: Andrea, come si inserisce questo nella strategia? Se hai meno budget devi essere più selettiva?
Andrea Saez: Concordo con Paweł: bisogna rilasciare con intenzione. Non tutto deve essere perfetto. Talvolta capita di promettere che si tornerà a migliorare una funzione, ma poi si passa subito a novità. Questo è il rischio: si cade nella trappola delle nuove funzionalità senza mai raffinare le basi (usabilità, semplificazioni). Spesso si presume che i clienti capiranno perché “la funzione c’è”.
Aakash Gupta: Tutti i commenti sono corretti. Brent e Todd pongono il problema chiave della fabbrica delle funzionalità: la sindrome dell’oggetto luccicante, funzioni lasciate a metà, mai migliorate, si passa sempre alla prossima. Una via d’uscita è portare insight sull’utilizzo reale all’executive team: esempio, dopo 100 session replay solo 3 click su una funzione; i dati dicono retention al 7%. Quindi o si itera per aumentare adozione/retention, o—spesso—serve eliminare funzioni che ostacolano il core dell’esperienza dell’utente (problema tipico nel B2B, aspiranti piattaforme a 10 milioni di ARR). Meglio focalizzarsi sul core.
Andrea Saez: Credo sia Pendo che ha dimostrato che l’80% delle funzionalità non viene usato. È un numero enorme.
Hannah Clark: Questo ci porta alla sezione finale: siamo in modalità fabbrica… e ora? Molti sono qui proprio perché lavorano già in una fabbrica delle funzionalità o temono di scivolare lì dentro.
Supponiamo che cambiare modello sia impossibile nel breve, per via delle dinamiche aziendali. Quali passi può compiere chi guida il prodotto per tornare a focalizzarsi sul valore?
Aakash Gupta: Se sei in posizione di leadership, tocca a te. Se sei VP di prodotto, CPO ecc., il tuo lavoro è chiamare fuori tutti i problemi dell’organizzazione. Non vantarsi dei rilasci, ma risolvere problemi aziendali. Quello della fabbrica delle funzionalità è tra i più sentiti.
Interroga il team: che strategia avevamo? Che funzioni avevamo promesso? Quanti di quei rilasci sono realmente riusciti? Se il 75% non ha avuto successo, vogliamo ripetere? Se no, come cambiamo?
Non comunicare in modo autoreferenziale, però. Non dire “Marty Kagan dice che dobbiamo valorizzare i PM”, ma parla la lingua degli stakeholder: traduci gli insegnamenti in soluzioni concrete per loro.
Spesso, però, anche il miglior VP non può nulla contro founder/CEO troppo accentratori. In quel caso occorre ragionare sul proprio percorso e valutare se cambiare azienda.
Andrea Saez: Proprio questo volevo aggiungere: puoi essere il miglior CPO o VP prodotto, ma senza il supporto del CEO e del C-level, non otterrai nulla. L’allineamento vero deve esserci a quel livello, dopo tutto scende più facile.
Ho lavorato con CPO totalmente privi di influenza, in realtà guidate dalle vendite. Inoltre, occorre focalizzarsi su comportamenti utente misurabili e scalabili, non solo su funzioni nuove. Bisogna chiedersi: è davvero di valore per il cliente? Aiuta davvero a risolvere un problema o lo complica?
Paweł Huryn: Concordo con quanto detto finora. Dal punto di vista di PM/team di prodotto senza potere, comunque spesso si può influenzare qualcosa, anche se non l’intera organizzazione. Nel mio caso, per iniziativa personale, siamo riusciti a usare Agile in un team e 4 team correlati, evitando il modello SAFE (che personalmente considero waterfall mascherato). Abbiamo analizzato i problemi storici, misurato gli insuccessi passati e proposto una sperimentazione cambiando il modello solo nel nostro team. In quel caso ha funzionato (non nell’intera azienda, ma almeno per l’iniziativa).
Hannah Clark: Grazie per la testimonianza da chi ha meno influenza: molti si ritrovano proprio lì e vogliono comunque dare impatto al proprio lavoro.
Paweł Huryn: Anche senza permessi si possono fare tante cose all’interno del team: collaborare con designer ed engineer, coinvolgerli nel brainstorming, parlare con i clienti senza aspettare sempre istruzioni dall’alto.
Andrea Saez: Una cosa che voglio aggiungere, sollevata da Paweł, è la quantità di fatica necessaria. Quando hai detto cosa avete fatto, mi ha colpito. Di solito nella mia carriera tendo a mollare e cambiare azienda, perché è davvero estenuante fare una trasformazione simile. Ma si impara molto.
Hannah Clark: È davvero un percorso prezioso da portare con sé, ovunque si vada dopo.
Se vuoi seguire gli speaker di oggi, sono tutti grandi esperti. Il libro di Andrea, “The Product Momentum Gap”, è su Amazon. Iscriviti alla newsletter di Aakash “Product Growth” e a quella di Paweł “Product Compass”. Troverai altre collaborazioni nei podcast ma soprattutto tanti contenuti utili dai tre panelist.
Passiamo ora alle domande dal pubblico. Primo: come si passa dalla fabbrica delle funzionalità alla creazione di valore continuo per utente e cliente, con reale impatto sul business? Accennato nella puntata ma riassumiamo.
Andrea Saez: Proprio di questo tratta il mio libro! Si parla di unire strategia di prodotto e valore per il cliente: come identificarlo, misurarlo, allinearci come team. Abbiamo un template chiamato “product VCP” (product Value creation plan), fondamentale perché—come spiegava prima Paweł—le decisioni non devono essere prese in isolamento dal team di prodotto. Va ascoltato anche sale, customer success, supporto… tutti devono partecipare al workshop così da capire insieme cos’è il valore e come consegnarlo.
Hannah Clark: Se vuoi vedere un esempio, ne abbiamo parlato anche nel podcast di un anno fa: “Come i leader di prodotto ostacolano la crescita aziendale”. Prossima domanda da Parker: che strumenti/metodi usate per stimolare discussioni strategiche e allineamento attorno a un obiettivo comune? Quali più efficaci?
Aakash Gupta: Per creare allineamento su un obiettivo, la cosa migliore è non proporre subito una soluzione, ma impostare il processo in modo collaborativo: concordare con chi non è convinto, arrivare insieme a definire l’obiettivo analizzando dati con un’analista o fonte terza super-respectata, quindi fare brainstorming strutturato (anche da remoto, es. con Miro), dichiarare pro e contro di ogni metrica/obiettivo, raccogliere feedback da chi ci lavora da tempo (PM, designer, engineer), confrontarsi di nuovo con l’analista, e solo alla fine (discussione congiunta) prendere una decisione condivisa. Serve più tempo, ma garantisce buy-in.
Hannah Clark: Sempre chiaro e preciso nel processo, grazie.
Domanda di Mikayla. Abbiamo una richiesta di revamp prodotto dal business e dal team UX, vogliamo capire pain point, insight, journey. Finora si è agito come fabbrica delle funzionalità: tante piattaforme, UI cucita da vari tool, il PM punta alla velocità ma non c’è una chiara direzione. Come uscirne?
Paweł Huryn: Qui è il PM a spingere feature non validate. È importante invertire il processo: chiedere quale problema si intende risolvere, esplorarlo, validarlo e verificarne l’allineamento alle priorità aziendali. Se serve, qualche membro del team può fare “reverse engineering” tra dati analytics e nuove funzionalità, cercando discrepanze e validando le assunzioni sottostanti.
Andrea Saez: Due domande magiche: che problema stiamo risolvendo e perché? E per chi? Non dimentichiamoci del “chi”. Ho vissuto una situazione simile: il team voleva solo rilasciare velocemente e io, da product marketer, ho semplicemente chiesto di spiegarmi problema e processo decisionale; solo così posso vendere la funzione. Far ragionare il team su queste logiche aiuta a reindirizzare l’attenzione e a rifocalizzare gli sforzi.
Hannah Clark: Ottimi suggerimenti. Andiamo avanti per questioni di tempo, ma grazie Mikayla per lo spunto.
Altra domanda da Brent. In teoria, man mano che un’azienda matura dovrebbe ridurre atteggiamenti da fabbrica delle funzionalità? Oppure può essere un segnale di mala gestione dei team prodotto?
Andrea Saez: Hannah, vorrei sentire la tua opinione.
Hannah Clark: Io sono outsider ma penso che inizialmente un’azienda dovrebbe essere tutto fuorché una fabbrica delle funzionalità: si ha un problema specifico da risolvere. La fabbrica delle funzionalità spunta quando, crescendo, si fanno compromessi per restare vivi. Quindi secondo me è più tipico nelle fasi di scaling.
Aakash Gupta: Credo che la percentuale sia simile in ogni fase. All’inizio si pensa “Copiamo l’altro prodotto, roadmap chiara” — anche quello è fabbrica delle funzionalità. Quindi può accadere in ogni fase. L’importante è capire cosa della fabbrica ci danneggia. La questione vera è: genero almeno il valore equivalente al mio stipendio? (Se prendo 150.000 dollari annui, genero almeno 150.000 dollari di profitto?). Se no, la fabbrica deve essere corretta. Su 100 aziende, almeno il 50% opera così. Anche aziende gigantesche (Meta) hanno PM realmente empowered, ma non sempre. Anche OpenAI ha innovazioni nate dal basso. In ogni fase esiste una quota importante in modalità fabbrica.
Hannah Clark: Domanda di Sahi: quali benefici aggiuntivi porta un PM con background ibrido business/tecnico rispetto a uno solo tecnico, considerando feature e design?
Andrea Saez: Secondo me, PM solo tecnici spesso perdono di vista il focus business: stiamo costruendo per vendere. Non dico che tutti debbano essere ossessionati dall’ROI, però chi ha base business ragiona subito su come le scelte impattano il business, mentre i tecnici rischiano di focalizzarsi troppo sugli aspetti tecnici. Esempio: spesso le domande su “come vendiamo questa funzionalità?” non vengono nemmeno poste. Una funzione Enterprise non serve allo stesso modo un individuo o startup. Non tutti arrivano a questo ragionamento se manca il background business.
Hannah Clark: Qualcuno vuole integrare?
Aakash Gupta: Penso che il punto sia: se hai esperienza business, spingi sulle skill di PM che generano impatto (costruisci il modello di crescita del team, dimensiona l’impatto di ogni feature, documenta bene i risultati); gioca coi tuoi punti di forza. I tecnici potranno imparare dal business, ma tu concentrati su come valorizzare i tuoi talenti (Excel per esempio). Il bello del ruolo è proprio modellarlo sui propri punti forti.
Andrea Saez: Concordo pienamente.
Hannah Clark: Todd chiede: Paweł, hai detto di valorizzare tutti gli insight. Ma quando trasformi insight in backlog item? Il backlog sembra il pavimento della fabbrica delle funzionalità. Consigliamo di archiviare item più vecchi di 12 mesi. Come la pensi?
Paweł Huryn: Non ricordo di aver detto di tenere proprio tutti gli insight, ma di usarli da tutte le fonti (utenti, stakeholder, analisi, survey). Quanto all’organizzazione, evito di mettere feature/storie utente nel backlog per i dev troppo presto. Prima discovery, test dei key assumption, poi—e solo se c’è confidenza—si passa alle user story vere e proprie. In pratica è come avere due backlog (anche diverso strumento, può essere anche Miro). Quando una cosa resta troppo tempo (es. oltre 100 item), archivio. Se serve davvero tornerà fuori.
Hannah Clark: Grazie a tutti per la partecipazione e un enorme ringraziamento ai nostri panelist per il tempo e gli spunti condivisi. Grazie di cuore a tutti, ci rivediamo presto.
Grazie per averci ascoltato. Per altri insight, guide e recensioni di strumenti, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altri episodi iscrivendoti a Product Manager ovunque trovi i tuoi podcast.
