MVP eller ferdig produkt med en gang?

Av Weapp · Oppdatert 2025-01-28

En MVP er den minste versjonen som tester om noen vil ha produktet før du bygger alt. Den største kostnaden i produktutvikling er å bygge feil ting, og en MVP er forsikringen mot nettopp det. Bygg et ferdig produkt med en gang bare når virkeligheten krever det: regulerte bransjer, offentlige anskaffelser eller betalende enterprise-kunder fra første dag.

Spørsmålet dukker opp i starten av hver produktsatsing: Skal vi bygge en forenklet første versjon, en MVP, eller satse på et ferdig produkt med alt på plass med en gang? Svaret avgjør både budsjett og risiko. En MVP (minimum viable product) er den minste versjonen som faktisk kan teste om noen vil ha det dere tenker å bygge. Et ferdig produkt er hele visjonen, bygget før markedet har sagt sitt.

Den største kostnaden er å bygge feil ting

I produktutvikling er den dyreste posten sjelden utviklingstimene. Det er å bygge noe ingen vil ha. Et ferdig produkt til for eksempel 2,5 millioner kr som møter et marked som trekker på skuldrene, betyr at hele summen er tapt. Ikke fordi arbeidet var dårlig, men fordi det var rettet feil vei.

Her er MVP-en ren risikoreduksjon, og den lar seg regne på. En MVP som koster en brøkdel av det ferdige produktet, kan gi det samme svaret på om markedet vil ha løsningen, bare mye tidligere og mye billigere. Faller hypotesen, har du tapt den lille summen i stedet for den store. Holder den, har du i tillegg fått betalende brukere og reell innsikt å bygge videre på. Oddsene i det regnestykket er vanskelige å slå.

Poenget er ikke å spare penger ved å bygge mindre. Poenget er å unngå å satse hele budsjettet før du vet om du bygger riktig ting.

Når et ferdig produkt med en gang faktisk er riktig

MVP-tenkningen er kraftfull, men ikke universell. Det finnes situasjoner der en forenklet første versjon ikke kan lanseres på en meningsfull måte, og der du må ha et minimum av funksjoner på plass allerede fra start:

Regulerte bransjer. Innen helse, bank og forsikring finnes det lovkrav som må være oppfylt før den første virkelige brukeren slippes inn. Du kan ikke skrelle bort kravene til sikkerhet, sporbarhet eller regeletterlevelse og kalle resten en MVP.
Offentlige anskaffelser. En anskaffelse spesifiserer hva som skal leveres. Der er det kravlisten som bestemmer omfanget, ikke hypotesen deres om markedet.
Betalende enterprise-kunder fra første dag. Har du allerede en stor kunde med avtale og en liste over nødvendige funksjoner, er forventningen et fungerende produkt, ikke et eksperiment. Markedsrisikoen er i praksis allerede besvart.

Fellesnevneren er at markedsrisikoen (vil noen ha dette?) allerede er fjernet eller erstattet av et bindende krav. Da faller MVP-ens viktigste poeng bort, og det blir fornuftig å bygge bredere med en gang.

Et konkret regneeksempel

Si at det ferdige produktet koster 2,5 millioner kr og tar ett år. Vei A: Bygg alt med en gang. Etter ett år viser det seg at funksjonen som var etterspurt, var en helt annen enn dere trodde. Mesteparten av arbeidet var bortkastet, og dere står likevel foran en ombygging.

Vei B: Bygg en MVP rundt kjernehypotesen for 500 000 kr på tre måneder. Brukerne viser tydelig hva de faktisk vil ha, delvis noe annet enn planlagt. Dere justerer kursen og bygger videre på det som er validert. Sluttsummen kan bli den samme, men pengene havner på riktig produkt. Forskjellen mellom veiene er ikke kostnaden, men sannsynligheten for at pengene ga noe som var verdt å ha.

Slik designer du en MVP som vokser i stedet for å kastes

En vanlig innvending er at en MVP er bortkastet fordi den uansett må bygges om. Det stemmer bare hvis den bygges som et engangseksperiment. En MVP kan like gjerne bygges som første steg i det egentlige produktet:

Velg en stack som holder. Velger dere teknologi og arkitektur som tåler produktet i full skala, kan MVP-en videreutvikles i stedet for å skrives om.
Kutt i bredde, ikke i kvalitet. Bygg færre funksjoner skikkelig snarere enn mange funksjoner slurvete. Det som bygges, skal holde; det som mangler, legges til senere.
La dørene stå åpne. Design kjernen slik at funksjonene som er prioritert bort, kan hektes på uten at fundamentet må rives.

Gjøres det slik, er ikke MVP-en en kostnad ved siden av produktet. Den er produktets første versjon. Vi i Weapp bygger normalt MVP-er nettopp på den måten som en del av tjenestene våre, med et bevisst veivalg om den skal bære videre eller være et rent eksperiment.

Usikker på hvor mye dere trenger å bygge for å få svar på det viktigste spørsmålet deres? Ta kontakt, så hjelper vi dere med avgrensningen.

Ofte stilte spørsmål

Er en MVP et halvferdig produkt?

Nei, det er en vanlig misforståelse. En MVP er helt ferdig for formålet sitt, som er å teste den viktigste hypotesen med virkelige brukere. Det som skiller den fra et ferdig produkt, er bredden, ikke kvaliteten. Den gjør én ting skikkelig i stedet for ti ting halvveis. En slurvete MVP tester bare om folk tåler feil.

Risikerer man ikke å virke useriøs med en MVP?

Bare hvis den lages slurvete. En godt avgrenset MVP kan føles gjennomarbeidet innenfor sitt lille område. De fleste tidlige brukere tilgir at funksjoner mangler, men ikke at det som finnes, er ødelagt. Legg kvaliteten i kjernen, så oppfattes produktet som seriøst selv om det er lite.

Hvordan vet vi om vi hører til unntakene som må bygge mer med en gang?

Still spørsmålet: Kan vi i det hele tatt lansere en forenklet versjon lovlig og troverdig? I en regulert bransje, i en offentlig anskaffelse eller overfor en enterprise-kunde med kravliste er svaret ofte nei. Da finnes det et minimum av funksjoner dere må ha på plass før den første brukeren slipper til. Der er en ren MVP feil vei.

Kan en MVP bygges videre, eller må den bygges om?

Det avhenger av hvordan den bygges. En MVP i en stack og en arkitektur som kan bære produktet videre, kan vokse til det ferdige produktet steg for steg. En MVP i midlertidig teknologi, ment å bevise noe raskt, må ofte skrives om etterpå. Bestem helt fra starten hvilken av de to det skal være.

Hva koster det å hoppe over MVP-steget?

Risikoen er at hele investeringen legges i et produkt ingen vil ha. Hvis du bygger alt ferdig med en gang for et millionbeløp og markedet ikke svarer, er hele summen tapt. En MVP til en brøkdel av prisen ville ha gitt det samme svaret tidligere. Kostnaden ved å hoppe over steget er altså størrelsen på feilgrepet du ikke rakk å oppdage.