Dall'idea ai primi utenti paganti: come abbiamo lanciato un SaaS B2B

È arrivata con un foglio di calcolo, un'intuizione e una scadenza che il convegno del suo settore le aveva imposto senza chiederle nulla. Tra quattro mesi sarebbe stata su un piccolo palco davanti a circa duecento persone che gestivano esattamente il tipo di impresa che la sua idea intendeva servire. Voleva poter mostrare loro qualcosa di reale: non slide, non un mockup, ma un prodotto in cui un estraneo potesse accedere e pagare. È da quella conversazione che parte questo caso studio, e la cosa più utile è quanto fosse ordinario il punto di partenza.

Abbiamo cambiato di proposito i dettagli identificativi. La fondatrice è reale, il prodotto è online, e i numeri sono vicini alla verità ma arrotondati e attenuati perché nessuno possa risalire a chi si tratta. Ciò che conta non è la nicchia specifica, ma la forma del percorso, perché quella forma si ripete quasi ogni volta che un fondatore non tecnico cerca di trasformare una buona idea in software funzionante. Se Lei si trova più o meno all'inizio di quella strada, ecco a grandi linee come possono andare i prossimi mesi quando le cose vanno bene.

La versione breve: un settore che conosceva a fondo, un processo manuale faticoso che tutti vi tolleravano, un foglio di calcolo con cui lo svolgeva in silenzio meglio dei suoi colleghi, e zero formazione tecnica. Undici settimane di lavoro concentrato dopo, c'erano i primi utenti paganti. Ecco come, e — più onestamente — ecco dove abbiamo inciampato.

La situazione: un foglio di calcolo che fa un lavoro vero

La fondatrice gestiva una piccola società di consulenza in un ambito regolamentato e ricco di documenti. I suoi clienti erano altre piccole imprese, e ognuna di esse lottava con la stessa incombenza ricorrente: raccogliere una pila di moduli, controllarne la completezza, rincorrere i pezzi mancanti e produrre un riepilogo pulito prima di una scadenza. La maggior parte dei suoi concorrenti lo faceva con e-mail, telefonate e una cartella di modelli Word. Lei lo faceva con un foglio di calcolo che aveva costruito e raffinato in quattro anni, e i suoi clienti la adoravano in silenzio per questo.

Quel foglio di calcolo era tutta l'intuizione. Non era un business plan né un'analisi di mercato: era una prova. Le persone si affidavano già al suo strumento, le chiedevano di usarlo per imprese che nemmeno consultava, si offrivano di pagare solo per l'accesso. Quando i clienti cercano di comprare qualcosa prima che Lei l'abbia costruita, può smettere di indovinare se c'è domanda. La domanda non è mai stata se valesse la pena farlo. La domanda era se questo potesse diventare un software che un'altra persona può usare senza che lei stia seduta accanto.

I suoi vincoli erano altrettanto reali. Un budget fisso che usciva dai suoi risparmi, non da un fondo. La scadenza del convegno. E una regola ferrea su cui ci siamo accordati presto: questo non poteva diventare un progetto che richiedeva la sua attenzione ogni giorno, perché aveva ancora una consulenza da mandare avanti. Qualunque cosa avessimo costruito doveva essere completabile, sostenibile e noiosa da gestire. Quelle tre parole hanno plasmato ogni decisione successiva.

Il primo compito è stato decidere cosa NON costruire

Quando i fondatori descrivono il prodotto dei loro sogni, l'elenco delle funzioni è sempre enorme, perché lo immaginano da anni. Il suo riempiva due pagine: dashboard, permessi di team, un registro di audit, promemoria automatici, un portale rivolto ai clienti, fatturazione, analisi, integrazioni con tre strumenti che i suoi clienti usavano e — naturalmente — «un po' di IA da qualche parte là dentro». Ogni voce era ragionevole. Costruirle tutte prima del lancio sarebbe stato un disastro.

Così abbiamo fatto l'esercizio che facciamo con tutti: per ogni funzione abbiamo posto un'unica domanda diretta. Se questa mancasse il giorno del lancio, un cliente si rifiuterebbe di pagare? Non «sarebbe più bello con questa», ma se la vendita morirebbe davvero. La maggior parte delle funzioni fallisce quel test, ed è proprio quello il punto. Quelle che sopravvivono sono il Suo vero prodotto. Tutto il resto è una roadmap, una cosa bella da avere, ma non quella che si costruisce per prima.

