Che cos'è un prodotto minimo vitale?

Quando si va da 0 a 1, la saggezza ingegneristica ci dice che è importante iniziare con un MVP. Dopotutto, la creazione di un MVP ti consente di ottenere feedback tempestivi, raggiungere i clienti in anticipo e scoprire incognite sconosciute. Compro questo argomento: nella mia esperienza è molto facile passare molto tempo a lavorare su cose che finiscono per non avere importanza e gli MVP mitigano questa preoccupazione. Ma cos'è un MVP? Ne riconosci uno quando ne vedi uno? Un gusto cresciuto con l'esperienza? Analizziamolo.

Perché costruire un MVP?

Per prima cosa ricapitoliamo, perché vogliamo creare MVP.

L'ingegneria riguarda fondamentalmente la costruzione di sistemi soggetti a vincoli. L'obiettivo numero uno di un MVP è quello di fornire una frazione significativa di valore aggiunto con una piccola frazione dello sforzo. Ciò ti consente di ottenere un feedback tempestivo per aiutarti a stabilire le priorità per il resto del lavoro. Spesso ti consente di scartare gran parte del lavoro e concentrarti su ciò che conta.

Nella mia esperienza, ho anche scoperto che questa mentalità ha un enorme vantaggio culturale ed esperienziale per il team di ingegneri che lavorano al progetto. I vincoli ti costringono a lavorare su ciò che conta. Arrivare a mostrare i progressi è soddisfacente. Inoltre, eviti di costruire pezzi che alla fine non sono così utili. È buona norma non attaccarsi troppo emotivamente al proprio codice, perché potrebbe essere necessario buttarlo via. Nonostante ciò, è comunque dannatamente bello vedere che la maggior parte del tuo lavoro va a buon fine, ed è triste dover lasciare andare qualcosa che hai ingegnerizzato troppo.

Cos'è un MVP?

Non sorprende che definire un MVP sia più difficile che descrivere perché ne vuoi uno. Diamo un'occhiata all'espansione dell'acronimo. Un MVP è un prodotto di minima complessità, praticabile in termini di utilità e un prodotto in quanto dovrebbe essere utilizzato da qualcuno rappresentativo del tuo pubblico.

Questi obiettivi a volte sono in contrasto, quindi come possiamo davvero navigare in questo?

Un MVP NON significa un'esperienza interrotta. Sebbene dovrebbe essere minimo in termini di complessità, dovrebbe essere completo in ciò che sta cercando di fare. Non deve cercare di fare tutto (non dovrebbe), ma dovrebbe essere completo in ciò che cerca di fare. L'intera arte di un MVP è trovare scorciatoie per ridurre la complessità mantenendo la fattibilità.

L'ambito di taglio è una parte fondamentale di questo. Ad esempio, un MVP di S3 per l'utilizzo su un sito Web di base potrebbe volere get, pute delete. Probabilmente non ha bisogno di URL prefirmati, caricamenti in più parti ed è meglio che non abbia ACL complessi.

Detto questo, spetta a te come ingegnere e progettista di prodotti scegliere quali parti sono i pezzi fondamentali che stai cercando di fornire. Se il tuo prodotto non è fattibile senza ACL, scegli un set minimo di ACL e distribuiscili completamente senza complessità e riduci l'ambito sul resto.

Infine, un MVP deve uscire con qualcuno. Forse va a pochi primi utenti. Forse va ai tuoi amici o al tuo capo. Forse lo lanci a tutti con un disclaimer "beta". Sono tutti fantastici, ma QUALCUNO dovrebbe usarlo prima che tu continui a lavorarci.

Che aspetto ha un MVP di successo?

Ci sono alcuni scenari post-MVP di successo.

• La gente lo adora e desidera di più. Costruisci più funzioni!
• La gente lo ama così com'è. Lascialo così com'è. Conserva le tue idee sulle funzionalità archiviate per quel momento in futuro in cui ti torneranno utili. Come minimo, sarà un manufatto divertente da guardare tra un anno o due con nostalgia. Nella migliore delle ipotesi è la tua tabella di marcia.
• La gente non è entusiasta. Itera (o lancialo)!

Continua a lanciare il codice!