Come definire un ambito MVP in 3 ore

Quando sono stato assunto come product manager da una società di elaborazione dei pagamenti in fase iniziale, l'azienda stava lottando per creare e fornire un sistema di gestione dell'inventario in modo tempestivo. La soluzione in atto era una semplice app per tastiera che non era facile da usare e, di conseguenza, causava un notevole abbandono dei clienti. Il mio lavoro era guidare un team incaricato di creare il sistema di inventario che avrebbe ampliato le capacità dell'app oltre la funzionalità della tastiera.

Poiché dovevamo operare su una linea temporale troncata, ho creato un approccio semplice ma radicalmente efficiente per concepire, progettare e costruire un prodotto minimo vitale (MVP) con caratteristiche principali che corrispondessero a ciò che i nostri utenti cercavano. Il processo ha condensato l'ambito di un MVP in una sessione intensiva di tre ore, invece di giorni o settimane, e ha fatto risparmiare al nostro team mesi di tempo nello sviluppo.

Questo processo di definizione dell'ambito MVP accelerato può essere utilizzato per guidare qualsiasi team di prodotto e può essere applicato alla creazione di qualsiasi prodotto zero-a-uno.

Panoramica del caso d'uso

Problema: la semplice funzionalità della tastiera dell'app non offriva agli utenti, che erano fornitori, la possibilità di gestire l'inventario o selezionare gli articoli da aggiungere all'ordine di un cliente.

Vincoli: la leadership dell'azienda voleva una soluzione consegnata in otto settimane; un potenziale round di raccolta fondi dipendeva, in parte, dal successo di una versione migliorata del prodotto.

Contesto: da un'analisi del mercato e dopo aver trascorso del tempo con molti dei nostri utenti, ho stabilito che questi fornitori avevano bisogno di un sistema di gestione dell'inventario per ottimizzare il flusso di vendita. Li ho visti elaborare gli ordini dei clienti: in primo luogo, hanno scritto gli articoli richiesti su pezzi di carta, hanno utilizzato calcolatrici per contare gli articoli e quindi hanno inserito gli ordini nell'app. Stavano usando tre strumenti quando avrebbero dovuto averne bisogno solo uno.

Soluzione: dovevamo sviluppare una soluzione che consentisse agli utenti di caricare i propri inventari in un catalogo digitale, gestire tali inventari e toccare gli articoli selezionati per aggiungerli al carrello di un cliente, il tutto all'interno dell'app.

La decisione dello sprint di progettazione

Poiché sapevamo già quale prodotto dovevamo sviluppare, ho deciso di rinunciare a un tipico sprint di progettazione: un workshop di quattro o cinque giorni in cui i team collaborano per identificare una grande sfida aziendale, raccogliere idee dai clienti su come risolvere il problema, sviluppare un concetto per un prodotto, progettare un prototipo e iniziare a testarlo.

Gli sprint di progettazione sono un metodo efficace per creare MVP, per coloro che hanno bisogno di identificare i problemi principali e che hanno tempo a disposizione per sviluppare soluzioni. Nelle aziende in fase iniziale o nelle nuove unità aziendali nelle organizzazioni esistenti, tuttavia, i problemi principali sono generalmente evidenti: sono stati sviluppati concetti e l'adattamento prodotto/mercato è stato solitamente determinato prima che vengano coinvolti product manager, ingegneri e designer.

Il seguente diagramma di flusso analizza i passaggi che ho seguito quando ho deciso che il modo migliore per procedere con questo progetto era saltare lo sprint di progettazione e iniziare con la sessione di tre ore, nota anche come kickoff del team. In quella riunione, i partecipanti avrebbero fatto un brainstorming e generato dozzine di idee per le funzionalità, quindi avrebbero ridotto l'elenco solo a ciò che era richiesto per l'MVP.

Il processo di sviluppo dell'MVP

Preparazione

