La Fabbrica di Funzionalità

Questo post è ispirato al post originale 12 Signs You’re Working in a Feature Factory e ha l’obiettivo di:

1. Chiarire cosa è un prodotto e qual è il ruolo del product manager.
2. Aiutarti a capire cosa non è un prodotto e a riconoscere se sei dentro il loop del costruire un “non prodotto”.

Cosa è un prodotto?

La prima parte è super facile eppure c’è ancora chi fa casino su cosa è un prodotto e su cosa dovrebbe fare chi il prodotto lo gestisce.

Ovviamente in questo caso ci riferiamo a prodotti digitali. Con una iper-semplificazione: un prodotto digitale è qualcosa che risolve un problema a un gruppo di utenti e per cui quel gruppo di utenti è disposto a pagare (con soldi, attenzione, tempo, dati, etc.).

Chi gestisce un prodotto digitale, ovvero il Product Manager, ha l’ingrato e arduo compito di decidere quali degli innumerevoli problemi che i nostri utenti hanno sia prioritario risolvere.

Più urgente e sentito è il problema più l’utente sarà disposto a pagare (con soldi, attenzione, tempo, dati, etc.).

Sembra filosofia, ma credimi che non lo è affatto. Stai con me e capirai.

Per risolvere questi problemi spesso si ipotizza che sia necessaria una nuova funzionalità del prodotto su cui lavoriamo. La funzionalità va progettata (design), va scritto del codice per renderla “reale” (sviluppo) e poi rilasciata in produzione affinché la funzionalità possa essere utilizzata per risolvere il problema.

Nella maggior parte dei casi la funzionalità che hai implementato per alleviare la sofferenza dell’utente ha meno impatto di quello che ti aspettavi, ma ciò è perfettamente normale.

Arrivati fin qui è super facile capire che la funzionalità rilasciata in produzione non è altro che un’ipotesi di una soluzione che si spera risolva un problema.

Semplifichiamo ancora di più:

la funzionalità (feature) è un mezzo, non è il fine del nostro prodotto.

Ma allora se è tutto così semplice e lineare perché spesso ci ritroviamo a lavorare su prodotti con decine di feature che nessuno usa? O a progettare continuamente su nuove funzionalità quando non si è neanche sicuri che quelle appena rilasciate abbiano un impatto?

Se non hai la risposta e ti ritrovi in questa situazione allora probabilmente sei in una fabbrica di funzionalità (feature factory).

Benvenuto o benvenuta 🥳!

Non sei solo, le fabbriche di funzionalità sono piene di persone molto in gamba che a un certo punto però hanno smarrito la via.

Noi da buoni eroi siamo qui oggi per aiutarti a capire se anche tu ci sei dentro.

Cosa è una fabbrica di feature?

Per “fabbrica di feature” si intende una tendenza tipica di aziende che sviluppano prodotti digitali nel concentrarsi più sulla produzione di funzionalità che sui reali benefici che queste funzionalità hanno per gli utenti a cui il prodotto si rivolge.

Qui non mi riferisco al fatto che costruisci una funzionalità che pensi abbia impatto e poi alla fine non ha l’impatto che ti aspettavi. Come ci siamo detti è perfettamente normale, sarebbe strano il contrario.

Qui intendiamo un approccio sistemico alla creazione di funzionalità che bruciano tempo e soldi senza neanche interrogarsi sulla possibilità che quelle funzionalità poi servano a qualcuno.

Dal mio punto di vista non è sbagliato in assoluto essere una fabbrica di feature, anzi ci sono ottime fabbriche di feature con cui collaboro spesso e si chiamano software house. Fanno un lavoro molto difficile e lo fanno molto bene.

Il punto è molto semplice: se vuoi solo creare feature non ha senso avere un team di dedicato di sviluppo prodotto e soprattutto non ti serve un Product Manager, ma è sufficiente un bravo Project Manager.

Di seguito troverai otto segnali che ti di diranno se attualmente stai lavorando in una fabbrica di funzionalità.

