Du har en idé til en app og to veje foran dig: bygge alt det, du drømmer om, med det samme — eller starte med en lille version og udvikle den skridt for skridt. Valget mellem et "fuldt produkt" og MVP udvikling er den vigtigste beslutning inden projektstart — og det sted, hvor virksomheder oftest brænder budgettet.
Hvad er et MVP i virkeligheden?
MVP (Minimum Viable Product) er den mindste version af produktet, som løser et reelt problem for brugeren. Ikke en "demoversion", ikke en prototype til fremvisning — et fungerende produkt, blot skåret ned til én central funktion. Et eksempel: den første version af en app til booking af aftaler har ikke brug for et loyalitetsprogram, chat og statistik. Den har brug for en kalender og en "book"-knap.
Hvornår er et MVP det rigtige valg?
- Ny idé, uvalideret marked — du ved endnu ikke, om folk vil bruge det. Et MVP er den billigste måde at finde ud af det.
- Begrænset budget — det er bedre at have én funktion, der er lavet fremragende, end ti, der er lavet halvt færdigt.
- Tidspres — et MVP kommer på markedet i 2–4 måneder i stedet for et år. Hver måned tidligere er en måned med rigtige tilbagemeldinger.
- Du søger en investor — et fungerende produkt med de første brugere overbeviser mere end den bedste præsentation.
Hvornår er et MVP en dårlig idé?
Der findes situationer, hvor en "minimal version" ikke fungerer: regulerede markeder (fintech, medicin — de lovgivningsmæssige krav skal opfyldes fra dag ét), produkter, hvor tillid er alt (ingen betror deres penge til en app, der ser ufærdig ud) samt digitalisering af virksomhedens eksisterende processer — hvis appen skal erstatte et system, der fungerer, skal den fra starten kunne alt det, som det system kan.
Den mest almindelige fejl: et "MVP", der ikke er M
I praksis indeholder 8 ud af 10 projektbriefs, vi modtager med bemærkningen "MVP", en liste over funktioner til to års udvikling. Testen er enkel: hvis fjernelsen af en funktion ikke betyder, at produktet holder op med at løse hovedproblemet — så hører den funktion ikke til i MVP'et. Vær benhård. Version 2.0 kommer hurtigere, end du tror.
Hvordan ser et godt forløb ud?
En gennemprøvet model: 1) workshop og prioritering af funktioner, 2) klikbar prototype (du tester på brugere, før der skrives kode), 3) MVP på 2–4 måneder, 4) indsamling af data og tilbagemeldinger, 5) videreudvikling i korte iterationer på baggrund af fakta, ikke fornemmelser. Sådan kører vi projekter i CodePort — og derfor afregner vi i etaper og ikke med én faktura for "det hele".