Che cos'è una feature factory?

E come capire se ci stai lavorando dentro

Ci sono parole (o espressioni) che ti aiutano a capire il mondo, a volte cogli qualcosa ma non sai descriverlo bene, ma poi scopri che qualcuno con le idee più chiare di te lo ha descritto e gli ha pure dato un nome.

Per me una di queste è stata “feature factory” (o fabbrica di funzionalità), coniata da John Cutler.

Una feature factory è un’azienda in cui lo sviluppo di un prodotto è trattato come se fosse una catena di montaggio di feature, che sono decise dai manager, abbellite dai designer, costruite dagli sviluppatori, lanciate e accatastate una sull’altra, senza nessun focus su quanto stiano o meno aiutando i clienti. Quindi tutto il focus è sulla creazione di novità scintillanti, senza preoccuparsi di a cosa serve quello che stai facendo.

Modern times - Charile Chaplin (1936)

Ci sono diversi indizi che puoi usare per capire se sei in una feature factory, dalla mia esperienza i più semplici sono:

• Nessuna attenzione alle metriche: l’ultima feature che hai lanciato la usa qualcuno? Che numeri vogliamo migliorare con questa funzionalità? Che numeri ci suggeriscono che ci serve?

• Nessuna rifinitura: se dopo il lancio di una nuova feature non cogli l’occasione per vedere come la gente la usa e rifinirla, stai lasciando buona parte del valore sul piatto. Ho visto raddoppiare i guadagni con questo genere di ritocchi.

• Nessun redesign: se una funzionalità c’è, ma è così scomoda da renderla quasi inutilizzabile è molto raro che venga rifatta. Per i clienti è una frustrazione quotidiana, ma senza metriche a supporto, le lamentele che arrivano non sembrano così preoccupanti.

• Non vengono mai eliminate funzionalità: non tutte le ciambelle vengono con il buco, una parte (anche consistente) delle cose che lanci non avrà successo e probabilmente sarà meglio toglierla per evitare di complicare inutilmente il tuo prodotto.

• Si lavora in fasi separate: i manager decidono cosa fare in autonomia, passano la palla ai designer, anche loro lavorano in isolamento e quando hanno finito passano la palla allo sviluppo, che quando ha finito lascia tutto al supporto.

• Si promettono feature per raggiungere accordi commerciali: molto spesso è una brutta idea, ed è figlia del pensiero “più feature abbiamo, meglio è”. E non tiene conto degli effetti più ampi che avrà l’aggiunta di una feature estranea, sia per i prossimi sviluppi che per gli altri clienti.

• Non sono previsti fallimenti: si approccia la creazione della feature come se non ci fosse incertezza, come se nella creazione di prodotti il focus fosse su quanta roba riesci a buttar fuori, più che sull’impatto che quello che hai creato ha sui tuoi clienti.

È un esperimento interessante anche vedere cosa viene festeggiato dal team o dall’azienda, ad esempio: il rispetto di una deadline per un progetto grosso o un traguardo di una metrica raggiunto?

La situazione virtuosa opposta invece è quella di un team orientato ai risultati (outcome) più che alle attività (output) e che ha l’autonomia necessaria per portare avanti questo tipo di lavoro. Un team in cui le diverse professionalità lavorano assieme, consce delle metriche fondamentali del proprio business, puntate verso la creazione di un certo impatto verso il cliente. La creazione di nuove funzionalità è solo uno dei mezzi che hanno a disposizione, molto spesso ci si troverà a ritoccare quelle esistenti, ridisegnarle o a lavorare su parti collaterali.

Se ti ho incuriosito qua c’è l’articolo originale di John Cutler con tanti approfondimenti.

---

Se sei nuovo qui, piacere di conoscerti! Sono Pietro Campagnano e come consulente strategico mi occupo di aiutare startup e piccole aziende a creare prodotti digitali.
Vuoi leggere altro? Qua ne puoi leggere un po’ di altri post e qua puoi trovare anche qualche mio talk.
Se pensi che io ti possa essere utile prenota una call da qui, così facciamo due chiacchere 🙂.