Ma ancora prima di cominciare se senti spesso nominare in azienda le parola “alta qualità”, “funziona bene”, “piace molto” per valutare il prodotto su cui stai lavorando la probabilità che tu sia dentro una fabbrica di funzionalità sale drasticamente.

Gli 8 segnali che ti diranno sei stai lavorando in una fabbrica di funzionalità

1. No Misurazione

Questo è super semplice ed è l’origine di tutti i mali, come vedrai. Di base non si misura quasi nulla, o meglio si misura solo ciò che si vuole misurare.

Si rilasciano delle funzionalità non sapendo esattamente che metrica dovrebbero muovere. Non sapendo esattamente che metrica la funzionalità dovrebbe muovere ci si sente quasi in imbarazzo a dover poi capire cosa misurare.

Non entro nei dettagli, ma se fai qualcosa devi sapere perché e come misurare il successo, viceversa ti troverai a fare qualcosa solo perchè qualcuno ti ha detto di farlo in funzione di una certa “qualità” che non si capisce esattamente che criteri debba seguire. 

Una regola semplice che puoi seguire: se non sai che metrica andrà ad influenzare una feature non svilupparla.

2. Non si fallisce 

Non potendo misurare il successo di un rilascio, non è possibile neanche misurare il fallimento. Super semplice anche quello.

“L’importante è rilasciare velocemente, rispettare i tempi e fare le cose bene, tipicamente lavorando molto. Lavorare molto è un buon segno” non si sa di cosa esattamente…

“Fare tante cose, rilasciare tante funzionalità è meglio di rilasciarne poche.”

Vederlo scritto sembra folle eppure sono conversazioni a cui ho assistito tante (troppe) volte.

Una regola che puoi applicare per comprendere l’utilità del fallimento: quando qualcosa non va esattamente per come te l’eri immaginata (ovvero il 99% delle volte), smetti di inca***arti e, invece di cercare qualcuno con cui prendertela, chiediti “cosa sto imparando”?

3. Ossessione per le priorità

Non misurando e non fallendo (quindi non imparando o imparando molto lentamente) si è ossessionati dal prendere la decisione giusta su cosa fare, piuttosto che farlo velocemente e imparare grazie ai dati/feedback.

Questo purtroppo porta spesso a deleghe su decisioni di prodotto quasi inesistenti.

Chi sta in alto si sente quasi obbligato a prendere la decisione giusta facendosi carico di un peso che non dovrebbe portare.

Fai attenzione: scegliere le priorità è senza dubbio la cosa più complicata da fare per chi sta creando un prodotto digitale, deve essere un processo rigoroso e disciplinato. Ma spesso si tende a dedicare la quasi totalità del tempo sulle idee che si vogliono sviluppare, lasciando poco o nessun tempo per la parte di validazione successiva.

Una regola super semplice che puoi seguire: se c’è qualcosa che tipicamente non vuoi fare perchè ti sembra troppo rischioso, troppo complicato, forse nascosta dietro quella esitazione c’è proprio la cosa che è più importante scoprire > fare > misurare > iterare.

4. Grandi Rilasci

È sempre tutto collegato: non fallendo, non misurando, non c’è spazio per l’iterazione e il miglioramento incrementale. No ha senso rilasciare frequentemente.

Magari si usa Scrum e ci si organizza in Sprint, ma è un Waterfall travestito da Agile. Alla fine di ogni sprint nulla di nuovo arriva al tuo utente.

Si pensa a fare tutto-bene-subito, i rilasci diventano dei mostri a tre teste ed è difficilissimo capire l’impatto che il rilascio ha.

La roadmap tipicamente è una lista di feature distribuita nel tempo piuttosto che una serie di obiettivi o problemi.

Esempio di un grande Rilascio senza lieto fine

L’esempio di Sara Tortoli, Product Manager in Zalando ti aiuterà a capire meglio:

“Nella mia prima esperienza da Product Manager, stavo lavorando ad una release che coinvolgeva tutta l’azienda in quanto andava a rivoluzionare il modo di lavorare dell’intera divisione, ridefinendo le daily tasks di +7 dipartimenti diversi.

Il progetto era così complesso e la soluzione divisa in prodotti completamenti diversi, sia backend che frontend, che i workload sono stati distribuiti in 3 team differenti.

