Jeg er ret sikker på, at næsten alle jer har hørt om konceptet MVP'er. Men der er også stor sandsynlighed for, at flertallet af jer betragter MVP'er som noget meget teoretisk, der sjældent har fundet praktisk anvendelse i den virkelige verden. Sandheden er dog, at eksempler på minimumsprodukter, der kan lanceres, findes overalt omkring os, og mange af de verdenskendte softwareprodukter startede som MVP'er.
Som erfaren produktchef med erfaring i at bygge MVP'er vil jeg gerne dele et par succeshistorier for at vise dig, hvor værdifuldt dette koncept er, hvis du er iværksætter i en lille startupvirksomhed.
Hvad er en MVP?
Et minimumsprodukt, der kan lanceres, er et af nøgleelementerne i Lean Startup, Eric Ries' metode til produktudvikling.
Den grundlæggende idé bag Lean og MVP er, at startups konstant går konkurs, og for at mindske denne risiko bør du først skabe en meget lille version af dit produkt, der indeholder kernefunktionerne, validere, at kunderne ønsker det, og bekræfte, at din forretningsidé fungerer, før du går i gang med udviklingen af det endelige produkt.
Lad os nu dykke ned i historierne om nogle af de mest succesfulde MVP-eksempler derude.
Eksempel nr. 1: Dropbox' usædvanlige format til MVP-udvikling
Lad os begynde med en platform, som mange af os sikkert bruger til at gemme digitale kopier af vigtige dokumenter eller som virksomhedslager til alt det, dit team arbejder på sammen.
Cloudlagring er blevet en integreret del af vores liv, og det er nu en standardløsning til både personlig og professionel brug. Men sådan var det ikke i 2007, da Drew Houston besluttede sig for at starte Dropbox.
Selvom Dropbox ikke var den første cloudlagringstjeneste på markedet på det tidspunkt (du havde allerede Box og Amazon S3, som tilbød en sådan tjeneste), var det den, der tilbød en problemfri oplevelse, når dine filer skulle synkroniseres med skyen.
Drew fandt på en interessant løsning til cloudlagring. I stedet for at få dig til manuelt at uploade og downloade filer ville Dropbox oprette en mappe på din computer, som holdt indholdet synkroniseret med skyen. Så alt, hvad du skulle gøre, var at tilføje eller fjerne filer fra denne mappe; resten var Dropbox' problem.
Det hele føles almindeligt for os i dag, men dengang var det noget fantastisk.
Men at skabe en så problemfri oplevelse betød, at Drews team skulle udvikle computerprogrammer til flere operativsystemer og finde på en kompleks filsynkroniseringsmekanisme, der kunne håndtere alt for dig i baggrunden.
Det betød, at Drew ikke kunne udvikle en MVP-version af Dropbox, eftersom selv det mindste funktionsomfang ville kræve en fuldt fungerende serverinfrastruktur og tage lang tid for hans team at bygge.
Men han ville virkelig gerne have tidlig feedback fra både brugerne og investorerne, da det ville hjælpe ham med at undgå kostbare fejl i appudviklingsprocessen og bygge noget, som markedet ville elske.
Så han valgte en meget ukonventionel tilgang. Hans MVP var en demovideo. Ja, det er rigtigt, han lavede ganske enkelt en forklarende video af sit produkt, hvor han viste den problemfri oplevelse ved at synkronisere filer med Dropbox.
Da Drew begyndte at vise denne video til sin målgruppe, var reaktionen langt bedre, end han kunne have forventet. Trafikken til Dropbox' websted steg til flere hundrede tusinde, og ventelisten til at afprøve betaversionen voksede til 75.000 personer.
Lærdomme fra Dropbox
Den vigtigste lærdom, vi sandsynligvis kan drage af historien om Drew og hans team, er, at man i softwarestartuppens verden skal tænke ud af boksen og ikke lade sig begrænse af tekniske begrænsninger.
Drew vidste, at det ville være fatalt at fortsætte uden at lære om brugernes behov. Derfor måtte han finde en alternativ løsning til en fuldt fungerende MVP.
Det er egentlig ligegyldigt, hvad din MVP er. Det kan være en mockup eller wireframe af en mobilapp eller et falsk websted bygget oven på WordPress. Så længe den type MVP, du vælger, hjælper dig med at få feedback og teste dine antagelser, er du godt på vej.
Den anden lærdom for os er, at der ikke er nogen undskyldning for at springe læringsfasen over og undlade at iterere på dit produkt.
Have an account? Log In
Eksempel nr. 2: Amazons ikkeeksisterende system på serversiden
Før Amazon blev en softwarevirksomhed af gigantiske dimensioner, startede virksomheden berømt som en onlineboghandel.
Det interessante ved Amazons oprindelseshistorie var, at Jeff Bezos' vision for Amazon ikke bare handlede om at sælge bøger online. Hans ambitioner var langt større end at blive verdens største onlineboghandel (som vi kan se på Amazons størrelse i dag).
Grunden til, at han valgte at begynde med bøger, var ganske pragmatisk—bøger var nemme at finde og billige at sende verden rundt.
Det er i dag utrolig nemt at oprette en onlinebutik takket være Shopify, WooCommerce og mange andre færdige værktøjer. Men det var i 1994, da Bezos startede Amazon, og han var nødt til at udvikle hele butikken, inklusive både brugerflade og bagvedliggende system, fra bunden.
Jeff havde ikke mulighed for at investere i at opbygge en hel onlinebutik. Derfor tog han i stedet "Troldmanden fra Oz"-tilgangen til at drive iværksættervirksomheder. Han havde brugerfladedelen klar—en onlinebutik, hvor folk kunne gennemse bøger, tilføje dem til deres indkøbskurve og afgive en ordre.
Men der var ingen bagvedliggende systemer og ingen automatisk behandling af disse ordrer. Når nogen købte en bog på Amazon, tog Jeff personligt hen og købte den i en fysisk boghandel og sendte den til kunden med det offentlige postvæsen.
Ud over at gøre det muligt for Jeff at starte en virksomhed uden en stor indledende investering gav denne tilgang ham også mulighed for tidligt at få tilbagemeldinger fra brugerne på både det websted, han drev, og hele processen med at sælge varer online.
Jeff indarbejdede konstant tilbagemeldinger fra brugerne i sin tjeneste, og i 1999 havde Amazon udviklet sig til noget, der er mere velkendt for os.
Ud over at omsætte tilbagemeldinger fra brugerne til konkrete forbedringer begyndte Jeff også at følge sin større ambition ved at tilføje nye produktkategorier til webstedet. I 1999 solgte Amazon allerede musik, videoer, elektronik, legetøj og andre typer produkter.
Lærdomme fra Amazon
Jeff er en af de gammeldags grundlæggere, der startede deres virksomheder "i deres mors garage". Selvom han brugte "Troldmanden fra Oz"-tilgangen, fordi han ganske enkelt ikke havde råd til et fuldt udviklet websted, fulgte han til sidst den bedste praksis: først at undersøge, om forretningsmodellen fungerer, før man bygger produktet.
Eksempel nr. 3: Zappos' MVP med negativ likviditet
Lad os fortsætte med pionererne inden for e-handel og tale om Zappos, en enorm onlinebutik med speciale i tøj og beklædning, som tilbyder titusindvis af varer og har genereret et par milliarder i omsætning.
Historien om Zappos begynder tilbage i 1999, da grundlæggeren Nick Swinmurn brugte meget tid på at lede efter et bestemt par sko, som han ønskede sig, i det nærliggende indkøbscenter, men ikke kunne finde. Han indså hurtigt problemet ved fysiske butikker—de har altid et begrænset udvalg af skomodeller, fordi et stort udvalg ville øge lager- og opbevaringsomkostningerne for den enkelte butik.
Skobrandene foretrak derfor normalt kun at vise og sælge de mest populære og almindelige modeller i størstedelen af de mellemstore og små butikker, de drev, og kun have de mere nicheprægede modeller tilgængelige i deres største butikker.
Det betød, at hvis man ønskede noget, der ikke var almindeligt, kunne man ikke finde det i sit lokale indkøbscenter og måtte rejse langt til den nærmeste butik, der førte ens yndlingsmærke.
En onlinebutik kan derimod vise et ubegrænset (i teorien) antal varer til brugere, der bor hvor som helst, uanset om det er i en lille by med et mindre indkøbscenter eller i et stort metropolområde med megabutikker.
Ligesom Jeff med Amazon havde Nick ikke økonomisk mulighed for at bygge en hel onlinebutik fra bunden. Selvom han teoretisk set kunne have bedt investorer om pengene, ønskede han ikke rigtig at løbe risikoen for, at hans onlinebutik mislykkedes, og at investorernes penge dermed gik tabt.
Derfor fulgte han samme vej som Amazon og startede et websted efter "Troldmanden fra Oz"-modellen. Nick tog til de lokale indkøbscentre, fotograferede alle de sko, der var tilgængelige dér, og lagde billederne op som varer til salg på sit MVP-websted.
Når en bruger afgav en ordre på Zappos.com, tog Nick hen til butikken i sit lokale indkøbscenter, der solgte den pågældende model, købte den og sendte den til kunden med posten. Som man kunne forvente, tjente Nick ikke penge på den måde, han drev butikken på efter "Troldmanden fra Oz"-modellen. Faktisk tabte han penge.
Det, Nick gik mest op i på dette tidspunkt, var dog ikke bundlinjen. Han ville opnå to ting—tilbagemeldinger fra kunderne og validering af sin forretningsmodel.
Som vi kan se på salgsomsætningen og antallet af produkter, der var tilgængelige på Zappos.com, fungerede Nicks forretningsmodel, og den førte til en enorm succes.
Erfaringer fra Zappos
Zappos og den måde, Nick drev concierge-versionen af MVP'en på, lærer os noget meget vigtigt om startupvirksomheder – det er i orden at tabe penge.
Lad mig være helt tydelig. Det er generelt ikke i orden for en virksomhed at tabe penge. Men hvis den befinder sig i en MVP-fase, er det acceptabelt at drive den med underskud, da MVP-produkter ikke er beregnet til at tjene penge til dig. I stedet er deres formål at få feedback fra dine kunder og validere din startupidé.
Eksempel nr. 4: Buffers landingsside før udviklingen
Ligesom vi produktchefer ser Jira eller Monday.com som vigtige elementer i vores værktøjsstak, betragter sociale mediechefer Buffer som et uundværligt værktøj i deres dagligdag.
Men før Buffer blev en fuldt udviklet platform til administration af sociale netværk, startede tjenesten som en app med én enkelt funktion.
Den pågældende funktion var muligheden for, at brugerne kunne planlægge flere opslag på Twitter. Selvom der allerede fandtes Twitter-klienter med denne funktion, ønskede Joel Gascoigne, Buffers medstifter og administrerende direktør, at gøre planlægningen enkel og behagelig ved at skabe en problemfri og brugervenlig oplevelse omkring planlægningsprocessen.
Han havde især en brugeroplevelse i tankerne, som skulle gøre det muligt for brugerne at planlægge et stort antal tweets samtidigt i stedet for at gøre det for hvert enkelt tweet (sådan som funktionen fungerede i de førnævnte Twitter-klienter).
Joel vidste, at hans idé nemt kunne slå fejl, så han valgte at skabe det mest minimale værdifulde produkt, man kunne forestille sig. Det var ikke en fungerende applikation, men blot en simpel landingsside.
Personer, der besøgte landingssiden, kunne læse om Buffers funktioner og klikke for at tilmelde sig. I stedet for at få adgang til applikationen fik Buffer-brugere imidlertid vist en besked om, at produktet endnu ikke var klar, samt en opfordring til at angive deres e-mailadresse, så Buffer-teamet kunne underrette dem, når produktet var klar til brug.
Antallet af brugere, der angav deres e-mailadresser for at få adgang til Buffer (der var mange af dem), var et signal til Joel om, at det var tiden og pengene værd at udvikle produktet.
Ud over at fastslå interesseniveauet for sit produkt brugte Joel også den e-mailliste, han havde indsamlet, til at kontakte brugerne, tale med dem, lære mere om, hvordan de planlagde at bruge hans planlægningsværktøj, og undersøge de frustrationer, de oplevede med andre applikationer, nærmere.
Erfaringer fra Buffer
Har du nogensinde formået at få en liste over personer, der er interesserede i dit produkt? Den største fordel, du får, er muligheden for at lære. Jeg er enig i, at disse personer også er dine fremtidige tidlige brugere, men de penge, de sandsynligvis kommer til at tjene til dig, vil være minimale. De erfaringer, du til gengæld får, er uvurderlige.
Eksempel nr. 5: Spotifys betaversion
Den streamingtjeneste, der sikkert lige nu afspiller en lo-fi-playliste til arbejde i baggrunden på din bærbare computer, startede tilbage i 2008, da Daniel Ek og Martin Lorentzon besluttede sig for at løse et interessant problem, som fandtes i musikbranchen på det tidspunkt.
Problemet var, at hvis man ville lytte til en sang, skulle man købe den (og det kostede mellem $1-2 tilbage i 2009). Det betød, at man enten skulle bruge hundredvis eller tusindvis af dollars for at få en omfattende playliste med alt det, man elskede, eller begrænse sig til de få sange, man havde råd til at købe.
Daniel og Martin havde en revolutionerende idé, der kunne løse problemet – en streamingtjeneste, der fungerede som en "alt hvad du kan spise"-buffet, hvor man betalte et månedligt abonnementsgebyr og lyttede til så mange sange, man ønskede.
I modsætning til de mange MVP-eksempler ovenfor byggede teamet bag Spotify faktisk en fuldt fungerende softwareprototype, som de distribuerede blandt musikbloggere til en betatest.
Kilde: Prototypr
Spotifys ingeniører skabte ikke blot en version af produktet, der indeholdt kernefunktionaliteten – de brugte faktisk måneder på at forbedre deres infrastruktur og reducere latenstiden, så streaming fra Spotify føltes som at afspille en sang, der var gemt på harddisken på brugernes enheder.
Den betaversion, de distribuerede, blev en enorm succes, og snart begyndte tusindvis af brugere at strømme til for at prøve denne nye revolutionerende måde at lytte til musik på.
Erfaringer fra Spotify
Spotify er et godt eksempel på, at man ikke må glemme V'et i en MVP. Pointen er, at din miniversion af produktet skal være levedygtig og derfor værdifuld på markedet.
Desuden er det helt i orden at bruge måneder på at implementere en enkelt funktion, hvis du mener, at dens fravær vil skade den centrale værdiproposition, som dit produkt har for dine potentielle brugere.
More Articles
Eksempel nr. 6: Airbnbs concierge-test
Vores sidste case om succesfulde MVP'er handler om rejse- og overnatningsplatformen Airbnb.
Deres historie begynder i 2007, da medstifterne Brian Chesky og Joe Gebbia indså, at de ikke havde penge nok til at betale huslejen for deres lejlighed i San Francisco.
For at kunne betale huslejen besluttede de snart at leje madrasser ud i deres lejlighed som sovepladser til deltagerne ved en designkonference, der blev afholdt i byen på det tidspunkt.
De tog derfor billeder af deres lejlighed og uploadede dem til en lille webside, som de havde oprettet til deres ”overnatningstjeneste”. Idéen virkede, og Airbnb-teamet besluttede at skalere den og gøre den til en forretning, hvor deres website fungerede som platformen, hvor folk kunne finde og booke et ophold i en andens hjem.
Ligesom Amazon og Zappos benyttede de Troldmanden fra Oz-MVP-tilgangen, eftersom den første overnatning, de tilbød på deres website, var deres egen lejlighed.
Derefter fortsatte de med at udvikle stadig mere avancerede versioner af deres MVP (som var et funktionelt website med en fungerende bookingmekanisme), som de brugte til at validere deres produktidé generelt og især én bestemt hypotese – nemlig at folk ville være villige til at leje deres lejlighed ud til andre mod betaling.
Lærdomme fra Airbnb
Nogle gange er din MVP ikke en engangsforeteelse, og du ender med at skabe forskellige versioner af din MVP (hvor du tilføjer nye funktioner hver gang), som du bruger til at indsamle kundefeedback og opnå indsigt i forskellige aspekter af dit produkt og din forretningsmodel.
Det handler alt sammen om at teste din forretningsmodel billigt.
Som vi har set i succeshistorierne ovenfor, er MVP ikke bare endnu et koncept fra lærebøger om produktledelse. Det er noget virkeligt, og arbejdet med MVP'er har hjulpet mange berømte digitale produkter med at blive valideret, før deres grundlæggere og produktudviklingsteam begyndte at lægge måneders hårdt arbejde i at bygge dem.
Hvis du vil have flere indsigter som denne, så glem ikke at abonnere på vores nyhedsbrev!
