Pronto per gli investitori non vuol dire completo
Due obiettivi che vengono confusi
C'è una differenza sostanziale fra un prodotto pronto per il mercato e un prodotto pronto per una raccolta. Il primo deve reggere l'uso quotidiano di chi paga. Il secondo deve rendere credibile una tesi: che esiste un problema, che sapete risolverlo, e che siete la squadra capace di farlo su scala più grande.
Sono obiettivi diversi e portano a scelte diverse su cosa costruire. Confonderli è il modo più comune di sprecare le settimane prima di un round, di solito aggiungendo funzionalità che non spostano nulla nella conversazione con l'investitore.
Cosa guarda davvero chi investe
Nella pratica, chi valuta guarda quattro cose, in quest'ordine.
Che il prodotto esista e funzioni. Un link che si apre, un flusso che va da capo a fondo senza inceppare. La differenza fra un mockup e un prodotto che gira è enorme, molto più della differenza fra un prodotto con dieci funzionalità e uno con venti.
Che qualcuno lo usi. Anche pochi utenti, purché veri e non amici. Venti utilizzatori reali con un comportamento osservabile valgono più di duemila iscrizioni a una lista d'attesa. La domanda che arriva sempre è: tornano?
Che sappiate cosa state misurando. Non serve una dashboard elaborata. Serve sapere quanti entrano, quanti completano l'azione principale, quanti tornano dopo una settimana, e sapere spiegare perché quei numeri sono quelli. Una squadra che conosce i propri dati grezzi è più convincente di una che mostra grafici che non sa commentare.
Che il passo successivo sia chiaro. Cosa fate con i soldi, in che ordine, e quale ipotesi verificate per prima. È qui che il prodotto e il piano devono combaciare.
Nessuna di queste quattro cose migliora aggiungendo funzionalità. Alcune peggiorano: un prodotto più largo è più difficile da spiegare in dieci minuti, e la demo è il momento in cui la larghezza diventa un costo.
Cosa peggiora la demo
Le funzionalità a metà. Una schermata che esiste ma non fa nulla è peggio di una schermata assente. Chi guarda ci clicca — clicca sempre — e quello che trova diventa il tema della conversazione. Meglio togliere che lasciare a metà.
Il dato di prova poco credibile. Utenti chiamati "Mario Rossi 1", importi da 999 euro ovunque, date tutte uguali. Il contenuto della demo comunica quanto seriamente state prendendo il prodotto. Popolarlo con dati verosimili è mezza giornata di lavoro e cambia la percezione.
Le prestazioni sotto pressione. Il momento peggiore per scoprire che una schermata impiega otto secondi a caricare è mentre qualcuno la sta guardando. Vale la pena provare il flusso della demo su una connessione lenta e con qualche migliaio di record.
Le promesse messe nell'interfaccia. Etichette come "presto disponibile" sparse nel prodotto raccontano che c'è più roadmap che sostanza. La roadmap sta nelle slide, dove si può contestualizzare.
Le cose invisibili che invece contano
Alcune cose non si vedono nella demo ma emergono nella due diligence tecnica, e sono quelle su cui conviene non risparmiare.
I dati devono essere vostri: codice, database e infrastruttura intestati alla società, non all'account personale di un fondatore o di un fornitore. È un controllo che viene fatto sempre, e trovarlo irrisolto rallenta un round nel momento peggiore.
Il trattamento dei dati personali deve essere difendibile. Non serve un apparato da multinazionale, serve sapere quali dati raccogliete, dove stanno, chi vi accede e con che base giuridica.
I backup devono essere stati provati almeno una volta. Un backup mai ripristinato non è un backup, è una speranza.
E deve esistere qualcuno che sa rimettere in piedi il sistema se cade. Nome e cognome, o un contratto. È una domanda che arriva più spesso di quanto si creda.
Le ultime tre settimane, spese bene
Se mancano tre settimane a un round, l'allocazione che rende di più raramente è "nuove funzionalità". Più spesso è questa: una settimana per far funzionare perfettamente il flusso principale, compresi i casi in cui l'utente sbaglia; una settimana per portare a bordo utenti veri e osservare cosa fanno; qualche giorno per sistemare dati di prova, prestazioni e i due o tre punti in cui il prodotto è palesemente ruvido.
E poi provare la demo. Ad alta voce, con qualcuno che non conosce il prodotto, almeno tre volte. Il numero di cose che si scoprono alla terza prova è sistematicamente più alto di quanto ci si aspetti.
La domanda tecnica che arriva sempre
Prima o poi, in quasi ogni conversazione, arriva una versione di questa domanda: "e se domani aveste diecimila utenti?". Non è una richiesta di avere già l'infrastruttura per diecimila utenti — costruirla adesso sarebbe anzi un cattivo segnale, perché significa aver speso su un problema che non avete.
È una domanda su quanto conoscete il vostro sistema. La risposta buona è concreta e onesta: sappiamo che il primo punto a cedere sarebbe questo, sappiamo più o meno a quale soglia, e sappiamo cosa faremmo. Sapere dove si romperebbe vale molto più che sostenere che non si romperebbe, che nessuno crede comunque.
Vale lo stesso per i costi: sapere quanto costa servire un utente oggi, anche approssimativamente, è una di quelle informazioni che distinguono una squadra che ha guardato i propri numeri da una che ha guardato solo il prodotto.
Dopo il round comincia il problema vero
Vale la pena dirlo, perché è la fase in cui si sbaglia di più. Un prodotto costruito per raccogliere non è ancora un prodotto costruito per crescere: le scorciatoie prese per arrivare alla demo vanno ripagate, e vanno ripagate presto. La differenza fra le squadre che accelerano dopo un round e quelle che si impantanano sta quasi sempre in quanto onestamente hanno tenuto la lista di quelle scorciatoie.
Se la lista esiste, è un piano. Se non esiste, il debito c'è lo stesso — solo che lo scoprirete un pezzo alla volta, nel momento in cui state assumendo e promettendo date.
Un investitore non compra funzionalità. Compra la convinzione che sappiate costruire la cosa giusta più in fretta degli altri — e il prodotto serve a dimostrarlo, non a coprire tutto.
