Definire il perimetro di un MVP: come decidere cosa costruire per primo

Definire il perimetro di un MVP significa scegliere un utente, un problema e un risultato misurabile, poi costruire solo ciò che serve per capire se quel risultato si verifica. Tutto il resto finisce in un elenco di cose da fare più avanti. Fatto bene, questo lavoro richiede giorni, non settimane, e decide se il tuo primo rilascio ti insegna qualcosa oppure brucia soltanto capitale.

Questa guida ripercorre il processo che usiamo con i fondatori a Zurigo e in tutta la Svizzera: dall'ipotesi da verificare al taglio delle funzioni, dalla conversazione sul budget alle metriche che ti dicono qual è il passo successivo.

In breve

• Costruisci il perimetro attorno a un utente, un compito da svolgere e un risultato che puoi misurare. Tutto ciò che non serve a questo aspetta.
• Metti per iscritto l'ipotesi che affonderebbe l'attività se fosse falsa, e progetta l'MVP per verificare prima quella.
• Un prototipo verifica se le persone capiscono il prodotto. Un MVP verifica se ne ricavano abbastanza valore da tornare o da pagare.
• Stima tempi e budget partendo dall'elenco delle funzioni, dalle integrazioni e dalle incognite, non da un numero generico. Fissa il perimetro e lascia che sia l'apprendimento a decidere la fase successiva.
• Definisci le soglie di successo prima del lancio, così dopo nessuno potrà rigirare il risultato.

Cos'è un MVP e a cosa serve definirne il perimetro

Un MVP è la versione più semplice di un prodotto che mette la tua idea davanti a utenti reali e verifica le ipotesi di fondo. Il punto è ridurre il rischio: vuoi scoprire presto se stai costruendo qualcosa che nessuno vuole. La guide to business model testing di Innosuisse e Founders Hive la presenta come una verifica scientifica: sostituire le ipotesi con fatti nel modo più rapido ed economico possibile. L'obiettivo non è dare ragione al fondatore.

Questa impostazione cambia il modo di definire il perimetro. Se l'MVP è un esperimento, il perimetro è ciò che serve all'esperimento. Se invece è la "versione uno" della visione completa, il perimetro cresce a ogni riunione. Quasi tutti gli sforamenti che vediamo nascono dal secondo atteggiamento.

La società di venture capital CRV dice la stessa cosa in un altro modo: l'unit of progress in an MVP è l'apprendimento convalidato, non il numero di funzioni o le righe di codice. Tieni questa frase appesa al muro mentre lavori sul perimetro.

MVP o prototipo: di cosa hai bisogno?

I fondatori chiedono spesso se serva un prototipo o un MVP. Rispondono a domande diverse.

	Prototipo	MVP
Domanda a cui risponde	Le persone capiscono come si usa?	Gli utenti reali ricavano abbastanza valore da continuare a usarlo o da pagare?
Forma tipica	Schizzi su carta, schermate Figma cliccabili, a volte una demo sviluppata	Un prodotto funzionante con poche funzioni
Cosa misuri	Completamento dei compiti, confusione, comprensione	Attivazione, ritenzione, disponibilità a pagare
Backend	Di solito assente o simulato	Reale, anche se minimo
Costi e tempi	Da pochi giorni a qualche settimana	Da qualche settimana a pochi mesi

La regola pratica: adatta il livello di dettaglio alla domanda. Se devi sapere se gli utenti trovano il pulsante di prenotazione, basta un modello cliccabile. Se devi sapere se gli studi medici abbandoneranno davvero la loro agenda cartacea, ti serve qualcosa che prenda appuntamenti veri.

Un avvertimento dal corso di product management della BYU: un MVP deve offrire un'esperienza abbastanza buona da rendere il riscontro un segnale onesto. Broken prototypes draw polite responses che non insegnano nulla. Piccolo non vuol dire fatto male. Un prodotto limitato che funziona vale più di uno ampio che funziona a metà.

La strada meno costosa è spesso una sequenza: prototipo per verificare la comprensione, test manuale per verificare la domanda, poi un MVP sviluppato quando sai cosa merita davvero del codice.

Passo 1: definisci l'utente, il problema e l'ipotesi

Prima di elencare una sola funzione, rispondi per iscritto a tre domande.

