Prioritizzazione MoSCoW:da 80 idee a 5 funzioni

Hai 80 idee di funzioni — 50 tue e altre 30 suggerite dai tuoi utenti. La prioritizzazione MoSCoW — Must have, Should have, Could have, Won't have — riduce quelle 80 idee alle 5 funzioni, o meno, che mettono davvero alla prova la tua ipotesi. Tutto il resto è una distrazione, e la maggior parte finisce tra le esclusioni.

Oltre alle tue 80, i concorrenti hanno altre 20 funzioni che tu non hai. Non puoi costruirle tutte, e non devi. Ecco il framework per tagliare senza pietà — la domanda di test per ogni categoria, che aspetto hanno una buona e una cattiva prioritizzazione su tempistiche reali, e la regola che ti impedisce di costruire cose che potresti semplicemente fare a mano.

Che cos'è la prioritizzazione MoSCoW per un MVP?

MoSCoW mette ogni funzione in uno di quattro contenitori, ciascuno con una sola domanda di test. Rispondi con onestà e l'elenco di 80 voci collassa da solo:

Nota che cosa non supera il test degli indispensabili in quell'esempio. Livelli di priorità? Gli utenti possono riordinare l'elenco a mano. Categorie e tag? Belli, non essenziali. Attività ricorrenti? Si possono creare a mano. Una funzione non è indispensabile perché è utile — lo è perché la tua ipotesi non è testabile senza.

Non stai costruendo un minimum viable product

Stai costruendo un prodotto minimo testabile. Questa riformulazione cambia tutto, perché àncora ogni decisione di prioritizzazione alla tua ipotesi invece che alla tua visione. La visione è per la versione 10. Se non riesci a enunciare la tua ipotesi in una frase, fermati e sistema prima quello — nasce direttamente dal lavoro di validazione che hai fatto prima di decidere di costruire qualsiasi cosa.

E l'esclusione è dove vive la disciplina. Non è un backlog — è un elenco di funzioni che stai decidendo attivamente di non costruire, ciascuna con un criterio scritto per riconsiderarla: dopo 100 utenti, dopo che la V1 è provata, o se gli utenti la richiedono cinque volte o più. Scrivere il criterio è ciò che impedisce alla funzione di rientrare di soppiatto nel perimetro alla seconda settimana.

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

Il secondo passaggio: impatto contro sforzo

MoSCoW ti porta da 80 a una rosa ristretta. La matrice impatto-sforzo ti porta a cinque. Valuta ogni funzione sopravvissuta su due dimensioni — quanto aiuta l'utente (1–10) e quanti giorni servono onestamente per costruirla — e compaiono quattro quadranti:

• Quick win (alto impatto, basso sforzo): questi sono il tuo MVP.
• Grandi progetti (alto impatto, alto sforzo): falli dopo la validazione, mai prima.
• Riempitivi (basso impatto, basso sforzo): rifinitura, solo se c'è tempo.
• Sprechi di tempo (basso impatto, alto sforzo): non costruirli mai — il motore di reportistica personalizzata che forse vorrebbero due utenti, la funzione di AI che nessuno ha chiesto, i permessi complessi per casi limite.

Sii scettico sui tuoi stessi numeri. I founder sottostimano sistematicamente lo sforzo e sovrastimano l'impatto — quindi aggiungi un margine del 50% a ogni stima, metti in discussione ogni punteggio di impatto 9 su 10 e tieni il tempo totale di sviluppo sotto le quattro settimane.

Fallo a mano prima di costruirlo

Per ogni funzione che sopravvive, fai ancora una domanda: posso farlo a mano per i primi 10 utenti? Se sì, non costruirlo ancora. Manda tu le notifiche email. Costruisci il report settimanale in un foglio di calcolo. Fai l'onboarding di ogni utente con una chiamata personale. Fattura a mano. Importa tu il loro CSV.

Il manuale prima di tutto lancia più in fretta, ti insegna ciò di cui gli utenti hanno davvero bisogno invece di ciò che dicono di aver bisogno, e costruisce relazioni con i primi utenti che contano di più. Ed è un test della domanda sotto mentite spoglie: se non ti va di fare qualcosa a mano per 10 utenti, perché costruirlo per 1.000? Automatizza solo quando hai fatto il compito a mano più di 10 volte, ogni volta richiede più di 30 minuti, lo schema è coerente e gli utenti lo chiedono esplicitamente.

