Il prototipo contro il prodotto: come capire quando la tua app creata con l'IA è davvero pronta

Qualche settimana fa, una founder che conosco ha creato un’app per la prenotazione di appuntamenti per terapeuti. L’intera cosa le ha richiesto quattro giorni con un creatore di app con IA. Fa quello che le serve: i terapeuti vedono il loro calendario, i clienti prenotano appuntamenti, le conferme partono via email. Funziona.

La sta fissando da due settimane e non l’ha lanciata.

Quando le ho chiesto perché, ha detto: “Funziona, ma… non sembra pronta”.

Le ho chiesto cosa cambierebbe. Ha detto: “Non lo so. È quello il problema”.

Questo è il momento più difficile nel creare con un creatore di app con IA. La cosa è funzionante, ma c’è un divario tra “funzionante” e “mi sentirei a mio agio a chiedere a persone vere di usarla”. Capire quel divario — e sapere da che lato ti trovi davvero — è la differenza tra pubblicare e restare bloccato per sempre nella fase della-voce-nella-testa.

Cosa significa davvero “pronta”

Ecco la distinzione che conta: un prototipo è qualcosa che usi per testare un’idea. Un prodotto è qualcosa che usi per risolvere un problema.

L’app di prenotazione per terapeuti è un prototipo. Dimostra che il concetto funziona. Un terapeuta potrebbe usarla. Ma ci sono diciassette piccole cose che la fanno sembrare grezza:

• Le email di conferma sono spoglie. Niente logo, niente personalizzazione del brand, testo generico.
• Le cancellazioni non inviano notifiche. I clienti semplicemente non si presentano.
• Non c’è una lista d’attesa se un terapeuta è al completo.
• Il flusso di iscrizione non raccoglie le specializzazioni del terapeuta, quindi non c’è modo di filtrare per tipo di pratica.
• Non c’è un’email di promemoria inviata 24 ore prima dell’appuntamento.

Nessuna di queste cose rompe l’app. Tutte fanno pensare a un terapeuta vero: “Sembra una cosa messa insieme in un fine settimana, non una cosa per cui mi stanno facendo pagare”.

Quella sensazione è reale, e conta. Un prototipo risolve il problema in teoria. Un prodotto lo risolve nella pratica, per la persona vera che lo usa.

Tre domande che separano il prototipo dal prodotto

Ecco la parte difficile: non puoi sapere tutto quello che manca. Nemmeno il tuo creatore di app può saperlo. Quindi ti servono tre domande veloci per capire da che lato della linea ti trovi.

1. Useresti questa app per risolvere il tuo problema?

Questa è onesta, perché devi davvero convivere con il tuo prodotto.

Se sei la founder di quell’app di prenotazione per terapeuti, la useresti per prenotare i tuoi appuntamenti di terapia? Non “potresti” — la useresti davvero al posto di uno scambio di email o di un Google Doc condiviso?

Se la risposta è no, non sei pronta. Sai esattamente cosa c’è di sbagliato — lo senti ogni volta che apri l’app. Se la risposta è sì, sei più vicina.

La founder che ho citato ha completato la propria iscrizione come terapeuta. Si è bloccata al modulo (chiedeva troppe informazioni prima di lasciarla prenotare). Ha visto l’email di conferma e ha pensato che sembrasse dilettantesca. Ha iniziato a pensare a come il suo terapeuta avrebbe ricevuto l’email e se sarebbe finita nello spam.

Non stava usando il proprio prodotto nel modo in cui lo farebbe un cliente pagante. Quando l’ha fatto, ha trovato dieci cose da sistemare.

2. L’hai mostrata a tre persone che non sei tu?

Parlare con i potenziali utenti è più difficile che costruire, e la maggior parte dei founder lo salta perché vuole sorprendere le persone al lancio. È un errore.

Non ti serve un focus group. Ti servono tre persone simili a chi pensi sia il tuo cliente. Per l’app dei terapeuti, sono tre terapeuti veri.

Ecco cosa stai cercando: dove si confondono? Dove esitano? Cosa chiedono? Non “cosa ne pensano?” (le persone sono troppo gentili). Chiedi loro di fare davvero la cosa — prenotare un appuntamento, inviare un’email di conferma, cancellare qualcosa.

Quando la founder ha mostrato l’app dei terapeuti a tre terapeuti, due di loro hanno chiesto: “Posso impostare delle regole su quando sono disponibile? Tipo, vedo nuovi clienti solo il giovedì, e non prendo appuntamenti doppi prima delle 14”. L’app aveva un calendario, ma non le regole. Aveva costruito il prototipo per come pensava lei che funzionasse la prenotazione, non per come lavorano davvero i terapeuti.

Quella è informazione di prodotto. Non potevi indovinarla da una specifica.

3. Cosa si romperebbe se la dessi a dieci utenti veri?

Questa è la domanda più difficile perché richiede di pensare davvero ai tuoi casi limite.

Per l’app dei terapeuti:

• Cosa succede se un cliente prova a prenotare due appuntamenti alla stessa ora? (L’app non controlla.)
• Cosa succede se un terapeuta cancella un appuntamento? I clienti vengono avvisati automaticamente? (No.)
• Cosa succede se l’indirizzo email di un cliente è sbagliato? C’è un modo per correggerlo senza ricominciare da capo? (No.)
• Cosa succede se un terapeuta ha un giorno di malattia e deve chiudere il calendario per una settimana? (Dovrebbe cancellare manualmente ogni appuntamento.)

