MVP, MMF, PSI, WTF? Parte prima: Capire il MVP
Quando lavoro con i nuovi Product Owner, trovo spesso che ci ritroviamo in un mare di TLA (acronimi di tre lettere) quando arriva il momento di iniziare a trasformare il loro Backlog di idee in incrementi di valore rilasciabili.
L’idea di suddividere il lavoro – suddividere i nostri rilasci di prodotti grandi e pianificati in piccoli incrementi di valore è dove molti nuovi Product Owner lottano. Come possiamo prendere questa roadmap del prodotto e trasformarla in qualcosa che i miei team Scrum possono effettivamente consegnare con una cadenza breve e regolare? Come posso trasformare questa enorme lista di Very Important Features (VIF) in un insieme iterativo di opportunità per imparare, fornire valore e mettere effettivamente qualcosa nelle mani dei nostri clienti? In altre parole….
“Qual è il nostro MVP?”
“E’ il nostro MMF?”
“Possiamo rilasciare questo PSI come MVP, o abbiamo bisogno di altre storie fatte prima di avere un MMF?”
Anche…. cosa??
Cosa significano questi TLA? Come sono diversi l’uno dall’altro? Come sono correlati? Perché dovrebbe importarmi?
Partendo da MVP (Minimum Viable Product), questa serie in tre parti aiuterà gli agilisti principianti a capire cosa significano questi TLA. Come sono diversi l’uno dall’altro? Come sono correlati? Perché dovrebbe interessarmi? Aiuterà anche a ricordare a coloro che lavorano in Agile da un po’ perché questi concetti sono i perni dell’agilità.
Per le persone che hanno appena iniziato a conoscere Scrum, possono rivolgersi alla Guida Scrum… e imparano rapidamente che la Guida Scrum è silenziosa sul come trasformare un prodotto in una collezione di piccoli incrementi di valore rilasciabili.
La mancanza di informazioni su questo importante argomento può essere davvero frustrante per i nuovi Product Owner. Speriamo che il resto di questo articolo chiarisca gli MVP, e ci sono sempre le classi di Certified Scrum Product Owner da controllare per ulteriori informazioni. Per ora, immergiamoci nel Minimum Viable Product.
Il MVP
Hai fatto le tue ricerche, hai guidato i focus group dei clienti attraverso alcuni round di Buy a Feature, e hai preso alcune decisioni su come potrebbe essere il tuo prossimo rilascio. In effetti, avete coinvolto il vostro team di marketing e state iterando delle idee su come fare un grande slancio – annunci in riviste specializzate, Tweets promozionali, post su Facebook…
Ma ci sono ancora alcune domande assillanti su alcune delle caratteristiche su cui state lavorando. Ci hai pensato, le hai analizzate, ma c’è questa voce nella tua testa che continua a chiederti: “Ma come fai a saperlo?”
Ecco dove entra in gioco il MVP – non Steph Curry, ma il (forse erroneamente chiamato) Minimum Viable Product.
L’enigma della Lean Startup
Nel suo libro “The Lean Startup”, Eric Reis ridefinisce confusamente il termine “Minimum Viable Product”, che spiega in un’intervista del 2015. In breve:
“Alcune avvertenze fin da subito. MVP, nonostante il nome, non riguarda la creazione di prodotti minimi. In secondo luogo, l’uso delle parole massimo e minimo nella definizione significa che non è decisamente una formula.”
Quindi, se il mondo della Product Ownership e la comunità Agile hanno ridefinito il Minimum Viable Product per non essere né sulla creazione del minimo né sui prodotti, allora cos’è?
Tutto sull’apprendimento
Quella voce fastidiosa nella parte posteriore della tua testa, che si chiede se c’è un modo per uscire dalla trappola della paralisi da analisi in cui ti trovi, cercando di trovare un modo per conoscere effettivamente le risposte ad alcune delle tue domande, invece di analizzare te stesso in un più profondo senso di falsa sicurezza? È qui che entra in gioco il Minimum Viable Product.
Se un PSI (Potentially Shippable Increment) consiste nel creare l’opportunità di spedire potenzialmente qualcosa di valore, e il MMF (Minimum Marketable Feature) consiste nel combinare quei pezzi di valore in una collezione di caratteristiche che risolvono i problemi dei clienti, il MVP consiste nel fare la quantità minima di lavoro che la tua squadra può fare per chiudere un ciclo di apprendimento convalidato.
Nella metodologia Lean Startup di scoperta del prodotto, una delle abitudini più importanti da prendere è quella di convalidare le ipotesi e creare esperimenti. Nelle organizzazioni più tradizionalmente avverse al rischio, la convinzione che il rischio debba essere analizzato dal prodotto prima del lancio porta a lunghi tempi di realizzazione e, in modo frustrante, a supposizioni basate sui dati circa i desideri e le esigenze dei clienti. Se siamo davvero bravi nell’analisi statistica, e se abbiamo dati davvero buoni su una porzione statisticamente significativa dei nostri clienti, possiamo fare un lavoro abbastanza buono per formulare un’ipotesi educata su ciò che i nostri clienti vogliono.
Ma, alla fine della giornata, è ancora un’ipotesi.
Quando stiamo creando gli MVP, stiamo intenzionalmente costruendo solo abbastanza funzionalità per porre le giuste domande ai nostri clienti – compreresti questo prodotto? Queste icone hanno senso? Questo flusso di lavoro ti frustra o ti aiuta a trovare il tuo prossimo ristorante preferito?
A questo punto, stiamo guardando prototipi di carta, wireframes di siti web, UI mock-ups; stiamo camminando dall’altra parte della strada verso il centro commerciale per mostrare i nostri progetti alle persone più vicine che possiamo, solo per validare rapidamente che siamo sulla strada giusta.
La magia nella creazione di un buon MVP non è negli strumenti o nelle tecniche, però; è nella disciplina, quando si vogliono analizzare i dati di una heat-map di un sito web per capire quale schema di colori funziona meglio, per prendere invece alcuni pennarelli e carta, abbozzare un paio di soluzioni a bassa fedeltà, e chiedere a qualcuno, “Quale di queste ti piace di più?