Hva er en MVP?

Kjapt ut i markedet

Når du skal utvikle et produkt har du som regel en klar visjon om hva produktet skal bli i fremtiden, ofte med store, hårete mål for funksjonalitet og opplevelse. Men hvor skal du begynne? Hva skal lages først? For å lykkes med produktutvikling er et MVP-tankesett essensielt. Det betyr at du ikke lager en enkeltstående del av løsningen ferdig og deretter går videre med å lage neste del, men at du heller tenker:

«Hva er det minste jeg kan bygge for å gi verdi til kunden min?»

På den måten vil den første versjonen av løsningen være funksjonell og kanskje du til og med kan begynne å få inn kunder på den. Det er først når du får inn ekte kunder i løsningen at du ser om folk er villige til å kjøpe produktet ditt.

Med ekte kunder får du konkrete tilbakemeldinger på hva du må prioritere fremover, og hvordan produktet ditt fungerer i praksis.

Ikke det samme som en prototype

Det er lett å forveksle konseptet MVP med en prototype. Definisjonen på en prototype er «en foreløpig utgave av et produkt». Prototypen brukes for å vise hva produktet er og teste hvordan det fungerer, men det er som regel ikke en løsning som tåler å produksjonssettes og testes ut i markedet. Ofte lager man en prototype som et proof of concept, altså for å vise hva ideen går ut på og å få tilbakemeldinger fra en mindre testgruppe eller for å få finansiering til å starte utviklingen av MVP-en.

Jeg pleier å si at prototyper er interaktive skisser. Ofte må disse kastes når man begynner å bygge løsningen på ekte, i motsetning til en MVP som er første versjonen av løsningen som bygges ut over tid.

Utviklingsprosessen for et produkt

Henrik Kniberg laget illustrasjonen under for noen år siden, som forklarer to ulike utviklingsprosesser for samme produkt. Det øverste løpet viser tradisjonelt utviklingsløp, mens det nederste viser utviklingen hvis du tar i bruk MVP-tankesettet.

Tenk deg at du skal lage en bil. Istedenfor å dele opp bilen i mange små deler og lage del for del, så tenker du «Hva er det minste jeg kan bygge for å gi verdi til kunden min?». Hva er det med en bil som gir verdi? Jo, å kunne frakte noe eller noen fra et sted til et annet. Hva er det minste du kan bygge for å få til det? Et rullebrett kanskje? Kunden er nok ikke megafornøyd med det, det er jo ikke så lett å skate. Men når du setter på et styre og det blir en sparkesykkel er det flere som kan ta den i bruk. Og når du har laget en hel sykkel kan enda flere bruke den, du kan til og med frakte to mennesker på den! Sånn jobber du, steg for steg helt til du har levert bilen. Gradvis gir produktet ditt mer og mer verdi til kunden din. Det er MVP-tankesettet.

Den tradisjonelle måten å gjøre det på der du bygger bilen del for del, vil sannsynligvis ikke gi verdi for brukeren før hele bilen er bygget. Du vil heller ikke få noe tilbakemelding fra kundene før produktet er helt ferdig, og da kan det allerede være for seint for å plukke opp faresignaler og muligheter du kunne innhentet allerede med skateboardet.

Når du jobber med produktutvikling tar det jo som regel mange år før produktet er ferdig utviklet. Kanskje blir det aldri fullverdig heller. Planene utvikler seg ettersom tiden går. Ved å utvikle basert på MVP-tankesettet kan du bygge produktet i tråd med det som gir verdi for kunden din. Steg for steg øker du verdien produktet har for brukerne og du sørger for å bygge akkurat det som trengs for å holde deg relevant i markedet.

Et eksempel på MVP

Jeg har den siste tiden jobbet med å utvikle et produkt som vi kaller Designmaskinen. Det er et superenkelt designverktøy som skal hjelpe alle ansatte i bedrifter med å lage markedsmateriell i tråd med retningslinjene for selskapets visuelle profil.

Da vi startet utviklingen av dette verktøyet måtte vi tenke nøye igjennom to ting:

1. Hva er det minste vi kan bygge for å gi verdi til kundene våre?
2. Hva er det minste vi kan bygge for å kunne selge produktet til kunder?

