Dall'idea al MVP SaaS: la guida passo passo per il fondatore

Quasi ogni articolo sul costruire un SaaS è in realtà scritto per qualcuno che ha già raccolto capitali. Presuppone un team, una riserva di liquidità, una roadmap e la calma di sapere che ci si può permettere di sbagliare per un anno. Se Lei è un fondatore con un'idea vera, un lavoro e dei risparmi di cui ha davvero bisogno, quel consiglio è silenziosamente pericoloso. Le dice di costruire in grande e in fretta, che è esattamente il modo in cui muore la maggior parte dei primi prodotti prima che qualcuno paghi un solo centesimo.

Da oltre un decennio aiuto le persone a trasformare le idee in software funzionante, e i fondatori che ricordo di più non sono quelli con i piani più audaci. Sono quelli che hanno cominciato in piccolo e sono rimasti onesti. Una fisioterapista che ha creato uno strumento di prenotazione per il proprio studio e ha finito per venderlo ad altri quaranta. Un addetto alla logistica che ha automatizzato le proprie scartoffie e si è reso conto che metà del settore aveva lo stesso problema. Nessuno di loro è partito da una grande piattaforma. Sono partiti da un compito doloroso e dalla disponibilità a farsi pagare per risolverlo.

Questa è dunque la guida che avrei voluto qualcuno consegnasse a quelle persone il primo giorno. Niente teatro della raccolta fondi, niente architetture alla moda, niente fingere che la prima versione debba impressionare. Solo un percorso sereno, da un'intuizione nella Sua testa fino al primo cliente pagante, e il discernimento per sapere cosa tralasciare lungo la strada.

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

Il termine prodotto minimo funzionante è stato tirato così tanto da non significare quasi più nulla. Alcuni fondatori sentono «minimo» e rilasciano qualcosa di imbarazzante che nessuno può usare. Altri sentono «prodotto» e passano otto mesi a costruire una piattaforma rifinita con fasce di prezzo, un pannello di amministrazione e una modalità scura, prima che un solo essere umano abbia confermato che pagherebbe per essa. Entrambi sono errori, e sono lo stesso errore con vestiti diversi: costruire prima di aver imparato qualcosa.

Un MVP utile è la cosa più piccola che può mettere davanti a un utente reale e che dimostra che la Sua idea centrale merita di essere pagata. Non la cosa più piccola che può costruire, ma la più piccola che Le insegna qualcosa di vero. Se la Sua idea è «uno strumento che permette ai dentisti di inviare automaticamente i promemoria di richiamo», l'MVP è il motore dei promemoria e nient'altro. Niente portale per i pazienti, niente cruscotto di analisi, niente account di team. Quelle sono risposte a domande che non si è ancora guadagnato.

Il motivo per cui questo conta così tanto è il costo. Ogni funzionalità che costruisce prima della validazione è una scommessa piazzata alla cieca. Riduca l'MVP al suo nucleo e avrà piazzato una scommessa piccola e recuperabile. Costruisca l'intera visione e avrà scommesso i risparmi, su una congettura. La disciplina del «minimo» non riguarda l'essere economici. Riguarda il restare in vita abbastanza a lungo da avere ragione.

Validi l'idea prima di scrivere una riga di codice

Ecco la verità scomoda che nessuno che Le vende sviluppo vuole dire: la maggior parte delle idee SaaS è sbagliata in qualche aspetto importante, e può scoprirlo per quasi niente. L'istinto è costruire prima e chiedere dopo. Lo inverta. La versione più economica del Suo prodotto è una conversazione, e la seconda più economica è una pagina di destinazione.

Prima di costruire qualsiasi cosa, Le servono prove di due cose. Primo, che il problema è reale e abbastanza doloroso che le persone ci dedicano già tempo o denaro, in modo goffo, con fogli di calcolo, foglietti adesivi e uno strumento che detestano. Secondo, che pagherebbero davvero per farlo sparire. «È una bella idea» non è una prova. «La userei» non è una prova. «Quanto costa, e posso iniziare lunedì?» questa è una prova.

Una pagina di destinazione con una promessa chiara e un pulsante «iscriviti alla lista d'attesa» o «prenota una demo» è il passo successivo. Se non riesce a far lasciare un'email a una manciata di sconosciuti per ciò che descrive, non è un problema di marketing da risolvere dopo: è un segnale ora, finché è ancora economico ascoltarlo. La validazione non è una fase da attraversare di corsa per arrivare alla parte divertente. Per un fondatore che spende i propri soldi, è la parte divertente: è dove evita l'errore costoso.