Prima della sessione di tre ore, ti consigliamo di raccogliere informazioni sui tuoi profili utente conversando e osservando i clienti attuali o potenziali e conducendo ricerche di mercato.

Quindi, crea una presentazione per i progettisti e gli ingegneri. Dovrebbe spiegare:

• Il problema che stai cercando di risolvere.
• Il prodotto che stai costruendo.
• In che modo il prodotto risolverà il problema in termini sia di metriche che di UX.
• L'impatto previsto del prodotto sulle attività tue e dei tuoi clienti.
• Le missioni e gli obiettivi e i risultati chiave (OKR) a livello aziendale e di squadra, nonché il modo in cui il prodotto aiuta a realizzare tali missioni e raggiungere tali OKR.

La presentazione dovrebbe fornire ai progettisti e agli ingegneri una solida comprensione del prodotto per procedere con l'ambito dell'MVP.

La riunione d'inizio di tre ore

Il kickoff dovrebbe coinvolgere l'intero team di sviluppo, consentendo loro di partecipare a ogni fase del processo, dall'ideazione e creazione della storia allo sviluppo del concept MVP. Ciò include i product manager senior, junior e associati; proprietari di prodotti; lead di prodotto (se applicabile); designer dell'esperienza utente; ingegneri del software; e ingegneri del controllo qualità.

Suggerimento rapido: sebbene non sia ortodosso, consiglio di includere gli ingegneri prima della fase di costruzione. In genere forniscono grandi idee e hanno una passione per il prodotto che stanno cercando di migliorare. Alla maggior parte di loro piace essere coinvolti nello scopo dell'MVP; li aiuta a diventare più coinvolti nel progetto e apprezzati dagli altri team.

Riunisci tutti in una sala conferenze o in uno spazio di lavoro virtuale. Nel nostro caso, avevamo 10 persone. Blocca tre ore.

Il prodotto e i viaggi dell'utente (60 minuti)

1. Consegna la presentazione. (15 minuti)

2. Inizia a identificare tutti gli utenti per il tuo prodotto. Anche se non hai ancora identificato alcun flusso o lavoro di funzionalità, puoi definire il numero di flussi che devono essere creati. (10 minuti)

   Suggerimento rapido: non sovraingegnerizzare aggiungendo più persone del necessario. Dopo il rilascio di MVP, il feedback dei clienti rivelerà se hai bisogno di ruoli aggiuntivi.

   Esempio di caso d'uso: avevamo tre persone: il gestore del negozio (o amministratore), il cassiere e il cliente finale. C'erano altri potenziali personaggi di livello senior, come il proprietario del negozio, ma ai fini di un MVP, quelli potevano essere coperti dall'amministratore.

3. Mappa il percorso dell'utente dall'inizio alla fine. Assegna un colore a ciascuna persona per aiutare a identificare ogni fase del flusso che un utente incontrerà. Per le riunioni di persona, affiggere note adesive su un muro o utilizzare una lavagna. Per le riunioni virtuali, usa una bacheca FigJam o qualcosa di simile. (35 minuti)

   Suggerimento rapido: chiedi al team di condividere tutte le proprie idee e di ottenere informazioni dettagliate. Ogni passaggio del flusso diventerà una funzionalità da creare e ogni utente avrà un flusso separato, ma il processo di definizione dei passaggi sarà lo stesso.

   Esempio di caso d'uso: ecco l'elenco delle funzionalità per il nostro personaggio cassiere:

   • Apri l'app del punto vendita.
   • Accedi utilizzando un PIN.
   • Identificare il primo articolo per l'acquisto del cliente.
   • Identificare la quantità per l'articolo.
   • Identificare eventuali articoli aggiuntivi per l'acquisto del cliente.
   • Aggiungi uno sconto su un articolo (se applicabile).
   • Somma il costo di tutti gli articoli nel carrello (a questo punto viene visualizzato il prezzo di acquisto completo, IVA inclusa).
   • Completare il checkout e l'elaborazione dei pagamenti.
   • Conferma l'acquisto.
   • Consenti al cliente di aggiungere un suggerimento.
   • Chiudi la vendita.
   • Mostra il totale di tutte le vendite giornaliere.
   • Scade dopo un periodo di inattività predeterminato (ad es. cinque minuti).

   Nota: questo elenco descrive in dettaglio la maggior parte delle funzionalità che abbiamo pensato per questa persona. Abbiamo creato circa 60 funzionalità totali in tutte le persone, con una sovrapposizione minima, poiché un cassiere, un gestore di negozio e un cliente finale interagiscono con l'applicazione in modi diversi. A seconda del tipo di prodotto che stai sviluppando, potrebbero esserci molte più sovrapposizioni di funzionalità tra i tipi di utenti.

   

