Product manager: cosa fa e quando serve a un'azienda

Il product manager decide cosa costruire, per chi e in che ordine. Se ti chiedi "product manager, cosa fa di preciso?", la risposta breve è questa: prende i problemi di chi userà un software, li trasforma in istruzioni chiare per chi lo sviluppa e controlla che il risultato serva davvero, senza sforare il budget. Non scrive il codice e non disegna le schermate. Sta in mezzo.

Io lo descrivo così: sto in mezzo tra chi scrive il codice, chi disegna e chi firma gli assegni. Ognuno dei tre parla una lingua diversa, e quasi tutti i soldi buttati in un progetto software si perdono nelle traduzioni sbagliate tra queste tre lingue.

Cosa fa un product manager, in concreto?

Un product manager passa la settimana a prendere decisioni su cosa entra nel prodotto e cosa resta fuori, e a far sì che quelle decisioni siano capite da tutti. Detto in attività concrete:

Ascolta chi userà il prodotto. Interviste, osservazione di come le persone lavorano oggi, lettura dei ticket di assistenza, dati di utilizzo. È la parte che si chiama product discovery.
Definisce il problema da risolvere. Prima di parlare di funzioni, mette per iscritto chi ha il problema, quanto gli costa e come lo risolve oggi.
Scrive i requisiti dal punto di vista di chi userà il prodotto. Non "fare un pulsante esporta", ma "come responsabile amministrativo voglio scaricare le fatture del mese in un file, così da mandarle al commercialista senza copiarle a mano". Con criteri di accettazione, cioè le condizioni precise che dicono quando il lavoro è finito. Ne parlo in dettaglio nell'articolo su user story e criteri di accettazione.
Mette in ordine il lavoro. Tiene la lista delle cose da fare (il backlog) ordinata per valore, e costruisce la roadmap di prodotto, cioè il piano di quali problemi affrontare e quando.
Dice di no. Alla maggior parte delle richieste. Ogni funzione in più costa sviluppo, test, manutenzione e complessità per chi usa il prodotto.
Accompagna lo sviluppo. Risponde ai dubbi del team, guarda le versioni intermedie, accetta o rimanda indietro il lavoro in base ai criteri concordati.
Porta il prodotto sul mercato. Lavora con chi fa marketing e vendite perché il lancio non sia un comunicato stampa e una speranza.
Misura. Dopo il rilascio guarda se le persone usano davvero la funzione, se tornano, se pagano. Le metriche di prodotto sono il modo di decidere con i dati, non con le sensazioni.

Il filo che tiene insieme tutto è una frase che ripeto spesso: prima il problema, poi lo strumento.

Product manager, project manager, product owner: che differenza c'è?

Il product manager risponde alla domanda "stiamo costruendo la cosa giusta?", il project manager a "la stiamo costruendo nei tempi e nei costi previsti?". Le due figure si sovrappongono nelle aziende piccole, ma il punto di vista è diverso.

Figura	Domanda principale	Di cosa risponde
Product manager	Cosa costruiamo e perché?	Valore per utenti e azienda, priorità, risultati dopo il lancio
Project manager	Come e quando lo consegniamo?	Tempi, costi, risorse, rischi di consegna
Product owner	Cosa fa il team nel prossimo sprint?	Ordine del backlog in un team che lavora con Scrum
Designer	Come lo usa una persona?	Esperienza d'uso, schermate, flussi
Sviluppatore	Come lo facciamo funzionare?	Codice, architettura, qualità tecnica

Il product owner è un ruolo definito da Scrum, uno dei metodi agili più diffusi: è la persona che ordina il backlog e decide cosa ha più valore. In molte aziende il product manager ricopre anche questo ruolo. Se vuoi capire come si inserisce nel metodo, trovi tutto nell'articolo su Scrum o Kanban.

Il project manager classico lavora bene quando il risultato è già chiaro e va solo consegnato. Nel software nuovo il risultato chiaro all'inizio non c'è quasi mai, ed è lì che serve chi decide cosa costruire mentre si impara.

Quando serve un product manager a un'azienda?

Serve quando stai spendendo soldi per sviluppare un software e nessuno in azienda ha il tempo, o le competenze, per decidere cosa va costruito e controllare che venga costruito bene. I segnali tipici:

Hai un'idea di gestionale, app o piattaforma, hai chiesto preventivi e ti sono arrivate cifre lontanissime tra loro per "la stessa cosa".
Stai già lavorando con una software house e ogni consegna è una sorpresa, quasi mai bella.
Il progetto doveva durare tre mesi e siamo al nono.
Gli sviluppatori ti fanno domande a cui non sai rispondere, e rispondi a intuito.
In riunione ognuno porta la sua priorità e si esce senza una decisione.
Il prodotto è uscito, ma non sai se le persone lo usano né cosa migliorare per primo.
Sei una startup con soldi contati e devi capire in fretta se l'idea sta in piedi.