Date le complessità sia tecniche che organizzative, che faceva sì che se una soluzione non era pronta l’altra non potesse essere rilasciata, acuita ancora di più dalla mancanza di comunicazione tra i 3 product teams, invece che rilasciare feature gradualmente si è optato per una big release in un giorno ben specifico, come nella migliore tradizione Waterfall.

Risultato: in un giorno di dicembre, tutti e tre product team erano seduti in una stanza con almeno altri 30 stakeholder ad osservare la big release che, come da manuale, è fallita clamorosamente. Ancora peggio, ci sono volute due settimane e molteplici iterazioni per capire davvero dove fosse il problema, che avremo potuto evitare tranquillamente se solo si fosse collaborato di più assieme e fatto release molto più piccole e frequenti, invece che affidarsi a una (umiliante) big release finale.”

5. Multi-Tasking Cronico

Quando è difficile definire le priorità perché i team di prodotto e il loro lavoro non sono direttamente collegati alle metriche aziendali e vengono valutati i rilasci piuttosto che l’impatto si ha la tendenza a continuare ad aggiungere “roba da fare”.

Team e persone lavorano contemporaneamente su tante/troppe cose perdendo anche il senso di quello che stanno facendo.

6. Inseguire Revenue

Sales: “Marco sviluppiamo la feature X così il cliente Y ci dà n milioni di €”

Marco: “Ma il cliente ha firmato qualcosa?”

Sales: “No, no ma fidati appena ci sarà la feature X il cliente Y mi ha detto che userà la nostra piattaforma”

Inutile dire che nel 90% dei casi dopo mesi di sviluppo e allocazione di risorse e budget il deal all’orizzonte veniva sostituito da una nuova richiesta di feature.

Più tipico del B2B che del B2C, ma il rischio di inseguire revenue è sempre dietro l’angolo.

Non sto dicendo che sia sbagliato in assoluto cogliere le occasioni e qualche volta deviare dai nostri piani per fare quella cassa che ci consentirà di sopravvivere.

Ma se diventa sistematico, la possibilità che tu sia dentro una fabbrica di funzionalità aumenta drammaticamente.

7. No Iterazioni

Iterare, nello sviluppo di prodotto, significa procedere progressivamente verso l’obiettivo, con frequenti e “piccoli” rilasci che ci consentano di capire grazie ai dati quantitativi o all’evidenze qualitative se ha senso andare avanti (persevere), aggiustare il tiro (pivot) o lasciar stare (fold).

E’ immediato comprendere che nel modello descritto finora non ci può essere spazio per questo tipo di approccio.

Per cui se ti trovi alla fine di ogni rilascio, di solito molto grande, a pensare immediatamente a quello successivo, completamente slegato da quello su cui hai appena lavorato allora fatti qualche domanda. 

8. Teatro del Successo

Il miglior modo per illustrare l’ultimo caso è leggere l’esempio reale scritto da Silvana De Santis, Lead Product Manager in The Fork:

“Primo giorno di lavoro in un nuovo team, azienda piuttosto grande e non conoscevo quasi nessuno sul prodotto per cui avrei lavorato. Gli sviluppatori mi informano che il venerdì successivo ci sarebbe stata una grande festa per il rilascio di un mega prodotto, super prio, su cui avevano lavorato per diversi mesi. Ero invitata! Ottima notizia per me che avrei approfittato dell’occasione per conoscere gente. 

Il venerdì arriva e mi accorgo che avevano fatto le cose in grande: location fantastica, alcol a fiumi, discorso del CEO e del VP Product su quanto fossero fieri del risultato, strette di mano, congratulazioni varie e fotografo ufficiale. 

Due mesi dopo, i risultati e i feedback dei clienti decretano la morte del  tanto celebrato prodotto, con conseguente perdita di mesi di sviluppo da parte dell’azienda. 

Quell’esperienza mi ha insegnato quanto sia importante celebrare l’impatto, piuttosto che il rilascio.”

–

E tu sei già dentro una Fabbrica di Funzionalità? O stai ancora aspettando di scoprirlo?