I en värld av försök och misstag är det den som hittar fel snabbast som vinner. Vissa kallar detta tillvägagångssätt för ”fail fast”. Eric Ries kallar det Lean, medan Kent Beck och andra mjukvaruutvecklare kallar det Agile.
Oavsett vad du kallar det är poängen att ta reda på vilka av dina antaganden om produkten som är felaktiga genom att få feedback från riktiga användare så snabbt som möjligt.
Den agila metoden förutsätter att produktutvecklingen delas upp i sprintar, vilket gör det möjligt att minska riskerna och reagera snabbt på nödvändiga förändringar.
Då den agila metoden bygger på idén om en iterativ process baserad på kundåterkoppling spelar MVP:n en central roll i den agila utvecklingen.
Byggandet av en Minimum Viable Product (MVP) hjälper till att leverera en ny produkt med tillräckliga funktioner för att tillfredsställa tidiga användare, vilket gör det möjligt att få värdefull återkoppling och bygga en komplett uppsättning funktioner senare.
MVP-konceptet praktiseras främst inom programvaruindustrin för att kontrollera produktens livskraft. Om du letar efter ett företag som kan bygga MVP åt dig kan du kolla in det här mjukvaruutvecklingsföretaget.
Majoriteten av dagens mjukvara utvecklas med hjälp av agil metodik. I den agila miljön hör du ofta uttrycket minimum viable product (MVP).
Denna term betyder helt enkelt: det mest minimalt utrustade du kan bygga som kommer att hantera möjligheten tillräckligt bra för de flesta av dina målkunder och validera din marknad och produkt.
Med andra ord, om du tänker på den kärnfunktion som du försöker låta kunderna utföra, vilken är den enklaste produkt du kan bygga som gör att de kan uppnå det målet?
Till exempel, låt oss säga att du går tillbaka i tiden och arbetar på den första versionen av en app för en tidning. Appens kärnfunktion skulle vara att informera sina läsare. Därför skulle den enklaste produkten du kunde bygga vara en lista med nyhetsrubriker och en knapp för att uppdatera.
Nyckeln till en framgångsrik MVP är återigen att fokusera på det kärnvärde som appen erbjuder, nämligen färska nyheter, snarare än att ägna din tid åt att bygga ytterligare funktioner i appen.
Notera att MVP inte innebär att produkten ska vara dålig. Sanningen är att den bör vara mycket bra på det den gör, men den bör fokusera på att göra endast ett fåtal kärnfunktioner.
I ett nötskal är MVP:
- Den har tillräckligt värde för att människor ska vara villiga att använda den eller köpa den initialt
- Den visar tillräckligt med framtida fördelar för att behålla de tidiga användarna
- Den ger en återkopplingsslinga för att vägleda den framtida utvecklingen
Varför ska du använda en agil metodik för att utveckla MVP:n?
En viktig skillnad mellan Agile och andra metoder är att Agile utnyttjar MVP:er. Med en agil metod bygger du det enklaste du kan, samlar in data om hur kunderna använder det och finslipar sedan produkten vid behov.
Detta gör att du kan arbeta ganska effektivt och bygga endast de funktioner som kunderna vill ha och kommer att använda i stället för att slösa tid på att bygga saker som kunderna inte bryr sig om.
Kontrastera detta med icke-MVP-baserade metoder för produktutveckling. Med andra metoder kan det sluta med att du spenderar mycket tid på att försöka bygga den ”perfekta” produkten med alla funktioner du kan tänka dig, men när den väl är ute i verkligheten upptäcker du att kunderna inte använder hälften av de funktioner som du trodde att de skulle göra.
Här är ett exempel på den agila minsta livsdugliga produkten (MVP):
Källa: Dropbox
Drew Houston, vd för Dropbox, bestämde sig för att skapa en MVP för det nystartade molnlagringsföretaget i form av en video.
De gjorde en förklaringsvideo och delade den med sitt nätverk för att mäta folks reaktioner. Den tre minuter långa videon förklarade vad Dropbox är och visade hur det skulle hjälpa människor.
Efter att ha släppt videon ökade företaget antalet anmälningar från 5 000 personer till 75 000 över en natt för ”early access” – allt detta utan att ha en riktig produkt.
De viktigaste fördelarna med att bygga MVP (agilt) är alltså:
- Initial Consumer Research
Desto snabbare produkten når ut till målanvändaren, desto snabbare får du feedback och analyserar kundens utmaningar eller preferenser. Om användarna inte tycker att din MVP är värdefull har du utrymme att svänga och testa andra värdeerbjudanden.
Och om det motsatta är fallet är du säker på att utvecklade funktioner är användbara för målkunderna, så du kan gå vidare. I värsta fall kan du frysa projektet för att minska dina förluster.
- Testfasen
Den största fördelen med att utveckla en MVP är att den gör det möjligt att testa olika affärsmodeller och koncept.
Då du erbjuder kärnan av funktioner snarare än en funktionstung produkt, kan du verifiera om deras produktkoncept stämmer överens med din affärsmodell, vilket ger dig en möjlighet att ändra en produkts inriktning baserat på resultaten.
I motsats till funktionstunga produkter har du, när MVP:n lanseras, möjlighet att identifiera vilka typer av sociala grupper som är de mest aktiva användarna, hur de interagerar med produkten och hur du kan tjäna pengar på den.
- Kostnadseffektivitet
Kvalitetsprodukterna är resultatet av flera års utveckling, med en lämplig prislapp. Men eftersom dessa produkter skapades iterativt under en längre tidsperiod sprids kostnaden över tiden.
MVP-strategin bidrar också till besparingar genom att förhindra att produkten blir alltför komplicerad. När produkten börjar få mer dragkraft och samla in mer information om i vilken riktning produkten rör sig kan du öka eller minska dina investeringar.
Om du är intresserad av att lära dig mer om agila och SCRUM-metodologier rekommenderar vi dig att kolla in den här artikeln från SCRUM Institute om hur man blir en SCRUM-mästare i en detaljerad steg-för-steg-process. De erbjuder också de mest populära och mest ekonomiska Scrum-certifieringsprogrammen globalt.
Processen för att bygga MVP (Agile)
Nu när du vet vad som är en MVP, varför den används i Agile och vilka fördelar den har, låt oss ta en titt på de 6 steg som krävs för att bygga en MVP.
Steg 1: Identifiera vilket problem du löser och för vem
När du utvecklar en version av nya produkter är de flesta inte tillräckligt rigorösa när det gäller att definiera de problem de försöker lösa och formulera varför dessa frågor är viktiga. Utan denna process kan produkten missa möjligheter och slösa resurser. Därför måste man bli bättre på att ställa rätt frågor så att de tar itu med rätt problem.
Ta en titt på din produktidé och fråga dig själv:
- Vem är din målgrupp?
Om du fastnar i det här skedet kan du försöka identifiera dina personliga utmaningar. Finns det något du skulle kunna göra bättre om du hade rätt verktyg?
- Varför behöver din målgrupp den här produkten?
Detta hjälper dig att identifiera huvudmålet med din produkt och lösningen på dina potentiella kunders behov.
- I vilken situation skulle de använda den?
Källa: I processen med att identifiera svaren på frågorna ovan är det viktigt att hålla allting realistiskt och dessutom göra tids- och kostnadsberäkningar.
Steg 2: Analysera dina konkurrenter
Sedan du kommit fram till vilket problem du ska lösa är det dags att se hur andra företag löser detta problem – eller åtminstone försöker lösa det. Vid det här laget är det uppenbart att du måste göra en konkurrentanalys om det finns liknande produkter på marknaden.
Du bör också komma ihåg att även om du inte tror att du har några direkta konkurrenter, kommer din tro på din produkts unika karaktär att grunda dig för att du med självförtroende kan föra ut din produkt på marknaden.
Steg 3: Definiera användarflödet, Wireframe & Design
Definiera användarflödet för din framtida produkt innebär att du fokuserar direkt på ditt primära mål. För att definiera det huvudsakliga användarflödet bör vi först definiera processtegen, vilket faktiskt är enkelt eftersom allt du behöver göra är att förklara de steg som krävs för att nå det primära målet för din produkt.
I det här skedet bör du inte tänka på funktioner – utan fokusera på grundläggande uppgifter som till exempel typer av mål som dina slutanvändare har när de använder din produkt, deras förväntningar etc.
När du är klar med att definiera användarflödet kan du gå vidare till wireframing, vilket helt enkelt är en illustration av en webbsida eller en app. En wireframe är en layout som uttrycker vilken typ av gränssnittselement som kommer att hitta en plats på viktiga sidor.
Wireframing Exempel:
Design av användargränssnittet (UI) sammanför koncept från interaktionsdesign, visuell design och informationsarkitektur. Här bör du dra nytta av det du lärt dig i de tidigare faserna för att skapa en upplevelse som kommer att överraska och glädja slutanvändaren.
När vi på Cleevio har den första prototypen klar (vanligtvis en klickbar mock-up) gör vi användartester. Användartestning är viktigt för att den nya appen ska bli framgångsrik. När vi har resultaten av användartesterna klara itererar vi wireframes och testar dem på nytt på användarna.
När wireframes är testade bör du gå vidare till designfasen som bör vara olika för varje plattform (iOS, Android, webb,…).
Steg 4: Analysera dina funktioner
Vet du att mer än 45 % av de funktioner som finns inbyggda i mjukvaruprodukter sällan eller aldrig används?
När du nu har skapat ditt användarflöde kan du börja skapa en mer detaljerad lista över funktioner för varje enskilt steg, men med statistiken i åtanke.
När du har lagt ut dina funktioner för varje steg måste du prioritera dem. Vilken är den viktigaste åtgärden som du vill att dina användare ska utföra? Detta blir din huvudfunktion.
En av metoderna för prioritering av funktioner är MoSCoW som används för att bestämma vilka funktioner som ska färdigställas först, vilka som måste komma senare och vilka som ska uteslutas. En annan teknik som används för att mäta funktionernas nödvändighet är baserad på affärsvärdet (tid att utveckla vs. nice to have vs. kostnader)
Källa: Produktplan
Steg #5: Utveckling & Testning
När du nu känner till funktionerna i din minsta livsdugliga produkt (MVP) är det dags att omsätta dem i praktiken. När du går över till utvecklingsfasen måste du testa din produkt och arbeta för att förbättra dess kvalitet.
När du har godkänt Wireframes bör du börja arbeta med uppläggningsarkitekturen, databasen och börja utveckla API, administration och all back-end.
Alpha- och betatestning kan vara till hjälp här, eftersom det är några av de populäraste sätten att testa en produkts prestanda i olika scenarier. Se till att anpassa testerna och bara göra de ändringar som påverkar hela användarupplevelsen.
Som standard bör du genomföra följande tester i en kontrollerad miljö innan appen lanseras:
- Funktionalitetstestning
- Användbarhetstestning
- Kompatibilitetstestning
- Krowdtestning
- Interfacetestning
- Prestationstestning
- Säkerhetstestning
Under utvecklingsprocessen bör du kontinuerligt testa alla implementerade funktioner.
Till exempel, här på Cleevio bygger vi mobilappar, och utgåvor av betabyggnader laddas upp till Googles alfa/betatestning och till Apples TestFlight. Interna testbyggen finns i Appcenter (ett officiellt verktyg från Microsoft).
När ”release candidate” (en produkt som är redo för marknaden) är klar gör vi öppna eller slutna betatester, där vi bjuder in så många relevanta användare som möjligt till betatestprogrammet och samlar in feedback om funktionalitet och buggar.
Steg #6: Iterativt komma fram till produktmarknadsanpassning eller misslyckande
Om du har validerat MVP:n kan du börja titta på produktens räckvidd och expandera. Vid den här tidpunkten kan du antingen skaffa startkapital för att komma snabbare ut på marknaden eller misslyckas.
För en mobilapp brukar vi göra en ”mjuk lansering” när vi släpper MVP:n i AppStore och Google Play, men vi uppmuntrar inte till någon marknadsföring av appen vid den här tidpunkten.
När appen får fler användare kan vissa buggar dyka upp och vi är noga med att åtgärda allt så fort som möjligt. Vanligtvis släpper vi nya builds varannan dag. När appen är stabil och vi har en kraschfri användarfrekvens på över 99,9 % rekommenderar vi att vi börjar med marknadsföring och skaffar fler användare.
Data är verkligen viktigt och därför rekommenderar vi att övervaka användarnas beteende med Mixpanel eller Google Firebase analytics så att vi kan förstå hur användarna verkligen använder appen.
Det är aldrig slut på utvecklingen av produkten. Mycket viktigt är att be om användarens feedback och iterera produkten. När vi har fler användare utför vi A/B-tester för att kunna testa olika lösningar och öka användarnas engagemang.
Källa: På Cleevio har vi utvecklat över 120 MVP:er under de senaste 10 åren, så vi har tillräckligt med erfarenhet i bagaget för att veta vilka MVP:er som skalar och vilka som brinner och dör.
Vi vet att det är lite överväldigande att förbereda en färdplan, dokumentation eller wireframes för din MVP-idé, så ta gärna kontakt med oss så ger vi dig gärna gratis råd.
För att få ett konsultationssamtal om din MVP, mejla oss på [email protected] .