Vad är en MVP – och vad är det inte?
Av CodexierPublicerad 5 min läsning
Minimum viable product är ett av de mest använda och minst överenskomna begreppen inom mjukvara. Investerare menar en sak, utvecklare en annan, och grundare menar ofta en mindre version av allt de så småningom vill ha. Den här guiden ger en arbetsdefinition, skiljer en MVP från en prototyp och en beta, förklarar hur litet som är litet nog och visar formerna en MVP kan ta, så att du kan planera en som faktiskt lär dig något.
Syftet: lära sig med riktiga användare
Anledningen att bygga en MVP i stället för hela produkten är osäkerhet. Ni vet inte ännu om problemet är tillräckligt smärtsamt, om er lösning passar, om folk betalar eller vad de gör andra gången de loggar in. En färdig produkt besvarar de frågorna dyrt. En MVP besvarar dem billigt, men bara om riktiga människor använder den i riktiga situationer. Interna demos och vänlig feedback räknas inte.
Inte en prototyp, inte en beta
| Sak | Vem som använder den | Vad den besvarar | Byggd för att hålla? |
|---|---|---|---|
| Prototyp | Ni själva, testdeltagare | Är flödet begripligt? Är idén vettig? | Nej, kastas |
| MVP | Riktiga användare med ett riktigt problem | Använder de den, betalar de och kommer de tillbaka? | Kärnan ja, resten nej |
| Beta | Tidiga kunder till en nästan färdig produkt | Vad är trasigt eller saknas före lansering? | Ja |
| Färdig produkt | Alla | Kan den skala och konkurrera? | Ja |
En klickbar prototyp är rätt verktyg när frågan gäller designen eller konceptet, och den kostar en bråkdel av kod; vår designsprint ger precis det. En beta kör ni när produkten finns och ni vill fånga fel. En MVP sitter mellan dem: tillräckligt med teknik för att vara pålitlig, tillräckligt lite för att vara billig att ändra.
Hur litet som är litet nog
Utgå från det enda jobb användaren anlitar produkten för och bygg bara vägen som slutför det jobbet. Allt som hjälper användaren efter att jobbet är klart, eller som tjänar en andra sorts användare, får vänta. Ett praktiskt test: skriv användarens berättelse från registrering till resultat i fem meningar. Dyker en funktion inte upp i de meningarna är den inte med i MVP:n.
- En användartyp. En andra roll fördubblar produkten; lägg till den när den första betalar.
- Ett kärnflöde, från början till slut, som fungerar väl. Inte tre flöden som fungerar dåligt.
- Manuellt bakom kulisserna är okej. Kan ni leverera något för hand till de första femtio kunderna, automatisera det inte ännu.
- Standardkomponenter för allt som inte är er idé: inloggning, betalningar, mejl, admin.
- Ett inbyggt sätt att prata med användarna: ett feedbackformulär, en supportadress, ett kort samtal efter första veckan.
Det som ändå måste hålla
Minimum betyder inte slarvigt. Användare bedömer förtroende under den första minuten, och en produkt som tappar deras data eller visar den för andra är inte livskraftig i någon storlek. Listan över vad en MVP måste få rätt är kort men inte förhandlingsbar: kärnflödet fungerar varje gång; användardata lagras säkert, säkerhetskopieras och hålls isär mellan kunder; inloggning och lösenordsåterställning fungerar; tar ni betalt fungerar kvitton och återbetalningar; och ni uppfyller grunderna i GDPR, alltså en integritetspolicy, ett sätt att radera sitt konto och ett register över vad ni behandlar.
Det som får vara grovt: den visuella designen utöver tydlighet, inställningssidorna, rapporter, integrationer ni kan ersätta med en manuell export och varje funktion för en andra användartyp. Grovhet där är ett tecken på disciplin, inte försummelse.
Exempel på olika MVP-former
Concierge-MVP
Ni levererar tjänsten för hand bakom ett enkelt gränssnitt. Ett bokningsformulär och en person som gör jobbet. Visar om tjänsten efterfrågas innan någon automation finns.
Enfunktions-MVP
Ett flöde gjort ordentligt, som att ladda upp ett dokument och få det analyserat. Ingen översikt, inga teamfunktioner, inga integrationer.
Kalkylarks-MVP
Produktens logik ligger i ett kalkylark eller ett no-code-verktyg; koden är bara delen användarna rör. Billig att ändra medan reglerna fortfarande rör sig.
Intern-först-MVP
Byggd för ert eget team eller en pilotkund med skriftligt avtal. Lär i en kontrollerad miljö innan allmänheten ser den.
När ni inte ska bygga någon MVP alls: har ni inte pratat med potentiella kunder kommer en landningssida och samtal först och kostar nästan inget. Är idén en kopia av en befintlig produkt med en liten twist är frågan inte om den kan byggas utan varför någon skulle byta, och ingen MVP besvarar det. Och räcker inte budgeten till en stabil kärna: bygg en mindre MVP i stället för en skör större. Vårt planeringspaket för MVP finns för att hitta den minsta livskraftiga formen innan kod skrivs; vad bygget sedan kostar täcks i vad en MVP kostar, och ett kostnadsfritt 15-minuterssamtal är snabbaste sättet att få veta vilken form som passar er idé.
Vanliga frågor
Hur lång tid ska det ta att bygga en MVP?
Veckor, inte kvartal, när omfattningen väl är definierad. Säger planen sex månader är omfattningen för stor för frågorna ni försöker besvara. Att skära ner till en användartyp och ett kärnflöde är det som får ner tidplanen.
Ska en MVP vara gratis för användarna?
Oftast inte. Betalningsvilja är en av de viktigaste sakerna ni försöker lära er, och gratisanvändare besvarar en annan fråga. Ett lågt pris, en pilotavgift eller en betald provperiod säger mer än ett stort antal gratisregistreringar.
Kan en MVP byggas med no-code-verktyg?
Ofta, och det är ett bra sätt att hålla första versionen billig. Gränserna är egen logik, integrationer verktyget inte stöder och köpare som ställer säkerhetsfrågor. Många produkter börjar i no-code och byggs om i kod när modellen är bevisad.
Vad händer när MVP:n fungerar?
Ni vet då vad användarna faktiskt gör, vilket sällan är vad planen antog. Nästa version byggs på den kunskapen, ofta genom att ersätta delar av MVP:n som medvetet var grova. Det är MVP:n som gör sitt jobb, inte ett misslyckande för första bygget.
Osäker på vad den minsta livskraftiga versionen av er idé är?
Beskriv jobbet er produkt gör för sin första användare. På 15 minuter skissar vi MVP-formen med er, pekar ut vad som måste hålla och vad som kan vänta, och säger om ett bygge eller fler samtal ska komma först.
Boka ett kostnadsfritt 15-minuterssamtal