Su cosa deve focalizzarsi un product manager? Certo, sul creare valore per il cliente rispondendo ai suoi bisogni concreti. Prendiamo tuttavia una settimana tipica da product manager e chiediamoci: qual è il miglior investimento delle risorse del team per realizzare la nostra visione?
Presi alla leggera, concetti come continuous discovery o peggio ancora continuous delivery possono generare l’idea errata che la stragrande maggioranza del tempo vada indirizzata alla creazione di nuove funzionalità o prodotti, con un piccolo buffer da devolvere a distrazioni e lavoro non pianificato.
John Cutler ha riassunto benissimo il problema in un tweet:
Ho avuto la fortuna di lavorare su dei prodotti interni dove il debito tecnico ereditato è stata la nostra principale zavorra. Ribadisco: è stata una fortuna. Questa esperienza ha avuto un valore unico nel farmi capire come la distribuzione delle risorse debba necessariamente essere pensata strategicamente e olisticamente.
Se oggi scegliete di dedicarvi solo allo sviluppo di nuove funzionalità, domani pagherete lo scotto: la vostra giornata sarà solo manutenzione, lavoro non pianificato e interruzioni.
“…e il 10% per il debito tecnico”
Un classico, vero? A volte il 10%, a volte il 20%: si arriva in fondo a una sessione di planning e si alloca una percentuale prestabilita delle risorse a debito tecnico o “altre iniziative di engineering”. L’unica possibile scusa per un simile approccio è la semplicità.
Tuttavia, è un principio sbagliato nell’essenza Presuppone infatti che vi sia del lavoro di cui non si può stabilire la priorità. Detto altrimenti: di cui non si può stabilire il valore.
Non è mai così: se un’iniziativa ha senso, che sia tecnica o “di prodotto”, l’iniziativa crea del valore all’interno della nostra strategia.
Applicazioni che spaventano gli sviluppatori
L’anno scorso il mio team ha ereditato un sistema di backend responsabile per la gestione di determinate strutture dati. Diversi altri prodotti sviluppati in azienda dipendono da questi dati – dalla loro disponibilità e correttezza innanzitutto.
Purtroppo l’applicazione che ci è stata consegnata era in pessimo stato. Per anni, chiunque l’aveva trattata come un semplice pezzo di codice. Ogni volta che serviva una nuova funzionalità veniva aggiunta senza riguardo per la qualità dell’architettura dati così come delle logiche che manipolavano i dati stessi. L’importante era arrivare in fretta al risultato.
Alcune conseguenze di questo approccio:
- Estrema instabilità: cambiamenti di piccola portata potevano generare incidenti estremamente difficili da diagnosticare e risolvere.
- Impossibile scalare.
- Assegnare uno sviluppatore a lavorare sull’applicazione era come assegnare una punizione. Nessuno voleva mettervi mano.
Naturalmente, l’applicazione richiedeva spesso l’introduzione di nuove funzionalità e cambiamenti, ed era anche al centro di un’iniziativa più larga che avrebbe incrementato di parecchio la quantità di dati da gestire e il traffico.
In una tale situazione, lavorare sulla stabilità e scalabilità dell’applicazione diventa una priorità. Derubricare tale iniziativa a “debito tecnico” sarebbe un errore strategico.
Qual è la ragione di fondo per cui si era arrivati a un tale risultato? Che l’applicazione era stata derubricata a “software di backend” invece che essere considerata ciò che è: un prodotto.
Siete un team, non due parti in negoziazione
Vi è un’immagine fastidiosa del planning per cui sviluppatori e product manager negozierebbero cosa inserire nello sprint. No. Siete un team: la strada è necessariamente in salita se non avete un’intesa su quali siano le priorità. L’applicazione di cui ho scritto sopra esemplificava esattamente questo problema: un team diviso, dove PM e sviluppatori hanno focus diversi e idee divergenti su quali siano le priorità.
Ogni settimana dedico almeno un’ora di tempo con gli sviluppatori a parlare esclusivamente di temi strettamente di prodotto. Al contempo chiedo a loro lo sforzo di darmi accesso alla comprensione di svariati dettagli tecnici. Solo con questo scambio possiamo avere sufficiente comprensione dei domini reciproci per poter soppesare iniziative di natura diversa (“nuova feature o refactoring?”).
Se l’architettura software su cui poggia il tuo prodotto sta diventando caotica – spaghetti code, eccessive dipendenze, librerie non aggiornate da secoli, … – il futuro non è roseo: con il tempo, la minima modifica diventerà sempre più dispendiosa. Non sperare che il “backlog tecnico” non sia affar tuo, perché se non è compreso e prioritizzato diventerà presto l’unico affare di cui riuscirai a occuparti.
Sempre verso nuovi orizzonti
Vi è poi un’idea romantica del product manager per cui la missione primaria sia la scoperta di nuovi bisogni e lo sviluppo di sempre nuove funzionalità o prodotti che li soddisfino.
La domanda ovvia è: guardando al vostro business, da dove provengono la maggior parte degli utili, o delle visite, o delle iscrizioni, o di qualsiasi altra metrica sia di rilievo? Siamo sicuri che le funzionalità che generano tale valore siano già ottimizzate e non richiedano ulteriore attenzione?
Certo, esplorare nuovi territori può avere un ritorno maggiore. Tuttavia, questo ritorno è sempre sufficiente a giustificare i rischi?
Un problema legato a questa prospettiva è la pianificazione delle risorse nel medio termine. Quando si lancia una nuova iniziativa ci si dimentica spesso che serviranno risorse per mantenerla attiva e per garantirne un ulteriore sviluppo almeno finché l’investimento giustifica il ritorno.
Invece di storcere il naso davanti all’idea di rimanere bloccati sullo stesso prodotto e non potersi dedicare a nuove esplorazioni, le domande da porsi sono:
- Come operazionalizzare il più possibile il mantenimento del prodotto esistente?
- Come individuare le funzionalità specifiche su cui vale la pena investire in ulteriore sviluppo? Qual è quel 20% del prodotto che rende l’80%?
La soddisfazione di domare la complessità
Se state iniziando la vostra carriera da product manager potreste essere attratti dalla possibilità di creare qualcosa di completamente nuovo e uscirne da eroi. Ed è sicuramente parte del fascino di questo lavoro.
Tuttavia, vi è molto di più. Il tweet di John Cutler ci ricorda che gestire un prodotto o un portfolio richiede avere una visione d’insieme, la quale inevitabilmente richiede di comprendere la complessità sottostante. Manutenzione, sperimentazione, sviluppo delle infrastrutture, richieste straordinarie, ricerca, sono solo alcuni degli aspetti da gestire per poter creare valore in maniera efficiente.
Forse è un’immagine meno sexy di quella venduta da altri blog, ma la soddisfazione intellettuale di venire a capo di una tale sfida è ciò che rende il product management appagante e stimolante.
