MVP eller färdig produkt direkt?
En MVP är den minsta version som testar om någon vill ha produkten, innan du bygger allt. Den största kostnaden i produktutveckling är att bygga fel sak, och en MVP är försäkringen mot just det. Bygg färdig produkt direkt bara när verkligheten kräver det – reglerade branscher, upphandlingar eller betalande enterprise-kunder från dag ett.
Frågan dyker upp i starten av varje produktsatsning: ska vi bygga en avskalad första version, en MVP, eller satsa direkt på en färdig produkt med allt på plats? Svaret avgör både budget och risk. En MVP – minimum viable product – är den minsta version som på riktigt kan testa om någon vill ha det ni tänker bygga. En färdig produkt är hela visionen, byggd innan marknaden har sagt sitt.
Den största kostnaden är att bygga fel sak
I produktutveckling är den dyraste posten sällan utvecklingstimmarna. Det är att bygga något ingen vill ha. En färdig produkt för till exempel två miljoner kronor som möter en marknad som rycker på axlarna innebär att hela summan är förlorad – inte för att arbetet var dåligt, utan för att det riktades fel.
Här är MVP:n en ren riskreduktion, och den går att räkna på. En MVP som kostar en bråkdel av den färdiga produkten kan ge samma besked om marknaden vill ha lösningen – bara mycket tidigare och mycket billigare. Faller hypotesen har du förlorat den lilla summan i stället för den stora. Håller den har du dessutom fått betalande användare och verkliga insikter att bygga vidare på. Oddsen i den kalkylen är svåra att slå.
Poängen är inte att spara pengar genom att bygga mindre. Poängen är att inte satsa hela budgeten innan du vet om du bygger rätt sak.
När en färdig produkt direkt faktiskt är rätt
MVP-tänket är kraftfullt men inte universellt. Det finns lägen där en avskalad första version inte går att lansera meningsfullt, och där du behöver nå ett golv av funktioner redan från start:
- Reglerade branscher. Inom vård, bank och försäkring finns lagkrav som måste vara uppfyllda innan den första riktiga användaren släpps in. Du kan inte skala bort kraven på säkerhet, spårbarhet eller regelefterlevnad och kalla resten en MVP.
- Offentliga upphandlingar. En upphandling specificerar vad som ska levereras. Där bestämmer kravlistan omfattningen, inte er hypotes om marknaden.
- Betalande enterprise-kunder från dag ett. Har du redan en stor kund med avtal och en lista över nödvändiga funktioner, är förväntan en fungerande produkt – inte ett experiment. Marknadsrisken är i praktiken redan besvarad.
Det gemensamma är att marknadsrisken – vill någon ha det här? – redan är undanröjd eller ersatt av ett bindande krav. Då tappar MVP:ns viktigaste poäng sin mening, och det blir rimligt att bygga bredare direkt.
Ett konkret räkneexempel
Säg att den färdiga produkten kostar 2 miljoner och tar ett år. Väg A: bygg allt direkt. Efter ett år visar det sig att den efterfrågade funktionen var en helt annan än ni trodde. Större delen av arbetet var bortkastat, och ni står ändå inför en ombyggnad.
Väg B: bygg en MVP kring kärnhypotesen för 400 000 kr på tre månader. Användarna visar tydligt vad de faktiskt vill ha – delvis något annat än planerat. Ni justerar kursen och bygger vidare på det som validerats. Slutsumman kan bli densamma, men pengarna landar på rätt produkt. Skillnaden mellan vägarna är inte kostnaden – det är sannolikheten att pengarna gav något värt att ha.
Så designas en MVP för att växa, inte slängas
En vanlig invändning är att en MVP är bortkastad eftersom den ändå måste byggas om. Det stämmer bara om den byggs som ett engångsexperiment. En MVP kan lika gärna byggas som första steget i den riktiga produkten:
- Håll i en stack som bär. Väljs teknik och arkitektur som klarar produkten i full skala kan MVP:n vidareutvecklas i stället för att skrivas om.
- Skär i bredd, inte i kvalitet. Bygg färre funktioner ordentligt snarare än många funktioner slarvigt. Det som byggs ska hålla; det som saknas läggs till senare.
- Lämna dörrar öppna. Designa kärnan så att de bortprioriterade funktionerna kan hängas på utan att fundamentet måste rivas.
Görs det så är MVP:n inte en kostnad vid sidan av produkten – den är produktens första version. Vi på Weapp bygger normalt MVP:er just på det sättet som en del av våra tjänster, med ett medvetet vägval om den ska bära vidare eller vara ett rent experiment.
Osäker på hur mycket ni behöver bygga för att få svar på er viktigaste fråga? Hör av dig så hjälper vi er avgränsa.
Vanliga frågor
Är en MVP en halvfärdig produkt?
Nej, det är en vanlig missuppfattning. En MVP är fullt färdig för sitt syfte – att testa den viktigaste hypotesen med riktiga användare. Skillnaden mot en färdig produkt är bredden, inte kvaliteten: den gör en sak ordentligt i stället för tio saker halvbra. En slarvig MVP testar bara om folk står ut med buggar.
Riskerar man inte att se oseriös ut med en MVP?
Bara om den görs slarvigt. En väl avgränsad MVP kan kännas genomarbetad inom sitt lilla område. De flesta tidiga användare förlåter att funktioner saknas, men inte att det som finns är trasigt. Fokusera kvaliteten på kärnan så uppfattas produkten som seriös trots att den är liten.
Hur vet vi om vi hör till undantagen som behöver bygga mer direkt?
Ställ frågan: kan vi över huvud taget lansera en avskalad version lagligt och trovärdigt? I en reglerad bransch, en offentlig upphandling eller mot en enterprise-kund med kravlista är svaret ofta nej – då finns ett golv av funktioner ni måste nå innan första användaren. Där är en ren MVP fel väg.
Kan en MVP byggas vidare eller måste den byggas om?
Det beror på hur den byggs. En MVP i en stack och arkitektur som bär vidare kan växa till den färdiga produkten steg för steg. En MVP i tillfällig teknik, tänkt att bevisa något snabbt, måste ofta skrivas om efteråt. Bestäm redan från start vilken av de två det ska vara.
Vad kostar det att hoppa över MVP-steget?
Risken är att hela investeringen läggs på en produkt ingen vill ha. Bygger du färdigt direkt för miljonbelopp och marknaden inte svarar, är hela summan förlorad. En MVP för en bråkdel hade gett samma besked tidigare. Kostnaden för att hoppa över steget är alltså storleken på det misstag du inte hann upptäcka.