Ciò che è sopravvissuto era quasi imbarazzante per quanto piccolo. Un utente poteva creare un account, impostare una pratica, invitare il proprio cliente a caricare i documenti richiesti e riavere lo stesso riepilogo pulito e verificato che produceva il suo foglio di calcolo — solo che automaticamente, e senza lei nel mezzo. Tutto qui. Niente dashboard. Niente ruoli di team. Niente IA, non ancora. Quattro funzioni, un compito chiaro, fatto come si deve.

Cosa abbiamo davvero costruito in undici settimane

Lavoriamo per cicli brevi e visibili, anziché sparire per tre mesi e tornare con una sorpresa. Circa ogni settimana la fondatrice riceveva un link a qualcosa su cui poteva cliccare, anche quando era brutto e collegato a metà. Quel ritmo conta più di quanto sembri: manteneva le sue decisioni piccole e frequenti, invece di lasciarle accumulare in un'unica spaventosa revisione finale.

Settimane 1–3: la spina dorsale

Prima abbiamo costruito il nucleo poco affascinante: gli account, un modo sicuro di archiviare i documenti e il modello dati sotto il flusso delle pratiche. Niente di tutto questo è visibile a un cliente, e tutto questo è la parte costosa da sistemare in seguito se la si fa di fretta. Poiché il prodotto gestiva documenti sensibili di altre imprese, abbiamo trattato il controllo degli accessi e la separazione dei dati come un requisito di lancio, non come un miglioramento successivo. È uno dei pochi punti in cui ci siamo rifiutati di tagliare.

Settimane 4–7: il vero lavoro

Poi la parte che lo rendeva degno di essere pagato: trasformare la logica del suo foglio di calcolo nel motore che controlla la completezza dei documenti e produce il riepilogo. Era il cuore del prodotto e gli abbiamo dedicato più tempo. Ci siamo seduti con lei e abbiamo smontato il perché di ogni regola nel suo foglio di calcolo — e parecchie si sono rivelate abitudini più che requisiti, il che ci ha permesso di semplificare. Entro la fine della settima settimana si poteva eseguire una pratica reale dall'inizio alla fine.

Settimane 8–11: renderlo sicuro per farsi pagare

L'ultimo tratto è stato la differenza tra una demo e un prodotto. Il pagamento, perché le persone potessero davvero abbonarsi. Una registrazione pulita che non richiedeva un manuale. La dozzina di piccoli stati di errore che decidono se un estraneo si fida del Suo software o se ne va. E i test — noiosi, ripetitivi — con la fondatrice e due clienti benevoli che hanno accettato di romperlo di proposito prima che lo facessero gli estranei. Quell'ultimo gruppo si è guadagnato lo sconto di accesso anticipato molte volte.

La domanda «mettici un po' di IA», con risposta onesta

La sua lista dei desideri conteneva l'IA, come ormai quasi tutte. Abbiamo obiettato, e vale la pena spiegare perché, perché è lo stesso consiglio che diamo a quasi tutti. Il lavoro che la versione uno doveva svolgere — controllare un insieme noto di documenti rispetto a un insieme noto di regole — è un lavoro che le regole fanno meglio dell'IA. È prevedibile, è verificabile, e quando un cliente regolamentato chiede «perché il sistema ha segnalato questo», Lei vuole una risposta chiara, non una scrollata di spalle.

Questo non significa che l'IA non avesse spazio. C'era un problema genuinamente disordinato, di natura linguistica, nascosto nel flusso: i clienti spesso caricavano documenti quasi giusti ma etichettati male, oppure incollavano informazioni come testo libero invece di compilare il modulo. Leggere quel groviglio e ordinarlo è esattamente ciò in cui l'IA moderna è brava. Quindi lo abbiamo annotato con cura — e poi lasciato alla versione due. Aggiungerlo prima del lancio avrebbe ritardato la scadenza per rifinire una funzione che nessuno aveva ancora chiesto di pagare.

Ottenere i primi utenti paganti

Ecco la parte che preoccupa di più i fondatori e per cui si preparano di meno. Un prodotto che nessuno riesce a trovare non è un'impresa, è un hobby. Ma questa fondatrice aveva un vantaggio che valeva più di qualsiasi budget di marketing: aveva già un pubblico che si fidava di lei, e alcuni di loro avevano chiesto di pagare prima che il software esistesse. Il piano di lancio si è appoggiato interamente su questo, e così dovrebbe fare anche il Suo, se ce l'ha.

