Il «minimum viable product» è una delle idee più citate e meno seguite del software. In pratica gli MVP falliscono in due modi. O sono così minimi da non dimostrare nulla, oppure crescono in silenzio fino a diventare una versione 1.0 con un anno di funzionalità che nessuno ha ancora chiesto. In entrambi i casi si spreca l’unica risorsa che un prodotto giovane non può sostituire: il tempo per imparare.
Ecco il metodo che usiamo con founder e team di prodotto per definire una prima versione piccola, rilasciabile e che risponda comunque a una domanda reale.
Dare un nome all’ipotesi da verificare
Un MVP è un esperimento, e un esperimento ha bisogno di un’ipotesi. Prima di qualsiasi elenco di funzionalità, scrivi l’ipotesi più rischiosa alla base del prodotto. Di solito è una di queste:
- Domanda: le persone a cui pensiamo hanno questo problema in modo abbastanza forte da cambiare il proprio modo di lavorare.
- Valore: il nostro modo di risolverlo è chiaramente migliore di ciò che fanno oggi, compreso non fare nulla.
- Disponibilità a pagare: loro, o la loro azienda, pagheranno un prezzo che rende sostenibile il business.
- Fattibilità: sappiamo davvero ottenere il risultato, per esempio con un’accuratezza dell’IA accettabile o con dati a cui possiamo accedere legalmente.
Scegli quella che ucciderebbe il prodotto se si rivelasse falsa e definisci l’MVP per verificarla. Un prodotto il cui rischio maggiore è la disponibilità a pagare ha bisogno di un checkout e di una pagina prezzi già nella prima versione. Un prodotto il cui rischio maggiore è la fattibilità potrebbe non avere bisogno di alcuna interfaccia, ma solo di una pipeline che dimostri che il risultato è abbastanza buono.
Disegnare l’unico percorso che deve funzionare
Poi descrivi l’unico percorso che un utente deve poter completare perché il test abbia senso. Non l’intero prodotto: una strada, dal primo contatto al momento in cui riceve valore.
Per uno strumento B2B di pianificazione dei turni potrebbe essere: un responsabile si registra, importa il team, pubblica i turni e i dipendenti li vedono sul telefono. Tutto ciò che sta su quel percorso deve funzionare bene. Tutto ciò che sta fuori può aspettare.
Scrivere il percorso come una breve storia, schermata per schermata, è anche il modo più rapido per scoprire che due persone del team avevano in mente due prodotti diversi.
Decidere cosa simulare
Una parte sorprendente di un prodotto agli inizi si può gestire a mano o con strumenti esistenti, purché l’utente non la viva come un malfunzionamento:
- onboarding fatto da una persona in videochiamata invece di una procedura self-service;
- report inviati come foglio di calcolo o PDF invece di una dashboard analitica;
- fatturazione tramite fattura o link di pagamento invece di un sistema di abbonamenti completo;
- un pannello di amministrazione su uno strumento pronto invece di un back office su misura;
- integrazioni tramite esportazione programmata invece di un’API in tempo reale.
Ognuna di queste scelte fa risparmiare settimane. E ognuna insegna qualcosa: se i clienti continuano a chiedere la versione self-service, sai cosa costruire dopo.
Cosa non tagliare mai
Essere minimi nel perimetro non significa essere superficiali nelle fondamenta. Alcune cose costano molto da aggiungere dopo e poco da fare bene subito:
- Autenticazione e permessi affidati a un fornitore collaudato, non a un login fatto in casa.
- Un modello dati aderente al business, soprattutto per account, organizzazioni e ruoli. La multi-tenancy aggiunta a posteriori è dolorosa.
- Un’igiene di base su sicurezza e privacy: connessioni cifrate, segreti fuori dal codice, dati personali trattati tenendo conto del GDPR.
- Analytics sull’unico percorso, per vedere dove le persone abbandonano. Senza, l’esperimento non ha un risultato.
- Deploy automatizzati, perché una correzione vada online in pochi minuti e nessuno abbia paura di rilasciare.
- Le basi di accessibilità e prestazioni, che costano poco in un codice nuovo e molto in uno vecchio.
Scegliere una tecnologia noiosa
Un MVP non è il posto per provare tre nuovi framework. Scegli uno stack che il team conosce bene e che resterà una scelta sensata se il prodotto avrà successo: per molti SaaS significa TypeScript con React o Next.js, un database PostgreSQL gestito e un cloud diffuso. L’obiettivo è che un MVP riuscito diventi la base del prodotto, non un prototipo da buttare sotto pressione.
Fissare i tempi prima del perimetro
Fissa prima il tempo, poi fai entrare il perimetro. Poche settimane fino ai primi utenti reali sono un obiettivo sano per la maggior parte degli MVP B2B. Se il percorso disegnato non ci sta, taglia lungo il percorso, non di traverso: semplifica i passaggi, simula di più, restringi il pubblico. Non rilasciare metà di ogni funzionalità.
Concorda in anticipo quale risultato varrà come successo, quale come fallimento e cosa farete in ciascun caso. Così il lancio diventa una decisione, non una sensazione.
Dopo il lancio: prima imparare, poi costruire
Il risultato più prezioso di un MVP non è il codice, ma ciò che impari nelle prime settimane di utilizzo. Parla con ogni utente iniziale che riesci a raggiungere. Osserva gli analytics del percorso. Tieni un breve elenco di ciò che le persone chiedono e con quale frequenza. Poi pianifica la versione due a partire dai fatti.
Se stai preparando un nuovo prodotto, il nostro team SaaS e MVP può condurre con te una breve fase di discovery, definire percorso ed esperimento e costruire la prima versione con le fondamenta descritte sopra. I nostri designer UX e UI prototipano il percorso prima che venga scritta una riga di codice. Raccontaci la tua idea.