Come validare un'idea di SaaS prima di scrivere una sola riga di codice

Il modo più costoso per scoprire se le persone vogliono il suo software è costruirlo. Eppure è esattamente ciò che fa la maggior parte dei fondatori alle prime armi: passano sei mesi e i loro risparmi a trasformare un'idea in codice, la lanciano nel silenzio e solo allora iniziano a chiedersi se qualcuno ne avesse bisogno. La validazione è la versione economica di quella lezione. È il modo per comprare la risposta con qualche settimana di conversazioni invece che con un anno della propria vita.

Ho visto molte persone intelligenti cadere nella stessa trappola. Hanno un'osservazione davvero valida — un fastidio reale in un settore che conoscono — e presumono che la distanza tra l'osservazione e il prodotto sia solo una questione di ingegneria. Non lo è. Quella distanza è piena di domande senza risposta: qualcun altro avverte questo dolore abbastanza da pagare? Abbandoneranno ciò che fanno oggi? Riesce a raggiungerli senza bruciare denaro? A queste domande non si risponde scrivendo codice. Si risponde parlando con le persone e osservando ciò che fanno davvero.

Questa è quindi la guida che do ai fondatori prima che assumano qualcuno per costruire qualcosa. Non si tratta di teatrino lean-startup né di riempire un canvas. Si tratta di una manciata di esperimenti onesti ed economici che le dicono se la sua idea ha un battito — e della disciplina di credere ai risultati, anche quando pungono.

Perché costruire prima sembra produttivo — e quasi mai lo è

Costruire è seducente perché sembra un progresso che si può vedere. Alla fine di una sessione di codice c'è una schermata che funziona, un pulsante che fa qualcosa, una cosa da mostrare al partner. Parlare di un problema con degli sconosciuti non produce alcun oggetto. È scomodo, è lento e alla fine non ha altro che appunti. Così i fondatori afferrano la tastiera, perché la tastiera li ricompensa più in fretta.

Il guaio è che una schermata funzionante non le dice quasi nulla sul fatto che l'idea sia giusta. Può costruire un prodotto bellissimo e privo di bug per un problema che nessuno ha, e sarà altrettanto morto di uno brutto. Il codice è la risposta a «come lo consegniamo?» — non a «qualcuno lo vuole?». Passare mesi sulla prima domanda prima di aver risposto alla seconda è il modo in cui i bravi ingegneri costruiscono soluzioni eleganti a problemi immaginari.

La validazione ribalta l'ordine. Lei passa qualche settimana e pochissimo denaro a dimostrare — o a smentire — l'ipotesi più rischiosa della sua idea prima di impegnarsi a costruire. Se l'idea è solida, entra nello sviluppo con prove, una specifica più chiara e i suoi primi utenti già in attesa. Se è debole, lo scopre al prezzo di qualche caffè e di una pagina di destinazione, non a quello di un prodotto.

Trovi l'unica ipotesi che potrebbe far crollare tutto

Ogni idea di SaaS poggia su una pila di convinzioni, e non sono ugualmente pericolose. Alcune sono sicure: «le persone usano l'e-mail», «alle piccole imprese non piacciono le scartoffie». Altre sono scommesse da cui dipende l'intera iniziativa e, se sbagliate, nient'altro conta. Il compito della validazione non è testare tutto. È trovare l'ipotesi più rischiosa e attaccare per prima proprio quella.

Per trovarla, scriva la sua idea in una sola frase: «[queste persone] hanno [questo problema] in modo abbastanza forte da pagare per [questa soluzione] invece di [ciò che fanno ora].» Poi si chieda, senza pietà: quale parola di quella frase, se si rivelasse falsa, affonderebbe l'idea? Di solito non è la soluzione. È se il problema fa abbastanza male da indurre a pagare, o se può davvero raggiungere quelle persone a un costo sostenibile.

