Man skulle kunna hävda att minimalt gångbara produkter (eller "MVP:er") är de mest välförstådda men samtidigt de mest felanvända verktygen i en digital entreprenörs arsenal. Nästan alla som bygger en ny produkt i dag börjar med en MVP. Det är dock få som har lyckats bemästra detta verktyg och få ut det mesta av det.
Så låt mig hjälpa dig att förstå MVP:er, hur man bygger en på rätt sätt och hur man utnyttjar deras fulla potential.
Vad är en minimalt gångbar produkt (MVP)?
Om du ställer den här frågan till en grupp entreprenörer och produktchefer kommer de flesta att svara att den minimalt gångbara produkten är den version av produkten som innehåller den minsta funktionalitet som är tillräckligt acceptabel för att lanseras på marknaden.
Och ja, tekniskt sett har de rätt. Den här definitionen är dock något bristfällig, eftersom den egentligen inte beskriver kärnsyftet med strategin för produktutveckling. Det är faktiskt därför många grundare och produktteam använder MVP:er på fel sätt eller kallar något för en MVP trots att det egentligen inte är en MVP.
Vissa tror att syftet med MVP:n är att tjäna pengar tidigt. Även om det är möjligt är det också helt okej att MVP:n inte genererar några intäkter alls. Så om folk inte köper din MVP-produkt ska du inte avfärda den ännu.
Andra tror att MVP:n är till för att bygga en kundbas som bevisar att produkten fungerar i ögonen på riskkapitalister som vill investera i den.
Återigen, det kan du göra, men det är inte syftet med en MVP.
Så vad är en MVP?
Även om konceptet att ”börja i liten skala, kontrollera om idén är genomförbar och sedan expandera” har funnits under hela den dokumenterade historien utvecklades den formella (och min favorit-)definitionen av MVP av ingen mindre än den store Eric Ries. I sin bok Den slimmade startupen betonar Eric att testa sina kärnhypoteser är det huvudsakliga syftet med en MVP.
Ur perspektivet med en slimmad startup spelar det egentligen ingen roll exakt hur MVP:n ser ut, så länge den:
Det finns alltså verkliga exempel på MVP:er överallt omkring oss – inklusive sådana som ännu inte ens är fungerande produkter. Kuponghanteringstjänsten Groupon lanserade till exempel sin MVP som en liten WordPress-webbplats som såg ut så här.
På den här webbplatsen delade Groupon-teamet helt enkelt dagliga erbjudanden med sin målgrupp.
Det finns gott om andra exempel på framgångsrika produkter där MVP-versionen var en landningssida, en grupp på sociala medier eller till och med en videodemonstration av en produkt som inte existerade (mer om det senare).
Varför nystartade företag behöver en minimalt gångbar produkt
Det finns en god anledning till att MVP:er är så populära som strategi för produktutveckling bland grundare av nystartade företag och produktchefer (trots att många av dem misstolkar konceptet). Att bygga en MVP-version gör det möjligt för nystartade företag i ett tidigt skede att undvika några av de största riskerna som hör ihop med livet som startup.
Låt mig lyfta fram några av dem och visa hur man kan minska dem genom att bygga en MVP.
1. De förhindrar försenade lanseringar
Den digitala världen är så snabb som den bara kan vara. Att lansera en produkt två kvartal senare än alla andra kan innebära att du förlorar marknadsandelar till dina konkurrenter. Tro mig, det är mycket svårare att locka över användare från någon annan än att få en ny användare från den öppna marknaden.
MVP:er löser det här problemet genom att tidigt knyta användarna till din plattform. Även om du kanske inte ger dem den färdiga produkt de drömde om kommer en framgångsrik MVP (förutsatt att den bekräftar dina kärnhypoteser) att behålla användarna hos dig tillräckligt länge för att du ska hinna leverera den slutliga produkten.
För att förstå hur mycket tid en MVP kan spara kan du ta en titt på det här diagrammet, som jag sammanställde med hjälp av data från Atlassian, Shopify och McKinsey.
Beroende på vilken typ av produkt du bygger kan du spara allt från nio månader till två hela år!
2. De minimerar redan investerade kostnader
Det är helt okej att den första versionen av en ny produkt som du lanserar misslyckas—
och ärligt talat kommer den förmodligen att göra det.
Faktum är att andelen misslyckade startupföretag är så hög (90%, enligt en rapport från CB Insights) att du bör fokusera mer på att sänka kostnaderna för dessa misslyckanden i stället för att hoppas att din nästa produkt ska bli en enorm framgång.
MVP:er är ett av de bästa verktygen för att hjälpa dig att göra exakt det. De hjälper dig att validera kundernas behov på marknaden mot ditt värdeerbjudande med minsta möjliga insats. Det innebär att du kan testa din affärsidé utan att gå igenom hela livscykeln för programvaruutveckling med en utdragen utvecklingsprocess. För kostnaden av att skapa en komplett produkt kan du alltså skapa ett dussin MVP:er och kontrollera om de blir omtyckta på marknaden.
Have an account? Log In
3. De hindrar startupföretag från att ”blindbygga” en produkt
Jag använder termen ”blindbygga” för att beskriva utvecklingen av en produkt utan särskilt mycket insikt i vad dina avsedda användare faktiskt vill ha. Detta är förmodligen den största synd en entreprenör kan begå.
Problemet med att skapa en komplett produkt med alla nya funktioner på din färdplan och en färdig prisstrategi är att du inte har någon aning om huruvida människor kommer att tycka om den förrän du har slutfört och lanserat den.
För det mesta kommer människor inte att tycka om den, och du måste göra om dina priser och funktioner. I vissa fall kan du till och med behöva inse att produkten måste skrotas helt eller att du måste ändra produktens prisstrategi fullständigt.
Det bästa sättet att undvika detta är att få tidig återkoppling från användare. Hur kan du göra det? Med en MVP, förstås!
Så bygger du en minimalt gångbar produkt: viktiga steg
När vi nu har gått igenom teorin bakom MVP:er går vi vidare till de mer praktiska delarna och förstår vilka steg som krävs för att bygga ett MVP-koncept som kan uppfylla sitt huvudsakliga syfte—att låta dig testa produktens livskraft på marknaden.
Steg 1: Identifiera ett problem att lösa
Varje bra produkt börjar med ett användarproblem som behöver lösas. Det finns två delsteg i denna process:
a) Identifiera problemet: Det här är vad många startupföretag gör fel—de identifierar fel problem.
Vid 1900-talets början var det centrala problemet inom transport inte brist på snabbare hästar eller bättre infrastruktur som lät hästar färdas långa sträckor. Det verkliga problemet var att människor behövde ett mer tillförlitligt och robust transportmedel. Henry Ford identifierade och löste framgångsrikt detta problem genom att introducera bilen.
Ett av de bästa sätten att identifiera rätt problem är ramverket de fem varför-frågorna.
b) Förstå problemet: Att hitta rätt problem att lösa är halva slaget. Den andra halvan handlar om att förstå det sammanhang och den verklighet där dina användare möter problemet.
Till exempel var TikToks automatiskt genererade undertexter ett resultat av att produktteamet förstod att många användare tittar på TikTok i miljöer där de måste stänga av ljudet.
För att göra detta behöver du genomföra användarintervjuer. Det finns ingen effektivare process än att prata med dina användare för att förstå deras sammanhang.
Steg 2: Definiera MVP:ns kärnfunktioner
Din typiska produktbacklogg kommer att innehålla fler funktioner än du behöver för din MVP.
För att förstå vilka av dem som behöver ingå i MVP:ns omfattning föreslår jag att du använder två fantastiska ramverk för funktionsprioritering:
Kano-modellen: Med denna grupperar du dina funktioner i sådana som gör dina användare entusiastiska, tillför dem värde linjärt och är kritiskt viktiga.
I exemplet med ett hotell är en attraktiv funktion den söta origamihandduken, prestandafunktionen är madrassens kvalitet och grundkravet är det säkra låset på dörren till rummet.
För din MVP fokuserar du på funktionerna som ”måste finnas”.
MoSCoW: Detta är en enkel övning där du tilldelar dina funktioner statusen ”Måste finnas”, ”Bör finnas” eller ”Kan finnas”. Funktioner som måste finnas täcker det centrala användningsfallet.
Med Spotify som exempel är sökning en funktion som måste finnas. Spellistor bör däremot finnas, medan visning av albumomslag på skärmen kan finnas.
För en MVP fokuserar du på funktionerna som måste finnas.
Steg 3: Bygg och testa MVP:n
Din MVP är inte en MVP om du lägger för mycket tid på att bygga den. Därför föreslår jag att du använder följande för att påskynda processen:
- Kodfri utveckling: Verktyg som Bubble låter dig skapa din första version på en bråkdel av den tid det tar att koda från grunden.
- Klickbara prototyper: Med moderna designverktyg kan du göra dina högupplösta trådramverk interaktiva – vilket sparar tid jämfört med att koda en version av produkten.
- Mallar och ramverk med låg kodnivå: Nästan alla större molnleverantörer har färdiga tjänster som du kan använda för att avsevärt påskynda utvecklingsprocessen.
Så snart du har byggt din MVP är det dags att lämna över den till användarna. Du kan använda plattformar som AppSumo och Product Hunt för att samla dina första användare och börja samla in feedback.
Steg 4: Mät framgång och iterera
Ett av kärnkoncepten inom Lean Startup är att mäta resultaten av dina tester med MVP:n och iterera utifrån dem.
Genom att integrera analysverktyg som Mixpanel, Amplitude och PostHog kan du enkelt mäta dina resultat.
Här är några av de viktigaste produktmätvärdena som du kan mäta med dessa verktyg.
Iterationsdelen är enkel. Du tittar på feedbacken och de viktigaste mätvärdena för att identifiera områden som kan förbättras, lägger till dessa förbättringar i MVP:n och släpper en ny version för testning.
Mitt enda råd här är att göra frekventa och små lanseringar. På så sätt kan du förstå om din nya funktion har förbättrat feedbacken eller dina mätvärden.
Vanliga MVP-misstag att undvika
Det är lite kontraintuitivt, men trots MVP:ers enorma popularitet tenderar människor att upprepa samma misstag. Den främsta orsaken är – du gissade det – att man misstolkar det grundläggande syftet med att ha en MVP.
För att hjälpa dig att undvika dessa fallgropar vill jag lyfta fram de tre vanligaste
1. Överutveckla din MVP-version
Många produktteam behandlar MVP:n som den version som är redo att säljas, och tror att de kan testa produkt–marknadsanpassningen med den. Inte riktigt. Det finns en annan version av produkten för det, som kallas MMP (minimum marketable product).
MVP-versionen är däremot mycket mindre och är avsedd att testa om din idé tilltalar riktiga användare.
2. Ignorera feedback
Användarkommentarerna och beteendeanalysen som du får från att testa din MVP är värda sin vikt i guld. Det är vanligt att inte uppmärksamma en del av denna feedback, eftersom man tror att användarna ändå kommer att gilla den slutliga versionen. Nej, det kommer de inte! Varför ens bygga en MVP-version om du vägrar använda Lean Startup-metoden med att skapa återkopplingsloopar?
3. Lansera för sent eller för tidigt
Båda är problematiska. Om du lanserar för sent förlorar hela konceptet med att ha en MVP sin betydelse. Men var också försiktig med att lansera för tidigt. Din MVP bör innehålla tillräckligt många funktioner för att testa dina centrala hypoteser. Dina testresultat blir missvisande om du inte har dessa funktioner.
4. Förväxla MVP med prototyper
Dessa två termer kan verka lite förvirrande. En prototyp är en interaktiv design som du kan använda för användartester. Även om den tekniskt sett kan fungera som en MVP kan du också koda en förenklad version av produkten som en MVP.
Så här skiljer sig MVP, prototyper och fullständiga produkter från varandra.
Som infografiken ovan visar motsvarar prototypernas mål MVP:ns mål. Den enda skillnaden är den fysiska leveransen för var och en.
Exempel från verkligheten på framgångsrika MVP:er
Jag skulle inte bli förvånad om du fortfarande inte är övertygad om effektiviteten i en MVP-strategi. Med tanke på att det finns mängder av populära verktyg och ramverk där ute som många inte tycker är särskilt användbara, tilltalar idén att bygga ett ”uselt första utkast” av produkten inte alla.
Men som Senior Product Manager, som har sett några verkliga katastrofer utvecklas i slow motion, är det här en fråga jag är beredd att gå i döden för. För att bevisa min poäng vill jag visa dig några exempel på MVP-produkter som utvecklats till teknikjättar.
More Articles
Dropbox
Minns du när jag sa att MVP:er inte nödvändigtvis måste vara kodade produkter? Dropbox-versionen av sin MVP var faktiskt en videopresentation!
I den här videon visar Dropbox grundare helt enkelt konceptet för en produkt som ännu inte hade kodats. Resultatet av presentationen blev dock en enorm tillströmning av människor som registrerade sig för att få tillgång till produkten så snart den var klar. Detta var signalen till Dropbox-teamet att de var på rätt spår.
Airbnb
Vår favoritplattform, som ligger bakom bostadsmarknadskriser i många turiststäder (japp, den förbjöds till och med i Florens i Italien av den anledningen!), började också som en icke-traditionell MVP.
Företagets grundare testade sin affärsmodells genomförbarhet genom att hyra ut sängplatser i sin lägenhet i San Francisco till flera konferensdeltagare. De ville förstå om människor skulle känna sig bekväma med att hyra en säng eller ett rum i någon annans lägenhet.
Svaret på den frågan var ja! Därför gav marknaden grundarna grönt ljus att börja bygga en plattform baserad på just den idén.
Zappos
Det sätt som Zappos använde för sin MVP är känt inom produktvärlden som testning enligt ”Trollkarlen från Oz”. I det här scenariot bygger du en webbplats för din produkt, men all bearbetning i bakgrunden hanteras av människor i stället för maskiner.
Zappos-teamet lanserade sin e-handelsbutik för skor som en webbplats utan någon hantering i backoffice. När användare beställde skor från dem köpte teamet skorna någon annanstans och skickade dem till användarna. Efter att ha fått bekräftelse från marknaden på att modellen fungerade började de bygga produktens bakände.
Även om dessa tre är de mest populära berättelserna om MVP:er som genomförts på rätt sätt finns det många fler framgångsrika MVP:er som har utvecklats till mycket framgångsrika produkter.
Verktyg och resurser för att bygga din MVP
Den sista delen av vår MVP-guide i dag handlar om att välja programvara för produktutveckling och utbildningsmaterial som kan hjälpa dig att förbättra effektiviteten och ändamålsenligheten när du bygger en MVP, testar dina hypoteser med tidiga användare och bearbetar användarfeedback.
Vi börjar med verktygen.
- Snabb prototypframtagning och användarupplevelse: Figma, InVision, Sketch, Framer och andra alternativ.
- Arbetsflödeshantering: Kanban-tavlor som Jira, Monday.com och Trello.
- Analys: Mixpanel, Amplitude och PostHog.
- Identifiering av målgrupp: Reddit och Similarweb.
- Bearbetning av kundfeedback: Typeform, SurveyMonkey och Google Forms.
Och om du inte har läst den än rekommenderar jag starkt att börja med Lean Startup som den bästa resursen för att förklara MVP-metoden inom den övergripande strukturen för cyklerna bygga–mäta–lära.
Glöm inte att prenumerera på vårt nyhetsbrev för fler resurser och guider om produktledning, samt de senaste poddarna, intervjuerna och andra insikter från branschledare och experter.