Trovi l'unica funzionalità senza cui il Suo prodotto non può vivere

Ogni idea SaaS, quando la descrive per la prima volta, arriva avvolta in una dozzina di funzionalità. C'è ciò che fa, e poi la costellazione di optional che la Sua mente ha già attaccato: report, integrazioni, app mobili, ruoli e permessi, un'API pubblica. L'abilità più preziosa per passare dall'idea all'MVP è imparare a spogliare via tutto questo e trovare l'unica funzionalità che, se sparisse, renderebbe l'intera cosa inutile.

Quella funzionalità centrale è il Suo MVP. Tutto il resto è un'ipotesi che testerà più avanti, una volta che le persone useranno il nucleo e Le diranno cosa manca davvero loro. I fondatori sbagliano sistematicamente l'ordine: costruiscono prima i comprimari perché dà più sicurezza, e finiscono il tempo e il denaro prima che l'unica cosa che conta venga mai rilasciata.

Il test della frase unica

Provi a descrivere cosa fa il Suo prodotto in un'unica frase senza alcun «e». «Permette agli studi di inviare promemoria automatici degli appuntamenti.» «Trasforma la foto di una ricevuta in una registrazione contabile.» «Tiene traccia dei preventivi che un artigiano ha inviato e gli ricorda di ricontattare.» Se Le serve un «e» per descrivere il valore, probabilmente ha due prodotti che lottano dentro un solo MVP, e dovrebbe rilasciare prima la metà più dolorosa.

• Scriva tutto ciò che immagina il prodotto faccia: tiri fuori tutto, non filtri.
• Per ogni voce si chieda: se questo non esistesse, qualcuno pagherebbe comunque? Cancelli ogni «sì».
• Ciò che resta dopo le cancellature è il Suo nucleo. Quello è l'MVP.
• Prenda le voci cancellate più forti e le metta in una lista «più avanti»: non eliminate, solo non ora.
• Resista alla tentazione di rimetterle. La lista «più avanti» è dove le buone idee aspettano di guadagnarsi il posto, non dove gli MVP vanno a morire.

Costruire, comprare o simulare: come realizzare l'MVP

Una volta che conosce la Sua unica funzionalità centrale, ha una scelta che i fondatori raramente fanno in modo consapevole: quanto di tutto questo deve davvero costruire da zero? La risposta onesta, per una prima versione, è di solito «meno di quanto pensa». Ci sono tre grandi strade, e la mossa intelligente è spesso un mix.

La strada no-code / di collegamento

Per alcuni MVP può collegare strumenti esistenti — un modulo, un database, un livello di automazione, un servizio email — e validare l'idea senza scrivere alcun codice su misura. Questo è brillante per verificare se le persone useranno il flusso di lavoro e pagheranno per esso. È rapido ed economico. I suoi limiti emergono più tardi: quando Le serve una vera esperienza di prodotto, un Suo modello di dati o qualcosa di genuinamente unico, il collante inizia a tendersi. È un buon problema: significa che è il momento di costruire sul serio, con utenti paganti già in mano.

La strada dello sviluppo su misura

Quando la Sua funzionalità centrale è l'elemento differenziante — il vero motivo per cui i clienti scelgono Lei —, quella parte merita software vero, su misura. L'errore è costruire su misura tutto ciò che le sta intorno. Non deve scrivere la Sua autenticazione, la gestione dei pagamenti o l'infrastruttura email; sono problemi risolti che dovrebbe noleggiare. Costruisca la parte che è unicamente Sua, noleggi il resto, e mantiene onesti sia il costo sia la tempistica.

La maggior parte degli MVP di successo che ho visto è un mix deliberato: mattoni noleggiati per l'impiantistica noiosa ma necessaria, e sviluppo su misura mirato sull'unica cosa che rende il prodotto degno di essere pagato. Sapere quale è quale — cosa costruire rispetto a cosa comprare — è esattamente il tipo di decisione su cui vale la pena avere un secondo parere prima di spendere alcunché.

Cosa può tranquillamente tralasciare nella versione uno

Sapere cosa lasciare fuori è importante quanto sapere cosa costruire, ed è dove i fondatori hanno più bisogno di un permesso. Eccolo dunque: ha il permesso di tralasciare quasi tutto. La prima versione esiste per imparare, non per impressionare, e quasi nulla di ciò che fa sembrare un prodotto «finito» La aiuta davvero a imparare.

