Come definire l'ambito di un MVP: riduca la sua prima versione a ciò che conta davvero

Quasi tutti quelli che vengono da noi con un'idea di app ne hanno già costruito la versione completa nella loro testa. Sanno descrivere la dashboard, la pagina delle impostazioni, il programma di referral, la modalità scura. Quello che di solito non sanno dire è quale singola parte di quel quadro, se funzionasse, renderebbe l'intera cosa degna di essere realizzata. Definire l'ambito di un MVP è il lavoro poco glamour e un po' doloroso di trovare quell'unica parte — e avere il coraggio di lasciare il resto per dopo.

Ho visto costruire molti primi prodotti, e quelli che faticano non falliscono quasi mai perché il team era pigro. Falliscono perché l'ambito era sbagliato fin dalla prima settimana. Si è infilato troppo nella versione uno, il budget si è esaurito prima che qualcuno imparasse alcunché, e al lancio il team aveva speso tutto solo per arrivare alla linea di partenza — senza soldi per reagire a ciò che gli utenti reali facevano davvero.

Questa è dunque la guida che do alle persone prima che venga scritta una sola riga di codice. Non riguarda i rituali agili né i framework sofisticati. Riguarda una domanda onesta — qual è la cosa più piccola che possiamo costruire per capire se questa idea è reale? — e la disciplina di continuare a rispondervi mentre la tentazione di aggiungere ‘solo un'altra funzione’ torna a farsi sentire. Perché torna sempre a farsi sentire.

Cos'è davvero un MVP (e cosa non è)

L'espressione è stata consumata dall'uso eccessivo, quindi siamo precisi. Un prodotto minimo funzionante è la versione più piccola della sua idea che offre valore reale a un utente reale e le insegna qualcosa che non avrebbe mai potuto imparare da una presentazione. La parola chiave che si dimentica è funzionante. Deve davvero funzionare per qualcuno, dall'inizio alla fine, anche se fa una cosa sola.

Ecco cosa un MVP non è. Non è una versione a metà del prodotto completo con angoli rotti dappertutto. Non è un prototipo da buttare. E di sicuro non è ‘la versione economica’ — l'economicità è un effetto collaterale di un buon ambito, non l'obiettivo. L'obiettivo è imparare. Sta spendendo il meno possibile per rispondere alla domanda più costosa che ha: qualcuno lo userà, e lo userà come penso?

Questa distinzione pesa più di quanto sembri. La mentalità del ‘primo 20%’ porta a una cosa rotta in ogni direzione e utile in nessuna. ‘Una cosa, fatta bene’ porta a qualcosa che una persona può prendere in mano, usare per davvero e su cui farsi un'opinione. Le opinioni sono l'intero scopo. Sul silenzio non si può iterare.

La trappola del costruire troppo, e perché è così facile caderci

Nessuno si prefigge di esagerare con l'ambito. Accade una decisione ragionevole dopo l'altra. Aggiunge il login, perché ovviamente servono gli account. Gli account implicano un flusso di reimpostazione della password, una verifica via e-mail e una pagina di impostazioni. Le impostazioni implicano un profilo, che implica il caricamento di immagini, che implica un posto dove archiviarle. Ogni passo è sensato di per sé. Impilati insieme, ha speso due mesi e una fetta di budget prima ancora di iniziare la parte che rende speciale la sua idea.

L'altra metà della trappola è emotiva. Tagliare funzioni dà la sensazione di ammettere che la propria idea è piccola. Non lo è — è ammettere che non si sa ancora quali funzioni contino, il che è semplicemente la verità. Ogni funzione che costruisce prima di avere utenti è una scommessa al buio. Alcune di quelle scommesse saranno sbagliate, e quelle che taglia dall'MVP sono le scommesse più economiche su cui sbagliare, perché non le ha mai piazzate.

Trovi l'unico compito che il suo MVP deve svolgere

Ogni prodotto, per quanto grande diventi alla fine, ha un ciclo centrale — l'unica sequenza che un utente ripete e che crea il valore. Per un'app di prenotazioni è trovare uno slot, prenotarlo, ricevere un promemoria. Per un marketplace è pubblicare una cosa, qualcuno la trova, il denaro cambia mano. Per uno strumento interno è acquisire il dato una volta, usarlo ovunque. Tutto il resto del prodotto esiste per sostenere, decorare o estendere quel ciclo. Il suo MVP è il ciclo. Solo il ciclo.

Per trovare il suo, completi questa frase ad alta voce: «Un utente viene al mio prodotto per ______, ed è soddisfatto se ______.» Il primo spazio è il compito. Il secondo è come capirà se ha funzionato. Se non riesce a riempire entrambi gli spazi in un solo respiro, non ha ancora trovato il nucleo — e non è pronto a definire l'ambito, tanto meno a costruire.

