Come uscire dalla Feature Factory (l'85% delle feature non serve a niente)

85%. Solo il 10-15% delle feature produce miglioramenti misurabili. Il resto? Nessun effetto, o peggio, effetto negativo.

Non è un'opinione — è uno studio di Microsoft e Google su migliaia di feature lanciate. La maggior parte di quello che produci non serve a niente.

E stai pagando per farlo.

Il dato viene da uno studio di Ronny Kohavi (ex Microsoft, ex Amazon) su migliaia di feature testate con esperimenti controllati. Su Bing, solo il 10-15% delle feature ha prodotto miglioramenti statisticamente significativi nella metrica target. Un terzo non ha avuto effetto misurabile. E un terzo ha peggiorato le cose. Google ha confermato numeri simili internamente.

Ora pensa alla tua azienda. Se anche solo il 50% di quello che produci non genera valore — quante ore, quanti soldi, quante persone stai dedicando a cose che non servono? Per una PMI da €2M con 3 sviluppatori, il 50% di spreco equivale a circa €150K/anno di stipendi bruciati su feature che nessuno userà mai.

Il termine "Feature Factory" lo ha coniato John Cutler nel 2016, in un post che è diventato virale nella comunità product. Cutler, all'epoca product evangelist in Pendo, ha identificato 12 segni che indicano se la tua azienda è una Feature Factory:

1. Nessuna misurazione del successo dopo il lancio
2. Nessun collegamento tra feature e risultati di business
3. Heavy project management ma zero product management
4. "Success theater" — spedire è il successo, nessuno chiede se ha funzionato
5. Le roadmap sono liste di feature, non liste di problemi da risolvere
6. I team non hanno contatto diretto con gli utenti
7. Le decisioni vengono prese da stakeholder lontani dal prodotto
8. Il backlog cresce più velocemente di quanto si riesca a consegnare
9. Nessun team ha il potere di dire "no" a una feature richiesta
10. Le retrospettive riguardano il processo, mai l'impatto
11. I designer sono "pixel pusher" — ricevono specifiche, non problemi
12. La velocità di rilascio è l'unica metrica che conta

Quanti di questi punti riconosci nella tua azienda? Se la risposta è più di 4, sei in una Feature Factory.

Marty Cagan, fondatore del Silicon Valley Product Group e autore di "Inspired" e "Empowered", ha tracciato una distinzione fondamentale che chiarisce il problema: Feature Team vs Empowered Team.

I Feature Team ricevono una lista di cose da costruire. Eseguono. Non chiedono perché. Non misurano l'impatto. Il successo è la delivery — hai spedito? Bene. Ha funzionato? Non è compito tuo.

Gli Empowered Team ricevono un problema da risolvere e una metrica di successo. Come lo risolvono è responsabilità loro. Il successo non è la delivery — è il risultato. Hai costruito qualcosa che non ha mosso la metrica? Non è un successo. È un esperimento fallito da cui imparare.

La differenza non è nelle persone. È nel sistema. Le stesse persone, in un Feature Team, producono feature inutili. In un Empowered Team, risolvono problemi reali. Come nel caso NUMMI di Toyota: non erano le persone ad essere rotte — era il sistema.

Henry Ford, 1913. La catena di montaggio riduce il tempo di produzione del Model T da 12 ore a 93 minuti. Rivoluzione industriale.

Il principio: più output = più valore. Ogni unità prodotta crea valore.

Lo abbiamo applicato al software, ai servizi, ai prodotti digitali. Più feature = più prodotto = più valore. Sbagliato.

In una fabbrica, ogni pezzo ha valore. Nel software e nei servizi, le feature confondono gli utenti, rallentano il prodotto, non vengono mai usate. Stai pagando per sabotarti. È lo stesso errore di chi copia gli strumenti di Toyota senza il sistema di pensiero.

Melissa Perri nel suo libro "Escaping the Build Trap" (2018) ha dato un nome a questa patologia: la Build Trap. Le aziende cadono nella trappola quando misurano il successo dall'output (quante cose abbiamo prodotto) invece che dall'outcome (quale impatto hanno avuto). La Build Trap è insidiosa perché sembra produttività — il team è occupato, le release sono frequenti, la roadmap avanza. Ma il valore per il cliente non cresce.

Il paradosso: più feature aggiungi a un prodotto digitale, più il prodotto peggiora. Ogni feature è un compromesso — spazio sullo schermo, attenzione dell'utente, complessità del codice. Come disse Antoine de Saint-Exupéry: "La perfezione non si raggiunge quando non c'è più nulla da aggiungere, ma quando non c'è più nulla da togliere."

Ogni feature che aggiungi ha un costo visibile — ore di sviluppo, design, test. Ma il costo reale è quello invisibile.

Martin Fowler, chief scientist di ThoughtWorks, ha formalizzato il concetto di Technical Debt — debito tecnico. Ogni feature aggiunta crea un "interesse" che paghi per sempre:

• Cognitive load per gli utenti: ogni opzione in più rende il prodotto più difficile da usare. Hick's Law: il tempo di decisione aumenta logaritmicamente con il numero di scelte. 10 opzioni invece di 3 non sono "meglio" — sono paralisi.
• Manutenzione per gli sviluppatori: ogni feature deve essere mantenuta, aggiornata, testata con ogni nuovo rilascio. Un'app con 100 feature richiede 10x il lavoro di manutenzione di una con 10.
• Superficie di test: ogni nuova feature interagisce con tutte le altre. Le combinazioni crescono esponenzialmente. Con 50 feature, le possibili interazioni sono nell'ordine delle migliaia.
• Documentazione e supporto: ogni feature genera ticket, domande, tutorial, FAQ. Il costo del supporto cresce linearmente (o peggio) con le feature.

I casi più famosi di rimozione di feature come strategia di crescita:

Instagram nel 2020 ha rimosso la tab IGTV dalla home, semplificando la navigazione. L'engagement sulla piattaforma è aumentato. Meno opzioni, più focus, più tempo speso.

Apple nel 2016 ha rimosso il jack per le cuffie dall'iPhone 7. Il mondo è impazzito. Le vendite non ne hanno risentito. Apple ha semplificato il design interno, migliorato la resistenza all'acqua, e creato un mercato da miliardi (AirPods) — tutto rimuovendo una feature.

Basecamp (ex 37signals) è l'esempio più radicale: Jason Fried e David Heinemeier Hansson hanno costruito un'azienda da centinaia di milioni rifiutandosi sistematicamente di aggiungere feature che i clienti chiedevano. Il loro libro "Getting Real" è un manifesto contro la Feature Factory: "Build half a product, not a half-assed product."

La domanda non è "questa feature è utile?" — la domanda è "questa feature è più utile di tutto ciò a cui devo rinunciare per costruirla e mantenerla?" Quasi sempre, la risposta è no.

Insight

Ogni feature ha un costo nascosto: cognitive load, manutenzione, test, documentazione. A volte rimuovere una feature crea più valore che aggiungerne una.

2006. Netflix ha un problema di retention sui DVD. La gente si iscrive e poi sparisce.

Hanno scoperto che il numero di DVD aggiunti alla coda nella prima sessione prediceva la retention. Chi aggiungeva molti DVD tornava. Chi ne aggiungeva pochi, spariva.

Hanno ottimizzato quel singolo momento. La retention è esplosa.

Non hanno aggiunto feature. Non hanno migliorato il catalogo. Hanno trovato il momento che contava e lo hanno reso inevitabile. Esattamente come i 7 amici di Facebook: un numero, un vincolo, risultati esponenziali.

Slack ha fatto lo stesso. Stewart Butterfield ha scoperto che i team che inviavano 2.000+ messaggi nei primi 30 giorni avevano un tasso di conversione da trial a pagamento del 93%. I team sotto i 500 messaggi? Quasi zero. La metrica che prediceva tutto non era una feature — era un comportamento. Slack ha riprogettato l'onboarding per massimizzare i messaggi iniziali, non per mostrare feature.

Questo principio si chiama North Star Metric — la singola metrica che predice il successo a lungo termine. Per Spotify è il tempo di ascolto. Per Airbnb le notti prenotate. Per la tua azienda, qual è? Se non lo sai, stai costruendo feature alla cieca.

Insight

Netflix non ha migliorato il prodotto aggiungendo feature. Ha trovato il singolo momento che prediceva la retention — e ha reso quell'esperienza imperdibile.

Se la Feature Factory è il problema, la sperimentazione controllata è la soluzione. E nessuno la fa meglio di Microsoft.

La piattaforma ExP (Experimentation Platform) di Microsoft esegue oltre 30.000 esperimenti controllati all'anno. Ogni modifica a Bing, Office, Teams, Azure viene testata su un campione prima di essere rilasciata a tutti. Ronny Kohavi, ex VP di Microsoft e autore di "Trustworthy Online Controlled Experiments", ha stimato che ExP genera centinaia di milioni di dollari di valore annuo — non costruendo di più, ma costruendo meglio.

Un esempio concreto: nel 2012, un ingegnere di Bing ha proposto un cambiamento nel modo in cui venivano mostrati i titoli degli annunci pubblicitari. Sembrava banale. Il test A/B ha rivelato un impatto di +$100 milioni di revenue annua. Senza il test, quella modifica sarebbe stata in coda dietro 50 feature "più importanti" secondo gli stakeholder.

Booking.com porta questo principio all'estremo: ogni dipendente può lanciare un esperimento senza chiedere permesso. L'azienda esegue migliaia di test contemporaneamente. Il CEO ha dichiarato che il 90% degli esperimenti fallisce — e questo è il punto. Il 10% che funziona genera miliardi.

Per le PMI, non servono piattaforme enterprise. Servono tre principi:

1. Ogni feature è un'ipotesi. Non "costruiamo X". Ma "crediamo che X migliorerà la metrica Y del Z%". Se non riesci a formulare l'ipotesi, non costruire la feature.
2. La metrica di successo si definisce PRIMA del lancio, non dopo. Il 90% delle aziende definisce il successo retroattivamente — cherry-picking la metrica che è migliorata. Questo non è sperimentazione. È confirmation bias.
3. Minimum Viable Test (MVT). Qual è la cosa più piccola che puoi costruire per testare l'ipotesi? Non il prodotto completo — la versione più economica che ti dà dati reali. Un mockup cliccabile. Una landing page. Un test manuale su 10 clienti. Come nel modello Zara: piccoli lotti, dati reali, scala solo i vincitori.

Il framework pratico per una PMI: prima del prossimo rilascio, scrivi su un foglio: "Se lanciamo [feature], ci aspettiamo che [metrica] migliori del [X%] entro [timeframe]." Se non riesci a compilare questa frase, non sei pronto per costruire. Sei pronto per capire meglio il problema.

Dato

Microsoft esegue 30.000+ esperimenti controllati all'anno. Il 90% fallisce. Il 10% che funziona genera centinaia di milioni. — Ronny Kohavi, "Trustworthy Online Controlled Experiments"

La soluzione non è "produci meno". È "produci sapendo".

La fabbrica produce. Lo scienziato sperimenta.

La differenza: ogni feature, ogni servizio, ogni iniziativa parte con un'ipotesi e una metrica di successo definite prima del lancio. Non dopo.

Ford ha inventato la fabbrica. Ma tu non costruisci auto. E nel tuo settore, la fabbrica non basta. Ti serve il laboratorio. Come Zara che lancia 12.000 prodotti: piccoli lotti, feedback reale, scala i vincitori.

Il template del laboratorio in 4 righe:

1. Ipotesi: "Crediamo che [cambiamento X] produrrà [risultato Y] per [segmento Z]."
2. Metrica: "Lo misureremo attraverso [metrica specifica] entro [timeframe]."
3. Soglia: "Consideriamo successo un miglioramento di almeno [X%]."
4. Kill criteria: "Se dopo [timeframe] la metrica non migliora del [X%], eliminiamo la feature."

Il kill criteria è la parte più difficile. Nessuno vuole eliminare qualcosa che ha costruito. Ma senza la disciplina di uccidere le feature che non funzionano, il prodotto diventa un cimitero di buone intenzioni. E ogni feature morta ma non rimossa consuma risorse — per sempre.