1. Chi è l'utente? Non "le piccole imprese". Un segmento preciso: per esempio, studi di fisioterapia indipendenti nella Svizzera tedesca con uno a tre terapisti.
2. Qual è il compito che devono svolgere? Descrivilo come qualcosa che accade davvero, non come qualcosa che potrebbero desiderare: cosa hanno fatto l'ultima volta, con quale frequenza, quale soluzione di ripiego usano e quanto costa loro in tempo, denaro o frustrazione.
3. Qual è l'ipotesi più rischiosa? Quella il cui fallimento manda all'aria l'attività. Spesso non è tecnica. È "le persone pagheranno per questo" oppure "cambieranno le loro abitudini attuali".

La guida di Innosuisse consiglia di trattare ogni elemento del modello di business come un'ipotesi, poi di ordinare le ipotesi in base a quanto sono critiche e a quanto sei incerto su di esse. Chiede anche metriche di successo falsificabili, definite prima di avviare gli esperimenti. Suggerisce da 10 a 20 colloqui strutturati sul problema per convalidare il segmento di clientela e il problema stesso.

In quei colloqui, chiedi dei comportamenti passati, non delle intenzioni future. "Useresti un'app che fa X?" ti procura un sì di cortesia. "Raccontami l'ultima volta che è andata storta" ti procura fatti. Il team di Lean Startup ha raccontato come un gruppo di fondatori abbia scoperto che la sua ipotesi iniziale sul problema era sbagliata solo dopo aver talking to users, cosa che gli ha evitato di costruire il prodotto sbagliato.

First Round Review va oltre e consiglia minimum viable tests sulle singole ipotesi rischiose prima ancora di costruire un MVP. Una pagina di destinazione può verificare la proposta di valore. Se la tua ipotesi riguarda la disponibilità a pagare, una versione manuale del servizio può verificarla a una frazione del costo.

Concierge e Mago di Oz: MVP con poco codice

Vale la pena conoscere due approcci. In un test Mago di Oz, l'utente vede un'interfaccia vera mentre dietro le quinte delle persone svolgono il lavoro a mano. In un test Concierge, è una persona a fornire il servizio direttamente all'utente. Mind the Product spiega bene the difference between the two. Entrambi ti permettono di capire la domanda prima di investire nell'automazione, ed entrambi sono MVP a tutti gli effetti.

Un fondatore che vuole uno strumento di abbinamento basato sull'intelligenza artificiale, per esempio, può spesso fare gli abbinamenti a mano per i primi 20 clienti. Se nessuno paga, hai risparmiato lo sviluppo. Se pagano, ora sai esattamente quali parti automatizzare per prime.

Passo 2: trasforma il risultato in un elenco di funzioni

Ora puoi scrivere le funzioni, e il criterio per ciascuna è semplice: l'utente principale ne ha bisogno per raggiungere il risultato principale nel primo rilascio?

Prendi come esempio uno strumento di prenotazione per studi medici. Se il risultato è ridurre gli appuntamenti mancati, l'essenziale è una pagina di prenotazione, le impostazioni di disponibilità, un calendario, la conferma, i promemoria e la disdetta. Pagamenti online, storico del paziente, rapporti e un'app mobile nativa sono funzioni di contorno. Sono utili e possono aspettare finché il percorso principale non si dimostra valido.

Un taglio semplice: indispensabile, utile, più avanti

Elenca tutte le funzioni che il team ha nominato, poi ordinale.

• Indispensabile: senza, l'utente non raggiunge il risultato. Se la togli, l'esperimento salta.
• Utile: migliora l'esperienza, ma l'utente può comunque raggiungere il risultato senza. Di solito esiste una soluzione manuale.
• Più avanti: una buona idea, ma non verifica l'ipotesi principale.

Sii severo con la colonna "indispensabile". Un buon segnale è quando sta in una schermata e riesci a descrivere tutto il prodotto in due frasi. Se non ci riesci, stai definendo il perimetro di un prodotto, non di un MVP.

Per ogni voce "utile", chiediti quale sia la soluzione manuale. Mandare i promemoria via e-mail partendo da un foglio di calcolo per i primi 30 utenti non costa nulla. Costruire un motore di notifiche costa settimane.

Adatta l'asticella al tuo mercato

Il livello di rifinitura giusto dipende dalla concorrenza. In un mercato affollato gli utenti ti confrontano con alternative già affermate, quindi il minimo è più alto. In un mercato nuovo, il primo compito è dimostrare che il problema esiste, e un prodotto più grezzo può bastare. Sii onesto su quale sia la tua situazione. Cambia la colonna "indispensabile" più di qualsiasi metodo.

