Teknologi · 3 min lesetid
Hva skal være med i en MVP, og hva kan vente?
En første versjon trenger en sammenhengende oppgave og et tydelig læringsmål. Resten må gjøre seg fortjent til plassen.
Datert
Bestem hva den første versjonen skal bevise
MVP brukes gjerne om en første, avgrenset versjon av et produkt. Jeg synes begrepet blir mest nyttig når vi kobler det til et spørsmål: Hva trenger vi å lære for å vite om vi bør bygge videre?
Det kan være om en bestemt målgruppe klarer å gjennomføre en oppgave, om resultatet er nyttig nok til at de kommer tilbake, eller om noen vil betale. Velg et spørsmål dere kan undersøke med faktiske brukere. «Se om folk liker appen» blir for uklart til å styre prioriteringene.
Bygg én hel arbeidsflyt
La oss bruke en tenkt løsning for å bestille et møterom. Den første arbeidsflyten kan være å finne et ledig rom, reservere det og få en bekreftelse. Da må løsningen håndtere at to personer forsøker å bestille samme tidspunkt. Den må også gi et forståelig svar når rommet ikke lenger er ledig.
Egendefinerte fargetemaer, avansert statistikk og støtte for ti språk kan trolig vente. Poenget er å avgrense bredden uten å bryte den oppgaven brukeren kom for å gjøre. En halvferdig kjerne gir dårlige svar på om ideen har verdi.
Skill mellom det synlige og det nødvendige
Tilgangskontroll, sikker håndtering av data og forståelige feilmeldinger kan være nødvendige allerede i første versjon. Hvor omfattende tiltakene må være, avhenger av bruken og opplysningene som behandles. Det må vurderes konkret.
Noe arbeid kan likevel gjøres manuelt en stund. Kanskje du kan opprette de første kundekontoene selv eller følge opp en bestilling på telefon. Da må arbeidsmengden være håndterbar og løftet til brukeren stemme med det som faktisk leveres.
Lag tre prioriteringer
Jeg ville delt oppgavene i «må fungere for testen», «kan gjøres manuelt» og «venter til vi har lært mer». For hver funksjon bør noen kunne forklare hvilken del av testen den støtter. Da kan gode ideer tas ut av første versjon uten å avvises for alltid.
I møteromeksemplet må tilgjengelighet og reservasjon fungere. Opprettelse av nye rom kan kanskje gjøres manuelt. Rapporter om årsutnyttelse kan vente. Disse konkrete skillene er mer nyttige enn å diskutere om en funksjon er «enkel» eller «avansert».
Avtal hva dere gjør med resultatet
Sett av tid til å observere bruken og snakke med dem som prøver. Se på hvor de stopper, hva de trenger hjelp til og om løsningen faktisk blir brukt igjen. Et registrert klikk forteller ikke alene om oppgaven ble løst.
Avslutt testperioden med en beslutning: fortsette, endre eller stoppe. Hvis dere bygger videre uansett hva dere lærer, var den første versjonen egentlig ikke laget for å undersøke noe. En god MVP gjør neste valg tydeligere.
Skrevet 30. oktober 2026. Datoen øverst er en redaksjonell datering av serien, ikke dokumentasjon på tidligere nettpublisering.
Bli kjent med Lars