Cosa deve — e cosa non deve — includere il vostro MVP SaaS al lancio

La parola «minimo» in prodotto minimo funzionante è la parte che tutti ignorano. I fondatori annuiscono all'idea di partire in piccolo, poi consegnano una specifica con quaranta schermate, tre ruoli utente, un motore di fatturazione, una dashboard di analytics e un «ah, e dovrebbe integrarsi con tutto». Quello non è un MVP. È un prodotto completo con l'ottimismo al massimo. Ed è di gran lunga il motivo più comune per cui i primi lanci arrivano in ritardo, fuori budget e comunque privi dell'unica cosa che i clienti volevano davvero.

Ho aiutato un buon numero di piccole imprese e fondatori solitari a portare fuori il loro primo prodotto software. La parte tecnica raramente è ciò che li fa inciampare. La parte difficile — ogni singola volta — è decidere cosa non costruire ancora. Un MVP non è una versione ridotta del vostro prodotto dei sogni con le funzionalità limate a caso. È una scommessa deliberata: la cosa più piccola che potete mettere davanti a utenti reali per dimostrare che l'idea centrale merita altro del vostro denaro e del vostro tempo.

Questa è quindi la guida che avrei voluto che più fondatori leggessero prima di scrivere la specifica. Niente gergo, niente teatrino del «muoviti veloce e rompi le cose». Solo un modo pratico per tracciare la linea tra ciò che appartiene alla prima versione e ciò che può — e deve — aspettare.

Cos'è davvero un MVP (e cosa non è)

Chiariamo la definizione, perché è qui che nasce gran parte della confusione. Un MVP è la versione più piccola e semplice del vostro prodotto che permette a una persona reale di fare l'unica cosa preziosa che il prodotto promette — e che vi permette di scoprire se tornerà a farla. Tutto qui. È uno strumento di apprendimento che si dà il caso sia fatto di software funzionante, non un lancio ridotto del prodotto finito.

La parola cruciale è funzionante. Un errore comune è leggere «minimo» e rilasciare qualcosa di così spoglio da mettere in imbarazzo l'utente: un flusso a metà che va in crash, una registrazione che porta a una schermata vuota. Quello non è minimo-funzionante, è minimo-rotto. L'altro fallimento è l'opposto: un prodotto così «completo» da richiedere un anno di lavoro, e a quel punto avete bruciato le vostre risorse per dimostrare un'ipotesi che avreste potuto testare in otto settimane.

Ecco il test mentale che uso. Per ogni funzionalità in elenco, chiedetevi: se la togliessimo, un utente potrebbe comunque ottenere l'unico risultato centrale per cui il prodotto esiste? Se la risposta è sì, quasi certamente non è da MVP. Quella sola domanda taglierà a metà la maggior parte delle specifiche — e la metà che taglia è quella che vi avrebbe fatto arrivare in ritardo.

Trovate l'unico compito che svolge il vostro prodotto

Prima di decidere cosa costruire, dovete avere una chiarezza brutale sull'unico compito che il vostro prodotto svolge per qualcuno. Non la visione. Non la roadmap. L'unica azione ripetibile che, se funziona, migliora la giornata di una persona e la rende disposta a pagare. La maggior parte delle specifiche in difficoltà è vaga proprio qui: descrivono una piattaforma, non un compito.

Provate a completare questa frase a voce alta: «Un utente arriva sul mio prodotto per ______, e se ne va avendo ______». Uno strumento per i turni: un responsabile arriva per pubblicare il turno della prossima settimana, e se ne va con ogni turno coperto e il team avvisato. Un'app di fatturazione: un libero professionista arriva per fatturare a un cliente, e se ne va con una fattura inviata e tracciabile. Se non riuscite a completare quella frase in modo pulito, non siete pronti a definire l'ambito — siete ancora pronti a pensare.

Ciò di cui ogni MVP SaaS ha davvero bisogno

Alcune cose non sono negoziabili, nemmeno nella prima versione più snella — non perché siano entusiasmanti, ma perché senza di esse il prodotto o non è utilizzabile o non vi insegna nulla. Pensatele come il pavimento, non il soffitto. Costruitele in modo semplice, ma costruitele bene.

• Un modo per accedere. Va bene anche un singolo login con email e password, ma uno vero e sicuro, perché tutto il resto dipende dal sapere chi è l'utente.
• Il flusso centrale, dall'inizio alla fine. L'unico compito, dal primo clic dell'utente fino al momento in cui ottiene il risultato prezioso: nessun vicolo cieco, nessun pulsante «in arrivo» nel percorso critico.
• Un posto dove i dati vivono davvero. Archiviazione reale, non un prototipo usa e getta, così il lavoro di un utente sopravvive a un aggiornamento e può tornare domani.
• Un modo per voi di vedere cosa succede. Un logging di base o una semplice vista admin, così quando qualcosa si rompe — e si romperà — potete scoprire perché senza tirare a indovinare.
• Un modo per gli utenti di contattarvi. Anche solo un link email. I primi utenti incontreranno limiti che non avevate previsto; volete che ve lo dicano, non che se ne vadano in silenzio.
• Il minimo indispensabile di fiducia: una nota sulla privacy, una gestione sensata dei dati e nessuna leggerezza con le informazioni delle persone.

Notate cosa non c'è in quell'elenco: fatturazione, onboarding sofisticato, pagine di impostazioni, app mobili, integrazioni. Arriveremo al perché tra un attimo. Il senso del pavimento è che è abbastanza piccolo da finirlo e abbastanza solido da imparare da esso. Un login che funziona, un flusso che consegna, dati reali e un modo per osservare gli utenti e parlare con loro. Quello è un prodotto funzionante.

