Vad är en MVP för en app?

Kort svar

En MVP, minimum viable product eller minsta livskraftiga produkt, är den första och minsta versionen av en app som löser kärnproblemet för användarna och går att släppa på riktigt. Enligt Wikipedia är det en tidig version av en produkt med minimala funktioner som räcker för att testas av användare och ge återkoppling för vidare utveckling. Syftet är att lära sig av verklig användning innan man lägger tid och pengar på fler funktioner. En MVP är liten, men den är inte halvfärdig: den måste fungera fullt ut inom sitt område, och den måste klara Apples granskning. För de flesta nya appar är en MVP det klokaste sättet att börja.

Vad en MVP egentligen är

Begreppet populariserades av Steve Blank och Eric Ries och är en central del av lean startup-metoden, där man utvecklar en produkt i korta cykler: bygg något litet, mät hur det används, lär dig och bygg vidare. MVP:n är det första varvet i den cykeln.

Det viktiga ordet är livskraftig. En MVP är inte en prototyp som bara ser ut som en app, och den är inte en betaversion full av fel. Den är en riktig app som riktiga användare kan använda för att lösa ett riktigt problem, bara med så få funktioner som möjligt.

Ett vanligt sätt att förklara skillnaden är med transport. Om målet är att ta sig från A till B, är en MVP inte ett bilhjul, eftersom ett hjul inte tar dig någonstans. En MVP är snarare en sparkcykel: enkel, men den löser problemet från början till slut. Sedan kan den bli en cykel och så småningom en bil, om användarna visar att det är vad de behöver.

	Prototyp	MVP	Fullständig app
Syfte	Testa en idé eller design	Lära av verklig användning	Tjäna en etablerad användarbas
Användare	Testpersoner	Riktiga användare	Riktiga användare
Fungerar på riktigt	Delvis eller inte alls	Ja, inom ett smalt område	Ja, brett
I App Store	Nej	Ja	Ja
Funktioner	Det som behövs för att visa idén	Kärnfunktionen, komplett	Många funktioner

Varför börja med en MVP

Den största risken för en ny app är inte att den byggs dåligt, utan att den byggs för något som ingen behöver i den form man trodde. En MVP minskar den risken.

Du lär dig snabbare. Riktiga användare beter sig annorlunda än man förväntar sig. Med en MVP får du se vad de faktiskt gör, vilka funktioner de använder och var de fastnar, efter några månader i stället för efter ett år.

Du spenderar mindre innan du vet. Varje funktion kostar pengar att bygga och att underhålla. Genom att vänta med allt som inte är nödvändigt slipper du betala för funktioner som visar sig vara onödiga.

Du kommer ut tidigare. En mindre app tar kortare tid att bygga. Vår guide om hur lång tid det tar att bygga en app visar hur stor skillnad omfånget gör för tidsplanen.

Du får något att visa. För startups som söker finansiering är en app med riktiga användare och verklig data ett mycket starkare argument än en presentation.

Ett exempel

Tänk dig en app för hundägare i Stockholm som vill hitta hundvakter i sitt område. Den fullständiga visionen innehåller profiler, bokning, betalning, chatt, recensioner, GPS-spårning av promenader, försäkring och ett lojalitetsprogram.

En MVP kan bestå av betydligt mindre: hundvakter skapar en profil, hundägare söker i sitt område, skickar en förfrågan och betalar i appen. Recensioner kan till en början hanteras enkelt, chatten kan vänta, och GPS-spårning, försäkring och lojalitetsprogram skjuts till senare versioner.

Efter några månader vet grundarna mycket mer. Kanske visar det sig att hundägarna bokar samma hundvakt varje vecka, vilket gör återkommande bokningar viktigare än sökning. Kanske är tryggheten det som avgör, vilket gör recensioner och verifiering viktigare än GPS. Den kunskapen hade de inte fått genom att bygga allt på en gång. Och de har sparat pengarna för de funktioner som visade sig vara oviktiga, pengar som nu kan gå till det användarna faktiskt efterfrågar.

Vad som hör hemma i en MVP, och vad som inte gör det

Att avgränsa en MVP handlar om att skilja det nödvändiga från det önskvärda.

Hör hemma i MVP:n	Kan vänta
Kärnflödet från början till slut	Alternativa flöden och specialfall
Inloggning om appen kräver det	Inloggning med många olika tjänster
Betalning om affärsmodellen kräver det	Rabattkoder och lojalitetsprogram
Grundläggande säkerhet och integritet	Avancerade inställningar
Stabilitet och felhantering	Animationer och specialdesign
En plattform	Flera plattformar samtidigt

Två saker får aldrig skäras bort: kvaliteten i det som byggs och det som krävs för att appen ska vara säker och följa reglerna. En MVP får ha få funktioner, men de funktioner den har måste fungera. Hanterar appen personuppgifter gäller dataskyddsförordningen från första dagen, oavsett hur liten appen är, och integritetsuppgifterna i App Store måste stämma med vad appen faktiskt samlar in.

