Il tuo MVP non valida niente. Spesso non è nemmeno in produzione.
È un video, un Figma, un ambiente con password, un account di prova che usi tu. La maggior parte di quelli che vediamo in Snowinch non sta testando un'ipotesi su utenti reali: sta proteggendo un prototipo da qualsiasi contatto che potrebbe romperlo.
Quello che chiami MVP
MVP è una parola usata per oggetti diversi. Landing, prototipo, una versione con meno feature del prodotto immaginato, beta chiusa, servizio fatto a mano. Nessuna di queste forme è automaticamente un MVP. Tutte possono esserlo, se stai testando qualcosa di preciso.
Nella pratica manca l'ipotesi. C'è il prodotto che si vuole costruire, e l'MVP è la prima versione di quella stessa cosa: più piccola, meno rifinita. Quello non è un test. È un prodotto incompleto.
Un prodotto incompleto si giudica da quanto manca. Un MVP si giudica da cosa hai imparato. La distinzione cambia l'ordine in cui costruisci e la soglia con cui decidi se continuare.
Cambia soprattutto una cosa che di solito resta fuori dalla conversazione: dove vive.
Produzione, non demo
Un test che non esce dal tuo computer non parla col mercato. Parla con te.
Il mini-prodotto finito è il caso più comune. Interfaccia curata, onboarding, piani di prezzo, landing sistemata. Ha chiesto tempo vero. Quando lo "lanci" sei già troppo dentro per leggere un no senza riscriverlo. E spesso non lo lanci nemmeno: resta in staging, oppure gira su un URL che mandi a gente che già ti conosce. Troppe variabili insieme (prezzo, copy, canale, feature) e zero utenti che non siano nella tua rubrica. Se qualcosa non converte, non sai cosa. Se nessuno entra, non hai validato il live. Hai validato la tua pazienza.
Il guscio vuoto è la reazione sbagliata. Titolo, qualche bullet, campo email. Le persone si iscrivono se il copy è curioso; la curiosità costa quasi zero. Una lista lunga senza un pagamento, senza un uso, senza un dato che debba stare al sicuro, valida il titolo. Non la disponibilità a pagare, non la tenuta, non le notti. È un segnale di copy.
Poi c'è il prototipo che "funziona" in una call. Condividi schermo. Clicchi tu. I dati sono finti. Qualcuno dice wow. Quella stanza non è produzione. Produzione è quando una persona che non sei tu crea un account, ci mette qualcosa di suo (un file, una carta, una mail di lavoro), e il sistema deve reggere senza che tu sia collegato. Se i dati di quella persona si possono perdere o leggere per sbaglio, il test è già un incidente in ritardo.
Anzi: il mini-prodotto chiuso in staging è peggio della landing vuota. La landing almeno ammette di essere un cartello. Lo staging truccato da lancio ti convince di aver "messo online" mentre l'unico utente sei tu.
La soglia che usiamo è secca. In produzione, non demo. Qualcuno di fuori può usarlo. C'è un segnale economico o un uso che costa (un pagamento, un'azione che non faresti per educazione). I dati si trattano come se appartenessero a loro, non a un dump di sviluppo. Se una di queste manca, stai ancora provando i costumi.
Preferisco una cosa sottile e vera in produzione a un oggetto lucido che vive sul mio hosting. Costa in estetica: sembra incompiuto. Lo prendo. L'incompiuto in live insegna. Il lucido in privato rassicura.
Il Wizard of Oz (lo fai a mano, il cliente crede che sia il prodotto) può stare nella porta. Va dichiarato, almeno a te stesso. Il giorno dopo non puoi fingere che quella coda manuale sia "già scalabile". O la chiudi in un perimetro, o ammetti che il live ancora non c'è.
L'ipotesi sbagliata, anche online
Si può essere in produzione e testare la cosa inutile.
Il rischio di un marketplace è se i due lati si incontrano e transano. Costruire prima registrazione, notifiche, interfaccia "usabile" produce grafici. Non produce la risposta. Vale per un sacco di prodotti: testi l'onboarding e non il pagamento; testi il modello AI e non se qualcuno torna dopo la prima risposta storta.
Un segnale negativo chiaro (nessuno paga, abbandonano in un punto, l'ipotesi cade) è un MVP che ha fatto il suo mestiere. Un segnale ambiguo (qualcuno ha cliccato, non sai perché) è da ridisegnare. Non perché sia "brutto". Perché non hai informazione.
La distribuzione conta quanto l'artefatto. Mandarlo ai tuoi contatti generici, ai follower, a chi ti vuole bene, sporca il no. L'ICP deve poter rifiutare in modo visibile.
Quando smettere di chiamarlo test
C'è il rischio opposto: testare per non spedire. Il ciclo diventa un modo per non affrontare utenti, dati, sonno.
Il passaggio utile è quando l'ipotesi più rischiosa ha un sì sufficiente, e quello che costruisci da lì deve stare in piedi da solo. Non certezza. Un motivo per investire nel prodotto vero, sapendo che le ipotesi secondarie si vedranno sotto carico reale.
A quel punto non stai più proteggendo una demo. Stai tenendo un live. In servizi è quella transizione: dallo scope stretto a qualcosa che può restare acceso. I case pubblicati sono uscite da quel giro, non da uno staging eterno.
Se il tuo "MVP" è ancora un link che hai paura di inoltrare a qualcuno con una carta in mano, non hai un problema di feature. Hai un oggetto che non è in produzione. Quello non valida il mercato. Non valida nemmeno te, la notte.
Se hai già un segnale e ti serve il live, non un'altra prova generale, si può parlare di perimetro. Se vuoi un sì su uno scope che resta in demo "perché tanto è un MVP", questa non è la conversazione.
