Come validare un'idea di software prima di svilupparla

Validare un'idea di software significa verificare, prima di scrivere codice, tre cose in quest'ordine: che il problema esista per persone identificabili, che quelle persone lo stiano già risolvendo in qualche modo faticoso, e che siano disposte a cambiare metodo. Si fa in poche settimane con conversazioni mirate, una pagina che descrive la proposta e al massimo un prototipo cliccabile. Il passo che quasi tutti saltano è l'ultimo: decidere in anticipo quale risultato ti farà dire che l'ipotesi è sbagliata.

Se hai un'idea in testa da mesi e ogni preventivo ti sembra alto per una cosa di cui non sei certo, il problema non è il preventivo: stai chiedendo una risposta a una domanda che non hai ancora formulato. Alla fine di questa guida avrai i passi da fare nelle prossime tre o quattro settimane e un criterio scritto per decidere se partire o fermarti.

Cosa serve prima di iniziare

• Una frase che descrive il problema, non la soluzione. Se contiene già le parole app, piattaforma o portale, riscrivila: hai descritto cosa vuoi costruire, non cosa non funziona oggi.
• Un elenco di venti persone o aziende che secondo te hanno quel problema, con nome e contatto. Non un profilo generico tipo "i piccoli artigiani", ma venti righe contattabili questa settimana.
• Il tempo di chi decide: da otto a dodici ore in tre settimane, quasi tutte di conversazioni.
• Onestà su cosa succede se la risposta è no. Se l'idea deve funzionare per forza perché hai già annunciato il progetto, non stai validando: cerchi conferme, e le troverai.

1. Definisci il problema e le persone che lo hanno

Scrivi il problema in una riga, con un soggetto preciso e una frequenza. Non "gestire i cantieri è complicato", ma "il capocantiere di un'impresa edile con dieci addetti passa ogni sera quaranta minuti a ricopiare i rapportini in un foglio di calcolo". Il risultato atteso è una frase che, letta a qualcuno di quel mestiere, gli fa dire "sì, esatto".

Definisci un segmento stretto, anche se ti sembra piccolo. Un segmento largo rende ogni risposta ambigua. Meglio cinquanta aziende con lo stesso processo che cinquemila con processi diversi: se l'idea funziona lì, la allarghi dopo.

Scrivi come il problema viene risolto oggi. Ogni problema reale ha già una soluzione: un misto di fogli di calcolo, messaggi, carta e memoria di una persona. Quello è il tuo termine di paragone, e la domanda non è se il tuo software è buono, ma se vale il fastidio di cambiare metodo.

2. Parla con utenti veri, prima di mostrare qualsiasi cosa

Chiedi conversazioni di venti minuti, non pareri sull'idea. La richiesta che funziona è "sto studiando come funziona oggi la gestione dei rapportini, mi racconti come fate voi?". Quella che non funziona è "dimmi che ne pensi della mia idea": ottiene gentilezza, non informazioni.

Fai domande sul passato, non sul futuro. "Quante volte è successo il mese scorso?", "Cosa hai fatto l'ultima volta?", "Quanto ti è costato?". Le domande sul futuro ("la useresti?", "pagheresti?") producono risposte cortesi, perché chi risponde non sta rinunciando a niente.

Registra due numeri per ogni conversazione: quante volte al mese si presenta il problema e quanto costa ogni volta. Avrai una tabella che dice, senza interpretazioni, se stai guardando un fastidio o un costo.

3. Misura la domanda con una pagina o un prototipo cliccabile

Pubblica una pagina che descrive la proposta come se esistesse già, con la promessa in due righe, tre benefici concreti e un solo pulsante. Dietro non serve niente: il pulsante raccoglie una mail e apre le iscrizioni a un gruppo ristretto. Il risultato atteso è un rapporto misurabile fra visite e iscrizioni.

Porta traffico qualificato, non traffico qualsiasi: annunci mirati per zona e settore, gruppi professionali, associazioni di categoria, la tua rete diretta. Cento visite dal segmento giusto valgono più di diecimila generiche.

Costruisci uno schema cliccabile di tre o quattro schermate e mostralo alle stesse persone che hai intervistato, chiedendo di provare un'operazione senza il tuo aiuto. Osserva dove si fermano e cosa chiedono: qui distingui le idee comprese al primo colpo da quelle che richiedono una spiegazione, e la spiegazione non scala.

4. Prezza l'ipotesi prima di costruirla

Metti un prezzo, anche provvisorio, e dillo. Finché il prodotto è gratis, tutti sono interessati. Pronunciare una cifra è il momento in cui inizi a raccogliere informazione vera, e il fatto che il prodotto non esista non è un ostacolo.