Caratteristiche essenziali dei viaggi dell'utente (45 minuti)

1. Raggruppa le funzionalità per ciascun tipo di utente nelle parti discrete di ciascun percorso utente su una lavagna reale o virtuale. Quindi, traccia una linea orizzontale sulla lavagna. Sopra la linea, identificare i set necessari per il funzionamento del prodotto. Sotto la linea, posiziona le funzionalità che è bello avere ma che possono aspettare fino a versioni successive. (30 minuti)

   Suggerimento rapido: dividere i progettisti e gli ingegneri in gruppi per completare questo passaggio, quindi riunirsi nuovamente per confrontare le note. Ciò è particolarmente utile nelle riunioni di 10 o più persone.

   Esempio di caso d'uso: per la nostra app, a questo punto avevamo 12 set di funzionalità, che coprivano il caricamento degli articoli nel catalogo dell'inventario, la determinazione del prezzo, la selezione degli articoli da aggiungere al carrello di un cliente, il check-out e la chiusura della vendita, il riordino dell'inventario in esaurimento, e altro ancora. Alla fine abbiamo ridotto a quattro il numero di set di funzionalità.

   Questo processo di eliminazione ci ha aiutato a determinare che l'accesso di sicurezza di un utente non era necessario nella prima iterazione dell'app. Né stava aggiungendo uno sconto o una mancia. Abbiamo anche deciso che il cassiere non doveva essere in grado di mostrare il totale di tutte le vendite giornaliere come parte di un MVP, anche se il gestore del negozio o il proprietario potrebbero farlo.

2. Perfeziona l'elenco delle funzionalità. Chiedi "Se questo fosse omesso, il prodotto funzionerebbe ancora?" Se la risposta è sì, lascia quella funzione fuori dall'MVP e salvala per un'iterazione successiva del prodotto. Se la risposta è no, devi includere quella caratteristica nell'MVP. Alla fine di questo processo, saprai cosa è veramente necessario per rendere funzionale il tuo prodotto. Spesso, questo consisterà in solo tre o quattro funzioni per ogni set. (15 minuti)

   Nota: evita di creare troppi set di funzionalità nell'MVP. Anche se dovresti anticipare opinioni dissenzienti su ciò che è più importante includere, è tuo compito di product manager fare la chiamata. Hai fatto le tue ricerche e disponi di dati per supportare le tue decisioni. In base alla mia esperienza, molti prodotti sono inizialmente costruiti in modo più robusto di quanto dovrebbero essere e la maggior parte delle aziende preferirebbe mettere qualcosa nelle mani degli utenti per i test e il feedback il più rapidamente possibile.

Progettazione, test e ingegneria del prodotto (75 minuti)

1. Chiedi ai progettisti di integrare le funzionalità principali in un design wireframe dell'MVP, che gli ingegneri utilizzeranno per costruire l'architettura del prodotto. (45 minuti)

