MVP eller prototype: Hvad er forskellen?
En prototype simulerer produktet: Den ser ægte ud, men virker ikke for alvor og bliver testet i interviews. En MVP virker faktisk og møder rigtige brugere i drift. Derfor koster en MVP ofte omkring ti gange mere. Prototypen svarer på om folk forstår idéen, MVP’en på om de bruger den og betaler.
“Vi skal bygge en prototype” og “vi skal bygge en MVP” bliver sagt som om det var det samme, og de to bliver blandet sammen på næsten hvert eneste opstartsmøde. Men de beviser forskellige ting og adskiller sig kraftigt i pris. Kort fortalt: En prototype simulerer produktet mens en MVP virker for alvor. Vælger du den forkerte af dem, koster det enten penge unødigt eller giver falsk tryghed. Her er forskellen der afgør budgettet.
Prototypen simulerer, MVP’en virker
En prototype er en troværdig attrap. Den ser ud og føles som produktet, men under overfladen er der ingen rigtig logik: Klikker du på en knap, springer du til den næste forberedte skærm, og intet bliver beregnet eller gemt. Den lever i interviews og demoer, hvor en testperson kan reagere på den som om den var ægte.
En MVP er det modsatte: et rigtigt produkt i drift, om end skåret ned til sit kerneflow. Den har kode, database, konti og ofte betalinger. Rigtige brugere kan bruge den uden at nogen står ved siden af og forklarer, og det de gør, er reel adfærd, ikke reaktioner i et interview.
Forskellen er altså ikke hvor færdige de ser ud, for begge kan se polerede ud. Forskellen er om der er noget der virker bag overfladen.
Derfor er prisen ofte ti gange højere
At en MVP kan koste i størrelsesordenen ti gange mere end en prototype, overrasker mange, men det følger direkte af forskellen ovenfor. En attrap kræver design og sammenkoblede skærme. Et fungerende produkt kræver derudover alt det usynlige: logik, datalagring, konti, sikkerhed, betalinger og drift.
| Aspekt | Prototype | MVP |
|---|---|---|
| Hvad den er | Simulering, sammenkoblede skærmbilleder | Fungerende produkt i drift |
| Beviser | Forståelse, flow, udtalt vilje | Reel adfærd, brug, betaling |
| Testes i | Interviews og demoer | Reel brug i drift |
| Relativ pris | Lavest | Ofte cirka ti gange højere |
| Ændres på | Timer | Dage til uger |
Den tidobbelte forskel er altså ikke et tillæg. Den afspejler at du får to vidt forskellige ting. Og den er berettiget fordi en MVP svarer på spørgsmål som en prototype aldrig kan nå: Kommer folk tilbage, gennemfører de flowet på egen hånd, betaler de med rigtige penge?
Rækkefølgen: prototype før MVP, og hvornår trinnet springes over
For et nyt produkt med usikkert design er den logiske rækkefølge prototype først og MVP bagefter. Prototypen lader dig finde det rigtige i oplevelsen billigt og hurtigt, med skærme der kan tegnes om mellem interviews indtil flowet sidder. Den validering tages derefter med ind i MVP’en, som tester forretningen for alvor, og prototypens skærme bliver desuden et grundlag der forkorter MVP’ens designfase.
Men nogle gange springes trinnet over med god samvittighed. Er flowet enkelt og velkendt, eller findes der allerede et afprøvet mønster at følge, tilfører prototypen ikke meget, og du kan gå direkte til MVP’en. Ligger usikkerheden udelukkende i teknikken og ikke i oplevelsen, er det heller ikke en prototype du har brug for, men en teknisk test.
Et konkret scenarie
Et team ville bygge en tjeneste med en ny måde at navigere i indhold på. Uden prototype: De bygger en MVP med det samme for 530.000 DKK, lancerer og opdager at brugerne ikke forstår navigationen. Der følger en ombygning og tabt tid.
Med prototype: De laver først en prototype for omkring 85.000 DKK, tester den på otte personer og ser straks at navigationen forvirrer. To omtegninger senere er flowet forståeligt, og først da bliver MVP’en bygget, på et koncept der allerede har vist sig at virke. Prototypen kostede ikke 85.000 DKK; den reddede et betydeligt større beløb og ugevis af tid. Sådan ser kalkulen ud når usikkerheden om designet er stor.
Den udbredte sammenblanding, og hvad den koster
Prisen for at forveksle begreberne betales i begge retninger. Bestiller du en “prototype”, men mener et produkt der skal kunne klare rigtige brugere, bliver du skuffet når attrappen ikke kan sættes i drift: Den blev aldrig bygget til det. Bestiller du en “MVP”, men vil egentlig kun teste om folk forstår idéen, betaler du for kode og drift når sammenkoblede skærme havde været nok.
Misforståelsen opstår fordi begge ord i daglig tale betyder cirka “en tidlig, enkel version”. Men de adskiller sig på det punkt der koster penge: om der er noget der virker bag overfladen. At finde ud af hvilken af de to du faktisk har brug for, allerede før du beder om et tilbud, er derfor en af de billigste beslutninger i hele projektet, og en af de dyreste at sjuske med.
Usikker på hvilket trin netop din idé har brug for? Hos Weapp finder vi ud af hvor usikkerheden ligger før noget bliver bygget, som en del af vores ydelser. Kontakt os med din idé, så peger vi på det rigtige startpunkt.
Ofte stillede spørgsmål
Kan man springe direkte til en MVP uden en prototype?
Ja, hvis usikkerheden ikke ligger i designet. Er flowet enkelt og velkendt, eller findes der allerede en afprøvet brugerflade at læne sig op ad, tilfører en prototype ikke meget. Ligger usikkerheden derimod i om brugerne forstår og vil have konceptet, sparer prototypen penge ved at fange misforståelserne før de bliver bygget i kode.
Hvorfor koster en MVP så meget mere end en prototype?
Fordi den faktisk virker. En prototype er sammenkoblede skærmbilleder uden logik under overfladen. En MVP har rigtig kode, database, konti, betalinger og drift: alt det der skal til for at rigtige brugere kan bruge den for alvor. Det er forskellen på en attrap og et produkt, og deraf størrelsesforskellen i pris.
Er prototypen spildte penge hvis vi alligevel skal bygge en MVP?
Nej, tværtimod. Samlet set sparer prototypen som regel penge fordi misforståelser bliver rettet mens de kun koster timer og ikke ugers udvikling. Desuden bliver prototypens skærme og flows direkte grundlag for MVP’en, og det forkorter dens designfase. Det du ikke kan genbruge, er kode: Der findes ingen i en prototype.
Hvad skal prototypen indeholde for at være brugbar?
De skærme og flows der bærer den vigtigste hypotese, udformet så virkelighedstro at en testperson glemmer at det er en attrap. Den behøver ikke dække alle tilfælde, kun den vej hvor du er mest usikker på om brugeren forstår og vil gå videre. Resten er fyld der forsinker testen.
Hvor mange trin er der mellem idé og færdigt produkt?
Ofte tre: en prototype til at teste oplevelsen, en MVP til at teste forretningen i reel brug og derefter en udbygning frem mod det færdige produkt. Man har sjældent brug for alle tre. Hvilke trin der kræves, afhænger af hvor usikkerheden ligger. Prototype og MVP løser forskellige problemer og bør ikke forveksles.