Cerca un impegno che costi qualcosa a chi lo prende. In ordine crescente di valore: una mail, una call fissata a calendario, una lettera di intenti firmata, un anticipo. Tre lettere di intenti dicono più di trecento iscrizioni a una lista.

5. Riduci il perimetro a un percorso solo

Scegli l'unico percorso che il primo rilascio deve coprire, dall'inizio alla fine, e scrivilo come sequenza di passi. Un percorso completo vale più di cinque abbozzati: le persone usano i prodotti in linea, non a pezzi.

Elenca esplicitamente cosa non ci sarà nella prima versione, prima di chiedere preventivi. È il principio del perimetro in un capitolato: la lista delle esclusioni tiene fermo il progetto quando arrivano le richieste in corso d'opera. Nella prima fase accetta anche il lavoro manuale dietro le quinte, invece di automatizzare percorsi che potrebbero non servire.

6. Scrivi in anticipo quando ti fermi

Definisci il criterio di stop prima di raccogliere i dati, in una riga con numeri e una data: "entro il 30 settembre, su dodici aziende del segmento, se meno di tre firmano una lettera di intenti, l'ipotesi è sbagliata e mi fermo". Scriverlo prima impedisce di reinterpretare i risultati dopo.

Prevedi l'esito intermedio. Molte validazioni non danno né sì né no: dicono che il problema esiste, ma in un segmento diverso da quello che avevi in mente. Lì si ripetono le conversazioni sul nuovo segmento, non si parte con il vecchio piano.

Il prototipo costruito con strumenti AI: cosa valida e cosa no

Gli strumenti di generazione assistita permettono di avere in un pomeriggio qualcosa che si apre nel browser, ha schermate coerenti e reagisce ai clic. Per validare sono utili: accorciano il tempo fra l'idea e la prima reazione di un utente. Restano però prototipi, e vanno trattati come tali.

Usali per verificare la comprensione, non la tenuta. Un prototipo del genere risponde bene a "questa cosa si capisce?", "l'utente arriva in fondo da solo?", "quali parole usa per descriverla?". Non risponde a "regge dieci utenti insieme?", "i dati sono al sicuro?", "se lo modifico fra sei mesi si rompe?".

Sappi cosa va rifatto prima di metterlo davanti a utenti veri con dati veri: gestione degli accessi, separazione dei dati fra utenti, controlli sui dati in ingresso lato server e non solo nel browser, struttura dell'archivio, registrazione degli errori. Sono le parti che un prototipo generato risolve nel modo più breve, che è la scelta corretta finché resta un prototipo.

Varianti: quattro situazioni diverse

Idea rivolta ad altre aziende. Il campione è piccolo e raggiungibile: punta alle conversazioni e agli impegni firmati più che ai numeri di traffico, e parla con chi ha potere di spesa, non solo con chi userebbe lo strumento.

Idea rivolta al consumatore. Qui contano i numeri, perché il valore per utente è basso e serve volume: la pagina di prova e il costo per iscrizione sono il segnale principale. Attenzione al canale: un risultato ottenuto con la tua rete personale non si ripete quando la rete finisce.

Azienda già avviata che vuole un prodotto nuovo. Il rischio è confondere il tuo processo con il mercato: fai descrivere il processo attuale a tre aziende esterne al tuo giro e conta le differenze.

Chi parte da zero, senza clienti né settore di riferimento. Devi scegliere un settore in cui hai accesso reale a persone. Senza quell'accesso la validazione diventa una ricerca di mercato lunga e generica.

Errori comuni

Chiedere pareri invece di raccogliere fatti. Amici e colleghi danno risposte incoraggianti perché è il comportamento educato. Sostituisci ogni domanda di opinione con una su un comportamento passato.

Costruire per non decidere. Quando i segnali sono deboli, la reazione più comune è aggiungere funzioni. Quasi sempre manca il problema, non la funzione.

Validare a lungo senza concludere. L'errore opposto esiste: sei mesi di interviste e nessuna decisione. La validazione ha una scadenza, che si scrive insieme al criterio di stop.

Quanto tempo serve

Per un'idea rivolta ad altre aziende, tre o quattro settimane bastano: una per definire il problema e i contatti, due per le conversazioni e la pagina di prova, qualche giorno per il prototipo cliccabile e la decisione. Il costo esterno resta basso; serve soprattutto tempo di chi decide.

Se il criterio dice di partire, il passo successivo è mettere per iscritto il perimetro, chiedere preventivi confrontabili ed entrare nella progettazione. Se dice di fermarti, fermati: è il risultato più economico che questa fase possa produrre, ed è il motivo per cui la si fa. Preferiamo dirlo prima di un preventivo che dopo sei mesi di sviluppo.