Jeg er ganske sikker på at nesten alle dere har hørt om konseptet MVP-er. Men sjansene er også store for at flertallet av dere betrakter MVP-er som noe svært teoretisk som sjelden har blitt brukt i praksis i den virkelige verden. Sannheten er imidlertid at eksempler på minimum levedyktige produkter finnes overalt rundt oss, og mange av de verdensberømte programvareproduktene startet som MVP-er.
Som senior produktleder med erfaring fra utvikling av MVP-er ønsker jeg å dele et par suksesshistorier for å vise deg hvor verdifullt dette konseptet er hvis du er gründer i en liten oppstartsbedrift.
Hva er en MVP?
Et minimum levedyktig produkt er et av nøkkelelementene i Lean Startup, Eric Ries’ metode for å utvikle produkter.
Hovedideen bak Lean og MVP er at oppstartsbedrifter stadig mislykkes, og for å redusere denne risikoen bør du først lage en svært liten versjon av produktet ditt som inneholder kjernefunksjonene, validere at kundene ønsker det, og bekrefte at forretningsideen din fungerer før du begynner å utvikle det endelige produktet.
La oss nå se nærmere på historiene til noen av de mest vellykkede MVP-eksemplene som finnes.
Eksempel nr. 1: Dropbox’ uvanlige format for MVP-utvikling
La oss begynne med en plattform som sannsynligvis mange av oss bruker til å lagre digitale kopier av viktige dokumenter eller som lagringsplass for alt teamet ditt arbeider med i fellesskap.
Skylagring har blitt en integrert del av livene våre, og det er nå en standardløsning både for personlig og profesjonell bruk. Men slik var det ikke i 2007, da Drew Houston bestemte seg for å starte Dropbox.
Selv om Dropbox ikke var den første skylagringstjenesten på markedet på det tidspunktet (du hadde allerede Box og Amazon S3 som tilbød en slik tjeneste), var det den som tilbød en sømløs opplevelse for synkronisering av filene dine med skyen.
Drew kom opp med en interessant løsning for skylagring. I stedet for at du manuelt skulle laste opp og ned filer, opprettet Dropbox en mappe på datamaskinen din som holdt innholdet synkronisert med skyen. Alt du trengte å gjøre, var derfor å legge til eller fjerne filer fra denne mappen; resten var Dropbox’ problem.
Alt dette føles selvfølgelig for oss i dag, men den gangen var det noe fantastisk.
Men å skape en slik sømløs opplevelse betydde at Drews team måtte utvikle skrivebordsapplikasjoner for flere operativsystemer og finne frem til en kompleks filsynkroniseringsmekanisme som skulle håndtere alt for deg i bakgrunnen.
Dette innebar at Drew ikke kunne utvikle en MVP-versjon av Dropbox som en applikasjon, ettersom selv det minste funksjonsomfanget ville kreve en fullt fungerende serverinfrastruktur og ta lang tid å bygge for teamet hans.
Men han ønsket virkelig å få tidlige tilbakemeldinger fra både brukerne og investorene, ettersom dette ville hjelpe ham med å unngå kostbare feil i apputviklingsprosessen og bygge noe markedet ville elske.
Derfor valgte han en svært ukonvensjonell tilnærming. MVP-en hans var en demovideo. Ja, det stemmer, han laget ganske enkelt en forklaringsvideo av produktet sitt der han viste den sømløse opplevelsen ved å synkronisere filer med Dropbox.
Da Drew begynte å vise denne videoen til målgruppen sin, var responsen mye bedre enn han kunne ha forventet. Trafikken til Dropbox-nettstedet økte til flere hundre tusen, og ventelisten for å prøve betaversjonen vokste til 75 000 personer.
Lærdommer fra Dropbox
Den viktigste lærdommen vi sannsynligvis kan trekke fra historien om Drew og teamet hans, er at du i programvareoppstartenes verden må tenke utenfor boksen og ikke la deg begrense av tekniske begrensninger.
Drew visste at det ville være fatalt å gå videre uten å lære om brukernes behov. Derfor måtte han finne en alternativ løsning til en fullt fungerende MVP.
Det spiller egentlig ingen rolle hva MVP-en din er. Det kan være en modell eller et trådskjelett for en mobilapp, eller et falskt nettsted bygget oppå WordPress. Så lenge typen MVP du velger hjelper deg med å få tilbakemeldinger og teste antakelsene dine, er du på rett vei.
Den andre lærdommen for oss er at det ikke finnes noen unnskyldning for å hoppe over læringsfasen og ikke videreutvikle produktet ditt gjennom gjentatte forbedringer.
Have an account? Log In
Eksempel nr. 2: Amazons ikke-eksisterende bakside
Før Amazon ble en gigant innen programvareselskaper, startet selskapet berømt nok som en nettbokhandel.
Det interessante ved Amazons opprinnelseshistorie var at Jeff Bezos’ visjon for Amazon ikke bare handlet om å selge bøker på nettet. Ambisjonene hans var langt større enn å bli verdens største nettbokhandel (noe vi kan se ut fra størrelsen på Amazon i dag).
Grunnen til at han valgte å begynne med bøker, var ganske pragmatisk – bøker var enkle å finne og billige å sende over hele verden.
Det er svært enkelt å opprette en nettbutikk i dag takket være Shopify, WooCommerce og mange andre ferdige verktøy. Men det var i 1994 da Bezos startet Amazon, og han måtte utvikle hele nettbutikken, inkludert både brukergrensesnittet og bakenden, fra bunnen av.
Jeff hadde ikke mulighet til å investere i å bygge en hel nettbutikk. Derfor tok han i bruk «Trollmannen fra Oz»-tilnærmingen for å drive oppstartsbedrifter. Han hadde riktignok brukergrensesnittet klart – en nettbutikk der folk kunne bla gjennom bøker, legge dem i handlekurven og legge inn en bestilling.
Men det fantes ingen bakende og ingen automatisk behandling av disse bestillingene. Når noen kjøpte en bok på Amazon, dro Jeff personlig til en fysisk bokhandel for å kjøpe den og sendte den til kunden via det offentlige postvesenet.
I tillegg til at denne tilnærmingen lot Jeff starte en virksomhet uten en stor investering på forhånd, gjorde den det også mulig for ham å få tidlige tilbakemeldinger fra brukerne, både på nettstedet han drev og på hele prosessen med å selge varer på nettet.
Jeff tok hele tiden brukernes tilbakemeldinger inn i tjenesten sin, og i 1999 hadde Amazon utviklet seg til noe som er mer kjent for oss.
I tillegg til å omsette brukernes tilbakemeldinger til konkrete forbedringer begynte Jeff også å følge sine større ambisjoner ved å legge til nye produktkategorier på nettstedet. I 1999 solgte Amazon allerede musikk, videoer, elektronikk, leker og andre typer produkter.
Lærdommer fra Amazon
Jeff er en av de gammeldagse gründerne som startet selskapene sine «i morens garasje». Selv om han brukte «Trollmannen fra Oz»-tilnærmingen fordi han ganske enkelt ikke hadde råd til et fullt utviklet nettsted, fulgte han etter hvert beste praksis ved å undersøke om forretningsmodellen fungerte før han bygde produktet.
Eksempel nr. 3: Zappos' kontantnegative MVP
La oss fortsette med pionerene innen netthandel og snakke om Zappos, en enorm nettbutikk som spesialiserer seg på klær og bekledning, tilbyr titusenvis av varer og har generert et par milliarder i inntekter.
Historien om Zappos begynner i 1999, da grunnleggeren Nick Swinmurn brukte mye tid på å lete etter et bestemt par sko han ønsket seg på kjøpesenteret i nærheten, uten å finne dem. Han innså raskt problemet med fysiske butikker – de har alltid et begrenset utvalg skomodeller tilgjengelig, fordi det å opprettholde et stort utvalg ville øke lagrings- og lagerkostnadene for hver enkelt butikk.
Skomerker foretrakk derfor vanligvis å vise frem og selge bare de mest populære og ordinære modellene i de fleste mellomstore og små butikkene de drev, og holde de mer nisjepregede modellene tilgjengelige bare i de største butikkene.
Det betydde at hvis du ønsket deg noe som ikke var vanlig, ville du ikke kunne finne det på ditt lokale kjøpesenter, men måtte reise langt til den nærmeste butikken som førte favorittmerket ditt.
En nettbutikk kan derimot vise frem et ubegrenset (i teorien) antall varer til brukere som bor hvor som helst, uansett om det er i en liten by med et lite kjøpesenter eller i et enormt storbyområde med megabutikker.
Akkurat som Jeff med Amazon hadde ikke Nick økonomisk kapasitet til å bygge en hel nettbutikk fra bunnen av. Selv om han i teorien kunne ha bedt investorer om disse pengene, ønsket han egentlig ikke å ta risikoen for at nettbutikken skulle mislykkes og at investorenes penger til slutt skulle gå tapt.
Derfor fulgte han samme vei som Amazon og startet et nettsted etter «Trollmannen fra Oz»-modellen. Nick dro til de lokale kjøpesentrene, fotograferte alle skoene som var tilgjengelige der, og la ut bildene som varer til salgs på MVP-nettstedet sitt.
Når en bruker la inn en bestilling på Zappos.com, dro Nick til butikken som solgte den aktuelle modellen på det lokale kjøpesenteret, kjøpte den og sendte den til kunden med posten. Som du kanskje kan forvente, tjente ikke Nick penger på «Trollmannen fra Oz»-måten han drev butikken på. Faktisk tapte han penger.
Det Nick brydde seg mest om på dette tidspunktet, var imidlertid ikke bunnlinjen. Han ønsket å få to ting – tilbakemeldinger fra kundene og validering av forretningsmodellen.
Som vi kan se av salgsinntektene og antallet tilgjengelige produkter på Zappos.com, fungerte Nicks forretningsmodell, og den førte til enorm suksess.
Lærdommer fra Zappos
Zappos og måten Nick drev concierge-MVP-versjonen på, lærer oss noe svært viktig om oppstartsbedrifter – det er greit å tape penger.
La meg presisere. Det er ikke greit at en virksomhet taper penger generelt. Men hvis den er i en MVP-fase, er det akseptabelt å drive med underskudd, ettersom MVP-produkter ikke er ment å tjene penger for deg. Formålet deres er i stedet å få tilbakemeldinger fra kundene dine og validere oppstartsidéen din.
Eksempel #4: Buffers landingsside før utvikling
Akkurat som vi produktledere ser på Jira eller Monday.com som viktige deler av verktøystakken vår, anser ledere for sosiale medier Buffer som avgjørende i det daglige arbeidet.
Men før Buffer ble en fullverdig plattform for administrasjon av sosiale medier, startet tjenesten som en app med én enkelt funksjon.
Funksjonen det var snakk om, var muligheten for brukere til å planlegge flere innlegg på Twitter. Selv om det allerede fantes Twitter-klienter med denne funksjonen, ønsket Joel Gascoigne, medgrunnlegger og administrerende direktør i Buffer, å gjøre planleggingen mer behagelig ved å skape en sømløs og brukervennlig opplevelse rundt planleggingsprosessen.
Han hadde særlig en brukeropplevelse i tankene som skulle la brukerne planlegge et stort antall tweets samtidig, i stedet for å gjøre det for hver tweet separat (slik funksjonen fungerte i de nevnte Twitter-klientene).
Joel visste at ideen hans lett kunne mislykkes, så han valgte å lage det minst mulige verdifulle produktet man kunne forestille seg. Det var ikke en fungerende applikasjon, men en enkel landingsside.
Personer som besøkte landingssiden, kunne lese om funksjonene i Buffer og klikke for å registrere seg. I stedet for å få tilgang til applikasjonen, fikk Buffer-brukerne imidlertid se en melding om at produktet ennå ikke var klart, samt en oppfordring om å legge igjen e-postadressen sin slik at Buffer-teamet kunne varsle dem når produktet var klart til bruk.
Antallet brukere som la igjen e-postadressene sine for å få tilgang til Buffer (det var mange av dem), fungerte som et signal til Joel om at det var verdt å bruke tid og penger på å bygge dette produktet.
I tillegg til å fastslå interessen for produktet sitt brukte Joel også e-postlisten han hadde samlet inn til å ta kontakt med brukerne, snakke med dem, lære mer om hvordan de planla å bruke planleggingsverktøyet hans og undersøke nærmere frustrasjonene de opplevde med andre applikasjoner.
Lærdommer fra Buffer
Har du noen gang klart å få en liste over personer som er interessert i produktet ditt? Den største fordelen du får, er muligheten til å lære. Jeg er enig i at disse personene også er dine fremtidige tidlige brukere, men pengene de sannsynligvis kommer til å tjene til deg, vil være svært små. Lærdommene du derimot får, er uvurderlige.
Eksempel #5: Spotifys betaversjon
Strømmetjenesten som sannsynligvis spiller av en lo-fi-arbeidsliste i bakgrunnen på den bærbare datamaskinen din akkurat nå, startet i 2008, da Daniel Ek og Martin Lorentzon bestemte seg for å løse et interessant problem som eksisterte i musikkbransjen på den tiden.
Problemet var at hvis du ville lytte til en sang, måtte du kjøpe den (og det kostet mellom 1 og 2 dollar i 2009). Det betydde at du enten måtte bruke hundrevis eller tusenvis av dollar på å få en omfattende spilleliste som inneholdt alt du likte, eller begrense deg til de få sangene du hadde råd til å kjøpe.
Daniel og Martin hadde en revolusjonerende idé som skulle løse dette problemet – en strømmetjeneste som fungerte som en «alt du kan spise»-buffé, der du betalte en månedlig abonnementsavgift og kunne lytte til så mange sanger du ville.
I motsetning til mange av MVP-eksemplene tidligere bygget teamet bak Spotify faktisk en fullt fungerende programvareprototype som de distribuerte blant musikkbloggere for en betatest.
Kilde: Prototypr
Spotify-ingeniørene laget ikke bare en versjon av produktet som inneholdt kjernefunksjonaliteten deres – de brukte faktisk flere måneder på å forbedre infrastrukturen og redusere forsinkelsen, slik at strømming fra Spotify skulle føles som å spille av en sang som var lagret på harddisken til brukernes enheter.
Betaversjonen de distribuerte, ble en enorm suksess, og snart begynte tusenvis av brukere å strømme til for å prøve denne nye, revolusjonerende måten å lytte til musikk på.
Lærdommer fra Spotify
Spotify er et godt eksempel på at man ikke må glemme V-en i en MVP. Poenget er at miniversjonen av produktet ditt bør være levedyktig, og derfor verdifull, i markedet.
Det er dessuten helt greit å bruke flere måneder på å implementere én enkelt funksjon hvis du tror at fraværet av den vil svekke kjerneverdiforslaget produktet ditt har for potensielle brukere.
More Articles
Eksempel nr. 6: Airbnbs testing med concierge-tjenester
Vår siste casestudie om vellykkede MVP-er handler om reise- og overnattingsplattformen Airbnb.
Historien deres begynner i 2007, da medgrunnleggerne Brian Chesky og Joe Gebbia innså at de ikke hadde nok penger til å betale husleien for leiligheten sin i San Francisco.
For å dekke husleien bestemte de seg snart for å leie ut madrasser i leiligheten som soveplasser for deltakerne på en designkonferanse som fant sted i byen på det tidspunktet.
De tok derfor bilder av leiligheten sin og lastet dem opp på en liten nettside de hadde laget for «overnattingstjenesten» sin. Ideen fungerte, og Airbnb-teamet bestemte seg for å skalere og gjøre en forretning ut av den, med nettstedet som plattformen der folk kunne finne og bestille et opphold i andres hjem.
Akkurat som Amazon og Zappos benyttet de seg av Trollmannen fra Oz-MVP-tilnærmingen, ettersom den første overnattingen de tilbød på nettstedet, var deres egen leilighet.
Etter det fortsatte de å bygge stadig mer avanserte versjoner av MVP-en sin (som var et funksjonelt nettsted med en fungerende bestillingsmekanisme), som de brukte til å validere produktideen generelt, og særlig én hypotese: at folk ville være villige til å leie ut leiligheten sin til andre mot betaling.
Lærdommer fra Airbnb
Noen ganger er MVP-en din ikke et engangstiltak, og du ender opp med å lage ulike versjoner av MVP-en din (der du legger til nye funksjoner hver gang), som du bruker til å samle inn tilbakemeldinger fra kunder og lære mer om ulike aspekter ved produktet og forretningsmodellen.
Det handler om å teste forretningsmodellen din på en billig måte.
Som suksesshistoriene ovenfor viser, er MVP ikke bare et konsept fra lærebøker om produktledelse. Det er noe virkelig, og utviklingen av MVP-er har hjulpet mange kjente digitale produkter med å bli validert før grunnleggerne og produktutviklingsteamet begynte å legge måneder med hardt arbeid i å bygge dem.
Hvis du vil ha flere innsikter som dette, må du ikke glemme å abonnere på nyhetsbrevet vårt!