• Più fasce di prezzo: scelga un unico prezzo, o all'inizio fatturi addirittura a mano.
• Un flusso di registrazione self-service: accogliere a mano i Suoi primi dieci clienti Le insegna più di qualsiasi imbuto automatizzato.
• Un cruscotto di amministrazione con grafici: finché ci sono dieci utenti, può leggere direttamente il database.
• Le app mobili, se per ora il web funziona bene su un telefono.
• Ruoli, permessi e account di team, finché un cliente reale non resta bloccato senza di essi.
• Impostazioni rifinite, personalizzazione dei temi e ogni caso limite: gestisca prima il percorso comune, il resto quando qualcuno lo incontra.

Un percorso realistico dall'idea al primo cliente

Ecco la sequenza che farei percorrere a quasi ogni fondatore. È volutamente lenta all'inizio e rapida una volta che si costruisce, perché gli errori costosi vivono tutti nei primi passi, quelli che i fondatori sono più tentati di saltare.

1. 1
   Scriva il problema in una frase

   Non la soluzione: il problema. «Gli studi perdono denaro per le mancate presentazioni perché i promemoria sono manuali.» Se non riesce a enunciare il problema con pulizia, non è pronto a risolverlo.
2. 2
   Abbia dieci conversazioni reali

   Parli con persone che hanno il problema. Ascolti il dolore e il denaro già speso. Adatti o abbandoni l'idea in base a ciò che sente, non a ciò che sperava.
3. 3
   Pubblichi una pagina di destinazione e un prezzo

   Descriva la promessa con semplicità, indichi un prezzo e chieda un'email o la prenotazione di una demo. Veda se gli sconosciuti si avvicinano. Questa è una validazione di cui può fidarsi.
4. 4
   Definisca l'unica funzionalità centrale

   Riduca l'idea all'unica cosa la cui assenza la rende inutile. Scriva la descrizione di una frase senza «e». Quello è il Suo perimetro di costruzione.
5. 5
   Decida costruire o comprare per ogni pezzo

   Costruisca su misura solo l'elemento differenziante. Noleggi accesso, pagamenti, email e hosting. Azzecchi questa mappa prima che qualcuno scriva codice: fissa l'intero Suo budget.
6. 6
   Costruisca la versione funzionante più piccola

   Punti a settimane, non a mesi. Se la sola funzionalità centrale richiede più di un paio di mesi, il perimetro è ancora troppo grande: tagli di nuovo.
7. 7
   Accolga a mano i Suoi primi clienti

   Li guidi di persona. Osservi dove inciampano. I primi dieci utenti sono il Suo miglior team di prodotto, e il Suo primo fatturato.
8. 8
   Migliori in base all'uso, non all'opinione

   Cambi ciò che l'uso reale Le dice di cambiare. Solo ora inizia a togliere voci dalla lista «più avanti», guadagnate dalla domanda, non aggiunte per congettura.

Quanto costa davvero: in denaro e in tempo

I fondatori chiedono sempre per prima la domanda sul costo, e la risposta onesta è «dipende, e ne controlla gran parte Lei». Il singolo fattore di costo più grande è di gran lunga il perimetro: quanto ha deciso di costruire prima di decidere di imparare. Un MVP stretto con una funzionalità centrale e l'impiantistica noleggiata è un progetto modesto e ben definito. La stessa idea costruita come piattaforma completa con tutto attivo è un universo di costo diverso e ha una probabilità molto più alta di fallire prima del lancio.

Il costo che la maggior parte delle persone dimentica è il tempo: il Suo. Ogni mese che passa a costruire qualcosa che nessuno ha confermato di voler comprare è un mese della Sua vita e dei Suoi risparmi speso su una congettura. È questo il vero argomento per iniziare in piccolo: non che piccolo sia economico, ma che piccolo è rapido, e rapido significa che impara se ha ragione mentre la scommessa è ancora recuperabile. Un fondatore che raggiunge un cliente pagante in tre mesi con uno strumento ristretto è in una posizione enormemente più forte di chi sta ancora rifinendo una grande piattaforma dopo un anno.

C'è anche un costo più silenzioso: ogni funzionalità che rilascia è qualcosa che ora deve mantenere, supportare e spiegare. Un prodotto piccolo che fa una cosa in modo affidabile è più economico da gestire, più facile da vendere e più semplice da migliorare di uno dilagante che fa dieci cose a metà. La sobrietà non è solo il modo in cui sopravvive alla costruzione: è il modo in cui mantiene l'attività vivibile dopo.

Domande frequenti