Questa sequenza conta perché il costo del test sale a ogni passo. Un'intervista sul problema è gratuita. Un test di disponibilità a pagare costa una pagina di destinazione. Un test della soluzione potrebbe richiedere un prototipo cliccabile. Costruire è il test più costoso di tutti. Lei vuole fallire a basso costo e presto, non a caro prezzo e tardi — quindi mette davanti i test più economici e più letali.

Parli con le persone — ma lo faccia nel modo giusto

La cosa più utile che può fare è parlare con le persone che ritiene abbiano il problema. Non i suoi amici, non altri fondatori — gli esseri umani reali che lo userebbero. Ed ecco l'inganno che rovina la maggior parte dei tentativi: le persone sono educate. Chieda «userebbe uno strumento che fa X?» e quasi tutti diranno sì, perché dire sì è gratuito e gentile. Quel sì non vale nulla. Ha affondato più startup di qualunque fallimento tecnico.

La soluzione è smettere di chiedere del futuro e iniziare a chiedere del passato. Il futuro è il luogo in cui le persone mentono per essere gentili; il passato è il luogo in cui vive la verità. Invece di «userebbe questo?», chieda «mi racconti l'ultima volta che ha avuto a che fare con questo problema». Cosa ha fatto? Quanto tempo ci è voluto? Quanto le è costato? Ha cercato una soluzione? Ne ha pagata una? Il comportamento reale batte l'entusiasmo ipotetico ogni singola volta.

Domande che ottengono risposte oneste

• «Mi accompagni attraverso l'ultima volta che è successo.» — fa emergere il flusso di lavoro reale, non una versione idealizzata.
• «Cosa ha fatto al riguardo?» — rivela se la cosa le interessa davvero o se si limita a scrollare le spalle.
• «Quanto tempo o denaro le è costato?» — trasforma un dolore vago in un numero.
• «Ha già provato a risolverlo prima? Com'è andata?» — le dice se ci sono budget e intenzione.
• «Cos'altro la infastidisce più di questo in questo momento?» — verifica se il suo problema rientra anche solo nella loro top cinque.

Quante conversazioni? Meno di quante immagini. Quando avrà condotto dieci interviste oneste e ben fatte con le persone giuste, lo schema sarà di solito evidente. O tre o quattro di loro si illuminano e descrivono il dolore con dovizia di particolari — oppure sono tutte cortesemente tiepide, e nessuno sviluppo, per quanto ingegnoso, lo correggerà. Da dodici a quindici bastano abbondantemente per prendere una decisione di cui fidarsi.

Modi economici per testare la domanda reale

Le conversazioni le dicono se il problema è reale. La domanda successiva è se le persone agiranno — e l'unico modo per saperlo è chiedere un piccolo impegno prima che il prodotto esista. È qui che la validazione diventa un po' scomoda, ed è anche qui che diventa onesta. Parlare costa poco; un clic, un indirizzo e-mail o un acconto no.

Non deve costruire nulla per condurre questi test. Le serve un'unica pagina che descriva chiaramente la promessa e chieda un'azione specifica. L'azione è il dato. Se le persone leggono il suo pitch e non fanno nulla, quella è la sua risposta, ed è una risposta molto più economica del lanciare nel vuoto tra sei mesi.

1. 1
   Pubblichi un pitch di una pagina

   Descriva il problema e la sua soluzione in un linguaggio semplice, con una chiamata all'azione chiara. Una semplice pagina di destinazione è sufficiente — per ora senza alcun prodotto dietro.
2. 2
   Chieda un segnale reale

   Non un «mi piace». Chieda alle persone di iscriversi a una lista d'attesa con la loro e-mail, di preordinare o di prenotare una chiamata. Più dire sì costa loro, più quel sì significa.
3. 3
   Porti un po' di traffico onesto

   Lo condivida dove il suo pubblico reale già si trova — una community pertinente, un piccolo annuncio, qualche messaggio diretto. Vuole sconosciuti, non la sua rete benevola.
