MVP står for "Minimum Viable Product" — den minste versjonen av produktet som er god nok til at ekte brukere kan bruke den og gi reelle tilbakemeldinger. Poenget er ikke å bygge en dårlig versjon av produktet, men å bevisst avgrense omfanget til kjernefunksjonaliteten som tester den viktigste antagelsen bak forretningsideen, før man investerer tid og penger i alt det andre.
Hvorfor en MVP, og ikke bare bygge hele produktet?
Fordi de fleste antagelser om hva kunder vil ha, viser seg å være delvis feil når produktet faktisk møter ekte brukere. Bygger man et fullverdig produkt basert på antagelser som ikke er testet, risikerer man å bruke måneder — og ofte betydelig kapital — på funksjonalitet ingen faktisk bruker. En MVP snur rekkefølgen: test den viktigste antagelsen først, billigst og raskest mulig, og bygg videre basert på det du faktisk lærer.
Hva bør være med i en MVP?
- Kjerneverdien — den ene tingen produktet må gjøre for at noen skal ha lyst til å bruke det.
- Nok stabilitet til at ekte brukere kan stole på det, selv om funksjonaliteten er begrenset.
- En måte å måle bruk og tilbakemelding på — uten data om hvordan MVP-en faktisk brukes, lærer man ingenting av den.
Det som typisk ikke bør være med: avanserte tilpasningsmuligheter, integrasjoner "man kanskje trenger senere", eller polert design utover det som trengs for at brukeren skal stole på produktet.
Tegn på at du bygger for mye, for tidlig
- Du bygger funksjonalitet "i tilfelle" noen ber om det, i stedet for fordi noen faktisk har bedt om det.
- Lanseringen er stadig utsatt fordi "det mangler bare én ting til".
- Du kan ikke i én setning forklare hvilken antagelse den første versjonen faktisk skal teste.
- Ingen ekte brukere har sett eller prøvd noe ennå, flere måneder inn i utviklingen.
Fra MVP til skalerbart produkt
En MVP er ikke ment å vare evig — den er ment å svare på om ideen har livets rett, og gi et konkret grunnlag for hva som faktisk bør bygges videre. Når MVP-en har vist at noen vil ha produktet, bør neste fase adressere det MVP-en bevisst hoppet over: skalerbar arkitektur, sikkerhet, betalingsløsning og alt det som gjør produktet klart for flere brukere og eventuelt investorer.
Neste steg
Har du en idé du vurderer å bygge en MVP av? Det raskeste er en samtale om hvilken antagelse som er viktigst å teste først, og hva et realistisk omfang og en realistisk tidslinje ser ut som for akkurat ditt produkt.
- Hvor lang tid tar det å bygge en MVP?
- Det avhenger av omfanget, men poenget med en MVP er at den skal ta vesentlig kortere tid enn et fullverdig produkt — typisk uker snarere enn måneder.
- Er en MVP det samme som en billig eller dårlig versjon av produktet?
- Nei. En god MVP er bevisst avgrenset i omfang, men fortsatt solid nok til at ekte brukere kan bruke den og gi ærlige tilbakemeldinger.
