MVP, MMF, PSI, WTF? Del ett: Att förstå MVP
När jag arbetar med nya produktägare upptäcker jag ofta att vi fastnar i ett hav av TLA:s (Three Letter Acronyms) när det är dags att faktiskt börja förvandla deras backlog av idéer till släppbara värdeökningar.
Tanken på att bryta ner arbetet – att bryta ner våra stora, planerade produktreleaser till mindre värdeökningar – är där många nya produktägare kämpar. Hur tar vi den här produktplanen och förvandlar den till något som mina Scrum-team faktiskt kan leverera på en kort, regelbunden period? Hur kan jag förvandla denna enorma lista över mycket viktiga funktioner (VIF) till en iterativ uppsättning möjligheter att lära sig, att leverera värde och att faktiskt ge våra kunder något i händerna? Med andra ord….
”Vad är vår MVP?”
”Är det vår MMF?”
”Kan vi släppa den här PSI:n som en MVP, eller behöver vi fler berättelser innan vi har en MMF?”
Alltså….vad????
Vad betyder dessa TLA:s? Hur skiljer de sig från varandra? Hur är de besläktade? Varför ska jag bry mig?
Den här tredelade serien börjar med MVP (Minimum Viable Product) och hjälper nybörjaragilister att förstå vad dessa TLA:er betyder. Hur skiljer de sig från varandra? Hur är de relaterade? Varför ska jag bry mig? Den kommer också att hjälpa till att påminna dem som har arbetat med agilitet ett tag om varför dessa begrepp är grundbulten i agilitet.
För personer som precis har börjat lära sig om Scrum kan de vända sig till Scrum-guiden … och lära sig snabbt att Scrum-guiden är tyst om hur man förvandlar en produkt till en samling små, släppbara värdeökningar.
Den bristande informationen om detta viktiga ämne kan vara mycket frustrerande för nya produktägare. Förhoppningsvis kommer resten av den här artikeln att klargöra MVP:s, och det finns alltid Certified Scrum Product Owner-klasser att kolla in för mer information. Låt oss nu dyka ner i Minimum Viable Product.
The MVP
Du har gjort din forskning, du har gått igenom kundfokusgrupper genom några omgångar av Buy a Feature, och du har fattat några beslut om hur din nästa utgåva kan se ut. Du har till och med engagerat ditt marknadsföringsteam och du har idéer om hur du ska göra ett stort framträdande – annonser i branschtidningar, promotade Tweets, Facebook-inlägg…
Men du har fortfarande några tjatande frågor om några av de funktioner som du arbetar med. Du har tänkt på dem, du har analyserat dem, men det finns en röst i ditt huvud som fortsätter att fråga: ”Men hur vet du det?”
Det är där MVP kommer in i bilden – inte Steph Curry, utan den (kanske felaktigt namngivna) Minimum Viable Product.
The Lean Startup Conundrum
I sin bok ”The Lean Startup” omdefinierar Eric Reis på ett förvirrande sätt begreppet ”Minimum Viable Product”, vilket han förklarar i en intervju 2015. I korthet:
”Några förbehåll direkt från början. MVP handlar trots namnet inte om att skapa minimala produkter. För det andra innebär definitionens användning av orden maximal och minimal att den definitivt inte är formelmässig.”
Så, om världen av produktägarskap och det agila samfundet har omdefinierat Minimum Viable Product till att varken handla om att skapa ett minimum eller produkter, vad är det då?
Allt om lärande
Den där gnagande rösten i bakhuvudet som undrar om det finns en väg ut ur den analysförlamningsfälla du befinner dig i, och som försöker komma på ett sätt att faktiskt veta svaren på några av dina frågor, i stället för att analysera dig själv in i en djupare känsla av falsk säkerhet? Det är där den minsta livsdugliga produkten kommer in i bilden.
Om en PSI (Potentially Shippable Increment) handlar om att skapa en möjlighet att potentiellt leverera något av värde, och MMF (Minimum Marketable Feature) handlar om att kombinera dessa delar av värde till en samling funktioner som löser kundernas problem, handlar MVP om att göra det minsta möjliga arbete som teamet kan göra för att stänga en validerad inlärningsslinga.
I Lean Startup-metodiken för produktupptäckt är en av de viktigaste vanorna att få in en vana att validera hypoteser och skapa experiment. I mer traditionellt riskbenägna organisationer leder tron på att risken måste analyseras ur produkten före lanseringen till långa ledtider och, vilket är frustrerande, databaserade antaganden om kundernas önskemål och behov. Om vi är riktigt bra på statistisk analys och om vi har riktigt bra data om en statistiskt signifikant del av våra kunder kan vi göra ett ganska bra jobb med att formulera en kvalificerad gissning om vad våra kunder vill ha.
Men i slutändan är det fortfarande en gissning.
När vi skapar MVP:er bygger vi avsiktligt precis tillräckligt med funktionalitet för att kunna ställa de rätta frågorna till våra kunder – skulle du köpa den här produkten? Är de här ikonerna vettiga? Är det här arbetsflödet frustrerande eller hjälper det dig att hitta din nästa favoritrestaurang?
I det här skedet tittar vi på pappersprototyper, wireframes för webbplatser, UI mock-ups; vi går över gatan till köpcentret för att visa våra konstruktioner för de närmaste människorna vi kan, bara för att snabbt bekräfta att vi är på rätt spår.
Maginalen i att skapa en bra MVP ligger dock inte i verktygen eller teknikerna; den ligger i disciplinen, när du vill analysera data från en värmekarta för en webbplats för att ta reda på vilket färgschema som fungerar bäst, att i stället ta några tuschpennor och papper, skissa ett par låg-fidelity-lösningar och fråga någon: ”Vilken av de här tycker du bäst om?”