Det finns många möjliga sätt att lansera en ny produkt, och lika många hinder på vägen. Det finns dock ett sätt att bedöma chanserna för framgång innan du dyker i fullt engagemang, och det är där Minsta livskraftiga produkt (MVP) kommer in.
Om du bara vill visa människor den första versionen av din produkt eller om du vill få en förståelse för om din affärsidé löser ett verkligt problem, är att skapa en MVP vägen att gå. Det låter dig Undvik oönskade scenarier som att slösa tid och pengar, och du kommer säkert Spara månader av ansträngning rör sig i fel riktning.
Låt oss ta en titt på vad en MVP är, och fördelarna med att bygga en.
En MVP är en mjukvaruutvecklingsteknik, som först användes av den amerikanska entreprenören Eric Ries, som försäkrar en första fungerande versionen av produkten, med alla nödvändiga krav för att den ska uppfylla sitt huvudmål. Det är värdefullt för användare som det är, och har mycket utrymme för förbättringar genom en uppsättning funktioner som inte beaktas för den ursprungliga versionen, men kan implementeras i ett senare skede.
MVP är ett koncept som används så mycket, och ändå, så svårt att få rätt. En MPV är inte en prototyp, det är inte heller en förlanseringsversion av en produkt. Det är inte en betaversion av något slag, och det föregår inte Den verkliga produkten. I mjukvaruutveckling är det inte heller Mest värdefull spelare, som har samma initialism, men den används i helt olika områden.
Den huvudmålet för MVP är att testa marknaden och få feedback för ytterligare produktförbättring. Genom att veta att ansträngningen att bygga en MVP är mycket mindre än vad som skulle behövas för att implementera alla de ursprungligen övervägda funktionerna, är alla resultat positiva, även i värsta fall.
Om användare adopterar produkten direkt i detta skede skapar du en gemenskap runt den och får utrymme för ytterligare förbättringar med mindre tryck. Samtidigt kommer samma användare att vara de som påpekar vad de tycker att produkten saknar, vilket ger värdefull input för nästa förbättringsrunda. Du kan sedan planera därefter och till och med skrapa några funktioner som man tänkte innan du lanserade MVP, i vissa fall.
I det oönskade scenariot där produkten inte antas, eller misslyckas med att tjäna sitt syfte, kommer det fortfarande att ge värdefull insikt för att antingen anpassa eller släppa produkten, enligt den insamlade feedbacken. Kanske var det ett UI- eller UX-problem eller kanske problemet som produkten skulle lösa var felbedömd. Dessutom finns det också externa faktorer som påverkar resultatet av en produktlansering. Med så mycket som möjligen kan gå fel finns det ingen anledning att inte spela det säkert från början.
I något av ovanstående fall visar sig att bygga en MVP vara det bästa valet. Det kan alltid bero på den tillgängliga budgeten och på affärsmål, men ändå är MVP inte en teknik som bara bör användas för korta budgetar. Små startups gör det lika mycket som stora företag, och det är alltid mer en fråga om strategi än om påtvingade begränsningar.
Men hur börjar man bygga en MVP?
Allt börjar med design. Att gå direkt från idé till implementering med minimal ansträngning på design visar sig vanligtvis vara en mycket dålig idé, oavsett projektets art. Det är inte så att du bara kan få någon att måla ett fint lager ovanpå prototypen när den är klar och kalla det ”designen”.
När du arbetar med produktdesigners förstår du att de är mer som arkitekter än målare. De behöver stöd från ingenjörer för att designa, men den mest kreativa delen av deras jobb är inte hur produkten kommer att se ut, utan snarare vad den ska göra och varför. Och tills faktiska användare använder produkten arbetar alla med antaganden (vissa kanske bara har mer exakta antaganden än andra).
Med detta i åtanke kan vi försöka svara på frågan: ska en MVP vara snabb och lätt att genomgå en verklighetskontroll? Om du har teamet som kan leverera det på tre dagar, varför göra mer? Om idén visar sig välkomnas av människor, har du förtroende och fullt förtroende för att investera i 3 månaders ansträngning och pengar.
Efter det behöver du pengar för att fortsätta växa till hela produkten, varje gång du ökar användarbasen och inte bara sitter på ditt kontor och hypoteser. Samtidigt kommer produktdesignern att kunna observera, analysera och tolka de bevis du samlar in från verklighetskontrollen för att hjälpa dig att investera din tid och pengar klokt.
Om du tror att det är omöjligt att testa din idé på 3 dagar har du fel. Vad du behöver är inte en fullt fungerande produkt, utan helt enkelt ett bevis på att din idé kommer att driva ett visst intresse, vilket är något som kan uppnås med en bråkdel av vad du tycker att din produkt ska göra.
För det andra, oavsett hur genial din idé är, måste dess implementering föregås och hanteras av en riktig produktdesigner. Bra design hjälper dig att ta bort fettet i idén, förstå kärnan i ditt värdeförslag och leverera en elegant lösning för att testa det snabbare.
Kom ihåg: Mer design innebär mindre utveckling, och det är vanligtvis fokus för MVP. Det handlar inte om att stapla funktioner ovanpå varandra, utan att koncentrera ansträngningarna på det som verkligen betyder för att släppa en fungerande produkt som uppfyller ett specifikt mål.
Det finns många sätt att planera ett MVP-projekt, men här kommer jag att fokusera på en specifik metod: Scrum, som visas nedan.
Konceptet introducerades av Hirotaka Takeuchi och Ikujiro Nonaka i samband med produktutveckling 1986, och det har drabbats av flera mutationer under de följande decennierna. Enkelt uttryckt är det en process som syftar till att leverera små produktiterationer över tid, istället för att gå igenom hela produktutvecklingen i sin slutliga version innan du levererar något värde. Det är vanligtvis relaterat till Agila utvecklingsmetoder.
Låt oss nu se hur vi kan anpassa det till Att bygga en MVP.
Produktbackloggen och uppgiftslistan, till vänster om bilden som presenterades tidigare, representerar de olika funktioner som du vill implementera på din produkt. Dessa kommer att övervägas på flera sprints som inträffar i fasta tidsramar efteråt. Slutsatsen av varje sprint genererar feedback som kommer att användas som input för nästa omgång, och det kommer att hända så många gånger som behövs för att slutföra projektplanen.
Föreställ dig att målet med den första sprinten är att bygga en MVP. Produkten levereras som den är och uppdateras enligt samma process, enligt fastställda prioriteringar i projektplanen. Den största fördelen är den regelbundna leveransen av värde inom korta tidsramar och chansen att reagera snabbt på förändringar.
Att upprepa denna process kommer så småningom att leda till projektets slut, med flera omgångar av feedback däremellan. Detta är en av de viktigaste egenskaperna hos en MVP. Det gör att du kan ha fler kontrollpunkter att gå tillbaka till om något går fel, och samtidigt kommer du att belöna användare successivt över tid med produktförbättringar baserat på deras behov.
Detta är bara en av många möjliga vägar att bygga en MVP och arbeta därifrån, och den som vi tar till utveckla digitala produkter oss själva. Det är baserat på ett agilt tänkesätt, där målet är att kontinuerligt leverera värdefull programvara i steg om steg. Andra alternativ finns tillgängliga, men idéerna som stöder projektet kommer att vara mycket lika i alla fall. Det är upp till dig att välja den som bäst passar dina behov.
Ser du fram emot att bygga en ny produkt? Lista din affärsmålTänk på de olika strategier som gör det möjligt för dig att komma dit du vill vara och starkt överväga att ta MVP-vägen.
De viktigaste fördelarna som kommer av det är Minskad risk och återkopplingsinsamling, och båda kommer att göra det möjligt för dig att bättre planera följande steg. Det är inte konsekvensen av att inte ha något annat alternativ, det är en affärsstrategi i sig, och många framgångsrika företag fortsätter att göra det som ett sätt att testa marknaden innan de går in.
Allt börjar i design, eftersom det är det viktigaste steget i att bygga en MVP. Produktdesigners kommer att kunna trimma fettet och hålla produkten till dess väsentligheter innan de går vidare till utveckling. Projektplanen slutar dock inte i MVP, eftersom det vanligtvis är det första steget i en mycket större process.
Slutsatsen är att du alltid kan drömma stort, men du bör börja med båda fötterna på marken. En minsta livskraftig produkt är ett löfte om något Större och bättre, och att släppa projektet efter att det har slutförts skulle vara ett misstag lika allvarligt som att inte släppa en MVP alls.
Baserat på en artikel som ursprungligen skrevs av Nicholas Mandelbaum för Imaginary Cloud
Tyckte den här artikeln intressant? Du kanske gillar dessa också!
Innehållshanterare, textredigerare, och presentatör av strategiska idéer, tillsammans med att vara en ivrig beundrare av filmkonst och visuellt berättande.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