Cosa lasciare deliberatamente fuori dalla v1

Questa è la sezione a cui i fondatori resistono, quindi sarò schietto: la maggior parte delle cose che sembrano essenziali per il primo lancio non lo è. Sembrano essenziali perché un «prodotto vero» le ha — ma non state ancora costruendo un prodotto vero, state costruendo una domanda. Lasciarle fuori non è tagliare gli angoli. È l'intera disciplina di un MVP.

Fatturazione automatica e prezzi complessi

Quasi certamente non vi serve un motore di fatturazione self-service, piani a livelli, rateizzazione e logica di solleciti nella versione uno. Se i primi utenti vogliono pagare, potete incassare manualmente — una fattura, un link di pagamento, una breve telefonata. La fatturazione manuale per i vostri primi dieci clienti vi dice una cosa che quella automatica non può: se qualcuno pagherà del tutto. Costruite la macchina una volta dimostrato che c'è denaro da incassare.

Ruoli e permessi elaborati

I sistemi di permessi multiruolo — amministratori, gestori, visualizzatori, regole di accesso granulari — sono una vera palude ingegneristica e moltiplicano enormemente la superficie di test. Per una prima versione, un solo tipo di utente è quasi sempre sufficiente. Imparerete le vere esigenze di permessi guardando team reali usare la cosa, e quelle esigenze raramente sono ciò che avreste supposto sulla carta.

Integrazioni, app mobili native e la dashboard

«Deve integrarsi con tutto» è la frase che raddoppia in silenzio i tempi. Scegliete al massimo una integrazione, e solo se fa parte del compito centrale. Le app native iOS e Android possono quasi sempre aspettare — una web app responsive funziona oggi su un telefono. E la dashboard di analytics che tutti vogliono? Gli utenti non possono analizzare dati che non hanno ancora creato. Rilasciate prima ciò che crea i dati; visualizzateli quando c'è qualcosa da mostrare.

Un metodo semplice per tracciare la linea

Conoscere il principio è una cosa; applicarlo alla propria specifica, dove ogni funzionalità sembra una creatura vostra, è più difficile. Ecco un metodo che funziona perché impone una decisione su ogni voce invece di lasciare tutto scivolare in «essenziale».

1. 1
   Elencate ogni funzionalità che avete immaginato

   Buttate fuori tutto — niente filtri per ora. Mettete sul tavolo l'intera lista dei desideri così che nulla resti nascosto e non detto per riapparire a metà costruzione come sorpresa.
2. 2
   Valutate ciascuna rispetto al compito centrale

   Per ogni funzionalità, chiedetevi: un utente ne ha bisogno per completare l'unico compito centrale, dall'inizio alla fine? Segnatela come «centrale», «utile» o «un giorno». Siate onesti — la maggior parte finisce nelle ultime due.
3. 3
   Tenete solo «centrale» per la v1

   Il vostro MVP è il mucchio «centrale» e nient'altro. I mucchi «utile» e «un giorno» non sono respinti: sono la vostra roadmap, parcheggiati dove appartengono.
4. 4
   Verificate il taglio col buon senso

   Guardate cosa resta e chiedetevi: un utente reale può trarre valore reale solo da questo? Se sì, avete definito un MVP. Se qualcosa rompe davvero il flusso centrale, riportate dentro solo quella voce — e nient'altro.

La disciplina sta nel passo quattro. C'è sempre la tentazione di «riportare dentro solo un'altra cosa», e poi un'altra, finché avete ricostruito in silenzio il prodotto completo. Concedetevi di salvare solo le voci che rompono davvero il flusso centrale — non quelle che lo renderebbero semplicemente più gradevole. Il più gradevole è ciò a cui serve la versione due.

Funzionante significa comunque che deve sembrare reale

C'è una modalità di fallimento dall'altro lato della linea, e merita un nome. Nella fretta di rilasciare in piccolo, alcuni fondatori rilasciano qualcosa di scadente — e lo chiamano MVP. Un flusso centrale che perde il vostro lavoro, una registrazione che dà un 404, testi pieni di segnaposto. Questo non mette alla prova la vostra idea in modo equo; mette alla prova se gli utenti tollereranno un'esperienza rotta, e la risposta è sempre no. Concluderete che l'idea è fallita quando in realtà è stata l'esecuzione.

«Minimo» si applica all'ambito, mai alla qualità della parte che tenete. Meno funzionalità, ciascuna solida. L'unico flusso che rilasciate dovrebbe sembrare finito — veloce, chiaro e affidabile — anche se è l'unica cosa che il prodotto fa. Un prodotto stretto fatto bene batte ogni volta un prodotto ampio fatto male, soprattutto quando chiedete a degli sconosciuti di affidarvi il loro lavoro.

L'MVP non è il traguardo — è la prima lettura

Ecco la parte che riformula tutto: il lancio non è l'obiettivo. L'obiettivo è ciò che imparate nelle settimane successive. Un MVP che esce e vi dice «gli utenti amano il cuore ma continuano a chiedere X» è un successo clamoroso — anche se X significa un mese di lavoro in più. Un MVP che esce nel silenzio, senza che nessuno torni, ha comunque svolto il suo compito: vi ha risparmiato di costruire le altre trenta funzionalità su fondamenta che nessuno voleva.

Pianificate quindi le prime settimane con la stessa intenzione della costruzione. Osservate cosa le persone fanno davvero, non cosa dicono nei sondaggi. Parlate con chi è tornato e con chi no. Lasciate che l'uso reale — non la vostra specifica iniziale — decida cosa va nella versione due. La roadmap che avete parcheggiato prima non è una promessa; è un'ipotesi, e i vostri utenti stanno per darle un voto.

Domande frequenti