9 errori di sviluppo SaaS che affondano in silenzio le giovani startup

Quasi nessuno costruisce un prodotto SaaS male di proposito. Gli errori che affondano le giovani startup sono decisioni silenziose, dall'aria ragionevole, prese da persone intelligenti sotto pressione, e sul momento sembrano tutte corrette. Abbiamo visto ripetersi gli stessi nove su decine di prodotti, nei garage dei fondatori come nei team ben finanziati. La buona notizia è che sono prevedibili, il che significa che sono evitabili. Questo è l'elenco che vorremmo ogni fondatore avesse appiccicato al monitor prima di scrivere la prima riga di codice.

Sviluppiamo software per piccole e medie imprese, il che significa che veniamo chiamati in due momenti molto diversi. A volte è il giorno uno, quando non c'è altro che uno schizzo e un'idea. Più spesso, purtroppo, è il nono mese, quando un fondatore ha speso i propri risparmi, il prodotto tecnicamente funziona e tuttavia nessuno lo paga. Il secondo tipo di chiamata è quello che ci ha insegnato questo elenco. Ogni singola volta, l'autopsia rivela lo stesso piccolo insieme di ferite, inflitte presto e lasciate incancrenire.

Nessuno di questi errori riguarda il talento. Chi li commette è di solito capace e laborioso. Il problema è che costruire SaaS premia un tipo molto specifico di moderazione che non viene naturale quando si è entusiasti della propria idea. Passiamo dunque in rassegna i nove, più o meno nell'ordine in cui tendono a mordere, e siamo onesti sul perché ciascuno sia così allettante.

1. Costruire per sei mesi prima di parlare con un solo cliente

Questo è il peccato originale, ed è il più costoso. Un fondatore è convinto che l'idea sia buona — e potrebbe esserlo — quindi si chiude, costruisce a testa bassa per sei mesi ed emerge con un prodotto rifinito che nessuno ha chiesto. Il mercato non premia lo sforzo. Premia la soluzione di un problema per la cui scomparsa qualcuno pagherà.

La soluzione non è complicata, è solo scomoda: mostri qualcosa di grezzo a veri potenziali clienti prima che sia pronto. Un mockup cliccabile, una landing page, persino una versione manuale del servizio svolta a mano via e-mail. Ogni settimana passata a costruire prima di aver confermato che le persone lo vogliono è una settimana che forse sta spendendo ad arredare una casa nella strada sbagliata.

2. Costruire per un milione di utenti che non si hanno

Il secondo errore indossa il costume della professionalità. Il fondatore, o un ambizioso ingegnere dei primi tempi, progetta il sistema per reggere una scala enorme fin dal giorno uno: microservizi, Kubernetes, database multiregione, elaborati livelli di cache. Sembra responsabile. In realtà è una trappola. Sta spendendo la sua risorsa più scarsa — il tempo — per difendersi da un problema che sarebbe fortunato ad avere.

Un noioso monolite a database singolo la porterà comodamente fino ai suoi primi mille utenti e ben oltre il primo fatturato. Le decisioni di architettura che contano su grande scala non sono quasi mai quelle che può prevedere all'inizio, e la complessità prematura rende il prodotto più lento da cambiare, che, agli inizi, è l'unica cosa che davvero la uccide. Costruisca per i prossimi dieci clienti, non per il milionesimo immaginario.

3. Un MVP che non è né minimo, né valido, né un prodotto

Tutti sono d'accordo nel costruire un MVP. Quasi nessuno lo fa davvero. Ciò che viene rilasciato invece è una dilagante "versione uno" infarcita di ogni funzionalità che il fondatore sia riuscito a immaginare, perché tagliare funzionalità sembra tagliare l'ambizione. Il risultato richiede tre volte tanto, costa tre volte tanto ed è più difficile da cui imparare, perché quando un prodotto gonfio fallisce, non può dire quale parte fosse sbagliata.

Un vero MVP fa una cosa abbastanza bene da far sì che qualcuno la paghi. Tutto qui. La disciplina non sta nel decidere cosa includere; sta nel decidere cosa lasciare fuori, sapendo che ogni funzionalità "ovvia" che rinvia è una settimana che riprende e una domanda a cui potrà rispondere con utenti veri anziché con congetture.