Decidi la piattaforma per ultima

I fondatori partono spesso da "ci serve un'app per iOS e Android". Chiediti se un'applicazione web adattiva porterebbe lo stesso apprendimento. Di solito sì, a costi più bassi e senza la revisione degli store di mezzo. Se un'app nativa serve davvero, pianifica per tempo la scheda nello store. Essere indexed correctly on launch day conta, perché un'app nuova con metadati deboli è invisibile alle persone con cui vuoi fare i test.

Passo 3: stimare tempi e budget in Svizzera

Non ti daremo un unico numero valido per tutti, perché ti porterebbe fuori strada. In Svizzera i prezzi variano molto a seconda di chi costruisce, di cosa si costruisce e di quante incognite ci sono. Quello che possiamo fare è dirti cosa determina la stima, così da poter valutare qualsiasi offerta ricevi.

I quattro fattori che determinano la stima di un MVP

1. Numero e complessità dei percorsi principali. Ogni percorso utente (registrazione, prenotazione, pagamento, gestione) ha schermate, logica, casi limite e test. Tre percorsi ben definiti sono un progetto molto diverso da dieci.
2. Integrazioni. Fornitori di pagamento, CRM, ERP, sistemi di negozio online, identità ed e-mail aggiungono ciascuno del lavoro e spesso delle incognite. Collegarsi a un sistema datato è la classica fonte di sorprese.
3. Conformità e dati. I dati personali trattati secondo la legge svizzera sulla protezione dei dati, o le regole di settore nella sanità e nella finanza, comportano scelte di progettazione e di hosting. Mettile sul tavolo al primo colloquio, non al quinto.
4. Incognite. Se il problema non è ancora convalidato, o il design non è definito, il budget deve assorbire i cambiamenti. Un perimetro fisso a prezzo fisso funziona solo quando il perimetro è davvero fisso.

Come ottenere un'offerta affidabile

• Porta il perimetro riassunto in una pagina: utente, risultato, ipotesi, elenco delle funzioni indispensabili e ciò che resta esplicitamente fuori.
• Chiedi chi farà davvero il lavoro e se saranno le stesse persone dall'avvio alla consegna. I cambi di personale a progetto in corso sono una delle cause più frequenti di requisiti riscritti.
• Chiedi cosa possiedi alla fine: codice, repository, account di hosting, documentazione. Vuoi poter proseguire senza lo studio, se lo decidi.
• Chiedi un piano per fasi: un primo rilascio tagliato sull'esperimento, poi un momento di decisione, invece di una sola grande stima per l'intera visione.

Come principio di massima per la pianificazione, un MVP con un perimetro ben definito si misura in settimane o pochi mesi, non in un anno. Se un'offerta va ben oltre, probabilmente il perimetro è cresciuto fino a non essere più un MVP.

Passo 4: fissa i criteri di successo prima di costruire

Il documento più utile non è l'elenco delle funzioni. È la frase che dice quale risultato ti convincerebbe a continuare e quale a fermarti.

Le tue soglie devono essere precise. Un esempio da Unlock Labs è un target conversion rate del 25% per le iscrizioni alla lista d'attesa. Il tuo numero dipenderà dal canale e dal prezzo, quindi confrontalo con conversion rate benchmarks realistici per offerte simili, invece di sceglierne uno che suona bene.

Un insieme di segnali utilizzabile, secondo Microsoft for Startups, copre tre aspetti da leggere insieme: activation, retention and conversion. Il loro metodo di convalida verifica inoltre fattibilità del prodotto, scalabilità tecnica e domanda di mercato in parallelo, invece che una dopo l'altra.

Uno schema di perimetro che puoi copiare:

Voce	Esempio
Utente	Professionisti indipendenti, da 1 a 3 collaboratori
Risultato	Ridurre gli appuntamenti mancati
Ipotesi più rischiosa	Gli studi manderanno i promemoria con un nuovo strumento
Funzioni principali	Pagina di prenotazione, disponibilità, calendario, conferma, promemoria, disdetta
Rimandato	Pagamenti, storico del paziente, rapporti, app nativa
Soglia di successo	Definita prima del lancio: studi attivati, ritenzione a 4 settimane, conversioni a pagamento
Data di verifica	Fissata all'avvio

Passo 5: lancia in piccolo, poi decidi cosa costruire dopo

