MVP eller prototype: Hva er forskjellen?
En prototype simulerer produktet: Den ser ekte ut, men fungerer ikke i virkeligheten, og den testes i intervjuer. En MVP fungerer faktisk og møter virkelige brukere i drift. Derfor koster en MVP ofte rundt ti ganger mer. Prototypen svarer på om folk forstår ideen, MVP-en på om de bruker den og betaler.
«Vi skal bygge en prototype» og «vi skal bygge en MVP» sies som om det var det samme, og de blandes sammen i nesten hvert oppstartsmøte. Men de beviser forskjellige ting og skiller seg kraftig i pris. Kort fortalt: En prototype simulerer produktet, mens en MVP fungerer i virkeligheten. Å velge feil gir enten unødvendige kostnader eller falsk trygghet. Her er forskjellen som avgjør budsjettet.
Prototypen simulerer, MVP-en fungerer
En prototype er en troverdig attrapp. Den ser ut og føles som produktet, men under overflaten finnes det ingen reell logikk. Klikker du på en knapp, hopper du til neste forberedte skjermbilde, og ingenting beregnes eller lagres. Den hører hjemme i intervjuer og demoer, der en testperson kan reagere på den som om den var virkelig.
En MVP er det motsatte: et fungerende produkt i drift, om enn skåret ned til kjerneflyten. Den har kode, database, kontoer og ofte betaling. Virkelige brukere kan ta den i bruk uten at noen står ved siden av og forklarer, og det de gjør, er faktisk atferd, ikke reaksjoner i et intervju.
Forskjellen er altså ikke hvor ferdige de ser ut (begge kan se polerte ut), men om det finnes noe som fungerer bak overflaten.
Derfor er kostnaden ofte ti ganger så høy
At en MVP kan koste i størrelsesorden ti ganger mer enn en prototype, overrasker mange, men det følger direkte av forskjellen over. En attrapp krever design og lenkede skjermbilder. Et fungerende produkt krever i tillegg alt det usynlige: logikk, datalagring, kontoer, sikkerhet, betaling og drift.
| Aspekt | Prototype | MVP |
|---|---|---|
| Hva den er | Simulering, lenkede skjermbilder | Fungerende produkt i drift |
| Beviser | Forståelse, flyt, uttalt vilje | Faktisk atferd, bruk, betaling |
| Testes i | Intervjuer og demoer | Faktisk bruk i drift |
| Relativ kostnad | Lavest | Ofte ca. ti ganger høyere |
| Endres på | Timer | Dager til uker |
Tidoblingen er altså ikke et påslag. Den gjenspeiler at du får to vesensforskjellige ting. Og den er berettiget fordi en MVP svarer på spørsmål en prototype aldri kan svare på: Kommer folk tilbake, fullfører de flyten på egen hånd, og betaler de faktisk?
Rekkefølgen: prototype før MVP, og når steget hoppes over
For et nytt produkt der utformingen er usikker, er den logiske rekkefølgen prototype først, MVP etterpå. Prototypen lar deg treffe riktig med opplevelsen billig og raskt, med skjermbilder som kan tegnes om mellom intervjuene til flyten sitter. Den valideringen tas så videre inn i MVP-en, som tester forretningen i virkeligheten, og skjermbildene fra prototypen blir i tillegg et grunnlag som korter ned designfasen for MVP-en.
Men steget hoppes noen ganger over med god samvittighet. Er flyten enkel og velkjent, eller finnes det allerede et utprøvd mønster å følge, tilfører prototypen lite, og du kan gå rett på MVP-en. Ligger usikkerheten bare i teknologien og ikke i opplevelsen, er det heller ikke en prototype du trenger, men en teknisk test.
Et konkret scenario
Et team ønsket å bygge en tjeneste med en ny måte å navigere i innhold på. Uten prototype: De bygger MVP-en direkte for 620 000 kr, lanserer og oppdager at brukerne ikke skjønner navigasjonen. Ombygging og tapt tid følger.
Med prototype: De lager først en prototype for rundt 100 000 kr, tester den på åtte personer og ser med en gang at navigasjonen forvirrer. To omtegninger senere er flyten forståelig, og først da bygges MVP-en, på et opplegg som allerede har vist seg å fungere. Prototypen kostet ikke 100 000 kr; den sparte dem for en betydelig større sum og flere uker. Slik ser regnestykket ut når usikkerheten om designet er stor.
Den vanlige sammenblandingen og hva den koster
Prisen for å forveksle begrepene betales begge veier. Bestiller du en «prototype», men mener et produkt som skal tåle virkelige brukere, blir du skuffet når attrappen ikke kan settes i produksjon. Den var aldri bygget for det. Bestiller du en «MVP», men egentlig bare vil teste om folk forstår ideen, betaler du for kode og drift når lenkede skjermbilder hadde vært nok.
Misforståelsen oppstår fordi begge ordene i dagligtale betyr omtrent «en tidlig, enkel versjon». Men de skiller seg på det som koster: om det finnes noe som fungerer bak overflaten. Å avklare hvilken av de to du faktisk trenger, allerede før du ber om et tilbud, er derfor en av de billigste beslutningene i hele prosjektet, og en av de dyreste å slurve med.
Usikker på hvilket steg akkurat din idé trenger? Vi i Weapp finner ut hvor usikkerheten ligger før noe bygges, som en del av tjenestene våre. Ta kontakt med ideen din, så peker vi ut riktig startpunkt.
Ofte stilte spørsmål
Kan man hoppe rett til en MVP uten prototype?
Ja, hvis usikkerheten ikke ligger i designet. Er flyten enkel og velkjent, eller finnes det allerede et utprøvd grensesnitt å støtte seg på, tilfører en prototype lite. Ligger usikkerheten derimot i om brukerne forstår og vil ha opplegget, sparer prototypen penger ved å fange opp misforståelsene før de bygges i kode.
Hvorfor koster en MVP så mye mer enn en prototype?
Fordi den faktisk fungerer. En prototype er skjermbilder som er koblet sammen, uten logikk under overflaten. En MVP har fungerende kode, database, kontoer, betaling og drift, altså alt som kreves for at virkelige brukere faktisk skal kunne bruke den. Det er forskjellen på en attrapp og et produkt, og derav størrelsesforskjellen i pris.
Er prototypen bortkastede penger hvis vi uansett skal bygge en MVP?
Nei, tvert imot. Prototypen sparer som regel penger totalt sett fordi misforståelser rettes mens de bare koster timer, ikke uker med utvikling. I tillegg blir skjermbildene og brukerflyten fra prototypen direkte grunnlag for MVP-en, noe som korter ned designfasen. Det du ikke kan gjenbruke, er kode. Det finnes ingen kode i en prototype.
Hva bør prototypen inneholde for å være nyttig?
De skjermbildene og den brukerflyten som bærer den viktigste hypotesen, utformet realistisk nok til at en testperson glemmer at det er en attrapp. Den trenger ikke å dekke alle tilfeller, bare den veien der du er mest usikker på om brukeren forstår og vil gå videre. Resten er utfylling som forsinker testen.
Hvor mange steg er det mellom idé og ferdig produkt?
Ofte tre. Først en prototype for å teste opplevelsen, så en MVP for å teste forretningen i faktisk bruk og til slutt videreutvikling til et ferdig produkt. Man trenger sjelden alle tre. Hvilke steg som kreves, styres av hvor usikkerheten ligger. Prototype og MVP løser forskjellige problemer og skal ikke forveksles.