Hvad er en MVP? Forskellen på MVP, prototype og pilot

En MVP (minimum viable product) er den mindste version af et produkt som rigtige brugere kan tage i brug, og som giver dig et klart svar på om idéen holder. Hvad er en MVP så ikke? Den er ikke et halvfærdigt produkt med fejl, ikke en klikbar skitse (det er en prototype) og ikke en specialløsning til én kunde (det er en pilot).

Jeg er freelanceudvikler og bygger SaaS-produkter og webplatforme, så jeg tjener penge når nogen beslutter sig for at bygge. Netop derfor vil jeg hellere have at du bygger den rigtige ting i den rigtige rækkefølge, end at du bruger budgettet på en første version som ikke kan svare på noget.

Den korte version: MVP, prototype og pilot

Min beslutningsregel er enkel. Er du usikker på om folk forstår løsningen, så lav en prototype. Er du usikker på om nogen vil betale, så lav en MVP. Har du en konkret kunde der vil afprøve løsningen før de skriver under, så lav en pilot.

Er du tidligt i forløbet med en SaaS-idé, kan du se hele vejen fra idé til betalende kunder i min guide til at bygge en SaaS. Her holder jeg fokus på selve begrebet, og på hvordan du finder ud af hvad din MVP skal være.

Hvad betyder minimum viable product?

Begrebet blev for alvor udbredt af Eric Ries, forfatteren bag bogen The Lean Startup. I et blogindlæg fra 2009 definerer han en MVP som den version af et nyt produkt der lader et team indsamle mest mulig valideret læring om kunderne med mindst mulig indsats. Valideret læring betyder her viden der bygger på hvad kunderne gør, ikke på hvad de siger.

To ord bærer betydningen:

• Minimum betyder så lidt som muligt. Kun det der skal til for at besvare spørgsmålet.
• Viable betyder levedygtig. Produktet skal kunne bruges af rigtige mennesker til at løse et rigtigt problem, og det skal fungere godt nok til at de vender tilbage.

Problemet er at "minimum" er let at huske, og "viable" er let at glemme. Henrik Kniberg, dengang hos det svenske konsulenthus Crisp, lavede en af de mest kendte tegninger af forskellen. I stedet for at levere et hjul, så flere dele og til sidst en bil, leverer du først et skateboard, så et løbehjul, en cykel, en motorcykel og til sidst en bil. Hver version kan bruges til det kunden faktisk har brug for, nemlig at komme fra A til B.

Kniberg foreslår selv at erstatte MVP med mere præcise begreber: det første produkt der kan testes, det første der kan bruges, og det første kunderne holder af (Kniberg, 2016). Hans pointe er at ét ord dækker over vidt forskellige forventninger til kvalitet, og det er præcis der misforståelserne opstår.

For en SaaS betyder det at en MVP er et lille, men helt produkt. En kunde kan oprette sig, løse sin opgave fra start til slut og betale. Det er ikke en fjerdedel af det store produkt.

Hvad en MVP ikke er

De fleste misforståelser handler om at blande omfang og kvalitet sammen, eller om at bruge ordet om noget helt andet.

Ikke et halvfærdigt produkt

En MVP med mange fejl giver dig dårlige data. Melder brugerne fra, ved du ikke om det skyldes idéen, eller at login drillede. Skær i antallet af funktioner, ikke i hvor godt de virker. Den funktion der løser kerneproblemet, skal være god.

Ikke en fuld første version

Mange ønskelister med overskriften "MVP" er i virkeligheden en komplet version 1: brugerroller, rapporter, integrationer, app og administrationspanel. Det er ikke forkert at ville have det hele på et tidspunkt, men det er ikke et minimum, og det tager lang tid før du får svar på det vigtigste spørgsmål. Har du svært ved at skære, så se min liste over 12 funktioner din SaaS kan undvære ved lancering.

Ikke en prototype

En prototype ligner produktet, men den gemmer ikke rigtige data og kan ikke tage imod rigtige kunder. Den er god til at teste om folk forstår et forløb, og den er billig at ændre. Men en positiv reaktion på en prototype er ikke det samme som en betaling. Folk er venlige i en testsession, og det koster dem ingenting at sige ja.

Ikke en pilot