Metti l'MVP davanti a utenti reali in sessioni strutturate e tieni d'occhio i numeri allo stesso tempo. Guardare qualcuno che prova a completare il percorso principale ti dice perché le metriche sono quelle che sono. Le metriche ti dicono se quello che hai visto nelle sessioni è rappresentativo.

Poi confronta i risultati con le soglie che avevi fissato. Gli esiti possibili sono tre:

• Soglia raggiunta: costruisci la cosa più preziosa che resta nell'elenco, non la richiesta fatta a voce più alta.
• Raggiunta in parte: individua dove gli utenti abbandonano e cambia una cosa alla volta.
• Non raggiunta: torna all'ipotesi. Forse il segmento, il problema o il prezzo erano sbagliati. Cambiare direzione a questo punto significa che l'MVP ha funzionato, non che è fallito.

L'MVP è l'inizio di un ciclo di apprendimento fatto di rilascio, misurazione, apprendimento e miglioramento. A guidare le prossime decisioni di prodotto deve essere il comportamento reale, più delle opinioni espresse attorno al tavolo.

Errori frequenti nella definizione del perimetro

• Partire dalla soluzione. "Ci serve una dashboard" non è un bisogno dell'utente. Parti dal compito da svolgere.
• Costruire per tre tipi di utente insieme. Scegline uno. Gli altri verranno dopo.
• Trattare ogni richiesta degli interlocutori come indispensabile. Usa la classificazione qui sopra e rendi visibile il compromesso.
• Saltare il test manuale. Se puoi simularlo a mano, fallo prima.
• Nessun criterio di arresto. Senza una soglia, qualsiasi risultato può sembrare incoraggiante.
• Sottovalutare le integrazioni. Tutto ciò che tocca un negozio online, un CRM o un ERP esistente richiede un'analisi a sé.
• Scegliere un fornitore che cambia il team a progetto in corso. La continuità conta più di una presentazione ben confezionata.

Come ti aiutiamo in Ampersand

Siamo un piccolo studio di Zurigo e gli ingegneri senior restano sul tuo progetto dalla prima consulenza alla consegna. Questo conta soprattutto nella definizione del perimetro, dove una decisione sbagliata diventa in silenzio una riscrittura tre mesi dopo. Realizziamo siti web, applicazioni web e mobile, MVP e piattaforme, e possiamo aiutarti a definire il perimetro prima che inizi lo sviluppo con i nostri piani di consulenza: Guidance costa 799 CHF al mese. Una volta che il prodotto è online, l'assistenza Run & monitor costa 750 CHF al mese. Le altre offerte vengono definite in base al progetto; dai un'occhiata ai servizi e piani o ai nostri lavori recenti.

Domande frequenti

Qual è la differenza tra un MVP e un prototipo?

Un prototipo verifica se le persone capiscono come si usa il prodotto, spesso tramite un design cliccabile. Un MVP è un prodotto funzionante che verifica se gli utenti reali ne ricavano abbastanza valore da continuare a usarlo o da pagare. Molti team fanno entrambe le cose, partendo dal prototipo.

Quante funzioni deve avere un MVP?

Il minimo necessario a produrre il risultato principale per un utente. Se non riesci a descrivere il prodotto in due frasi, l'elenco è probabilmente troppo lungo. Sposta tutto il resto in un elenco di cose da fare e riprendilo dopo aver osservato comportamenti reali.

Quanto tempo serve per costruire un MVP?

Un MVP con un perimetro ben delimitato richiede di solito da qualche settimana a pochi mesi, a seconda del numero di percorsi principali, delle integrazioni e dei requisiti di conformità. I tempi crescono in fretta quando il perimetro non è chiaro o il design continua a cambiare. Un piano per fasi con un momento di decisione dopo il primo rilascio mantiene l'impegno gestibile.

Devo parlare con gli utenti prima di definire il perimetro?

Sì. I colloqui sul problema, incentrati su esperienze reali e recenti, sono il modo più economico per verificare che stai risolvendo qualcosa a cui le persone tengono. La guida di Innosuisse suggerisce da 10 a 20 colloqui strutturati per convalidare il segmento di clientela e il problema.

Fonti

• guide to business model testing
• unit of progress in an MVP
• Broken prototypes draw polite responses
• talking to users
• minimum viable tests
• the difference between the two
• activation, retention and conversion
• target conversion rate
• conversion rate benchmarks
• indexed correctly on launch day