Il cimitero delle funzionalità: che fine fanno quelle che nessuno usa?
Ogni prodotto ha funzionalità inutilizzate. Perché finiscono nel cimitero, quanto costa tenerle e come capire quando è il momento di lasciarle andare.
Ce le ha ogni prodotto.
Funzionalità che hanno richiesto giorni di lavoro.
Funzionalità che in riunione di pianificazione sembravano entusiasmanti.
Funzionalità che, ne erano tutti convinti, gli utenti avrebbero adorato.
E poi…
Nessuno le ha usate.
Restano lì in silenzio dentro il prodotto, occupano spazio, aggiungono complessità e pian piano diventano qualcosa a cui il team smette di pensare.
Benvenuto nel cimitero delle funzionalità.
Ogni funzionalità nasce per un motivo
La maggior parte delle funzionalità inutilizzate non sono cattive idee.
Ed è proprio questo che rende il problema interessante.
Di solito un team non costruisce qualcosa senza motivo.
Magari l’avevano chiesta gli utenti.
Magari l’aveva lanciata un concorrente.
Magari gli analytics mostravano un’opportunità.
Magari il founder pensava che avrebbe migliorato il prodotto.
O magari il team era semplicemente convinto che:
«Agli utenti piacerà da morire.»
Quindi la costruiscono.
La testano.
La lanciano.
E poi arrivano i numeri.
Non ci clicca quasi nessuno.
Costruire è più facile che togliere
Una volta che una funzionalità esiste, toglierla può sembrare un’ammissione di fallimento.
Le conversazioni di solito suonano più o meno così:
- «Ma ci abbiamo messo tre settimane a costruirla.»
- «E se poi agli utenti serve?»
- «Forse la gente non l’ha ancora scoperta.»
- «Teniamola, per ora.»
E la funzionalità resta.
Poi se ne aggiunge un’altra.
E un’altra.
E un’altra ancora.
Alla fine il prodotto diventa complicato: non perché qualcuno avesse deciso di complicarlo, ma perché non si toglie mai niente.
Il costo nascosto di una funzionalità inutilizzata
Una funzionalità inutilizzata non ti manda una fattura ogni volta che qualcuno la ignora.
Ma può comunque costare al team.
Può:
- Rendere l’interfaccia più difficile da navigare.
- Aumentare il lavoro di manutenzione.
- Aggiungere test da fare.
- Richiedere più documentazione.
- Far crescere le richieste al supporto.
- Rendere l’onboarding più confuso.
- Togliere attenzione a funzionalità più importanti.
La funzionalità può avere quasi zero utenti e generare comunque lavoro.
È una delle cose strane del software.
Anche il codice che nessuno usa ha un costo.
Più funzionalità non vuol dire sempre più valore
È facile misurare i progressi in base al numero di funzionalità rilasciate.
Cinque funzionalità questo mese.
Dieci il prossimo.
Venti entro fine anno.
Dà la sensazione di essere produttivi.
Ma gli utenti non scelgono un prodotto perché ha l’elenco di funzionalità più lungo.
Lo scelgono perché li aiuta a fare qualcosa meglio, più in fretta o più facilmente.
A volte una funzionalità in più migliora quell’esperienza.
A volte dà solo agli utenti un’altra cosa da capire.
Di più non vuol dire automaticamente meglio.
A volte vuol dire solo di più.
E se gli utenti non riescono a trovarla?
Qui le cose si fanno interessanti.
Una funzionalità poco usata non è per forza una funzionalità inutile.
Magari gli utenti semplicemente non sanno che esiste.
È una differenza importante.
Prima di togliere qualcosa, chiediti:
«Gli utenti stanno ignorando questa funzionalità o non riescono a trovarla?»
Una funzionalità utile sepolta in un menu confuso può sembrare del tutto inutile nei tuoi analytics.
Un onboarding migliore potrebbe aiutare.
Una navigazione più chiara potrebbe aiutare.
Un’etichetta migliore potrebbe aiutare.
Un piccolo suggerimento dentro il prodotto potrebbe aiutare.
Quindi, prima di spedire una funzionalità al cimitero, assicurati che se lo meriti davvero.
Parla con chi la usa davvero
Gli analytics possono dirti cosa sta succedendo.
Spesso sono gli utenti a dirti perché.
Se solo il 2% degli utenti usa una funzionalità, parla con qualcuno di loro.
Chiedigli:
- «Perché la usi?»
- «Che problema ti risolve?»
- «Cosa faresti se domani questa funzionalità sparisse?»
Potresti scoprire che la funzionalità non è popolare, ma è preziosissima per un piccolo gruppo di utenti.
Ed è una distinzione importante.
Una funzionalità non deve essere popolare per avere valore.
La domanda che prima o poi tocca a ogni funzionalità
A un certo punto ogni team di prodotto dovrebbe chiedersi:
«Se oggi non avessimo questa funzionalità, la costruiremmo di nuovo?»
Se la risposta è no, vale la pena approfondire.
Magari la funzionalità va riprogettata.
Magari andrebbe nascosta alla maggior parte degli utenti.
Magari andrebbe unita a qualcos’altro.
O magari… andrebbe tolta.
Il tempo già speso a costruire qualcosa non dovrebbe decidere se merita di restare.
Quella è solo la trappola dei costi irrecuperabili.
Togliere una funzionalità è sviluppo di prodotto anche questo
Eliminare qualcosa può sembrare un passo indietro.
Non lo è.
Anche togliere complessità inutile può essere un progresso.
Quando una funzionalità sparisce, il prodotto può diventare:
- Più facile da capire.
- Più facile da mantenere.
- Più facile da far scoprire ai nuovi utenti.
- Più facile da spiegare.
- Più facile da navigare.
A volte il miglior aggiornamento di prodotto non è:
«Abbiamo aggiunto qualcosa di nuovo.»
È:
«Abbiamo reso il prodotto più semplice.»
E gli utenti potrebbero apprezzarlo più di un altro pulsante nell’interfaccia.
Ma non trasformarla in un’operazione di pulizia
Anche qui c’è una trappola.
Un team può fissarsi a togliere tutto ciò che non ha numeri d’uso enormi.
Non sempre è una mossa furba.
Alcune funzionalità si usano raramente, ma diventano importantissime quando qualcuno ne ha bisogno.
Prendi un pulsante di export.
La maggior parte degli utenti potrebbe non toccarlo mai.
Ma chi lo usa potrebbe dipenderne.
Quindi l’utilizzo da solo non dovrebbe decidere il destino di una funzionalità.
Guarda il quadro completo:
Utilizzo + valore + feedback degli utenti + costo di manutenzione.
È un modo molto migliore per valutare se qualcosa merita di restare.
Costruisci partendo da una domanda, non solo da una funzionalità
Prima di costruire qualcosa, chiediti:
Che problema stiamo risolvendo?
Poi:
Chi ha davvero questo problema?
E infine:
Come capiremo di averlo risolto?
Sembrano domande banali.
Ma possono farti risparmiare settimane di sviluppo.
Invece di festeggiare quante funzionalità ha rilasciato il team, festeggia quanti problemi reali sono stati risolti.
È un modo molto migliore di misurare i progressi.
Il cimitero non è sempre una brutta cosa
Prima o poi ogni prodotto avrà funzionalità che non hanno funzionato.
È normale.
Alcune idee falliranno.
Alcuni esperimenti non prenderanno piede.
Alcune funzionalità diventeranno obsolete.
Fa parte del costruire software.
L’obiettivo non è evitare del tutto il cimitero delle funzionalità.
L’obiettivo è imparare da quello che ci finisce dentro.
Se cinque funzionalità falliscono per lo stesso motivo, è un’informazione utile.
Se gli utenti ignorano sistematicamente un certo tipo di funzionalità, è un segnale.
Se togliere qualcosa migliora davvero l’engagement, è una lezione.
Il fallimento diventa prezioso quando ci presti attenzione.
Crea screenshot pronti per lo store in pochi minuti: gratis, senza filigrana sugli export.
Launch Shots è gratis per iniziare. Tutti i template (oltre 110), più di 220 cornici dei dispositivi e mockup 3D, localizzazione AI e caricamento diretto su App Store Connect e Google Play Console. Nessuna carta di credito richiesta.
Inizia gratis →In conclusione
I buoni prodotti non si costruiscono aggiungendo all’infinito.
Si costruiscono capendo cosa merita di restare.
Ogni funzionalità dovrebbe guadagnarsi il suo posto: non perché il team ci ha passato settimane, ma perché aiuta davvero qualcuno.
A volte questo significa costruire qualcosa di nuovo.
A volte significa migliorare qualcosa che esiste già.
E a volte…
significa aprire il cimitero delle funzionalità e, finalmente, lasciar andare qualcosa.
Perché nel software meno non è sempre meglio.
Ma il superfluo non è mai gratis.