Un rapido controllo dell'ambito

Prima che una funzionalità entri nella prima build, facciamo rispondere ai fondatori a voce alta a una domanda: "Se rilasciassimo senza questo, un solo cliente pagante rifiuterebbe di usare il prodotto?" Se la risposta onesta è no, aspetta. Si stupirà di quanto del suo elenco di funzionalità "essenziali" evapori sotto quell'unica frase.

• Se una funzionalità esiste per impressionare gli investitori, non per servire un utente, aspetta.
• Se una funzionalità gestisce un caso limite che meno di 1 utente su 20 incontrerà, aspetta.
• Se sta costruendo impostazioni per configurare un comportamento che nessuno ha ancora chiesto di cambiare, aspetta.
• Se 'il concorrente ce l'ha' è l'unico motivo per cui è nell'elenco, aspetta.
• Se rimuoverla non fermerebbe una singola vendita, aspetta.

4. Trattare fatturazione e onboarding come un ripensamento

I fondatori riversano tutto il loro amore nella funzionalità centrale e poi, due settimane prima del lancio, si ricordano che i clienti hanno bisogno di un modo per registrarsi, pagare e iniziare davvero a usare la cosa. La fatturazione viene attaccata in preda al panico. L'onboarding è una schermata di accesso e un'alzata di spalle. Ma il percorso dal "visitatore interessato" all'"utente pagante e attivato" è la sua azienda, ed è lì che la maggior parte del suo fatturato si disperde in silenzio.

Abbiamo visto prodotti con una funzionalità centrale genuinamente eccellente perdere la maggioranza delle registrazioni nei primi cinque minuti perché nessuno capiva cosa fare dopo essersi registrato. Abbonamenti, prove, ratei, pagamenti falliti, disdette, l'esperienza a stato vuoto di un account nuovo di zecca: non sono scartoffie. Sono il prodotto vero, per il cliente, nel momento in cui decide se restare.

5. Sbagliare la multitenancy (o saltarla)

Questo è quello che sembra andare benissimo fino al momento in cui è una catastrofe. SaaS significa molti clienti che condividono un unico sistema, e come separa i loro dati — la multitenancy — è una decisione fondante. La sbagli e o costruisce qualcosa che non riesce a isolare correttamente i clienti, o peggio, rilascia un bug in cui un'azienda può vedere i dati di un'altra. Non c'è modo più rapido di perdere tutti i clienti in una volta di una fuga di dati tra inquilini.

Non serve una configurazione esotica. Per la maggior parte dei prodotti in fase iniziale, un singolo database condiviso con un identificativo di inquilino rigorosamente applicato su ogni tabella e ogni query è perfettamente sufficiente, a patto che quell'isolamento sia integrato nelle fondamenta e testato, non cosparso dopo. L'errore non è scegliere l'approccio semplice. L'errore è non decidere consapevolmente e scoprire la falla quando è già in produzione.

6. Rilasciare al buio senza alcun modo di vedere cosa fanno gli utenti

Lancia. Le persone si registrano. E poi... silenzio. Non ha idea di quali funzionalità tocchino, di dove si blocchino o del perché se ne vadano. Così tira a indovinare. Costruisce la funzionalità successiva su un sospetto, o sull'e-mail del cliente più rumoroso, o sul proprio intuito — che, dopo mesi dentro al proprio prodotto, è lo strumento meno affidabile che possieda.

Un'analitica di prodotto di base e un modo semplice per raccogliere riscontri non sono un lusso da fase di crescita. Sono il modo in cui tiene il timone. Senza, non sta gestendo un'azienda, sta gestendo un'opinione costosa. Persino sapere qualcosa di semplice come "l'80% degli utenti non apre mai la funzionalità su cui ho passato due mesi" vale più di altri due mesi a costruire alla cieca.

7. Rimandare sicurezza e backup a 'dopo'

La velocità è la religione della fase iniziale, e per lo più è corretto. Ma c'è un piccolo insieme di cose catastroficamente costose da aggiungere a posteriori, e la sicurezza è in cima alla lista. Memorizzare le password correttamente, blindare chi può accedere a cosa e — per favore — avere backup funzionanti e testati non sono funzionalità opzionali da aggiungere quando si ha tempo. Sono il pavimento su cui costruisce.