Se ti riconosci in due o più punti, il problema non è tecnico. È di decisione e di traduzione. Ed è proprio il lavoro del product manager. Per la parte economica, ho scritto una guida a parte su come sviluppare un software senza buttare soldi.

Quando invece non ti serve

Non ti serve un product manager se stai comprando un software già fatto e devi solo configurarlo, o se il progetto è piccolo e definito al millimetro: un sito vetrina, un modulo da aggiungere a un gestionale esistente con specifiche già scritte dal fornitore. In questi casi basta un buon fornitore e qualcuno in azienda che controlli le consegne.

Non ti serve nemmeno se in azienda qualcuno fa già questo lavoro senza averne il titolo. Il nome conta poco, conta che qualcuno lo faccia.

Se il tuo problema non è il mio mestiere, te lo dico subito. Spesso nella prima chiamata viene fuori che non serve sviluppare niente, ma solo usare meglio uno strumento che hai già.

Come lavora un product manager: dal problema al rilascio

Un buon product manager lavora a cicli brevi, così scopriamo di aver sbagliato quando costa poco invece che a sei mesi dal lancio. Il mio metodo segue sempre cinque passi: ascolto, definisco, costruisco, lancio, ottimizzo.

Ascolto

Parlo con chi userà il prodotto e con chi lo paga. Non chiedo "cosa vorresti?", perché le persone rispondono con soluzioni immaginarie. Chiedo come fanno oggi, l'ultima volta che hanno avuto il problema, quanto tempo ci hanno perso. Le risposte su fatti passati sono molto più affidabili delle promesse sul futuro.

Definisco

Metto per iscritto il problema, chi lo ha e come capiremo di averlo risolto. Da qui nascono le user story con i criteri di accettazione e la prima versione della roadmap. È anche il momento in cui si decide cosa resta fuori dalla prima versione, che di solito è più della metà delle idee iniziali.

Costruisco

Il team sviluppa in cicli di una o due settimane. Alla fine di ogni ciclo c'è qualcosa che si può vedere e provare, non una percentuale di avanzamento su un foglio. Se la direzione è sbagliata, ce ne accorgiamo dopo due settimane, non dopo sei mesi. Spesso si parte da un MVP, la versione più piccola che permette di imparare qualcosa di vero.

Lancio

Il prodotto arriva a utenti veri, prima pochi e poi di più. Il lancio va preparato come una campagna: a chi si rivolge, con quale messaggio, su quale canale, come si misura.

Ottimizzo

Guardo i dati di utilizzo, parlo con chi lo usa e con chi lo ha abbandonato, e decido il ciclo successivo. Ogni ciclo si chiude anche con una retrospettiva, per migliorare il modo di lavorare del team e non solo il prodotto.

Le riunioni, in tutto questo, hanno una regola sola: finiscono con una decisione. Se non c'è niente da decidere, non c'è bisogno di riunirsi.

Perché conta che chi decide il prodotto sappia anche venderlo

Un prodotto che funziona ma che nessuno conosce è un costo, non un investimento. Per questo nel mio lavoro tengo insieme prodotto e marketing: chi decide cosa costruire sa già come si venderà.

In pratica significa farsi alcune domande fin dalla prima settimana, non a sviluppo finito:

A chi lo venderemo, e dove si trovano queste persone? Su Google mentre cercano una soluzione, su Facebook e Instagram, nel giro dei fornitori del settore?
Qual è la frase che spiega il prodotto in una riga, e la capisce chi non ci ha mai lavorato?
Quale funzione sarà il motivo per cui qualcuno compra, e quale invece è solo "carina"?
Come misureremo se le persone arrivano, provano e restano?

Quando queste risposte arrivano presto, cambiano anche le priorità dello sviluppo. Capita spesso che la funzione più richiesta internamente non sia quella che convince un cliente a pagare. Ed è meglio scoprirlo prima di costruirla.

È lo stesso approccio con cui ho progettato, costruito e lanciato Skeo, un CRM leggero che porta i contatti delle campagne direttamente nel kanban del team commerciale.

Product manager interno, esterno o a tempo parziale?

Dipende da quanto prodotto hai e da quanto cambia. Non esiste una risposta giusta per tutti, ma le opzioni sono tre.

Opzione	Quando ha senso	Attenzione a
Interno a tempo pieno	Il software è il cuore dell'azienda e cambia ogni settimana	Costo fisso alto, serve trovare la persona giusta
Esterno a progetto	Devi far sviluppare un software nuovo con un inizio e una fine	Prevedere il passaggio di consegne a chi lo seguirà dopo
Esterno a tempo parziale	Il prodotto esiste, va migliorato a cicli e non giustifica una persona fissa	Serve un referente interno che prenda decisioni con lui

