MVP-omfang: sådan beslutter du, hvad der skal med i appens første version

Det mest almindelige problem med en MVP er ikke teknisk. Funktionslisten vokser ved hvert møde, fordi hver funktion virker nødvendig, og nogle måneder senere har du et produkt, der gør mange ting middelmådigt og ikke svarer på det vigtigste spørgsmål: vil nogen bruge det.

Start med en hypotese, ikke med funktioner

Før du skriver funktioner ned, så skriv i én sætning, hvad MVP’en skal teste. For eksempel: »Projektledere i byggevirksomheder vil rapportere fremdrift hver uge via mobilen i stedet for at maile regneark.«

Tilføj et måltal, der bekræfter eller afkræfter hypotesen. Ikke »brugerne kan lide den«, men en adfærd, der kan tælles: hvor mange af de inviterede brugere der kom tilbage i anden uge, hvor mange rapporter der blev oprettet, hvor mange virksomheder der vil betale.

Én rejse fra start til slut

En MVP skal lade brugeren gennemføre én hovedrejse fra den første skærm til det resultat, vedkommende kom efter. Det er bedre, at én rejse virker helt, end at fem virker halvt.

Skriv alle de funktioner ned, du kan komme i tanke om, og placer hver af dem i én af tre grupper:

1. Nødvendige for hovedrejsen. Uden dem når brugeren ikke frem til resultatet.
2. Klares manuelt. Ting, som en person kan klare bag kulisserne i starten: oprette konti, sende rapporter, håndtere betaling mod faktura.
3. Senere. Alt andet.

Den anden gruppe er den mest værdifulde. At betjene de første kunder manuelt tager tid, men viser, hvad der faktisk er værd at automatisere.

Det kan som regel vente

• Et omfattende adminpanel. I starten er en enkel datavisning eller direkte adgang til databasen for teamet nok.
• Roller og rettigheder. Én kontotype er ofte nok til de første test.
• Sprogversioner. Medmindre du tester produktet på flere markeder på én gang.
• Notifikationer i mange kanaler. Mail er nok.
• Native apps. Hvis hovedrejsen virker i mobilens browser, kan en app i app-butikken vente.
• Flere integrationer. Én, den vigtigste, er som regel nok.

Det skal ikke vente

»Minimum« handler om omfanget, ikke om kvaliteten. Selv den første version har brug for:

• sikkert login og databeskyttelse, fordi et datalæk i en MVP er lige så virkeligt som i et modent produkt,
• analyse, der måler hypotesens måltal, fordi MVP’en ellers ikke tester noget,
• en gennemarbejdet hovedrejse, fordi brugere vurderer et produkt efter det, der virker, ikke efter planerne,
• grundlæggende tilgængelighed og en privatlivspolitik.

Prototype først

Før du begynder at kode, så test hovedrejsen på en klikbar prototype med et par personer fra målgruppen. En ændring i en prototype koster en brøkdel af en ændring i koden, og de første samtaler ændrer som regel skærmenes rækkefølge og det, brugeren vil se først. Hvem du skal tale med, og hvad du skal spørge om, har vi beskrevet i artiklen om B2B-personaer.

Fast tid, fleksibelt omfang

Det virker bedst at fastlægge deadline og budget på forhånd og lade omfanget være det, der varierer. Viser noget sig at være sværere end ventet, ryger det ud af den første version i stedet for at udskyde lanceringen. Hos os tager en MVP som regel 6–8 uger: én brugerrejse, én integration og idriftsættelse i produktion.

Efter lanceringen

Et par uger efter lanceringen går du tilbage til hypotesen og måltallet. Der er tre ærlige beslutninger: bygge videre, skifte retning eller stoppe. Hver af dem er en succes for MVP’en, fordi den blev truffet ud fra data og ikke ud fra mavefornemmelse.

Planlægger du et digitalt produkt og vil afgrænse den første version, så se, hvordan vi bygger apps og SaaS.