Che aspetto hanno una buona e una cattiva prioritizzazione

Stessa idea di task manager, due decisioni di perimetro. La versione cattiva: attività ricorrenti, sottoattività, tag e categorie, tracciamento del tempo, condivisione di team, un'app mobile, vista calendario, diagrammi di Gantt — 90 giorni per costruirla. La versione buona: crea attività, imposta la scadenza, segna come completata, semplice vista a elenco e un riepilogo email giornaliero inviato a mano ai primi 10 utenti — 14 giorni. Rilasciato in due settimane invece che in tre mesi.

Del resto, il vero costo non sono le funzioni tagliate — è l'apprendimento perso. Un CRM per freelance tagliato da un piano di otto funzioni e 120 giorni a cinque funzioni (aggiungi contatto, aggiungi note, tagga lo stato, ricerca semplice, esportazione CSV manuale) è uscito in 21 giorni, e gli utenti hanno rivelato qualcosa che nessuna roadmap aveva previsto: non volevano affatto la gestione dei progetti, volevano promemoria di follow-up. Un costruttore di landing page tagliato da un piano di 60 giorni a cinque template, testo modificabile e un modulo base ha scoperto che gli utenti volevano più template, non la personalizzazione. Novanta giorni in più di sviluppo sarebbero stati novanta giorni passati a costruire la cosa sbagliata.

Le cinque trappole che riempiono di nuovo il tuo perimetro

1. "Ma questo è centrale per la nostra visione." La visione è per la V10. Che cosa è centrale per testare l'ipotesi?
2. "Gli utenti l'hanno menzionato." Quali utenti? Quanto dolore? Pagheranno? Una persona pronta a pagare pesa più di dieci suggerimenti del tipo "non sarebbe bello se…".
3. "Sono solo due giorni in più." Due giorni diventano due settimane con il debugging. Taglialo; aggiungilo dopo se se ne dimostra la necessità.
4. "I concorrenti ce l'hanno." Loro ci hanno speso anni. Tu stai testando, non competendo.
5. "Non possiamo lanciare senza." Sì, puoi. Qual è il minimo assoluto?

Se la tua lista finale ha più di cinque funzioni, non hai finito di tagliare. La funzione migliore è quella che non costruisci: ogni taglio rilascia più in fretta, impara più in fretta, costa meno e si mantiene più facilmente. Il tuo obiettivo non è costruire un prodotto. Il tuo obiettivo è testare un'ipotesi.

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

Domande frequenti

Che cosa significa MoSCoW?

Must have, Should have, Could have, Won't have. Ogni categoria ha un test: gli indispensabili sono ciò senza cui l'ipotesi non si può testare; gli importanti sono ciò senza cui i primi utilizzatori userebbero comunque il prodotto; gli opzionali sono ciò la cui assenza non farebbe smettere nessuno di usarlo; le esclusioni distraggono dal valore di base e vengono tagliate in modo esplicito.

Quante funzioni dovrebbe avere un MVP?

Cinque o meno. Se la tua lista è più lunga, non hai finito di tagliare. Tieni il tempo totale di sviluppo sotto le quattro settimane, aggiungi un margine del 50% a ogni stima di sforzo e metti in discussione ogni funzione "indispensabile" — la maggior parte appartiene alle esclusioni.

Qual è la differenza tra Must have e Should have?

Una funzione Must have è quella senza la quale non puoi testare la tua assunzione di base — toglila e l'esperimento è morto. Una funzione Should have migliora in modo significativo l'esperienza, ma i primi utilizzatori userebbero comunque il prodotto senza, quindi aspetta fino a dopo la validazione della V1.

Quando dovrei automatizzare un processo manuale?

Solo quando l'hai fatto a mano più di 10 volte, ogni volta richiede più di 30 minuti, lo schema è chiaro e coerente e gli utenti chiedono esplicitamente l'automazione. Fino ad allora, il lavoro manuale costa meno del codice — e ti insegna ciò di cui gli utenti hanno davvero bisogno.