Eliminare una funzionalità ogni trimestre:meno è meglio

Eliminare una funzionalità ogni trimestre: ogni trimestre, depreca una funzionalità — quella meno usata del tuo prodotto. La maggior parte dei prodotti si porta dietro una lunga coda di funzionalità che meno del dieci per cento degli utenti tocca in un mese tipico, e ognuna di esse tassa ogni modifica futura. Eliminarne una per trimestre è la disciplina che tiene un prodotto costruito da una persona abbastanza compatto da evolvere per anni.

Ecco perché il peso in eccesso costa più di quanto pensi, come funziona il rituale trimestrale, perché fa stare male e come distinguere una funzionalità morta da un'attività morta.

Il costo nascosto delle funzionalità che nessuno usa

Guarda l'uso delle funzionalità nella tua dashboard. Per ogni funzionalità del prodotto, quale percentuale di utenti la usa davvero in un mese tipico? Fallo una volta e troverai la lunga coda: funzionalità che meno del dieci per cento degli utenti tocca.

Quelle funzionalità sembrano gratis. Sono costruite, sono rilasciate, stanno lì. Ma ti costano di continuo, perché ogni volta che cambi qualcos'altro nel prodotto devi assicurarti di non aver rotto quelle della lunga coda — e quella manutenzione si accumula per tutta la vita del codice. Ogni funzionalità morta è una tassa permanente su ogni funzionalità viva.

Per un solo founder la tassa è peggiore che per un team, perché sei l'intero reparto manutenzione. Un'ora spesa a tenere in vita una funzionalità usata al cinque per cento è un'ora non spesa sull'esperimento che fa crescere i ricavi.

Eliminare una funzionalità ogni trimestre: il rituale dell'eliminazione

La disciplina è abbastanza semplice da stare in un paragrafo. Ogni trimestre: scegli la funzionalità meno usata. Comunica la deprecazione al piccolo numero di utenti che ci facevano affidamento. Rimuovila.

I risultati sono immediati e cumulativi. Il codice diventa più semplice. Il prodotto diventa più incisivo. Il peso della manutenzione cala. E la prossima funzionalità che costruisci atterra in un sistema più piccolo e più pulito — il che significa che viene rilasciata più in fretta e rompe meno.

Mettilo in calendario come la revisione delle metriche del lunedì: quattro eliminazioni all'anno, programmate, non negoziabili. Se aspetti che una funzionalità sia "ovviamente" morta, aspetterai per sempre, perché nessuna funzionalità annuncia il proprio funerale.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Perché eliminare funzionalità è psicologicamente difficile

Non è un problema tecnico. È emotivo. Hai dedicato tempo a quella funzionalità. Ricordi la settimana in cui l'hai costruita e il cliente che l'aveva chiesta. E qualche utente, da qualche parte, si lamenta ogni volta che rimuovi qualcosa.

Ecco l'asimmetria che intrappola i founder: le lamentele per la rimozione sembrano più taglienti di quelle per il peso in eccesso, anche se il peso in eccesso fa più danni cumulativi. La rimozione produce un'email arrabbiata oggi; il peso in eccesso produce un prodotto più lento, rilasci più lenti e un codice che nessuno vuole rifattorizzare — distribuiti in modo invisibile sui prossimi tre anni.

Elimina lo stesso. I founder capaci di eliminare le proprie funzionalità sono quelli che tengono i prodotti abbastanza compatti da evolvere. Quelli che non ci riescono sono quelli i cui prodotti diventano musei di decisioni storiche. Un museo è bellissimo da visitare. È terribile da mantenere da soli.

Pivot o pazienza: quando non è una funzionalità, è l'attività

A volte i dati d'uso sollevano una domanda più grande di "quale funzionalità muore questo trimestre". A volte suggeriscono che l'attività, così com'è costituita, non funziona. Eliminare una funzionalità ed eliminare la direzione sono decisioni diverse, e i dati ti dicono quale delle due hai davanti:

La disciplina è guardare con onestà. La tentazione è continuare a spingere sulla cosa esistente perché ci hai investito tempo e cambiare direzione sembra un fallimento. I dati non si curano dei costi irrecuperabili. E un pivot non è un fallimento — è l'applicazione di tutto ciò che hai imparato a una versione più incisiva della scommessa. La maggior parte delle attività di successo ha fatto almeno un pivot all'inizio, perché la prima idea raramente è quella giusta, anche quando è stata validata. La validazione ti dice che il problema è reale; costruire ti dice se la tua soluzione è giusta. La stessa onestà vale prima di costruire qualsiasi cosa — è quando abbandonare un'idea di business.

La disciplina opposta conta altrettanto: sapere quando non fare pivot. I founder che cambiano rotta ogni tre mesi non costruiscono mai niente. Un plateau con attivazione rotta e churn alto è un segnale di pivot; un plateau con fondamentali sani è un segnale di pazienza. Se non sei sicuro di quale hai, fai la diagnosi con esperimenti strutturati — le ripetute correzioni all'onboarding che non spostano mai l'attivazione sono già di per sé il dato.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Come decido quale funzionalità eliminare?

In base all'uso, non ai sentimenti. Misura quale percentuale di utenti tocca ogni funzionalità in un mese tipico, ordina in modo crescente e depreca il fondo della lista. La maggior parte dei prodotti ha una lunga coda sotto il dieci per cento di uso — quella coda è la tua coda di eliminazioni per i prossimi trimestri.

E se i clienti si lamentano quando rimuovo una funzionalità?

Qualcuno lo farà — qualcuno si lamenta ogni volta che rimuovi qualcosa. Comunica la deprecazione direttamente al piccolo numero di chi ci faceva affidamento, dai un preavviso, poi procedi. Le lamentele per la rimozione sembrano più taglienti di quelle per il peso in eccesso, ma il peso in eccesso fa più danni cumulativi; un'email oggi vale più di un prodotto stagnante tra un anno.

Ogni quanto devo rimuovere funzionalità dal mio SaaS?

Una per trimestre. Programmata, come la revisione delle metriche del lunedì. Quattro eliminazioni all'anno bastano a far calare il peso della manutenzione mentre il prodotto continua a evolvere — e sono abbastanza rare perché gli utenti fedeli non sentano mai il terreno muoversi sotto i piedi.

Come capisco se dovrei fare un pivot invece?

Un problema di funzionalità è locale: una funzionalità poco usata dentro metriche sane. Un segnale di pivot è sistemico: attivazione persistentemente bassa nonostante ripetute correzioni all'onboarding, churn che non risponde al lavoro sulla retention, feedback che indicano un problema che il tuo prodotto non può risolvere, o un mercato più piccolo di quanto pensavi. E ricorda il contrappeso — i founder che cambiano rotta ogni tre mesi non costruiscono mai niente.