2. Consenti agli specialisti di prodotto e ai designer di lavorare insieme su alcuni test UX leggeri del design del wireframe. (15 minuti)

   Nota: esistono pochissimi scenari di gestione del prodotto in cui è necessario creare senza coinvolgere il cliente finale, ma in caso di test e sviluppo rapidi, è possibile testare un prototipo di design internamente o con amici e familiari che non conoscono il prodotto. Se sono confusi, lo saranno anche alcuni dei tuoi utenti.

3. Fornisci i wireframe progettati agli ingegneri affinché inizino a costruire l'architettura dell'MVP. Non avranno tutto ciò di cui hanno bisogno, o il tempo, per creare una soluzione completa, ma possono iniziare e l'architettura che costruiscono verrà utilizzata per completare l'MVP. Nel frattempo, i team di progettazione e prodotto possono continuare a testare i loro wireframe con membri del team interni o amici e familiari che agiscono come utenti. Il fatto che i team lavorino contemporaneamente su questo passaggio consente di risparmiare tempo. (15 minuti)

Man mano che diventi più abile nell'utilizzo di questo processo, diventerà più facile identificare quali funzionalità sono i componenti principali di un MVP e quali possono essere costruite in seguito. La pratica ti impedirà anche di costruire le cose sbagliate: potresti avere qualcosa in mente per l'elenco "più tardi", solo per scoprire successivamente che nessun cliente lo vuole.

Risultati e risultati chiave

Prima dei nostri sforzi, la nostra app era una tastiera con i numeri da 0 a 9, un punto decimale e un pulsante di addebito. A causa di questa limitazione e del flusso di lavoro inefficiente che ha creato, nel corso di un anno, la nostra fidelizzazione è stata bassa, circa il 20%. Sebbene avessimo acquisito nuovi utenti più rapidamente della concorrenza, li avremmo persi quasi altrettanto velocemente.

Durante il processo di creazione dell'MVP, abbiamo creato quattro set di funzionalità chiave, tutte di portata minima ma di alta qualità. Un utente può ora:

1. Carica gli articoli nell'inventario direttamente da un dispositivo mobile semplicemente utilizzando una fotocamera, inserendo un nome e inserendo un prezzo.
2. Seleziona quegli articoli e aggiungili al carrello di un cliente.
3. Chiudi la vendita mentre visualizzi gli articoli in vendita.
4. Visualizza il numero di articoli venduti in un determinato periodo di tempo.

I clienti hanno apprezzato il prodotto migliorato. Il tasso di fidelizzazione è stato del 45% tra i nuovi utenti che hanno sfruttato la funzionalità del catalogo per il checkout almeno cinque volte entro la prima settimana di caricamento degli articoli.

Grazie all'efficienza del nostro processo di scoping MVP, abbiamo costruito e consegnato la nostra app completamente finita in circa due mesi. Questo processo avrebbe probabilmente richiesto quattro mesi o più con un approccio di sviluppo tradizionale, se il prodotto fosse mai stato realizzato.

Questo processo accelerato consente di risparmiare tempo e denaro. Uno sprint di progettazione completo può essere costoso. L'inizio della riunione di avvio rende il mio processo più economico sin dall'inizio e questi risparmi sono amplificati dalla tempistica di sviluppo complessiva molto più breve.

Tuttavia, i due processi possono anche funzionare in tandem: se il tuo team ha completato uno sprint di progettazione per definire un problema di core business e la soluzione che devi creare, puoi utilizzare il mio processo per definire il tuo ambito MVP in modo più efficiente.

Ricorda che questo processo è solo l'inizio: un MVP è un lavoro in corso che verrà ulteriormente perfezionato nelle versioni successive. Una volta che è completamente compilato e pronto per essere distribuito, ti consiglio di aggiungere un interruttore beta che gli utenti possono disattivare per tornare alla vecchia esperienza dell'app. Sfruttare il software di comportamento, come Heap, per tenere traccia di quanti utenti esercitano questa opzione ti darà una buona idea di ciò che deve essere aggiunto o modificato per migliorare il tuo prodotto nell'iterazione successiva.