Il product management è tutto una questione di storytelling. Quindi lasciate che vi racconti come io vedo il product management, e come l'AI lo ha cambiato, raccontandovi una storia.
La domanda di colloquio che non dimenticherò mai
Ho iniziato la mia carriera come ingegnere presso RealNetworks e, nel giro di pochi anni, ero responsabile del team di prodotto e sviluppo per RealPlayer. All'epoca era un prodotto consumer piuttosto significativo: aveva centinaia di milioni di utenti e ha contribuito a portare audio e video nei primi giorni di Internet. Mi sedevo in riunioni con i colleghi del lato business, che proponevano idee come: "Dovremmo mostrare un annuncio ogni volta che il player si avvia". Sapevo che non era la cosa giusta da fare, ma non avevo modo di controbattere ai loro fogli Excel che mostravano quanto denaro avremmo guadagnato. Volevo diventare un vero product manager e ho concluso che probabilmente avrei dovuto andare alla business school.
Ho iniziato la business school a Berkeley e, poco dopo il mio arrivo, ho visto sulla lista email della mia ex università che LinkedIn stava assumendo. Ho fatto domanda e mi sono ritrovato a sostenere un colloquio con Reid Hoffman. Si è seduto e mi ha fatto una domanda di colloquio che non dimenticherò mai:
"Allora, vuoi essere un product manager. Qual è l'artefatto che produce un product manager?"
Ha approfondito. Gli ingegneri hanno un artefatto: il codice. Il business development ha un artefatto: contratti firmati. I designer creano l'aspetto visivo e la grafica. Il CEO ha l'organigramma, il piano di finanziamento e la visione che tiene tutti insieme. E il product manager?
Gli ho detto che non ero sicuro che i product manager avessero davvero "artefatti" di quel tipo, ma che la cosa fondamentale che facciamo è raccogliere tutto ciò che sta succedendo e scriverlo in una spec. La spec è il progetto tecnico. È dove definiamo i requisiti, tutto ciò che faremo, e diventa uno dei documenti più importanti dell'azienda perché sblocca ogni team affinché possa costruire partendo da lì.
Ero chiaramente nervoso. Credo che se ne sia accorto, perché mi ha rassicurato dicendo che era una buona risposta. Alla fine ho ottenuto il lavoro, ho lasciato la business school per entrare in LinkedIn e ci ho pensato su quella domanda da allora.
L'evoluzione dalla spec alla storia
Perché ho dato la risposta sbagliata.
Eravamo ancora nell'Era Waterfall dello sviluppo software. Su LinkedIn stavamo cercando di reinventare una piattaforma di lavoro all'interno di una piattaforma social: dove i responsabili delle assunzioni potessero vedere le candidature nel contesto delle connessioni reciproche, e i candidati potessero vedere gli annunci di lavoro e trovare modi attraverso la loro rete per arrivare alla porta principale. Durante questo processo di scoperta, ho scritto una spec di 120 pagine che definiva l'intera esperienza e quali erano i requisiti.
Ci ho pensato molto negli anni successivi. Perché quella spec, ovviamente, non è l'artefatto più importante. La storia lo è.
La spec descrive un sistema, cosa deve fare e quali caselle devono essere spuntate prima che sia finito. Questo non è l'arte del product management. Il product management riguarda il raccontare la storia delle persone che useranno il prodotto e perché sarà importante nelle loro vite. Deve essere immediatamente comprensibile, a chiunque tu stia parlando. E deve essere ripetibile: le persone devono poterla passare fedelmente, senza che tu sia nella stanza.
È un documento completamente diverso, e un lavoro completamente diverso.
Dieci anni fa ho tenuto un talk sul product management, e la gente me lo manda ancora; il che è o lusinghiero, o un segno che il campo non si è mosso. Considererò entrambe le possibilità. Comunque, l'intero talk si riduceva a una frase: "Un product manager aiuta il suo team (e l'azienda) a consegnare il prodotto giusto ai suoi utenti." Ho passato la maggior parte del talk a scomporre quella frase, parola per parola.
- Aiuta il suo team. Non sei il leader. Molte persone pensano che il product manager sia il leader. Sei la persona che aiuta a far accadere le cose. Il che significa che devi...
- Capire il tuo team e la tua azienda. Il tuo team è il tuo dominio: devi capirlo! E devi capire come si inserisce nel quadro generale, così da servire gli obiettivi dell'azienda e non solo i tuoi.
- Consegnare. Possiamo parlare quanto vogliamo, ma alla fine della giornata, ciò che conta è mettere il prodotto davanti ai clienti.
- Il prodotto giusto per i tuoi utenti. Siamo finalmente arrivati al lavoro: affinare cosa "giusto" significhi realmente.
Quanto di tutto questo cambia in un mondo di AI?
Cosa sta cambiando
Ovviamente qualcosa è cambiato, anzi, diverse cose. Da un lato, sta cambiando come scriviamo codice e quanto velocemente possiamo passare da un'idea a qualcosa di funzionante. Dall'altro, sta cambiando cosa gli utenti si aspettano che un prodotto sia. Penso che abbiamo appena toccato la punta dell'iceberg, specialmente nel consumer. Poter descrivere ciò di cui hai bisogno e avere il prodotto che te lo consegna, magari con agenti in esecuzione in background, senza che tu debba imparare e interfacciarti.
Non c'è dubbio che il costo del creare cose sia crollato. Non è più così difficile definire l'ambito di qualcosa e provarlo; questo ti dà un'enorme flessibilità. Ma il costo del giudizio non è cambiato affatto. Capire cosa costruire è più importante ora che mai.
Lo sviluppo del prodotto è un ciclo. Una volta qualcuno aveva un'idea - e non deve necessariamente essere tua; in una buona azienda può provenire da qualsiasi parte. La provi. Scrivi una spec, o un brief di prodotto, o qualunque nome dia il tuo team a quel documento. C'è un costo iniziale: scoping, design, discussioni - tutto ciò che deve accadere prima di spendere prezioso tempo di ingegneria. Questi sono tutti rituali che abbiamo inventato per proteggere il tempo degli ingegneri dalle cattive decisioni. Perché ottenevi solo sei o otto giri attorno a quel ciclo all'anno.
Poi creare cose è diventato assurdamente economico. Non leggermente più economico; un ordine di grandezza diverso. E ciò che è successo è davvero interessante. Quel vecchio ciclo esiste ancora - solo riordinato in una nuova sequenza.
Il vecchio ciclo andava: idea, spec, costi, scoping, tutto il resto, poi la costruzione. Ora:
- Prima, prendi l'idea e la costruisci rapidamente con l'AI, solo per vedere come funziona e come si sente.
- Giochi con essa, e capisci come si sente e come si adatta al quadro generale. I prototipi battono gli "e se", sempre.
- Poi la progetti. Ora che ci hai giocato, sai cos'è, e puoi effettivamente parlare di cosa servirà affinché questo sia più di un prototipo. Intendo design qui in entrambi i sensi: design visivo e UX, e anche design ingegneristico.
- Poi consegni e impari.
Si inverte completamente: da spec-and-scope, a build-and-play. Penso che questo cambi il product management più di qualsiasi altra cosa stia accadendo adesso.
Questo significa finalmente che la spec non è più il deliverable; davvero. Non devi iniziare scrivendo un lungo documento e facendo tutto bene sulla carta. Questo era vero in senso aspirazionale, ma ora è semplicemente vero, in senso letterale.
Ma voglio essere cauto, perché c'è un errore uguale e opposto che puoi commettere.
Le demo sono quasi gratuite ora. I prodotti funzionanti no. Continuo a vedere il rovescio della medaglia di questo nuovo approccio: "Fantastico, consegnalo subito." Non è ancora così che funziona. Dobbiamo tutti rispettare il fatto che la distanza da un prototipo a qualcosa di reale richiede ancora tempo per essere percorsa.
C'è un po' di stereotipo sui product manager, secondo cui il loro lavoro consiste principalmente nel chiedere: "Rientra nel programma?" Butta via completamente questa idea. La domanda più importante è: Rientra nel prodotto?
Abbiamo tutti grandi idee, e ora abbiamo tutti agenti che possono programmare per noi. Decidere cosa costruire ufficialmente non è più un dibattito sulle risorse. È un dibattito sull'impatto. "Questo o quello", non "questo o niente". Il gusto e la curatela contano molto qui, quando hai una visione e sai davvero cosa stai cercando di fare per il mondo. Ma il sistema che costruisci deve comunque sembrare completo.
La mia più grande preoccupazione riguardo all'AI è che ci permette di andare più veloci, e quindi di stipare tutto dentro. Parliamo di "AI slop" nei contenuti; questo è ciò che l'AI slop significa per il prodotto. L'ho già visto accadere in alcuni posti, e penso che siamo tutti un po' preoccupati. Quando chiunque può costruire qualsiasi cosa, decidere cosa costruire è l'intero lavoro. Ed è un problema di narrazione. Che storia vuoi raccontare? Che storia vuoi che i tuoi clienti capiscano? Che storia vuoi che viva nelle loro teste?
Il tuo lavoro come PM non è scrivere una spec di ciò che il prodotto farà. Riguarda la creazione di una comprensione condivisa - un quadro condiviso di cosa stiamo facendo e perché. Perché l'utente è qui? Cosa prova ad ogni passo, e perché è importante? Dove è impressionante, e dove è noioso? Va bene che un prodotto sia noioso occasionalmente, purché tu sappia dove. Ma se non riesci a scrivere un buon script, il prodotto sarà noioso.
Il dono che l'AI ti dà è che ora puoi scoprirlo gratuitamente, fin dall'inizio. Puoi costruirlo rapidamente, farti un'idea, giocarci, e capire quella frase: cosa fa questo prodotto per qualcuno nella sua vita? Perché se puoi rispondere a questo, puoi rispondere alla mia domanda: "Le persone lo stanno effettivamente usando?" Perché ora hai detto cosa fa, e stai chiedendo se lo fanno.
Cosa NON sta cambiando
Cosa significa avere una "visione" per il tuo prodotto?
Quando dico visione, non intendo una dichiarazione di missione. Quelle contano, ma non sono una visione. Una visione è la ragione end-to-end per cui il prodotto esiste per gli utenti. Ho un semplice framework per questo:
- Scopo. Perché qualcuno prende il tuo prodotto e lo mette nella sua vita?
- Azioni principali. Quando lo prendono, cosa stanno effettivamente facendo? Può esserci più di una cosa, devi capirle tutte.
- Ciclo. Qual è la frequenza prevista di ciascuna di quelle azioni principali?
Tutta la mia carriera, mentre incontravo fondatori e altre figure del prodotto, chiedevo loro: le persone stanno usando il vostro prodotto? E quasi sempre saltano direttamente ai dati utente. "Abbiamo un rapporto DAU/MAU del 50%. Abbiamo superato le 10.000 registrazioni. Abbiamo un milione di persone in lista d'attesa. Il nostro ARR è di un milione. Stiamo processando quattro miliardi di token al giorno. Siamo arrivati al #3 sull'App Store."
Alcuno di questi è una risposta alla domanda che ho fatto?
A volte ripeto la domanda, ma aggiungo una parola in più: le persone stanno *davvero* usando il vostro prodotto? E poi, a volte, colgono ciò a cui mi riferisco.
Lo scopo di LinkedIn era trovare ed essere trovati. Forse l'azione principale, per alcune persone, era semplicemente rispondere quando qualcuno contattava. Per la maggior parte delle persone non è una cosa quotidiana; potrebbe essere una o due volte all'anno.
Guarda quel ciclo - una o due volte all'anno. Capire questo era critico affinché LinkedIn funzionasse, perché la rete aveva bisogno di un numero molto elevato di persone disposte a essere trovate, e almeno alcune persone che facessero la ricerca.
LinkedIn era dopotutto un social network, quindi potresti essere tentato di spingere gli utenti a compiere azioni ogni giorno. Non l'abbiamo fatto. Invece, abbiamo speso un enorme quantità di tempo nei primi giorni assicurandoci che le persone mantenessero i loro profili accurati. Andava benissimo se venivi trovato solo una o due volte all'anno, purché quando accadeva, cliccavi e capivi: "Qualcuno mi sta contattando, fantastico."
Quando misuri se il tuo prodotto sta funzionando, quelle azioni principali sono ciò che conta. Concentrati sul traffico diretto: trova le persone che letteralmente sono venute da te. Hanno l'app installata e toccano l'icona, o digitano il tuo dominio a mano; sono venuti da te, di propria volontà. Quello è il traffico che conta, rispetto a tutti gli altri modi in cui puoi riportare qualcuno indietro nel momento.
E poi conta davvero solo le persone che eseguono le azioni principali. Non "hanno aperto brevemente l'app", ma hanno effettivamente interagito con essa. Su Discord sarebbe: "sono entrati in una sessione live. Hanno effettivamente letto e inviato messaggi."
Se non riesci a definire quali sono quelle azioni principali, allora non hai un prodotto, perché non hai qualcosa che comprendi.
Ora, una cosa che è nuova, e che amo, è che nei prodotti AI dove l'utente parla con il prodotto, o lo interroga in qualche modo, ora hai una trascrizione letterale del tuo percorso utente. Puoi vedere cosa dicono le persone con le proprie parole. Puoi vedere l'esatto momento in cui qualcuno ha desistito e riformulato. Puoi vedere cosa si aspettavano che il prodotto facesse e non ha fatto. LEGGETE QUESTI! L'AI è ottima per far emergere cose che non avresti visto prima, ma non puoi farle riassumere tutto, e non puoi farle formare la tua opinione per te. Formare la tua opinione - capire qual è davvero la storia - è il lavoro e l'arte del product management.
Onboarding
L'onboarding è il singolo momento più importante che hai per raccontare la tua storia a un cliente. Hanno scoperto il tuo prodotto - forse tramite un annuncio, un invito virale, un articolo, qualunque cosa. Sanno che esisti; sono curiosi e vogliono provarlo. Non otterrai mai più tutta questa attenzione da loro.
Devi ricordare, a questo punto, che non tutti arrivano al tuo prodotto con la stessa motivazione. Ci sono gli entusiasti. Vogliono entrare così tanto. Sono pronti. E, giusto per chiarezza, se lavori nell'azienda, vivi nell'entusiasmo. Tutti interni alla tua azienda dovrebbero essere trattati come entusiasti; sono già immersi nel prodotto ogni giorno. Quando fanno onboarding sul prodotto pensano: "So cosa sto facendo, questo è noioso, perché c'è questo passaggio?"
Dall'altra parte ci sono i passanti. Non sono così interessati a te. Ne hanno sentito parlare, l'hanno controllato, ma il messaggio non è arrivato, e stanno per andarsene.
Questi due tipi di utenti sono gli estremi della distribuzione. Nel mezzo c'è un grande centro sfocato. Queste sono persone che sono arrivate per una ragione: sono curiose! Vogliono saperne di più! E puoi genuinamente convertirle in utenti core del tuo prodotto. Queste sono le persone intorno alle quali devi costruire. Otterrai gli entusiasti comunque. Il centro è chi devi capire.
Presumi che i tuoi utenti siano motivati e curiosi. Prenditi il tempo per introdurre il prodotto, passo dopo passo. Più passaggi semplici battono meno passaggi complessi. L'ho dimostrato con test A/B in più aziende nel corso degli anni. Se ogni passaggio è discreto e semplice, ed è chiaro cosa stai chiedendo e cosa stai insegnando, batte schermate singole grandi, o scelte complesse per mantenere basso il numero di passaggi. Sempre.
Quindi come lo costruisci effettivamente?
Inizia ripetendo il messaggio principale: Ecco a cosa serve. Enuncia il contesto, dentro il prodotto. Va bene chiedere i dati di base - email, password, telefono. Per tutto il resto, spiega perché stai chiedendo, e come si collega. Poi suddividi il tuo prodotto nei suoi concetti chiave, ognuno con un'azione chiara per l'utente da intraprendere.
I prodotti AI hanno reso questo più difficile, non più facile. Ottieni la casella di prompt vuota. In alcuni modi è la peggior schermata di onboarding mai progettata. È una scatola magica. Può fare qualsiasi cosa. Quindi... cosa vuoi fare?
Molti prodotti oggi iniziano con: "Ciao, sono qui per aiutarti, chiedimi qualsiasi cosa!" Parlando per me, non sono la persona più articolata o creativa, in quel momento. Devi insegnare le capacità concetto per concetto. "Se chiedi qualcosa del genere, posso farlo." E poi lascia che il prodotto lo faccia. Porta l'utente ad almeno un caso d'uso prezioso rapidamente, idealmente con i propri dati, così è effettivamente prezioso per loro.
Le persone mi chiedono a volte: con un flusso più lungo, non cadranno più persone? Sì! Ma quelli che arrivano fino in fondo sono molto, molto più propensi a usare effettivamente il tuo prodotto. Se stai facendo un test A/B tra due diversi flussi di onboarding, NON guardare quante persone sono arrivate alla fine del flusso. Guarda quante persone tornano il giorno successivo, o la settimana successiva, e quante hanno eseguito un'azione principale. Se chiedi loro, in quel momento, "Cos'è questo prodotto?", dovrebbero darti più o meno la risposta giusta. I tuoi dati di retention, da questo punto in avanti, sono la tua pagella.
Una storia da Twitter
Sto per racchiudere tutto questo raccontandovi una storia da Twitter.
Mi sono unito a Twitter alla fine del 2009. Avevamo un problema di crescita - tranne che non era davvero un problema di crescita. Twitter era costantemente nelle notizie. Le persone ne parlavano sui blog, i media ne parlavano, e molte persone chiedevano: "Cos'è questa cosa chiamata Twitter? Devo andare a capirlo e registrarmi." E poi milioni di loro lo fecero. Ma non tornarono mai.
Il problema era che nessuno poteva dirti cosa fosse Twitter. Posso effettivamente dimostrarlo:
Didascalia: "alla fine siamo arrivati al numero uno."
Il modo in cui facevamo l'onboarding era che le persone si registravano e vedevano opzioni per "Trova i tuoi amici" o "Segui 20 persone casuali". La maggior parte saltava, e poi atterrava su una pagina che sembrava così:
Questo è piuttosto terribile! È una grande scatola vuota. Le persone la guardavano e pensavano: "...non ho niente da dire." E poi se ne andavano. Se chiedevi loro in quel momento, "Cos'è Twitter?", avrebbero detto: "Penso che riguardi dire qualcosa al mondo? O trovare i miei amici? Non lo so."
Quindi abbiamo ricostruito l'onboarding nel corso di un paio di anni, e abbiamo trovato la cosa che funzionava, che era il Learn Flow. Insegnavamo loro Twitter, un concetto alla volta, come una storia. E ha spostato la retention più di qualsiasi altra cosa che abbiamo consegnato quell'anno.
Il Learn Flow, schermata per schermata
Prima, la nuova home page: "Benvenuto su Twitter." Non abbiamo provato a mettere contenuti lì, solo: "Scopri cosa sta succedendo adesso con le persone e le organizzazioni a cui tieni." Questa è una descrizione piuttosto buona di Twitter, onestamente.
Poi: Questo è un tweet. È un breve messaggio, fino a 140 caratteri, e può contenere link. Ora sai che i tweet sono l'unità di questa cosa.
Successivamente devi costruire la tua timeline. Quindi ti mostravamo una timeline. Ti facevamo cliccare "segui" sulle persone a sinistra. E quando cliccavano segui, i loro tweet apparivano a destra. Così ottieni l'intera idea, in un movimento: Clicco segui, i tweet appaiono, questa è la mia timeline. Che è il concetto effettivo di Twitter - tweet, seguire, e una timeline.
E poi, finalmente, la tua timeline. Avresti riconosciuto ogni account su di essa, perché li avevi effettivamente seguiti tu stesso.
L'onboarding è la tua storia.
Il prodotto giusto per i tuoi utenti
Il tuo lavoro come product manager è aiutare il tuo team e la tua azienda a consegnare il prodotto giusto ai tuoi utenti. In un mondo di AI, la consegna è meno un problema di quanto non lo fosse prima. Capire il prodotto giusto, e chi sono i tuoi utenti, è importante tanto quanto è sempre stato. Se non di più.
Chiediti sempre se le persone stanno davvero usando il tuo prodotto. Capisci cosa significa. Pensa allo scopo, alle azioni principali, al ciclo. Dedica più tempo all'onboarding di quanto sembri ragionevole. È dove converti il centro sfocato, ed è dove racconti effettivamente la storia del tuo prodotto.
Usa l'AI per andare più veloce sui prototipi — ma non accelerare il tuo giudizio. Non rinunciare al tuo giudizio. Non dire semplicemente, "Beh, testiamolo e vediamo." È così che finisci con un prodotto trascurato. Mantieni il tuo giudizio ovunque. La parte più difficile del lavoro è ancora bilanciare tutta la nostra creatività come product manager contro tutti i dati a cui ora abbiamo accesso.
Buona fortuna!