MVP och App Store

Här finns en fallgrop som många missar. Apple granskar varje app innan den publiceras, och en MVP som känns ofärdig kan bli avvisad. Enligt Apples riktlinjer för App Review ska inskickade appar vara slutliga versioner med all nödvändig information, och platshållartext, tomma webbplatser och annat tillfälligt innehåll ska vara borttaget (riktlinje 2.1). Riktlinje 4.2 om minsta funktionalitet säger att appen ska innehålla funktioner, innehåll och gränssnitt som lyfter den över en ompaketerad webbplats, och att en app som inte erbjuder tillräcklig nytta kanske inte godkänns.

Apple skriver också att över 40 procent av de olösta problemen i App Review gäller just riktlinje 2.1. Det betyder att en MVP måste vara liten på bredden men komplett på djupet. “Kommer snart”-knappar och tomma vyer är precis det som leder till avvisning.

Ett vanligt missförstånd

Det vanligaste missförståndet är att MVP betyder billigt och slarvigt. Det gör det inte. En MVP med fel, krascher och förvirrande design lär dig ingenting om din idé, eftersom användarna slutar använda den av helt andra skäl. Då vet du inte om idén var dålig eller om appen var det.

Det andra missförståndet är att en MVP är en engångsprodukt som slängs. Med rätt arkitektur är MVP:n grunden som nästa version byggs på. Det kräver att koden skrivs ordentligt från början, även om funktionerna är få. Att äga den koden är lika viktigt för en MVP som för en stor app, vilket vår guide om vem som äger koden till appen förklarar.

Efter MVP:n: mät, lär och välj nästa steg

Det som händer efter lanseringen är det som gör en MVP värd besväret. Utan uppföljning är den bara en liten app.

Börja med de frågor du bestämde i förväg. Slutför användarna kärnflödet? Kommer de tillbaka efter en vecka, och efter en månad? Var i appen lämnar de? Siffrorna berättar vad som händer, men inte varför, så kombinera dem med samtal. Några korta intervjuer med användare som slutat, och med användare som stannat, ger ofta mer än veckor av analys.

Sedan kommer beslutet om nästa version. Det finns i grunden tre vägar:

• Fortsätt och bygg ut. Kärnflödet fungerar och användarna kommer tillbaka. Lägg till de funktioner som användarna efterfrågar mest, en i taget.
• Justera. Idén håller, men något centralt behöver ändras, till exempel målgruppen, prissättningen eller det viktigaste flödet.
• Byt riktning. Användarna använder appen till något annat än du trodde, eller inte alls. Det är ett dyrt besked att få, men mycket billigare efter en MVP än efter en fullständig app.

Oavsett väg ska nästa version byggas på samma grund. Därför lönar det sig att skriva MVP:n ordentligt från början, så att den kan växa utan att behöva skrivas om.

Så avgränsar du din MVP

Ett enkelt sätt att komma fram till rätt omfång:

1. Formulera kärnproblemet i en mening. Vilket problem löser appen, och för vem?
2. Beskriv det viktigaste flödet. Vad gör användaren, steg för steg, för att få problemet löst?
3. Lista alla funktioner du kan tänka dig. Allt får komma med på listan.
4. Stryk allt som inte behövs för flödet. Var hård. Fråga för varje funktion: kan en användare få kärnvärdet utan den?
5. Lägg tillbaka det som krävs för kvalitet och regler. Säkerhet, integritet, felhantering och det Apple kräver.
6. Bestäm vad du vill lära dig. Vilka frågor ska MVP:n besvara, och hur mäter du svaret?

Hos AJBU börjar de flesta projekt med en sådan avgränsning, eftersom den avgör både tidsplan och budget. Om du räknar på kostnaden, läs vår guide om vad det kostar att bygga en app, och exempel på appar vi har byggt finns under vårt arbete.

Testa innan du släpper

En MVP ska testas av riktiga människor innan den publiceras. Med Apples TestFlight kan testversioner delas med en grupp testare innan appen släpps i App Store, och det är ett bra sätt att fånga de värsta problemen innan första intrycket görs. Bestäm också i förväg vad du ska mäta när appen väl är ute: hur många som slutför kärnflödet, hur många som kommer tillbaka, och var användarna lämnar appen.

När en MVP passar mindre bra

En MVP är inte alltid rätt väg. Inom områden där misstag får allvarliga följder, som vård, finans eller säkerhetskritiska system, måste även första versionen uppfylla höga krav på säkerhet och regelefterlevnad, och då blir den sällan särskilt minimal. Detsamma gäller när en app ska ersätta ett befintligt system som många redan är beroende av: användarna accepterar sällan att förlora funktioner de redan har. I de fallen är det bättre att avgränsa på andra sätt, till exempel genom att börja med en mindre grupp användare, än att skära bort funktioner som är nödvändiga.