Sia spietato sulla differenza tra il ciclo centrale e le cose che sembrano essenziali ma non lo sono. Il login sembra essenziale. Di solito non lo è, nella versione uno — molti MVP partono con un singolo link condiviso, un invito manuale o nessun account, e imparano tutto ciò che serve prima di costruire il meccanismo di autenticazione. Le dashboard analitiche sembrano essenziali. Non lo sono; può leggere il database a mano quando ha undici utenti. Riduca al ciclo e si stupirà di quanto cade via.

Smisti ogni funzione in deve, dovrebbe e non avrà

Una volta nominato il ciclo centrale, prenda il suo grande elenco di funzioni e smisti ciascuna in tre secchi. I secchi sono volutamente netti, perché è la nettezza che ferma le interminabili conversazioni del ‘ma forse’.

• Deve: il ciclo centrale letteralmente non funziona senza. Se la toglie, non c'è prodotto. Tenga questo elenco scioccantemente corto — di solito da tre a sei voci.
• Dovrebbe: migliora il prodotto, ma il ciclo funziona comunque anche senza. Tutto ciò che è qui aspetta la versione due. Nessuna eccezione nella prima versione.
• Non avrà (ancora): le funzioni che sceglie consapevolmente di non costruire ora. Scriverle conta — è così che rassicura sé stesso, e il suo team, che l'idea non viene abbandonata, solo messa in sequenza.

Il trucco che fa funzionare tutto è il terzo secchio. La maggior parte delle persone litiga solo tra deve e dovrebbe, il che è estenuante e non finisce mai. L'elenco del ‘non avrà ancora’ è dove vive il sollievo — è una promessa al suo io futuro che l'idea brillante è al sicuro e pianificata, solo non ora. Una volta che le persone si fidano che nulla viene buttato, smettono di lottare per tenere tutto nella versione uno.

Definisca l'ambito per tempo e denaro, non per elenco di funzioni

Ecco uno spostamento silenzioso che cambia tutto: smetta di definire l'ambito in base a ‘cosa vogliamo’ e cominci a definirlo in base a ‘cosa sta nel budget e nella scadenza’. Decida prima quanto denaro e quante settimane è disposto a spendere per rispondere alla sua domanda centrale. Poi faccia stare l'elenco delle funzioni dentro quella scatola. Sembra al contrario, ma è il singolo vincolo più utile che possa darsi, perché impone la prioritizzazione che altrimenti eviterebbe.

Una scatola fissa fa anche qualcosa di psicologico. Quando il budget è aperto, ogni funzione è discutibile e l'elenco non fa che crescere. Quando la scatola è fissa — diciamo otto settimane e una cifra stabilita — la conversazione si ribalta. Smette di essere ‘dovremmo aggiungere questo?’ e diventa ‘cosa esce se questo entra?’. Quella seconda domanda è quella che costruisce buoni MVP. I compromessi sono visibili invece che nascosti, e il team li fa di proposito.

Un esempio reale: ridurre l'ambito di un'idea di gestione interventi

Rendiamolo concreto con un caso su cui abbiamo lavorato — reso anonimo, ma fedele a come vanno queste cose. Una piccola impresa di riscaldamento e idraulica è venuta da noi volendo un'app per la sua squadra sul campo. Il brief, sulla carta, era enorme: pianificazione interventi in tempo reale, tracciamento GPS dei furgoni, un portale clienti, fatturazione automatizzata, inventario dei pezzi su ogni veicolo, un generatore di preventivi, documentazione fotografica e una suite di report per il titolare. Un prodotto genuinamente utile, col tempo. Come prima versione, un modo garantito per spendere il budget di un anno prima di imparare alcunché.

Così abbiamo fatto l'esercizio. Abbiamo posto al titolare la frase: ‘Un utente viene a questo per ______, ed è soddisfatto se ______.’ Dopo qualche andirivieni, è emersa la vera risposta. Il più grande dolore quotidiano dei tecnici non era la pianificazione né la fatturazione — era l'andirivieni delle scartoffie. Finivano un intervento, scarabocchiavano ore e pezzi su un foglio, tornavano in sede, e qualcuno in ufficio ribatteva tutto nel gestionale di contabilità, spesso giorni dopo, spesso con errori. Il ciclo centrale era semplicemente: acquisire ciò che è successo durante l'intervento, una volta sola, sul posto, così nessuno deve ribatterlo.

Cosa è passato — e cosa no

È stato smistato tutto. Il secchio deve si è ridotto a quattro cose: un elenco degli interventi di oggi per ogni tecnico, un semplice modulo per registrare ore e pezzi usati per intervento, un allegato fotografico, e un modo per l'ufficio di vedere quei dati nel momento in cui venivano inviati. Quello era l'intero MVP. Niente GPS, niente portale clienti, niente generatore di preventivi, niente report sofisticati — tutto parcheggiato, esplicitamente, sull'elenco ‘non avrà ancora’ con una nota che sarebbe arrivato.

