Come Coltivare una Mentalità da Fondatore All’interno di un’Azienda Consolidata (con Brendan Fortune)
Leggi la Trascrizione:
Stiamo testando la trascrizione dei nostri podcast utilizzando un software. Per favore, perdona eventuali errori di battitura: il bot non è accurato al 100% delle volte.
Hannah Clark: Domanda onesta: secondo te quale ruolo è più difficile—essere il fondatore di una startup o essere il primo PM in quella startup fondata? Credo che si possa sostenere una tesi valida per entrambi, a seconda dell’esperienza passata. Quindi, anche se la domanda può sembrare soggettiva, penso possiamo concordare che entrambi i ruoli investano profondamente nel successo di un prodotto. Ma ecco il problema: il successo di un PM dipende anche dalla sua capacità di guadagnare e mantenere la fiducia della leadership. E se vuoi che un fondatore si fidi di te, forse dovrai iniziare a pensare come un fondatore.
Il mio ospite oggi è Brendan Fortune, Chief of Staff di Customer.io. Nel corso della sua carriera, Brendan ha visto in prima persona come adottare una mentalità da fondatore sia un grande vantaggio per i product manager, soprattutto in contesti da zero a uno. Tra poco lo sentirete condividere preziose intuizioni su come gestire le tensioni rispetto a risolvere problemi, fallire velocemente (e i suoi fallimenti preferiti), E il momento più emozionante del viaggio zero a uno. Cominciamo.
Bentornati a The CPO Club podcast.
Brendan, grazie per essere qui con noi oggi. Come va?
Brendan Fortune: Sto alla grande. Grazie Hannah per avermi invitato.
Hannah Clark: Puoi raccontarci qualcosa del tuo percorso e come sei arrivato dove sei ora in Customer.io?
Brendan Fortune: Sono sempre affascinato dalle storie delle persone perché di solito si fermano alla parte in cui fanno la transizione verso il mondo del prodotto. Quindi cercherò di raccontare la mia.
Ho iniziato nell’IT support quando ero al college a Los Angeles. Poi, dopo la laurea, sono stato fortunato. Un recruiter che non avevo mai conosciuto mi ha cercato per lavorare in una startup di 150 persone nel settore della voice-over IP. Un ambito molto tecnico. Così ho iniziato come supporto tecnico. E di notte scrivevo musica da film perché avevo ancora il sogno di Hollywood.
Col tempo, ho capito che la musica per film era più sana per me come hobby che come lavoro. Così ho lasciato. Mi sono iscritto a un MBA per lavoratori; per chi non li conosce, io non li conoscevo, è un tipo di percorso part time. Hai un lavoro a tempo pieno e poi vai anche a scuola: dura tre anni.
È lì che ho scoperto il product management, questa combinazione di competenze tecniche, creatività e leadership che mi ha davvero entusiasmato. Ho sfruttato l’MBA come leva per ottenere una posizione di junior product manager nell’azienda in cui ero già da quattro anni, prima nel supporto tecnico e poi nell’IT.
È stato difficile, complicato. All’inizio non volevano darmi il ruolo. Probabilmente avevano ragione, ma alla fine ho comunque svolto quel lavoro. Dopo qualche mese ci sono riuscito. Da lì sono uscito da quell’azienda come direttore prodotto. Ho fatto un’esperienza da GoDaddy nel loro reparto hosting.
Poi ho lavorato da Drip, piattaforma SaaS di marketing automation. Ora sono in Customer.io. Ho iniziato nel prodotto, ora da chief of staff il mio lavoro è creare sistemi organizzativi che aiutino i leader di engineering, prodotto e design a esprimersi al meglio. Qualunque cosa voglia dire. È una realtà complessa, quindi.
Hannah Clark: Oggi ci concentreremo sulla mentalità da fondatore e su cosa significa all’interno delle costrizioni di un’azienda consolidata. È un gioco molto diverso rispetto a una startup.
Per prima cosa, inquadriamo un po’ il nostro tema. Come definiresti tu una mentalità da fondatore, se dovessi riassumerla? E cosa significa davvero per te nella pratica?
Brendan Fortune: Questa è una domanda interessante perché, per me, a volte mi mette quasi a disagio sentire parlare di “mentalità da fondatore” tipo, non ho mai fondato una mia azienda. Allora posso avere una mentalità da fondatore? C’è qualcosa che non va in me?
Negli anni lavorando insieme a fondatori ho cambiato prospettiva. Per me, mentalità da fondatore vuol dire inclinazione a creare qualcosa di proprio invece di seguire quello di qualcun altro. Può essere un nuovo prodotto, una nuova filosofia, o un nuovo approccio alla gestione. Può essere qualsiasi cosa. Ma il comportamento che definisce è: davanti a una sfida, il tuo istinto è creare una soluzione tua o cercare risposte fuori da te stesso? La mentalità da fondatore è crearti la via d’uscita. Non vuol dire ignorare tutto il resto, ma essere scettici sulle idee degli altri finché non le hai davvero capite.
Questo per me è avere una mentalità da fondatore. Posso fare alcuni esempi: considerandone uno legato al prodotto, visto che siamo in un podcast di product manager. Quando fui assunto da GoDaddy, il leadership team mi disse: “Costruisci per noi un prodotto di cloud hosting”.
Erano ancora i primi tempi di Amazon Web Services. Google aveva appena iniziato. GoDaddy pensava di avere una possibilità. Tre mesi dopo sono tornato e ho detto: “No, non è l’idea giusta per il business”. Invece, dovremmo sviluppare servizi gestiti sopra AWS, che era un piano molto dibattuto. Ricordo che parlando con colleghi e capi c’era questa sensazione: “Ehi, non dovresti fare questo… quali sono le implicazioni politiche?”.
E penso che la mentalità da fondatore sia dire ciò che credi realmente, non solo ciò che pensi sia corretto o che qualcun altro pensa sia giusto se non lo capisci davvero. Succede anche in altri modi. Uno dei miei preferiti, molto nerd, viene dal mio ruolo da chief of staff: in Customer.io abbiamo un processo per cui i team customer facing, come support, customer success o sales, devono porre domande o segnalare problemi a engineering, prodotto e design. Bug o altro.
Per molto tempo avevamo un iter dove una persona creava un ticket, poi un engineering manager la assegnava a una squadra dopo revisione manuale. Un processo pesante: i ticket potevano restare fermi per ore o giorni. La decisione era: questa triage la dovrebbe fare un engineering manager o un altro umano, tipo tech support. Doveva esserci una revisione manuale. Penso che un altro esempio di mentalità da fondatore sia applicare nuova tecnologia.
In questo caso, abbiamo usato un semplice bot LLM su Zapier che, leggendo il ticket creato, lo abbina automaticamente all’area di competenza giusta, assegnandolo senza intervento umano. La quasi totalità dei ticket ora è prioritizzata istantaneamente, dove prima serviva molto tempo.
Quando ti trovi di fronte a un falso dilemma, tipo “deve funzionare così o cosà”, probabilmente c’è un’altra via, che una mentalità da fondatore aiuta a trovare.
Hannah Clark: Sì, direi che è enfasi sulla creatività e risorse limitate, su come ottenere di più con meno o trovare soluzioni innovative. Credo molto nell’idea che la creatività sia alimentata da vincoli. Quindi questa mentalità è molto vicina a ciò.
Approfondiamo e parliamo di mentalità da fondatore nei progetti prodotto “zero a uno”. Qual è la sfida principale che secondo te un PM deve affrontare quando cerca di lanciare un prodotto totalmente nuovo?
Brendan Fortune: Domanda bellissima. Inverto il punto di vista: credo che una delle sfide principali sia superare la mentalità da fondatore stessa, che può sembrare controintuitivo perché, se crei qualcosa di nuovo, devi pensare creativamente come un fondatore.
Ma c’è un pericolo: la mentalità da fondatore ti fa sentire troppo proprietario di ciò che hai creato. Hai mai sentito dire “questa è la mia creatura” parlando di un progetto? La proprietà può essere così intima. A volte lo si dice per scherzo, ma spesso è davvero così.
Se arrivi a sviluppare qualcosa da zero insieme a un team—che è l’unico modo che io conosco—devi fare di tutto per, diciamo, condividere il “viaggio genitoriale”. L’analogia regge: ci vuole un villaggio per crescere il prodotto. La sfida è proprio questa: facile cadere nella trappola del “devo avere io le idee, prendere tutte le decisioni”. Ma spesso questo porta più a fallimenti che a successi rispetto al lavorare in squadra. Quindi la sfida principale è andare avanti da soli. Per superarla bisogna avere le persone giuste sin dall’inizio: “mettere le persone giuste sull’autobus” (dal libro Good to Great di James Collins). L’idea è che non serve sapere subito cosa costruire per sapere con chi partire. Serve armonizzare forze e debolezze nel team, così superi il lato negativo del “questo è il mio bambino”.
Hannah Clark: Per estendere l’analogia del genitore: vuoi un partner che condivida valori ma compensi le tue debolezze, completi i tuoi punti di forza. Questo rende bene l’idea.
Approfondiamo il portare a bordo le persone giuste. Come capisci chi deve essere sull’autobus? Come valuti le forze e le debolezze?
Brendan Fortune: Faccio esempi semplici. Schema diffuso: sei un genio tecnico o molto forte sul prodotto, ma ti manca la capacità narrativa e il carisma che aiutano a guidare il team. Bisogna cercare chi compensa. Questo in particolare vale nei prodotti nuovi in aziende consolidate: l’evangelizzazione non serve solo verso i clienti ma anche all’interno, soprattutto verso la leadership, dato che si spostano risorse e denaro. Se non hai questa competenza, devi cercarla. Altro esempio: se devi creare un prodotto in un campo che non conosci, meglio trovare chi ha il dominio o chiederti se è giusto gestire quel prodotto. Una delle cose più rischiose è quando chi guida non ha vissuto il mercato. Ho pensato si potesse imparare in fretta; ho fallito.
Hannah Clark: Immagino da quanto serva input dagli utenti, feedback, apprendimento costante per riuscire davvero a capire il prodotto. Può essere una grande sfida per chi parte senza base.
Parliamo un attimo del “fail fast”. È quasi una frase fatta. Tante culture di team la professano ma difficilmente ne codificano i contorni. Ad esempio, quanto tempo e risorse diamo a un’idea prima di definirla un fallimento? Come definiamo il fallimento? E come diamo ai collaboratori la libertà di dire “questo non funziona”? Esiste questa sicurezza psicologica? Consigli pratici per favorire la cultura del “fail fast”?
Brendan Fortune: Ottima domanda che sento vicina, specie come l’hai impostata: la teoria è diffusa, poi in pratica… Secondo me il “fail fast” ha valore, ma il modo in cui viene incorniciato spesso è fuorviante.
Si può pensare che “fail fast” voglia dire fallire quanto vuoi, oppure al contrario che sia tollerato solo a parole ma non nei fatti: il primo errore si perdona, il secondo no. Una cosa che mi viene in mente sono i principi di leadership di Amazon, per esempio “i leader hanno spesso ragione”. Mio fratello, che ci ha lavorato, la trovava un’esagerazione: è il team che deve essere potenziato, non il capo unico decisore.
Il “fail fast” spesso nelle aziende in realtà vuol dire che devi avere spesso ragione e il vero obiettivo sarebbe riuscire in fretta grazie ai fallimenti. E qui entra il tema di definire successo e fallimento. È domanda classica in riunione: “ok tutto bello… ma quali sono i success metrics?”. Ottima domanda, stimolante, va posta. Ma spesso si pretende di dover definire i parametri di successo già prima di iniziare e in modo rigido—o va o non va.
Forse da qualche parte ha funzionato, ma in tutti i prodotti che ho lanciato da zero non è MAI andata così. Un esempio fresco di Customer.io. Il nostro progetto più recente si chiama Customer IO Data Pipelines.
È una piattaforma dati: punto unico di integrazione dei dati clienti, che poi vengono distribuiti (CRM, automazioni marketing ecc.). All’inizio i metriche di successo erano: conquistare clienti da concorrenti offrendo prezzi più bassi, generare ricavi ricorrenti a doppia cifra mensile da nuovi clienti dedicati solo a questo prodotto (quindi non clienti già nostri), e coprire il costo del nuovo team sei mesi dopo il lancio. Indovina, dopo sei mesi, quante metriche avevamo raggiunto.
Hannah Clark: Direi zero, o al massimo una.
Brendan Fortune: Esatto, zero. Forse l’ho lasciato intuire (ride). Ma non abbiamo chiuso il progetto. Non si tratta di “sunk cost”? È che anche senza quei numeri abbiamo trovato successo altrove.
Abbiamo visto che i clienti che non usavano già piattaforme simili erano quelli che adottavano meglio il prodotto. E abbiamo visto un nuovo volano economico: il pricing era per API call (modello variabile); più dati invii, più valore ottieni e più paghi. I clienti che hanno adottato stanno crescendo mese su mese. Non abbiamo sottratto clienti alla concorrenza, ma abbiamo trovato valore nella crescita nell’utilizzo e quindi in ricavi successivi. Il tutto molto più lento del previsto, ma con potenziale di lungo periodo. Quindi se stai facendo un “zero to one”, sii attento alle metrics ma aspettati che evolvano e magari il successo emerga in modi imprevisti. Finché trovi valore da qualche parte, puoi andare avanti. Se non ce n’è proprio, lì sì che è fallimento.
Hannah Clark: Riflessione preziosa, molto valida anche per la vita: le aspettative si trasformano, ma ci sono altri valori e traguardi da raggiungere.
Visto che parliamo di fallimenti: ti chiedo, qual è il tuo fallimento preferito nella carriera che ti ha dato più valore?
Brendan Fortune: Bella domanda. Vorrei dire che ne ho tanti, ma dopo il discorso sul “leader ha sempre ragione” meglio non esagerare. Scherzi a parte, ho molti errori da cui ho imparato.
Quello che mi viene in mente prima è GoDaddy, dove tentavamo di lanciare Enterprise WordPress, un prodotto di hosting per grandi agenzie tipo quelle che creano siti importanti (ABC.com ecc.). Doveva essere scalabile per i loro volumi e flessibile come WordPress per gli utenti meno tecnici. C’erano già soluzioni di successo sul mercato. Avevamo buoni rapporti coi clienti, pilot attivi… Team di 5-6 persone, soprattutto ingegneri. Dopo 9-12 mesi abbiamo chiuso il progetto circa un mese dopo il lancio.
Il motivo: abbiamo creato un prodotto che era morto già alla partenza. Non si poteva promuovere dall’ambiente di staging a produzione in modo semplice. Pensavamo di essere super ingegnosi, lo abbiamo reso sicuro fino al limite: nessuna modifica in produzione senza una procedura molto macchinosa. Tecnicamente brillanti, ma il cliente non lo voleva: non avevamo validato davvero, a parte dire “ehi che ne dici?” e ricevere semplici cenni (il cosiddetto “mom test”). Siamo finiti dritti nel “mom test”. Morale: se ti credi furbo, accertati di esserlo davvero. E se nessuno del team ha esperienza nel dominio—e nel nostro caso era così—occhio.
Hannah Clark: Per chi non conosce il “mom test”, puoi spiegare brevemente?
Brendan Fortune: In pratica: se vai a chiedere “ti piace questa idea?” a qualcuno che ti vuole bene o semplicemente ti sostiene (tipo una mamma…) otterrai sempre una risposta positiva. Non avrai mai il feedback critico o onesto che ti serve. Ottieni il supporto, non la verità. E la differenza fra “ti supporto” e “metto soldi sul tavolo” è enorme.
Hannah Clark: È vero, ed è anche una questione culturale: in Nord America molte persone tendono ad assecondare per gentilezza, e poi si ritrovano a ricevere un prodotto che non interessa loro affatto.
Brendan Fortune: Esattamente. Si potrebbe aprire una parentesi sul tema “radical candor” — il feedback radicale — che si oppone all’empatia dannosa o all’aggressività inutile. Quando sento parlare della cultura nordamericana del “supporto” a tutti i costi, mi viene in mente questa contrapposizione: la radical candor è totalmente controcultura.
Hannah Clark: Ok prendo il gancio! In effetti, il feedback radicale è qualcosa che la nostra cultura tende a evitare, ma è fondamentale per i team di prodotto: pensiamo a quanti milioni di dollari si sono sprecati per mancanza di feedback diretto.
Brendan Fortune: Sicuramente miliardi! In tutte le aziende dove ho lavorato, nessuna a mio avviso ha mai centrato questo tema. Credo che la cultura aziendale sia una “attenzione da gestire”, non un problema da risolvere. Non si raggiunge mai una meta fissa: c’è sempre fluttuazione, mai perfezione. Faccio un esempio: quando cerco di costruire fiducia con un collaboratore, spesso condivido i miei obiettivi di carriera—una cosa personale—che a volte può sembrare calcolo politico, proprio l’effetto opposto a quello che vuoi. Ma per avere radical candor serve fiducia, altrimenti il feedback rischia di diventare tossico. Ho avuto responsabili che, vedendo scontri di idee (ad esempio fra chi vuole “fail fast” e chi privilegia la scalabilità), cercavano di raffreddare le tensioni per protezione, ma così si uccide il confronto costruttivo. Il feedback radicale è conflitto! Ma il conflitto può generare valore.
Hannah Clark: Condivido. Il conflitto è un’opportunità. Abbiamo scritto un intero articolo su questo!
A proposito, torniamo su “tensioni da gestire”, framework molto utile anche nella leadership. Non sempre se ne parla esplicitamente, ma si applica in molte aree della gestione delle persone. Puoi spiegarlo?
Brendan Fortune: Provo a rispondere con la lente del product manager. All’inizio sei misurato sulla capacità di “spedire”: risolvi problemi per i clienti rilasciano cose. Quando le “spedisci”, c’è senso di fine lavoro.
Ma quando passi a ruoli più ampi, il rischio è di portare lo stesso schema—identifico i problemi, li risolvo, sono a posto. Magari creando un processo, una riunione con agenda ecc. Ma la realtà è che, le persone cambiano, i team cambiano (anche solo restando gli stessi membri): le tensioni e problemi sono in costante mutamento. E devi far crescere le persone, che devono cambiare! Le soluzioni di ieri non valgono più. Pensare a questi temi come “tensioni da gestire”, e non problemi da risolvere una sola volta, aiuta molto: appena risolvi qualcosa, devi ricominciare daccapo. È un mindset creativo, che collega alla mentalità da fondatore: se ti piace creare, sarà una partita continua.
Hannah Clark: Bellissimo: da people manager, impari che non c’è mai una risoluzione vera — questa consapevolezza ti aiuta anche nella gestione delle energie.
Sullo stesso tema: parliamo di allineamento. Ognuno ha una propria idea di “allineamento in team”, ma è davvero cruciale per un nuovo prodotto. Come ottieni l’allineamento del team su una grande consegna?
Brendan Fortune: Ci ho pensato molto lavorando su Pipelines. Due cose che funzionano, ma ho iniziato a praticarle troppo tardi. Primo: feedback 1 a 1. E non mi riferisco solo al feedback critico.
Ad esempio, se preparo una roadmap con visione, mockup, ecc., è facile voler essere efficienti: “presento tutto a tutti insieme, faccio Q&A e abbiamo l’allineamento”. In realtà, l’allineamento di gruppo non funziona — anche con pochi partecipanti. Un mese dopo scopri che uno dei presenti non aveva capito o si sentiva escluso. Senza sentirsi ascoltati, non si può nemmeno “disaccordare e impegnarsi”. Quindi, prima di condividere una proposta in gruppo, passa dai feedback 1 a 1 con gli stakeholder chiave e assicurati di averli davvero ascoltati e compresi: “da quello che ho capito, il tuo dubbio è questo…”. A volte uso Miro in remoto per visualizzare i feedback. Investi lì il tempo, soprattutto col core team: una sola mezz’ora non basta.
Secondo punto per l’allineamento dei leader: la “learning roadmap” (non l’ho inventata io, l’ho letta da qualche parte). Gli executive vogliono vedere progresso: cosa state costruendo? Devono vedere il ritorno degli investimenti. Ma nei progetti da zero, a lungo non hai ancora valore economico. Anche se ne sono consapevoli, sono incentivati a spingere, a chiedere risultati concreti. E la paura di fare brutta figura può minare l’allineamento. La learning roadmap ti permette di mostrare progressi anche prima di generare ricavi: non prometti solo la delivery di una feature per X data, ma anche risposte alle domande chiave della settimana (“questo deve essere un prodotto stand-alone o integrare quello esistente?”, “useremo pricing variabile o fisso?”, “quanti sono già pronti a firmare un contratto d’acquisto anche solo sulla visione?”). Elenca i tuoi dubbi e affrontali, “spedendo” la risposta con evidenza. Così la leadership vede progresso e partecipa alle decisioni: altro modo di costruire allineamento.
Invitale nel percorso di co-creazione della soluzione.
Hannah Clark: Ottimo consiglio per gestire queste tensioni.
Prima di chiudere: “zero a uno” vuol dire anche lasciare andare, far “crescere il bambino”. Come ti allontani da un prodotto che hai portato da zero? Perché è difficile? Come gestisci il cambiamento quando c’è questa forte sensazione di paternità?
Brendan Fortune: Primo: come già detto, la cosa ideale è non farlo mai diventare solo tuo “bambino”. Difficile, soprattutto perché in queste fasi serve crederci più di tutti, mettere la propria energia, i propri sogni. È facile che diventi quasi parte dell’identità.
Quindi, se non riesci ad evitarlo, il mio consiglio è: definisci in anticipo un punto finale, prendi il controllo sul passaggio di consegne. Se puoi scegliere il momento, emotivamente è più semplice. Ad esempio, per Data Pipelines mi sono spostato su un altro ruolo solo dopo aver trovato e inserito chi avrebbe raccolto il testimone da me.
C’è una citazione di Yoda (non la farò con la voce, non sono capace!): “Trasmetti ciò che hai imparato: forza, maestria… ma anche errori e fallimenti. Noi siamo ciò che loro supereranno. Questo è il vero compito del maestro”. Mi piace pensare che il vero successo sia quando qualcun altro riesce a fare meglio di te. Vale anche per la gestione delle persone. Se riesci a ragionare così, il passaggio del testimone diventa motivo di orgoglio.
Hannah Clark: Bellissimo. Sei perdonato per non aver imitato Yoda.
È stata una conversazione straordinaria: grazie Brendan, per tutti gli spunti!
Dove possono seguirti online?
Brendan Fortune: Sono su LinkedIn, volentieri se qualcuno vuole scrivermi, in particolare se avete tentato questi approcci e non hanno funzionato: raccontatemelo! Su Twitter sono @mnproductmgr, anche se difficile ricordare. Vivo in Minnesota, da cui MN.
Hannah Clark: Stato sottovalutato, ne abbiamo parlato!
Grazie mille, Brendan. Spero di sentirti presto.
Brendan Fortune: Grazie Hannah.
Hannah Clark: Grazie a tutti per averci ascoltato. Per altri approfondimenti, guide pratiche e recensioni di strumenti, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altre conversazioni simili iscrivendoti a The CPO Club, ovunque ascolti i tuoi podcast.




