MVP står for minimum viable product. Det er den minste versjonen av en app som lar en ekte bruker løse et ekte problem fra start til slutt. Ikke en halvferdig app, men en smal en.
Hvordan du avgrenser og tester den første versjonen, har vi skrevet om i MVP for app: hva bør du bygge først?. Denne artikkelen handler om det som skjer etterpå: når appen er i drift, folk bruker den, og du skal bestemme hva som kommer neste gang.
Det er her prosjekter enten tar av eller stopper opp. Forskjellen handler sjelden om teknologi.
Hvorfor det lønner seg å starte smalt
Den vanligste måten å tape penger på et appprosjekt er å bygge alt før noen har brukt noe.
Vi har sett prosjekter der det er brukt et år og store summer på en app med førti funksjoner, for så å oppdage at brukerne benytter seks av dem regelmessig. De seks kunne vært bygget på noen uker. Ingen enkeltbeslutning var feil. Feilen var å bestemme alt før man visste noe.
En MVP snur på rekkefølgen. Dere bygger det dere er sikrest på, setter det i drift, og lar de neste beslutningene bygge på hva folk faktisk gjør framfor hva dere trodde de ville gjøre. Resten av denne artikkelen handler om hvordan dere tar de beslutningene.
Ha budsjett igjen når første versjon er ute
Hold av minst en fjerdedel av budsjettet til månedene etter lansering. Det er da pengene gir mest, fordi dere endelig vet hva brukerne trenger. Den vanligste feilen er å bruke opp alt på versjon én og stå uten midler akkurat når lærdommen kommer.
Vil du se hva en første versjon og videreutviklingen kan koste, kan du sette sammen et anslag i priskalkulatoren, eller lese mer i hva koster det å lage en app.
Bestem på forhånd hva som skal måles
Velg ett tall før lansering. Hvor mange som fullfører oppgaven. Hvor lang tid den tar sammenlignet med i dag. Hvor mange som kommer tilbake neste uke. Ett tall dere følger med på er mer verdt enn en rapport ingen åpner.
Det gir den interne diskusjonen om videreutvikling et grunnlag, framfor at den blir en meningsutveksling. Og det er tallet som forteller om dere skal skalere, endre retning eller stoppe.
Se på hva folk gjør, ikke bare hva de sier
Brukere er dårlige til å fortelle hva de trenger, og gode til å vise det.
Det mest verdifulle signalet er omveiene. Hvis noen eksporterer data til et regneark hver fredag, tar skjermbilder for å dele noe, eller bruker kommentarfeltet til å notere noe det ikke er ment for, har dere funnet neste funksjon. De har allerede bestemt at behovet er stort nok til å gjøre ekstra arbeid. Slike omveier dukker bare opp når noe er i faktisk bruk.
Det nest mest verdifulle er hvor de faller fra. Hvis mange starter en oppgave og ikke fullfører, ligger det et problem der, og det er som regel ikke der dere ville gjettet.
Ønskelister fra brukere er nyttige, men behandle dem som symptomer framfor bestillinger. Når noen ber om en bestemt knapp, er det verdt å spørre hva de prøver å oppnå. Ofte finnes det en enklere løsning på det egentlige problemet.
Prioriter etter hvor mange det gjelder
Den vanligste fellen etter lansering er å bygge det den mest høylytte brukeren ber om. Den nest vanligste er å bygge videre fra lista som ble skrevet i planleggingsfasen, før dere visste noe.
En nyttigere rekkefølge er å se på hvor mange det gjelder, hvor ofte det skjer, og hvor mye arbeid som spares hver gang. En liten forbedring i noe alle gjør daglig, slår en stor forbedring i noe få gjør sjelden. Vær også ærlige om hva som bare er ryddighet. Ting som irriterer dere internt, men som brukerne ikke merker, kan vente.
Det som må bygges om når volumet vokser
En MVP er med vilje bygget for å komme raskt i drift, og noen av valgene der holder ikke i det lange løp. Det er ikke en feil, det er en avveining dere gjorde bevisst.
Det første som melder seg er som regel administrasjon. Å håndtere brukere og innhold manuelt fungerer med tjue brukere og blir uholdbart med to hundre. Da er det tid for det administrasjonsgrensesnittet dere utsatte.
Deretter kommer ytelse. Spørringer mot databasen som var raske med tusen rader, blir trege med en million. Dette er normalt og håndterbart, men det krever at noen ser på det før brukerne merker det.
Og til slutt tilganger og roller. Når flere typer brukere kommer til, holder det sjelden med skillet mellom vanlig bruker og administrator. Dette er verdt å ta ordentlig når det først skal gjøres, fordi feil her er blant de mest alvorlige som finnes i forretningsapper.
Hold tempoet oppe med små leveranser
Fristelsen etter en vellykket lansering er å planlegge en stor versjon to. Det er som regel feil.
Fortsett i samme rytme: små endringer, ofte, med brukere som ser resultatet. En app som forbedres litt annenhver uke, oppleves som levende. En som står stille i et halvår og så endrer seg mye på én gang, skaper usikkerhet hos dem som har vent seg til den. Det gjør også hver endring tryggere, fordi det er lett å se hva som forårsaket et problem når endringene er små.
Husk vedlikeholdet som går uansett
Uavhengig av ny funksjonalitet må appen holdes i live. Apple og Google gir ut nye versjoner av operativsystemene hvert år og krever jevnlig at apper bygges mot nyere versjoner for å bli værende i butikkene.
Regn 10 til 20 prosent av utviklingskostnaden årlig til dette, i tillegg til det dere bruker på videreutvikling. Vi anbefaler å oppdatere jevnlig i små steg framfor å ta et stort hopp annethvert år.
Når dere bør stoppe opp
Ikke alle MVP-er skal skaleres. Noen ganger viser tallene at kjernen ikke fungerer, og da er det riktige å stoppe eller endre retning.
Det er ikke et nederlag. Det er nettopp det dere kjøpte for pengene: å finne ut av det etter tre måneder framfor etter to år. Prosjekter som ikke tør å ta den beslutningen, bruker gjerne like mye igjen på å bevise at den første antakelsen var riktig.
Kort sagt
Bygg det minste som løser et ekte problem helt. Sett det i drift. Mål om det virker. La det dere lærer bestemme hva som kommer neste gang, og fortsett i små steg når det gjør det.
Vil du diskutere hva en fornuftig første versjon kunne vært for din idé, eller trenger du hjelp med å videreutvikle en løsning som allerede er i drift? Se hvordan vi jobber med apputvikling og webapplikasjoner, eller ta kontakt.