Invece di un lancio pubblico clamoroso, abbiamo fatto il contrario: uno silenzioso e deliberato. Due settimane prima del convegno, ha scritto alla manciata di clienti che avevano già chiesto, ha offerto loro un prezzo da membro fondatore e li ha attivati a mano, osservando in videochiamata come lo usavano. Ogni confusione diventava una correzione. Quando è salita su quel palco, non proponeva un'idea; descriveva un software che i suoi colleghi già pagavano, e poteva dirlo onestamente.

1. 1
   Inizi dalle persone che stanno già chiedendo

   Il suo primo contatto è andato solo ai clienti che in precedenza si erano offerti di pagare. La domanda calda converte prima ancora che quella fredda risponda.
2. 2
   Attivi i primi a mano

   Nessun eroismo self-service all'inizio. Ha accompagnato dal vivo ogni primo utente, trasformando ogni punto di confusione in una correzione concreta.
3. 3
   Prezzo per i fondatori, non per sempre

   I primi utenti hanno avuto una tariffa fondatore chiaramente limitata nel tempo. Premiava il loro rischio e dava ai clienti successivi un motivo per l'aumento dei prezzi.
4. 4
   Usi la scadenza come lancio

   Il convegno non era un trucco di marketing aggiunto dopo: era la forzatura che ha mantenuto onesto il perimetro per tutto il percorso.

Il risultato — e cosa significa davvero

Alla fine del mese di lancio, il prodotto aveva i suoi primi abbonati paganti — un numero piccolo, del tipo che si conta ancora su due mani, ognuno un'impresa reale che pagava un vero canone mensile. Sembra modesto, e lo è. È anche il traguardo più difficile di tutta la vita di un prodotto software. Passare da zero clienti paganti a qualcuno è molto più difficile che passare da qualcuno a molti, perché è il momento in cui l'idea smette di essere Sua e diventa quella del mercato.

I numeri qui sotto sono indicativi e arrotondati, ma sono fedeli alla forma di ciò che è accaduto. Ciò che vogliamo che ne tragga non sono le cifre — sono le proporzioni. Una prima versione strettamente definita, un budget piccolo e mirato, una tempistica breve e un lancio puntato sulla domanda calda anziché su tutta internet.

Dove abbiamo sbagliato

Un caso studio che elenca solo successi è una pubblicità, quindi ecco la parte onesta. Abbiamo commesso due errori che vale la pena nominare, perché Lei sarà tentato dagli stessi.

Primo, abbiamo sottovalutato l'onboarding. Avevamo definito il prodotto con cura, ma trattato i primi cinque minuti dell'esperienza di un nuovo utente come un ripensamento, qualcosa da sistemare alla fine. Si è rivelato il momento decisivo, e abbiamo passato una settimana non prevista a ricostruire la registrazione e la prima schermata vuota perché un estraneo potesse capire cosa fare senza che glielo dicessero. La prossima volta, l'esperienza di primo utilizzo è una funzione dal primo giorno, non dalla decima settimana.

Secondo, abbiamo lasciato che una regola «piccola» del motore di controllo si gonfiasse. La fondatrice ha menzionato un caso limite quasi di sfuggita, abbiamo convenuto che fosse facile, e in silenzio ha divorato tre giorni perché i dati del mondo reale erano più disordinati di quanto il suo foglio di calcolo pulito avesse mai rivelato. La lezione non era «evita i casi limite» — era che il suo foglio di calcolo aveva svolto in silenzio una pulizia manuale che lei aveva dimenticato di fare. Il software deve rendere visibile quel lavoro invisibile, e questo costa sempre più di quanto chiunque si aspetti.

Se si trova dove si trovava lei

Ciò che ha fatto funzionare tutto questo non è stata un'architettura ingegnosa né uno strumento alla moda. È stata disciplina sul perimetro e onestà sulla domanda. Lei aveva la prova che le persone lo volevano prima che scrivessimo una riga di codice, e siamo stati spietati nel costruire la versione più piccola per cui qualcuno avrebbe comunque pagato. Nessuna di queste cose richiede una formazione tecnica. Entrambe sono cose che può iniziare questa settimana, da solo.

Se ha un foglio di calcolo che le persone Le chiedono continuamente di eseguire, o un processo manuale per cui i Suoi clienti La ringraziano, potrebbe essere più vicino a un prodotto di quanto pensi. La mossa pericolosa è immaginare la versione finita, completa di funzioni, e bloccarsi davanti a quanto sembra grande. Non lo faccia. Trovi l'unico compito che deve assolutamente svolgere, costruisca solo quello e lo metta davanti a chi sta già chiedendo. La roadmap può aspettare. Il primo utente pagante no.

Domande frequenti