Du har en idé til en app, og lista over hva den kan gjøre blir lengre for hver uke. Det er godt at du ser mulighetene. Det blir et problem hvis alt på lista skal med i første versjon.
En MVP er måten å unngå det på. Denne artikkelen handler om de konkrete valgene: hva som hører hjemme i første versjon, hva som kan vente, og hvordan du tester om ideen holder før du bruker mye penger på å bygge den.
Hva betyr MVP i apputvikling?
MVP står for minimum viable product, eller minste levedyktige produkt. I apputvikling er det den minste versjonen av appen som lar en ekte bruker løse et ekte problem fra start til slutt.
Tre deler av den setningen er viktige. En ekte bruker er ikke deg selv eller en kollega som vil være hyggelig. Et ekte problem er noe folk bruker tid eller penger på i dag. Fra start til slutt betyr at brukeren aldri trykker på en knapp og får beskjed om at funksjonen kommer snart.
En MVP er altså ikke en dårlig app, men en smal app. Det du kutter er bredde, ikke kvalitet. Det brukeren faktisk møter, skal virke og se ordentlig ut.
Målet er å lære. Du bygger den for å få svar på spørsmål du ikke kan tenke deg fram til: Vil folk bruke dette? Kommer de tilbake? Vil de betale?
Når bør du bygge MVP i stedet for full app?
Kort sagt: nesten alltid når du lager noe nytt for et marked du ikke kjenner godt.
En MVP passer godt når
- du er usikker på om brukerne vil ha løsningen, eller hvordan de kommer til å bruke den
- budsjettet er begrenset, og du trenger resultater for å få mer penger, internt eller fra investorer
- tiden til markedet betyr noe, fordi andre kan komme før deg
- du har flere mulige hovedfunksjoner og ikke vet hvilken som er viktigst
En mer komplett første versjon kan være riktig når appen skal erstatte et system som er i daglig drift, og brukerne ikke klarer seg med halve behovet dekket. Det samme gjelder når regelverk krever bestemt funksjonalitet fra første dag, som i deler av helse og finans. Og når du digitaliserer en prosess dere allerede kjenner godt, med kjente brukere, ligger usikkerheten mer i gjennomføringen enn i behovet.
Selv da lønner det seg å bygge og teste i biter, selv om det som til slutt settes i drift, er mer komplett.
Funksjoner som bør være med i første versjon
Her er fem prioriteringsregler vi bruker når vi avgrenser en første versjon sammen med kunder.
1. Én bruker, én oppgave, hele veien
Velg den viktigste brukeren og den viktigste oppgaven. Beskriv reisen: hvor starter brukeren, hva gjør hen underveis, og når er hen ferdig? Alt som trengs for at den reisen skal fungere, er med.
Ta en bookingapp for en frisørkjede. Den viktigste reisen er at kunden finner en ledig time, bestiller og får en bekreftelse. Frisørenes side kan i starten være en enkel oversikt over dagens timer. Statistikk, lojalitetsprogram og gavekort kan vente.
2. Det som gjør appen trygg å bruke
Innlogging hvis dataene skal følge brukeren mellom enheter, riktige tilganger, at data ikke går tapt, og at personopplysninger håndteres i tråd med GDPR. Dette kuttes aldri, uansett budsjett. Det er vanskelig og dyrt å bygge inn i etterkant, og en sikkerhetsfeil i første versjon kan stoppe hele prosjektet.
3. Det du trenger for å måle
Bestem hvilke få hendelser som forteller om ideen holder: hvor mange som starter oppgaven, hvor mange som fullfører, og hvor mange som kommer tilbake neste uke. Det må måles fra første dag. Uten tall har du bare en liten app, ikke en MVP.
4. En enkel vei for tilbakemeldinger
De første brukerne er de mest verdifulle du noen gang får, fordi de prøver noe uferdig og fortsatt bryr seg. Gjør det lett for dem å si fra, med en lenke til e-post eller et kort skjema i appen.
5. Grunnen til å bytte
Brukeren løser problemet på en eller annen måte i dag, kanskje med et regneark, en Messenger-gruppe eller papir. Appen må være merkbart bedre på akkurat det som gjør dagens løsning tungvint. Den ene grunnen til å bytte må være på plass og være god, ellers tester du ikke ideen din, bare om folk orker å bytte vane.
Et nyttig kontrollspørsmål når du står fast: hvis vi fjerner denne funksjonen, mister vi da svaret på det vi prøver å finne ut? Er svaret nei, kan den vente.
Funksjoner du ofte bør vente med
Erfaringsmessig er det de samme tingene som kan utsettes uten at de første brukerne merker det.
- Administrasjonspanel. Med noen titalls brukere kan dere håndtere ting manuelt, direkte i databasen eller i et enkelt verktøy. Et eget panel er i praksis en løsning til, og en av de største kostnadene i mange prosjekter.
- Flere brukerroller. Start med det skillet du faktisk trenger, ofte bare bruker og administrator.
- Sosiale funksjoner. Kommentarer, følgere, deling og chat er krevende å bygge og moderere, og gir lite før det finnes mange brukere.
- Integrasjoner. En manuell eksport eller et regneark én gang i uka er ofte nok til å finne ut om integrasjonen er verdt å bygge.
- Avanserte innstillinger og personalisering. Gode standardvalg slår mange valg i starten.
- Flere språk, nettbrettversjon og frakoblet bruk. Med mindre målgruppen krever det, for eksempel at brukerne jobber der dekningen er dårlig.
- Betaling i appen. For fysiske varer og tjenester kan du ofte ta betalt utenfor appen i starten, med faktura eller betalingslenke. Selger du digitalt innhold, har Apple og Google egne regler som må med fra start.
En god tommelfingerregel er å gjøre ting manuelt til det begynner å gjøre vondt. Når noen i teamet bruker en time hver dag på noe appen kunne gjort, vet du at det er verdt å bygge, og du vet nøyaktig hvordan det bør fungere.
Prototype, MVP eller full app: hva passer når?
Det er tre ulike steg som svarer på ulike spørsmål. Mange hopper over det første og betaler for det i det andre.
Klikkbar prototype
En prototype er et design som oppfører seg som en app når du trykker på det, men uten kode og data bak. Den svarer på om folk forstår hva de skal gjøre, og om flyten gir mening. Den er typisk klar på to til fire uker og koster en brøkdel av en app. Her er endringer billige: å flytte en knapp tar minutter, ikke dager. Les mer om klikkbar prototype og UI/UX-design.
MVP
En MVP er en ekte app i hendene på ekte brukere. Den svarer på om folk faktisk bruker løsningen, kommer tilbake og er villige til å betale. En MVP uten innlogging, der data lagres på telefonen, ligger typisk på 50 000 til 100 000 kroner og tre til fem uker. Med innlogging og backend er nivået 80 000 til 300 000 kroner og seks til fjorten uker, avhengig av hvor mye som skal med.
Full app
En full app er bygget for skala, med administrasjon, flere roller, integrasjoner og alt det du med vilje utsatte. Den svarer på hvordan du vokser, ikke om ideen holder. Kommer du hit uten å ha gått gjennom de to første stegene, har du tatt mye risiko på én gang.
Slik tester du markedet før du bygger for mye
Det finnes billigere måter å lære på enn å bygge. Her er de i stigende rekkefølge etter hva de koster.
Samtaler. Snakk med fem til ti personer i målgruppen om hvordan de løser problemet i dag. Ikke spør om de ville brukt appen din, for det sier alle ja til. Spør hva de gjorde sist gang problemet oppsto, og hva det kostet dem. Er svaret at de ikke gjorde noe, er problemet kanskje ikke stort nok.
Landingsside. Beskriv appen som om den fantes, og legg til påmelding til en venteliste. Kjør en liten annonsekampanje mot målgruppen og se hvor mange som melder seg på. Det koster noen tusenlapper og kan gi et ærligere svar enn mange møter.
Brukertest av prototypen. Gi fem personer fra målgruppen en oppgave og si ingenting mens de prøver. Etter fem tester har du som regel sett de største problemene.
Manuell tjeneste. Lever tjenesten for hånd bak et enkelt skjema før du automatiserer noe. Skal appen sette opp treningsprogram, kan du lage programmene selv og sende dem på e-post de første ukene. Du lærer mye om hva brukerne vil ha, og har ikke kodet noe ennå.
Forhåndssalg. Lager du noe for bedrifter, spør om de vil signere en intensjonsavtale eller betale for tidlig tilgang. Det er det sterkeste signalet du kan få før appen finnes.
Uansett metode: bestem på forhånd hva som teller som et ja. Hvor mange påmeldinger, hvor mange som fullfører oppgaven, hvor mange som sier ja til å betale. Ellers er det fristende å tolke alle resultater som oppmuntrende.
Vanlige feil i MVP-prosjekter
For mye i første versjon. «Bare én ting til» er den vanligste årsaken til at en MVP tar et halvt år. Hver funksjon du legger til, gjør det også vanskeligere å se hva som faktisk fungerer.
For lite i første versjon. Det motsatte skjer også. Løser appen bare halve problemet, sier brukerne nei, og du tror ideen er dårlig når det var avgrensningen som var feil.
Testing på venner og familie. De vil deg vel, og det er nettopp problemet. Finn brukere som ikke kjenner deg og som har problemet i dag.
Ingen mål før lansering. Uten tall bestemt på forhånd blir diskusjonen om veien videre en meningsutveksling.
Hele budsjettet på versjon én. Hold av minst en fjerdedel til månedene etter lansering. Det er da du vet nok til å bruke pengene riktig.
Svak grunnmur. En MVP skal være smal, men koden under bør tåle å bygges videre på. Det gjelder særlig nå som mye kan lages raskt med AI-verktøy. Det er lett å få noe som ser ferdig ut, men som må skrives om når de første tusen brukerne kommer.
Venting på perfekt. Den første versjonen vil alltid føles litt flau for dem som laget den. Er den ikke det, har du sannsynligvis ventet for lenge.
Neste steg: fra MVP til lanserbar app
En MVP trenger ikke å ligge i App Store fra dag én. Mange starter med en lukket test gjennom TestFlight for iPhone og intern testing i Google Play, med en liten gruppe utvalgte brukere. Det gir rom til å rette opp det åpenbare før appen blir offentlig.
Før en offentlig lansering må noen ting være på plass: personvernerklæring, skjermbilder og beskrivelse til butikkene, og at appen oppfyller kravene til Apple og Google. Apples gjennomgang tar som regel noen dager, og første innsending blir ikke alltid godkjent. Regn med det i planen.
Etter lansering handler det om å se hva folk gjør, prioritere det som gjelder flest, og levere små forbedringer ofte. Vi har skrevet mer om akkurat den fasen i fra MVP til fullverdig app.
Vil du vite hva en første versjon av din idé kan koste, kan du beregne pris på appen med en gang. Og vil du diskutere hva som bør med og hva som kan vente, kan du se hvordan vi jobber med apputvikling for iOS og Android, eller ta kontakt.