L'Errore: Costruire in Isolamento
Un fondatore che conosco ha speso 4 mesi a perfezionare un MVP per il mercato delle agenzie immobiliari. Dashboard intuitiva, integrazioni API pulite, design minimalista. Era bello. Era elegante. Era inutile.
Quando finalmente ha invitato 20 agenti immobiliari a testarlo, la prima reazione è stata: "Carino, ma... dove posso allegare le foto delle proprietà in batch?". La seconda: "Mi serve un tool per sincronizzare con i miei vecchi database Excel". La terza, più brutale: "Non mi serve questo. Mi serve qualcuno che telefoni ai proprietari per me".
Ha costruito un prodotto perfetto per il problema che lui pensava che avessero. Non per il problema che loro effettivamente avevano.
Perché Accade
Quando sei da solo con il tuo laptop, il tuo cervello inizia a ragionare come se fossi il cliente. Non è colpa tua — è il bias di disponibilità mentale. Pensi:
- "Un'interfaccia pulita farebbe felice chiunque"
- "Certo, gli utenti vorranno integrazioni futuro-proof"
- "Ovviamente preferiscono scalabilità a facilità d'uso"
Sbagliato su quasi tutti i fronti.
Il vero problema? Non stai osservando gli utenti mentre risolvono i loro problemi attuali. Stai immaginando come vorresti che risolvessero i loro problemi. È una differenza microscopica che costa mesi di lavoro.
Come Evitarlo: La Regola dei "Primi 10 Utilizzi"
Non è sufficiente mostrare il prodotto finito. Devi sederti accanto a 10 utenti reali mentre lo usano per risolvere un compito specifico. Guarda dove si fermano. Ascolta dove bestemmiavano (metaforicamente, speriam).
Ecco cosa concretamente fare:
-
Definisci il task prima del test: "Voglio che tu importi questi 50 contatti e crei una campagna di email per loro". Non "Che ne pensi del prodotto?"
-
Shut up and watch: Non spiegare mentre loro usano. Lascia che falliscano. Quando cliccano nel posto sbagliato, è una feature mancante, non un errore loro.
-
Registra i momenti di confusione: Quando l'utente fa una pausa, guarda il soffitto, e poi dice "Mmm, aspetta, dove devo...". Quella pausa è oro puro. Quel momento è il tuo MVP fallace.
-
Chiedi del presente, non del futuro: Non chiedere "Useremmo questo se...?". Chiedi "Che strumento usi adesso per fare questa cosa?". La risposta ti mostra il vero competitor.
Il Caso di Figma
Figma era un progetto di Dylan Field con questa ossessione: costruire uno strumento di design veramente collaborativo nel browser. Suonava bene in teoria.
Ma nei primi test con designer professionisti, scoprì che nessuno se ne importava della collaborazione in tempo reale se non poteva usare i font locali correttamente. La funzione "wow" era invisibile rispetto al problema basilare: "Perché il mio typeface preferito non c'è?"
Ha riscritto le priorità. La collaborazione arrivò dopo. E questo è il motivo per cui Figma è cresciuta — perché ha risolto il problema vero, non quello cool.
L'Antidoto Pratico
Prima di scrivere una sola riga di codice:
- Parla con almeno 20 potenziali utenti sul loro flusso di lavoro attuale
- Identifica il punto di dolore più comune (non il più interessante da risolvere)
- Costruisci una soluzione per quel dolore — anche se è noioso
- Testala con 5 utenti reali che fanno il compito vero
- Solo dopo, pensa a scalare e perfezionare
L'MVP non è un design esercizio. È un'ipotesi che devi testare con i corpi veri, le loro mani vere, i loro problemi veri.
Il resto è narcisismo.