4. 4
   Legga la conversione, non i complimenti

   Tra tutti coloro che hanno davvero compreso l'offerta, quanti hanno compiuto l'azione? Una manciata di iscrizioni reali dalle persone giuste vale più di mille auguri vaghi.

Il test della domanda più potente di tutti è chiedere denaro in anticipo. Una prevendita, un pilota a pagamento, un acconto per l'accesso anticipato — qualsiasi cosa in cui si apra un portafoglio. Sembra aggressivo, ed è la cosa più onesta che possa fare per sé stesso. Chi consegna anche solo una piccola somma per un prodotto che non esiste ancora le sta dicendo qualcosa che nessun sondaggio potrebbe. Se trova tre o quattro di queste persone, non ha più un'idea. Ha un'attività che aspetta solo di essere costruita.

Lo venda prima di costruirlo

C'è un passaggio tra «le persone sono interessate» e «le persone pagheranno ogni mese» che merita la propria attenzione: consegnare il valore manualmente prima di automatizzarlo. Se la sua idea è, poniamo, uno strumento che trasforma e-mail disordinate dei fornitori in un ordinato report settimanale, lo faccia prima a mano per tre o quattro clienti. Lei diventa il software. È lento e non scala, ed è proprio questo il punto — le permette di imparare cosa il prodotto deve davvero fare prima di averlo fissato nel codice.

Questo ottiene due cose insieme. Dimostra che le persone pagheranno per il risultato, non solo per l'idea di esso. E le insegna il flusso di lavoro reale — i casi limite, le eccezioni, i dettagli a cui i clienti tengono e che da un'intervista non avrebbe mai indovinato. Quando finalmente costruirà, non tirerà a indovinare sulla specifica. Codificherà un processo che ha già eseguito a mano e per cui è stato pagato.

Leggere i segnali con onestà

Tutto questo funziona solo se è disposto a credere ai risultati — e questo è più difficile di quanto sembri, perché a questo punto è affezionato all'idea. Il pericolo non sono i dati cattivi; è un fondatore che interpreta ogni segnale come un incoraggiamento. Un interesse tiepido viene ricordato come entusiasmo. Un'educata iscrizione alla lista d'attesa diventa «forte domanda». Qui deve combattere il suo stesso ottimismo.

Aiuta decidere, in anticipo, che aspetto ha una promozione. Prima di condurre un test, annoti il risultato che la spingerebbe a proseguire e quello che la spingerebbe a fermarsi. «Se meno di X delle mie interviste descrivono questo come un problema reale e ricorrente, lo abbandono.» Fissare l'asticella prima di vedere i dati è l'unica difesa affidabile contro il convincersi da soli di uno sviluppo che non si dovrebbe fare.

E a volte la risposta onesta è no. Non è un fallimento — è il sistema che funziona. Un processo di validazione che non può mai restituire «non costruirlo» non è validazione, è ricerca di permesso. I fondatori che vincono nell'arco di una carriera non sono quelli che non hanno mai idee cattive. Sono quelli che uccidono le idee cattive in tre settimane per qualche centinaio di euro invece di coccolarle per un anno.

Quando è davvero pronto a costruire

Diciamo che i segnali siano buoni. Il problema è reale, le persone lo hanno descritto con trasporto, alcune hanno messo del denaro. Ora — e solo ora — costruire ha senso. Ma anche qui la moderazione paga. L'obiettivo della sua prima versione non è essere il prodotto che immagina. È consegnare l'unico risultato centrale per cui i suoi clienti validati pagano, e niente altro per ora.

È qui che la validazione le consegna in silenzio un dono: una specifica nitida e supportata da prove. Sa per chi è, qual è il compito centrale, per cosa le persone pagheranno e quali funzionalità sono emerse più e più volte rispetto a quelle che interessavano solo a lei. Quella chiarezza vale più di qualsiasi quantità di progettazione preliminare. È la differenza tra costruire la piccola cosa giusta e costruire un tutto costosissimo.

Domande frequenti