MVP eller færdigt produkt med det samme?
En MVP er den mindste version der tester om nogen vil have produktet før du bygger det hele. Den største omkostning i produktudvikling er at bygge det forkerte, og en MVP er forsikringen mod netop det. Byg kun et færdigt produkt med det samme når virkeligheden kræver det: i regulerede brancher, ved udbud eller med betalende enterprise-kunder fra dag ét.
Spørgsmålet dukker op i starten af enhver produktsatsning: Skal vi bygge en nedskaleret første version, en MVP, eller satse direkte på et færdigt produkt med det hele på plads? Svaret afgør både budget og risiko. En MVP, minimum viable product, er den mindste version der for alvor kan teste om nogen vil have det I har tænkt jer at bygge. Et færdigt produkt er hele visionen, bygget før markedet har sagt sin mening.
Den største omkostning er at bygge det forkerte
I produktudvikling er den dyreste post sjældent udviklingstimerne. Det er at bygge noget som ingen vil have. Et færdigt produkt til f.eks. 2,1 mio. DKK som møder et marked der trækker på skuldrene, betyder at hele summen er tabt, ikke fordi arbejdet var dårligt, men fordi det var rettet mod det forkerte.
Her er MVP’en ren risikoreduktion, og det kan man regne på. En MVP der koster en brøkdel af det færdige produkt, kan give samme svar på om markedet vil have løsningen, bare meget tidligere og meget billigere. Falder hypotesen, har du tabt det lille beløb i stedet for det store. Holder den, har du desuden fået betalende brugere og reel indsigt at bygge videre på. Oddsene i den kalkule er svære at slå.
Pointen er ikke at spare penge ved at bygge mindre. Pointen er at undgå at satse hele budgettet før du ved om du bygger det rigtige.
Når et færdigt produkt med det samme faktisk er det rigtige
MVP-tankegangen er stærk, men ikke universel. Der er situationer hvor en nedskaleret første version ikke kan lanceres meningsfuldt, og hvor du skal nå et minimum af funktioner allerede fra start:
- Regulerede brancher. Inden for sundhed, bank og forsikring er der lovkrav der skal være opfyldt før den første rigtige bruger bliver lukket ind. Du kan ikke skære kravene til sikkerhed, sporbarhed eller regeloverholdelse væk og kalde resten en MVP.
- Offentlige udbud. Et udbud specificerer hvad der skal leveres. Dér er det kravlisten der bestemmer omfanget, ikke jeres hypotese om markedet.
- Betalende enterprise-kunder fra dag ét. Har du allerede en stor kunde med en aftale og en liste over nødvendige funktioner, er forventningen et fungerende produkt, ikke et eksperiment. Markedsrisikoen er i praksis allerede besvaret.
Fællesnævneren er at markedsrisikoen, vil nogen have det her?, allerede er fjernet eller erstattet af et bindende krav. Så falder MVP’ens vigtigste pointe bort, og det bliver rimeligt at bygge bredere med det samme.
Et konkret regneeksempel
Lad os sige at det færdige produkt koster 2,1 mio. DKK og tager et år. Vej A: at bygge det hele med det samme. Efter et år viser det sig at den funktion der var efterspørgsel på, var en helt anden end I troede. Størstedelen af arbejdet var spildt, og I står alligevel over for en ombygning.
Vej B: at bygge en MVP omkring kernehypotesen for 430.000 DKK på tre måneder. Brugerne viser tydeligt hvad de faktisk vil have, og det er delvis noget andet end planlagt. I justerer kursen og bygger videre på det der er valideret. Den samlede sum kan blive den samme, men pengene lander på det rigtige produkt. Forskellen mellem de to veje er ikke omkostningen. Det er sandsynligheden for at pengene gav noget der er værd at have.
Sådan designes en MVP til at vokse i stedet for at blive smidt ud
En udbredt indvending er at en MVP er spildt fordi den alligevel skal bygges om. Det passer kun hvis den bliver bygget som et engangseksperiment. En MVP kan lige så godt bygges som første trin i det rigtige produkt:
- Hold fast i en stack der kan bære. Vælger man teknologi og arkitektur der kan klare produktet i fuld skala, kan MVP’en videreudvikles i stedet for at blive skrevet om.
- Skær i bredden, ikke i kvaliteten. Byg færre funktioner ordentligt frem for mange funktioner sjusket. Det der bliver bygget, skal holde; det der mangler, kommer til senere.
- Lad dørene stå åbne. Design kernen så de nedprioriterede funktioner kan hænges på uden at fundamentet skal rives ned.
Gøres det på den måde, er MVP’en ikke en omkostning ved siden af produktet. Den er produktets første version. Hos Weapp bygger vi normalt MVP’er netop sådan som en del af vores ydelser, med et bevidst valg af om den skal bære videre eller være et rent eksperiment.
Usikker på hvor meget I skal bygge for at få svar på jeres vigtigste spørgsmål? Kontakt os, så hjælper vi jer med at afgrænse.
Ofte stillede spørgsmål
Er en MVP et halvfærdigt produkt?
Nej, det er en udbredt misforståelse. En MVP er helt færdig til sit formål: at teste den vigtigste hypotese med rigtige brugere. Forskellen i forhold til et færdigt produkt er bredden, ikke kvaliteten: Den gør én ting ordentligt i stedet for ti ting halvt. En sjusket MVP tester kun om folk kan leve med fejl.
Risikerer man ikke at virke useriøs med en MVP?
Kun hvis den er lavet sjusket. En velafgrænset MVP kan føles gennemarbejdet inden for sit lille område. De fleste tidlige brugere tilgiver at funktioner mangler, men ikke at det der findes, er i stykker. Læg kvaliteten i kernen, så opfattes produktet som seriøst selvom det er lille.
Hvordan ved vi om vi hører til undtagelserne der skal bygge mere med det samme?
Stil spørgsmålet: Kan vi overhovedet lancere en nedskaleret version lovligt og troværdigt? I en reguleret branche, i et offentligt udbud eller over for en enterprise-kunde med en kravliste er svaret ofte nej. Så er der et minimum af funktioner I skal nå før den første bruger. Dér er en ren MVP den forkerte vej.
Kan en MVP bygges videre, eller skal den bygges om?
Det afhænger af hvordan den bliver bygget. En MVP i en stack og en arkitektur der kan bære videre, kan vokse til det færdige produkt trin for trin. En MVP i midlertidig teknologi, tænkt til at bevise noget hurtigt, skal ofte skrives om bagefter. Beslut allerede fra start hvilken af de to det skal være.
Hvad koster det at springe MVP-trinnet over?
Risikoen er at hele investeringen bliver brugt på et produkt ingen vil have. Bygger du det færdige produkt med det samme for et millionbeløb, og markedet ikke reagerer, er hele summen tabt. En MVP til en brøkdel af prisen havde givet samme svar tidligere. Omkostningen ved at springe trinnet over er altså størrelsen på den fejl du ikke nåede at opdage.