Det vi trengte var en minimumsløsning der ansatte i en bedrift kunne lage og eksportere dokumenter basert på eksisterende maler. Malene var laget av designeren i bedriften og derfor i tråd med retningslinjene for den grafiske profilen deres. Brukeren får lov til å skrive inn tekst med en predefinert font, velge mellom predefinerte fargekombinasjoner og velge bilder fra et galleri. Dokumentet må være helt i tråd med retningslinjene for merkevaren for å kunne gi verdien verktøyet skal bidra med.

La oss snu på det: Hva var det vi ikke trengte å lage for å kunne selge dette produktet?

• Egen nettside og domene.

• Selvbetjent onboarding til løsningen.

• Administrasjonsgrensesnitt der designer for merkevaren selv kan lage maler.

• Ferdigstilt visuell identitet for produktet.

• Formater kundene våre ikke har spurt oss om å lage ennå.

I tillegg hadde vi masse funksjonalitet i verktøyet som ble satt på vent til kunder etterspør det, eller har merkevarer som krever det.

Ved å ta disse valgene er det mye vi må gjøre manuelt hver gang vi får en ny kunde, men på denne måten kan vi faktisk selge produktet selv om vi er tidlig i produktutviklingsprosessen. Vi har en sparkesykkel nå, og er på vei til å lage en bil. Det vil si at vi gir den verdien til kunden som produktet er til for å gjøre, men ikke på langt nær så mye som det kommer til å bli på sikt, når resten av produktet er på plass.

Det føles jo selvfølgelig litt ubehagelig å skulle invitere inn kunder på et produkt vi selv ikke føler er like bra som visjonen vår for verktøyet, men så lenge kundene opplever høy nok verdi og vi møter de essensielle behovene deres for verktøyet, gjør det ingenting om det legges til funksjonalitet etterhvert i kundeforholdet. Det vil jo bare oppleves som bra for kunden at produktet blir bedre og bedre ettersom tiden går.

MVP-tankegang hos NAV

Et annet prosjekt som har brukt MVP-tankegangen aktivt, var da kollegaen min, Daniel, var med å digitalisere søknadsskjema for barnetrygd for NAV. Dette var ingen enkel jobb, da selve skjemaet er komplisert og inneholdt mange avhengigheter. De ønsket også å hente inn mer detaljert og riktig data, sammenlignet med et enkelt papirskjema. Etter å ha digitalisert den første og enkleste delen av søknaden, skulle de utvide det for folk med knytning til andre EØS-land.

Selve EØS-skjemaet var komplisert, og de visste det ville ta lang tid å bygge inn all logikken det var behov for. For å skape verdi for brukerne så raskt som mulig, og samtidig gjøre det enklere for saksbehandlerne i NAV, startet de med å bygge inn logikken som skulle plukke opp om brukeren faktisk hadde en tilknytning til et annet EØS-land. Denne informasjonen brukte de til å informere dem om at de måtte laste ned, fylle ut og legge ved det fysiske skjemaet for EØS-barnetrygd dersom det var relevant for dem.

Dette ga både brukerne og NAV to umiddelbare gevinster: for det første førte det til at flere brukere ble klar over at de faktisk måtte fylle ut et tilleggsskjema, noe en mye større andel av dem gjorde. I tillegg fikk saksbehandlerne i NAV inn flere komplette søknader (altså søknader som hadde all nødvendig dokumentasjon vedlagt). Alt dette selv om den ene delen av skjemaet fortsatt var på papir!

MVP har sin opprinnelse i Lean Startup

Avslutningsvis vil jeg nevne at MVP-begrepet dukket opprinnelig opp i Lean Startup-metoden. (Anbefaling "What is the minimum viable product?" av Eric Ries). Metoden setter læring i sentrum når du utvikler nye produkter og tjenester. Det viktigste er å få kunders tilbakemelding på verdien du skaper, så tidlig som mulig, som senker risikoen.

For hvis du ikke lager det kunden faktisk trenger, risikerer du at produktet ditt er irrelevant og utviklingen du driver med er bortkastet. Ved å bygge en MVP og prøve den ut på ekte kunder får du testet tidlig om du treffer markedet og brukernes behov.