MVP: den minsta produkten som bevisar något
MVP är ett av de mest använda och mest missförstådda orden i produktutveckling. I många projekt betyder det ”första versionen, fast med färre funktioner”. Det borde betyda något annat: det minsta du kan bygga som besvarar din viktigaste fråga.
Vad MVP betyder
MVP står för minimum viable product, och begreppet fick sitt genomslag med Eric Ries bok The Lean Startup. Poängen var aldrig att leverera mindre. Den var att lära sig så mycket som möjligt, med så lite arbete som möjligt, om huruvida man bygger rätt sak.
En MVP är alltså ett experiment, inte en lansering. Den har ett syfte: att ge ett svar du inte har.
Tre vanliga missförstånd
”MVP är en halvfärdig version av hela produkten.” Då bygger man lite av allt, och inget av det fungerar tillräckligt bra för att någon ska vilja använda det. Henrik Knibergs välkända bild visar skillnaden: vill man ge någon en bil börjar man inte med ett hjul, utan med en skateboard. Något litet som redan tar personen från A till B.
”MVP betyder att kvaliteten får vara låg.” Minimal i omfång, inte i kvalitet. Det som finns med ska fungera. En MVP som kraschar svarar inte på om idén håller, bara på att appen är trasig.
”MVP är det vi lanserar.” Ibland. Men ofta är det bättre att låta en liten, utvald grupp använda den, så att du kan se vad som händer och prata med dem efteråt. En bred lansering ger mer brus och mindre insikt.
Börja med frågan, inte med funktionslistan
Det vanligaste sättet att avgränsa en MVP är att ta funktionslistan och stryka det som känns minst viktigt. Det ger en mindre app, men inte ett bättre experiment.
Börja i stället med det antagande som skulle fälla hela idén om det var fel. Om lärare inte hinner använda tjänsten under en lektion spelar resten ingen roll. MVP:n är det billigaste sättet att ta reda på det.
Ofta behöver den inte ens vara en app. En klickbar prototyp, en tjänst som levereras för hand, eller en enkel yta där allt bakom görs manuellt kan besvara samma fråga på en bråkdel av tiden. Vi går igenom de billigaste sätten att testa i Validera en appidé innan du bygger den.
Hur liten är liten nog?
Gå igenom varje del och fråga: om den här försvann, skulle vi fortfarande få svar på frågan? Blir svaret ja, stryk den. Det som blir kvar är din MVP.
Det hjälper också att avgränsa åt tre håll samtidigt: en grupp människor, en situation, ett jobb de försöker få gjort. En MVP som ska passa alla, överallt, för allt, är inte minimal.
Bestäm vad som räknas innan du bygger
Skriv ner vad som måste hända för att du ska gå vidare, och vad som får dig att ändra riktning. Mät beteende, inte åsikter: kommer folk tillbaka, tar de sig igenom det steg som tjänsten finns till för, och var fastnar de? Varför nedladdningar inte räcker skriver vi om i Varför de flesta appar aldrig används.
Efter MVP:n
En MVP har tre möjliga utfall: fortsätt, ändra riktning, eller sluta. Alla tre är framgång, så länge beslutet fattas på det du faktiskt såg. Det enda misslyckade utfallet är en MVP som inte gav något svar, för att ingen bestämde vad frågan var.
Går du vidare bygger nästa steg på det som höll, och svarar på nästa fråga. Så växer produkten: inte genom att lägga till funktioner, utan genom att varje del har förtjänat sin plats.