La crudeltà di questa categoria è che la si fa franca fino al momento in cui non si può più. Per un anno va tutto bene, e poi una violazione, una cancellazione di massa accidentale, una mattina di ransomware cancellano la fiducia e i dati che ha passato quell'anno a costruire. Non chiediamo un reparto di sicurezza. Chiediamo che le basi ci siano fin dall'inizio, perché il costo di aggiungerle dopo un incidente si misura in aziende morte.

8. Assumere il costruttore sbagliato per la fase sbagliata

I fondatori non tecnici affrontano una scelta brutale: chi costruisce davvero questa cosa? I due errori classici si rispecchiano. Uno è assumere il freelance più economico possibile, che consegna qualcosa che sembra giusto ma è tenuto insieme con il nastro adesivo, e poi si sgretola nel momento in cui deve cambiarlo. L'altro è sovra-assumere: un team senior completo con stipendi pieni per costruire un prodotto che non si è ancora guadagnato un solo cliente.

La risposta onesta dipende interamente da dove si trova. Per validare un'idea, vuole un team piccolo, senior e pragmatico che abbia già costruito prodotti in fase iniziale e sappia esattamente cosa lasciare fuori. Per scalare un prodotto comprovato, vuole persone diverse con istinti diversi. Far combaciare il costruttore con la fase è di per sé un'abilità, e sbagliarlo spreca più denaro di qualsiasi decisione tecnica di questo elenco.

9. Trattare il lancio come il traguardo

L'ultimo errore è il più triste, perché arriva dopo così tanto duro lavoro. Il team tratta il giorno del lancio come l'obiettivo, getta tutto per arrivarci e ci arriva esausto, senza piano, senza budget e senza energie per ciò che viene dopo. Ma il lancio non è il traguardo. È l'inizio dell'unica fase che conta: imparare da utenti veri e migliorare, settimana dopo settimana.

Un prodotto SaaS non è mai "finito". La prima versione è un'ipotesi, e i mesi dopo il lancio sono quando scopre quanto fosse sbagliata, nel senso buono. I fondatori che lo pianificano, che tengono un po' di pista e molta curiosità in riserva, sono quelli che trasformano un lancio traballante in un'azienda vera. Quelli che hanno speso tutto per raggiungere la linea di partenza tendono a non andare molto oltre.

Come evitare davvero tutti e nove

Leggere un elenco di errori è facile. Evitarli sotto la pressione delle scadenze, con i propri soldi in gioco e la propria idea nel cuore, è genuinamente difficile. Ecco dunque la versione breve di come tendono a operare i fondatori che fanno bene: non come regole, ma come abitudini che vale la pena rubare.

1. 1
   Validare prima di costruire

   Metta qualcosa di grezzo davanti a veri potenziali clienti e confermi che pagheranno, prima di scrivere codice serio. Economico da fare, brutale da saltare.
2. 2
   Scegliere il prodotto reale più piccolo

   Definisca l'unica cosa che il suo prodotto deve fare e rinvii spietatamente tutto il resto. Metta per iscritto ciò che la 'versione uno' deliberatamente non include.
3. 3
   Costruire noioso e isolare gli inquilini

   Usi l'architettura più semplice che funzioni, ma faccia della separazione dei dati tra clienti una decisione fondante e testata fin dal giorno uno.
4. 4
   Progettare presto il percorso del denaro

   Tratti registrazione, onboarding e fatturazione come prodotto centrale, non scartoffie. I primi cinque minuti decidono se il resto verrà visto.
5. 5
   Strumentarlo, poi lanciare per imparare

   Rilasci con analitica e riscontri di base in funzione, tenga pista per la fase dopo il lancio e tratti la prima versione come una domanda, non una risposta.

Noti che quasi niente di tutto questo riguarda l'abilità di programmazione. Riguarda il giudizio: sapere cosa costruire, cosa saltare e quando. È esattamente per questo che così tanti team tecnicamente capaci producono comunque prodotti che falliscono: la parte difficile del SaaS non è mai stata l'ingegneria. È stata la moderazione.

Domande frequenti