En pilot er en afprøvning hos én bestemt kunde, ofte en større virksomhed, i en aftalt periode og med aftalte succeskriterier. Den svarer på om løsningen virker i netop den organisation. Risikoen er at piloten vokser til en specialløsning, fordi kunden har ønsker som ingen andre deler. Det kan sagtens være en god forretning, men det er ikke en test af om der er et marked.

Ikke noget du smider væk

Nogle bruger MVP om en hurtig og sjusket udgave som skal skrives om bagefter. Er det planen, så kald det en prototype, og sæt penge af til at bygge produktet bagefter. En kodet MVP der virker, bliver typisk fundamentet for næste version, så datamodel, sikkerhed og framework bør vælges med det for øje.

Ikke alle MVP'er kræver kode

Spørgsmålet afgør formen, og mange af de vigtigste spørgsmål kan besvares uden en udvikler:

• En landingsside med pris og en knap til tilmelding viser om folk er interesserede nok til at handle.
• En manuel MVP, ofte kaldet en concierge-MVP, hvor du selv udfører det arbejde som softwaren senere skal klare, viser om kunderne vil betale for resultatet.
• En "Wizard of Oz"-MVP ligner et færdigt produkt udadtil, men bag facaden er det dig der gør arbejdet i hånden.
• Et no-code-værktøj eller et regneark med en formular kan klare de første kunder, hvis forløbet er enkelt.

Metoderne gennemgår jeg trin for trin i guiden til at validere en SaaS-idé. Pointen her er at en MVP ikke er defineret ved at være kode. Den er defineret ved at rigtige kunder bruger den til at løse et rigtigt problem.

Kode bliver nødvendig når produktet selv er værdien: når kunderne skal logge ind og arbejde i systemet hver dag, når data skal deles mellem flere brugere, eller når den manuelle udgave ikke længere kan følge med efterspørgslen.

Sådan finder du ud af hvad din MVP skal være

Rækkefølgen er vigtig. Starter du med en liste over funktioner, har du ikke noget at vurdere dem ud fra. Start i stedet med det du er mest i tvivl om.

1. Find den antagelse der kan vælte idéen

Skriv de ting ned der skal være sande for at idéen lykkes. Forestil dig at du vil lave et bookingsystem til fysioterapeuter med egen klinik. Så antager du at de bruger meget tid på booking i dag, at de vil skifte væk fra deres nuværende løsning, og at de vil betale fx 300 kr. om måneden. Vælg den antagelse der er mest usikker, og som slår idéen ihjel hvis den er forkert. Den skal din MVP teste.

2. Formulér spørgsmålet, og hvad der tæller som et ja

"Vil fysioterapeuter betale for det her?" er ikke præcist nok. Bestem på forhånd hvad der tæller som et ja, fx at ti klinikker betaler to måneder i træk. Uden et kriterium bliver ethvert resultat til "lovende", og så lærer du ingenting.

3. Vælg den billigste form der kan give et ærligt svar

Brug tabellen øverst. Tester du interesse, er en landingsside nok. Tester du forståelse, så lav en prototype. Tester du betalingsvilje, så lav en manuel eller en kodet MVP. Tester du om løsningen virker i én organisation, så lav en pilot. Vælg ikke kode fordi det føles mere rigtigt.

4. Afgræns til ét forløb fra start til slut

Skal MVP'en bygges i kode, så beskriv det ene forløb en ny kunde går igennem fra tilmelding til resultat, og byg kun det. Hvordan du sorterer ønskerne i praksis, gennemgår jeg i guiden til at afgrænse en SaaS-MVP.

5. Beslut på forhånd hvad du gør med svaret

Der er tre udfald: du fortsætter og bygger videre, du retter kursen med en anden målgruppe, pris eller et andet problem, eller du stopper. Skriv ned hvad der skal til for hvert af dem. Det lyder formelt, men det beskytter dig mod at blive ved med at bygge på en idé, bare fordi du allerede har brugt penge på den.

Hvad en kodet MVP skal kunne fra første dag

Når en MVP bygges i kode, er det "viable" der koster penge. Minimumskravene er de samme, uanset hvad produktet handler om:

• En kunde kan oprette sig og logge sikkert ind.
• Kernefunktionen virker fra start til slut, uden at du skal hjælpe til.
• Der er en måde at betale på, også selv om det er en faktura i starten.
• Kundernes data er adskilt fra hinanden, og der tages backup.
• Du får besked når noget fejler, så du ikke hører det fra kunderne først.
• Reglerne om persondata (GDPR) er overholdt fra første kunde.

Resten kan som regel vente til brugerne beder om det. Jeg bygger typisk MVP'er i Laravel, eventuelt med React eller Next.js til brugerfladen, fordi det er udbredte og veldokumenterede værktøjer som en anden udvikler også kan overtage. Det er ikke det eneste rigtige valg, men det er et valg du ikke skal fortryde, når produktet vokser.

Hvad det koster, afhænger mest af hvor meget der ligger i det ene forløb. Jeg har samlet realistiske prisniveauer og eksempler i artiklen om hvad en MVP koster.

Hvornår du ikke skal bygge en MVP endnu

Der er situationer hvor du hverken har brug for en MVP eller for en udvikler som mig:

• Du har ikke talt med en eneste potentiel kunde endnu. Start med samtaler, de er gratis og hurtige.
• Spørgsmålet kan besvares med en landingsside, et regneark eller en manuel service. Så er kode en dyr omvej.
• Du skal bygge et internt værktøj til din egen virksomhed, hvor brugerne og behovet er kendt. Der er ikke et marked at teste, så du skal bare bygge en god første version. Tanken om små skridt er stadig nyttig, men selve begrebet er ikke det vigtige.
• Du har én stor kunde der vil betale for en løsning. Så er det en pilot eller et kundeprojekt, og det skal aftales og prissættes som sådan.
• Du forventer at MVP'en bliver færdig. Det gør den ikke, og hele pointen er at du ændrer den, når du ser hvordan kunderne bruger den.

Næste skridt: fra idé til første version

Før du bruger penge på udvikling, så tjek at du har svar på det grundlæggende. Det gør både samtalen med en udvikler og tilbuddet mere præcise.

Kan du krydse de fleste af, er du klar til at tale om at bygge. På siden om udvikling af SaaS-produkter kan du se hvordan jeg arbejder, fra et betalt forprojekt til fast pris, hvor du og jeg afgrænser MVP'en sammen, til lancering og videreudvikling. Du ejer koden fra første dag.

Ofte stillede spørgsmål

Hvad er forskellen på en MVP og et proof of concept?+

Et proof of concept (PoC) tester om noget kan lade sig gøre teknisk, mens en MVP tester om nogen vil bruge og betale for det. En PoC er typisk et internt eksperiment uden rigtige brugere, fx om en bestemt integration eller AI-model giver gode nok resultater. Er der stor teknisk usikkerhed, er det fornuftigt at lave en PoC før MVP'en, så produktet ikke bygges på en antagelse der ikke holder.

Hvad betyder MLP og MMP?+

MLP står for minimum lovable product og MMP for minimum marketable product. Begge er forsøg på at gøre "viable" mere præcist. En MLP lægger vægt på at de første brugere skal holde af produktet, ikke bare kunne bruge det. En MMP er den første version som du kan markedsføre og sælge bredt. Pointen er den samme: lille omfang og høj kvalitet i det der er med.

Kan jeg selv bygge en MVP med AI-værktøjer eller no-code?+

Ja, til en prototype eller en tidlig test kan værktøjer som Lovable, Bolt eller Bubble bringe dig langt. Udfordringen kommer når rigtige kunder skal logge ind, betale og gemme data. Sikkerhed, adskilte data og vedligehold kræver erfaring. Brug gerne værktøjerne til at teste interessen, og få en udvikler til at gennemgå løsningen før den bruges med rigtige kundedata.

Hvad sker der med en MVP efter lanceringen?+

Den bliver ændret, ofte meget. Du ser hvordan kunderne faktisk bruger den, hvad de efterspørger, og hvor de falder fra, og så retter du til. Nogle funktioner bliver udbygget, andre bliver fjernet. Sæt derfor tid og budget af til månederne efter lanceringen, ikke kun til selve udviklingen. Lanceringen er starten på arbejdet med produktet, ikke afslutningen.