Molte PMI partono con un product manager esterno per la fase più delicata, cioè dalla definizione al lancio, e poi decidono se serve una persona interna. È una scelta sensata: nella fase iniziale servono esperienza e capacità di dire di no, dopo serve soprattutto continuità.

Se lavori già con una software house, il product manager esterno non la sostituisce. Fa da cliente competente: sa cosa chiedere, come verificarlo e quando una stima non torna. Ho scritto una guida su come lavorare con una software house senza sorprese.

Come riconoscere un buon product manager

Lo riconosci da quello che chiede, non da quello che promette. Ecco le domande che userei per valutarne uno, che sia un candidato o un consulente.

Ti chiede del problema prima che delle funzioni? Se nella prima mezz'ora parla di tecnologie, framework e app, è un cattivo segno.
Sa spiegarti le cose senza gergo? Se non riesci a capire cosa propone, non riuscirai nemmeno a controllarlo.
Ti dice di no? Un product manager che dice sì a tutto ti farà spendere di più, non di meno.
Parla di cicli brevi e di versioni da provare? Oppure di un grande progetto consegnato tutto alla fine?
Ti mostra come scrive un requisito? Chiedigli un esempio di user story con criteri di accettazione. Se non sa cosa sono, lascia stare.
Ti chiede come misurerai il successo? Numeri, non "vediamo come va".
Ti dice cosa non sa? Nessuno conosce ogni settore. Chi lo ammette e propone di andare a chiedere agli utenti è più affidabile di chi ha sempre la risposta pronta.

Un'ultima cosa: diffida da chi vende il metodo prima del risultato. Scrum, Kanban e sprint sono strumenti, il prodotto è il software che qualcuno usa e paga.

L'errore più comune: affidare il ruolo a chi non ha tempo

Il titolare che "fa anche il product manager" la sera, dopo vendite e amministrazione, risponde agli sviluppatori con giorni di ritardo, e il team aspetta o indovina. Entrambe le cose costano. Stesso discorso se il ruolo va allo sviluppatore più bravo: sa come costruire una cosa, non necessariamente se vale la pena costruirla. E chiunque lo faccia deve poter decidere le priorità di tutti i giorni senza convocare il consiglio.

Da dove partire domani mattina

Se stai pensando a un software, o ne hai uno a metà, prima di cercare un product manager fai questi tre passi. Ti servono comunque, chiunque scelga di coinvolgere.

Scrivi il problema in cinque righe. Chi lo ha, quanto spesso, cosa fa oggi per risolverlo, quanto gli costa in tempo o soldi. Niente funzioni.
Elenca chi deve decidere. Chi firma gli assegni, chi userà il prodotto, chi lo deve vendere. Se una persona manca, il progetto ha un buco.
Scegli un numero che dirà se ha funzionato. Ore risparmiate a settimana, clienti che pagano, pratiche gestite al giorno. Uno solo, per cominciare.

Con questi tre fogli in mano, la prima conversazione con chiunque sarà molto più utile. Se vuoi vedere come lavoro sul prodotto, trovi il servizio nella sezione product management e il metodo che seguo in tutti i progetti.

Domande frequenti

Il product manager deve saper programmare?

No, non deve scrivere codice. Deve però capire abbastanza di tecnologia da fare le domande giuste, riconoscere quando una stima è gonfiata o troppo ottimista e parlare con gli sviluppatori senza bisogno di un interprete. Molti buoni product manager vengono dal marketing, dal design o dal commerciale. Conta di più la capacità di capire i problemi delle persone e di prendere decisioni con dati incompleti.

Quanto tempo serve a un product manager per dare risultati?

Le prime cose utili arrivano in poche settimane: un problema scritto in chiaro, una lista di priorità condivisa, i primi requisiti verificabili. Sono già un risparmio, perché evitano di sviluppare cose inutili. I risultati sul prodotto, come utenti che lo usano e tornano, richiedono più tempo e dipendono da quanto il team sviluppa in fretta e da quanto è maturo il mercato.

Una piccola azienda può permettersi un product manager?

Spesso sì, se non lo intende come assunzione a tempo pieno. Una PMI che fa sviluppare un gestionale o un'app può coinvolgere un product manager esterno solo nelle fasi decisive: definizione, avvio dello sviluppo, lancio. Il confronto da fare è con il costo dello sviluppo stesso: anche poche settimane di lavoro risparmiate su funzioni inutili coprono di solito la spesa.

Che differenza c'è tra product manager e product owner?

Il product owner è un ruolo previsto da Scrum: la persona che ordina il backlog e decide cosa ha più valore nel lavoro del team. Il product manager è un ruolo più ampio, che comprende anche la scoperta dei bisogni, la strategia, il lancio e la misura dei risultati. Nelle aziende piccole spesso coincidono nella stessa persona, ed è normale.