Abbiamo costruito quel nucleo in una manciata di settimane anziché in buona parte di un anno. Ed ecco la parte che giustifica l'intero approccio: una volta attivo, le priorità reali del team si sono rivelate diverse dal brief. Il titolare aveva supposto che il tracciamento GPS sarebbe stato il prossimo passo; i tecnici lo hanno appena nominato. Quello che volevano, a gran voce, era inviare al cliente via messaggio una finestra di arrivo dall'interno dell'app — una funzione che non era nemmeno nell'elenco originale. Poiché l'MVP era piccolo ed economico, è rimasto budget per costruire ciò che volevano davvero, invece di ciò che avevano ipotizzato mesi prima.

Gli errori che rovinano in silenzio l'ambito di un MVP

Persino i team che sposano il ‘teniamolo piccolo’ tendono a inciampare sulle stesse poche cose. Nessuna è drammatica. Sono perdite lente che rigonfiano l'ambito mentre lei non guarda, finché un giorno il prodotto ‘minimo’ ha di nuovo trenta schermate e una tabella di marcia di sei mesi.

• Rifinire i bordi all'eccesso: passare giorni a perfezionare un pannello di amministrazione che vedrà solo lei, mentre il ciclo centrale è ancora grezzo. Lucidi ciò che gli utenti toccano; lasci il retrobottega brutto e funzionale.
• Costruire per una scala che non ha: progettare l'architettura per un milione di utenti quando deve dimostrare che i primi dieci torneranno. Risolva il problema della scala quando avrà il bel problema della scala.
• Confondere ‘irrinunciabile’ con ‘standard di settore’: solo perché ogni concorrente ha la funzione X non significa che il suo MVP ne abbia bisogno per testare la sua idea centrale. Non sta lanciando un prodotto finito, sta facendo un esperimento.
• Progettare in anticipo ogni caso limite: gestire gli input rari e strani prima di sapere se qualcuno usa il percorso comune e normale. Lasci che l'uso reale le dica quali casi limite siano persino reali.
• Nessuna definizione di completato: senza una riga scritta che descriva com'è ‘finito’, la costruzione non finisce mai. La dilatazione dell'ambito adora un progetto senza traguardo.

Se si protegge da uno solo di questi, sia l'ultimo. Una definizione di completato chiara e scritta — ‘un tecnico può registrare ore e pezzi di un intervento dal telefono, e l'ufficio lo vede all'istante’ — è lo strumento più potente per tenere onesto l'ambito. Ogni aggiunta proposta viene confrontata con quella frase. Se non serve la frase, è un'idea da versione due, per quanto buona sia.

Un processo semplice per definire l'ambito del suo MVP

Tirando le somme, ecco la sequenza che percorrerei con chiunque prima di avviare una prima versione. È volutamente a bassa tecnologia — gran parte la può fare con un documento e una conversazione onesta, molto prima di aver bisogno di uno sviluppatore nella stanza.

1. 1
   Nomini il ciclo centrale

   Completi la frase: ‘Un utente viene per ___, ed è soddisfatto se ___.’ Se non ci riesce, non è pronto a definire l'ambito — continui a parlare finché il vero compito non emerge.
2. 2
   Riversi ogni funzione, poi smisti

   Tiri fuori dalla testa tutta la lista dei desideri e la metta su carta. Smisti ogni voce in deve, dovrebbe o non-avrà-ancora. Tenga l'elenco ‘deve’ brutalmente corto.
3. 3
   Fissi la scatola

   Decida il budget e la scadenza prima di finalizzare l'elenco delle funzioni. Faccia stare l'elenco nella scatola, non il contrario.
4. 4
   Scriva la definizione di completato

   Una frase concreta che descrive il ciclo centrale funzionante. È il suo scudo contro la dilatazione dell'ambito per il resto del progetto.
5. 5
   Costruisca, lanci, osservi, poi decida

   Metta il nucleo davanti a utenti reali. Osservi cosa fanno davvero. Lasci che il loro comportamento — non le sue ipotesi precedenti — scelga cosa esce dopo dall'elenco ‘dovrebbe’.

Noti che l'ultimo passo la riporta all'inizio. Un buon MVP non è un evento una tantum, è il primo giro di una ruota. Definisce un ambito piccolo, rilascia, impara, e ciò che impara ridefinisce l'ambito della versione successiva. I team che vincono non sono quelli che hanno pianificato il prodotto perfetto in anticipo — nessuno lo fa. Sono quelli che hanno messo qualcosa di reale davanti agli utenti abbastanza in fretta perché la realtà potesse ancora orientarli.

Domande frequenti