Questi non sono bug. L’app non va in crash. Ma sono fastidi a fil di lama. Con dieci utenti veri e casi limite veri, li incontrerai tutti nella prima settimana.

Un prodotto gestisce i casi limite. Non tutti — alcune cose possono aspettare. Ma quelli che capitano nelle prime due settimane con utenti veri, quelli devono funzionare.

Come decidere: il test a tre livelli

Usa questo per capire dove sei.

Livello 1: flusso principale — Il percorso ideale funziona? Un utente riesce a fare la cosa principale per cui la tua app è progettata?

Per il prenota-terapeuti: sì. Qualcuno può iscriversi, prenotare un appuntamento, ricevere una conferma. Funziona.

Livello 2: casi limite dall’uso reale — L’hai mostrata a tre utenti veri. Hanno incontrato qualcosa che non avevi costruito? Si sono confusi da qualche parte?

Per il prenota-terapeuti: sì. I tre terapeuti volevano disponibilità basata su regole. Uno si è confuso perché l’email di conferma sembrava troppo generica. Uno ha provato a cancellare gli appuntamenti in blocco e non ci è riuscito.

Livello 3: rifinitura e professionalità — Sembra che tu ci tenga? O sembra che tu l’abbia messa insieme alla buona?

Per il prenota-terapeuti: sembra messa insieme alla buona. Le email di conferma sono spoglie. Non c’è personalizzazione del brand. Non c’è un messaggio di errore se qualcosa va storto, quindi se qualcosa si rompe, l’utente non ha idea di cosa sia successo.

Ecco la regola pratica:

• Tutti e tre i livelli funzionano? Sei un prodotto. Lancialo.
• Livelli 1 e 2, ma non il 3? Sei all’80%. Spendi una giornata sulla rifinitura.
• Livello 1 funziona, livelli 2 e 3 no? Sei un prototipo. Non lanciare ancora.
• Il livello 1 non è solido? Non sei pronta. Continua a costruire.

L’app dei terapeuti era bloccata sul confine tra Livello 1 e Livello 2. Il flusso principale funzionava, ma i terapeuti veri trovavano dei pezzi mancanti. Quindi la founder aveva una scelta: passare un’altra settimana con il suo creatore di app aggiungendo le funzionalità che i terapeuti chiedono davvero, oppure lanciare con quello che aveva e aggiungerle dopo.

(Le ha aggiunte. Le sono serviti tre giorni. Ora è un prodotto.)

La cosa che rende tutto difficile

Il motivo per cui così tanti founder si bloccano qui è che costruire è divertente e pubblicare fa paura.

Costruire è una conversazione con il tuo strumento di IA. Hai un’idea, la descrivi, lo strumento la realizza. C’è un ciclo di feedback che dura minuti. Pubblicare è diverso. Premi pubblica, e se qualcosa è sbagliato, lo scoprono persone vere. Non c’è un secondo tentativo.

Così troviamo ragioni per non pubblicare. “Non è abbastanza rifinita.” “Dovrei aggiungere ancora una funzionalità.” “E se i font fossero sbagliati?” E sei settimane dopo, sei ancora lì seduto su qualcosa che funziona ma non sembra pronto, e ti sei convinto che sia per via dei font.

Non sono i font.

Di solito è che non hai passato del tempo con un utente vero, oppure hai costruito qualcosa che aveva senso nella tua testa ma non si adatta bene a come lavorano le persone vere. Questo è risolvibile. Richiede solo di ammettere che non sai quello che non sai, e poi di andare a parlare con qualcuno che lo sa.

La checklist per essere pronti al lancio

Usa questa. È corta e onesta.

• L’ho usata io stesso per fare l’attività reale, e ha funzionato (non in modalità demo, ma davvero).
• L’ho mostrata a tre persone che la userebbero davvero, e ho sistemato le cose su cui si erano confuse.
• Ogni errore che può capitare ha un messaggio che dice all’utente cosa farci (non “errore”, ma una guida vera).
• Andrebbe bene se questa fosse l’ultima versione per sei mesi (cioè: è completa abbastanza da essere utile anche se non la tocco mai più).
• Sono più entusiasta di quello che imparerò dagli utenti veri che di aggiungere altre funzionalità nel vuoto.

Se riesci a spuntare tutte e cinque le caselle, sei pronto. Lancia.

Se non ci riesci, non farlo. Ma sii specifico sul perché. “Non sembra pronta” non è una ragione. “I terapeuti veri hanno bisogno di regole di disponibilità e non le ho ancora costruite” è una ragione. È concreta. È risolvibile. È la differenza tra essere bloccati ed essere su un percorso.

La founder dell’app dei terapeuti l’ha lanciata ieri. Ha il suo primo cliente pagante. Il prodotto non è perfetto, ma è reale, e il suo cliente le sta già dicendo cosa costruire dopo. È lì che sai di essere pronto: non quando l’app è perfetta, ma quando sei pronto a imparare cosa significhi davvero “perfetta” per le persone che la usano.