MVP-udvikling: byg det mindste produkt, der kan bruges

MVP er en test med et færdigt kerneflow – ikke bare en pæn prototype

Det vigtigste spørgsmål er ikke, hvor mange features en MVP indeholder. Det er, om en konkret bruger kan gennemføre den opgave, der gør produktet værdifuldt, og om du kan lære af det. Det kan være en ejer, der skal godkende en ordre, eller en kunde, der skal få overblik over en sag. Hvis flowet ikke kan afsluttes, er flere indstillinger og skærme sjældent den rigtige næste investering.

En prototype er nyttig, når du skal teste navigation, forståelse eller interesse uden rigtige konti og produktion. En MVP har derimod de nødvendige funktioner til, at udvalgte brugere kan anvende løsningen som aftalt. Det kan kræve login, database, grundlæggende adgangsstyring og en måde at håndtere fejl. Hvor meget det kræver, afhænger af, hvilke oplysninger og processer du håndterer.

MVP betyder heller ikke, at alt skal være specialbygget. Hvis en eksisterende platform eller en enkel hjemmeside kan afprøve efterspørgslen, kan det være en bedre første investering. Jeg starter derfor med at afklare, om du faktisk har brug for udvikling, eller om problemet kan testes billigere.

• Én vigtig opgave for en bestemt bruger
• Så lidt funktionalitet som muligt, men nok til en reel test
• Data og sikkerhed efter faktisk risiko
• Tydelig beslutning om næste iteration

Hvad bør din første version indeholde?

Det er valget af kerneflow og nødvendige begrænsninger, der gør et MVP-projekt styrbart.

• Én primær bruger

  Beskriv, hvem der skal kunne gennemføre flowet. Andre målgrupper kan komme senere, hvis de ikke er nødvendige for den første læring.

• Én afsluttet handling

  Løs et problem fra start til slut. Eksempel: opret opgave, tildel ansvar, registrer færdiggørelse og find status bagefter.

• Data, der faktisk skal gemmes

  Adskil testdata fra virkelige personoplysninger. Hvis data skal gemmes, aftaler vi ansvar, adgang, backup og sletning.

• Enkel administration

  Du skal kunne hjælpe en testbruger og forstå, hvad der er sket. Et fuldt administrationspanel er ikke nødvendigvis en del af første version.

• Måling af brugeradfærd

  Definér en observation på forhånd: kan brugeren fuldføre flowet, og hvor går vedkommende i stå? Vurder samtykke og privatliv, før tracking aktiveres.

• Bevidst fravalg

  Flere sprog, mange roller, app-butikker, komplekse betalinger og integrationer kan ofte vente. Men nødvendige sikkerhedskrav kan aldrig vælges fra for at spare tid.

Et konkret MVP-forløb fra problem til test

Vi afklarer omfanget, før udviklingen begynder, og træffer nye beslutninger ud fra det, testen viser.

1. Definér den vigtigste hypotese

   Sæt ord på, hvad brugeren skal gøre, og hvad du vil lære af en første release. Beslut hvordan succes og fiasko kan observeres.

2. Tegn flow og fejlveje

   Gennemgå både den normale handling og det, der sker, hvis data mangler, adgang afvises eller en ekstern tjeneste er nede.

3. Byg kun det aftalte

   Design, datamodel og udvikling samles om kerneflowet. Ændringer i scope besluttes, frem for at blive til skjulte opgaver.

4. Test med relevante brugere

   Lad brugerne prøve løsningen uden instruktion, og noter hvilke trin de faktisk kan gennemføre. En demo for dig selv er ikke den samme test.

5. Beslut næste investering

   Fortsæt, forenkle eller stop på baggrund af feedback og data. Udvidelse er et nyt afgrænset scope, ikke automatisk inkluderet i den første pris.

Det, der typisk skal med – og det, der kan vente

Det er eksempler, ikke en fast featurepakke. Dit produkt afgør, hvilke krav der er nødvendige.

Hvordan afgør du, om din MVP har lært dig noget?

Aftal før udviklingen, hvilken konkret handling en testbruger skal gennemføre. Det kan være at oprette en ordre, invitere en kollega eller få en opgave fra start til slut. Hvis du ikke kan observere den handling, kan du heller ikke bruge testen til at beslutte, hvad der skal bygges bagefter.

Du behøver ikke indsamle alt om brugerens adfærd. Ofte er korte samtaler, observation af opgaveforløbet og registrering af problemer nok til at afsløre, hvor produktet er uklart. Skal du bruge tracking, vælger du kun nødvendige events, afklarer lovligt grundlag og sørger for, at du ikke gemmer uvedkommende personoplysninger.

Efter den første test bør du skrive tre ting ned: hvilket problem brugeren faktisk fik løst, hvor vedkommende gik i stå, og hvad der derfor er vigtigst at ændre. Hvis løsningen ikke skaber værdi, kan det rigtige næste skridt være at forenkle produktet eller stoppe i stedet for at bestille flere funktioner.

Spørgsmål, før du bestiller en MVP

Hvad står MVP for?

Minimum viable product: den mindste anvendelige version, der kan afprøve en vigtig antagelse hos relevante brugere. Den skal være brugbar til sit aftalte formål, ikke kunne alt.

Hvad koster MVP-udvikling?

En afgrænset app-MVP starter fra 35.000 kr. ekskl. moms i min prisberegner. Prisen på en SaaS-MVP, portal eller større webapp afhænger af data, login, integrationer og drift og aftales særskilt.

Kan en MVP bygges som webapp?

Ja, og for mange interne systemer eller SaaS-idéer er browseren en fornuftig første kanal. Hvis formålet kræver særlige mobilfunktioner, vurderer vi app-løsningen separat.

Hvor mange funktioner skal den have?

Så få som muligt, men nok til at gennemføre kernehandlingen. Antallet er ikke et mål i sig selv; én god arbejdsgang kan være mere værd end 20 ufærdige skærme.

Kan du vise et færdigt SaaS-produkt som case?

Jeg viser kun projekter med deres faktiske status. Ventra er en pilotcase, og Valirs er et produktkoncept; ingen af dem skal læses som dokumentation for et bredt lanceret SaaS-produkt.

Hvad sker der efter første version?

Vi vurderer feedback, fejl, om brugerne gennemfører opgaven, og hvilken funktion der reelt er nødvendig næste gang. Drift og videreudvikling aftales særskilt.

Vælg mellem første app, webapp og SaaS

• App-udvikling pris – Se forskellen på pris og leverance for prototype og app-MVP.
• Webapp-udvikling – Når den første version skal leve i browseren.
• SaaS-udvikling – Når flere selvstændige kunder skal kunne bruge samme produkt.
• Hjemmeside til startups – Når du først skal teste interesse med en hjemmeside.
• Ventra – pilotcase – Læs om en platform i pilotfasen uden påstand om bred lancering.
• Design og udvikling af SaaS-onboarding – Jeg hjælper dig med at bygge eller forbedre de første trin efter oprettelse, så nye brugere hurtigere kommer frem til den opgave, de valgte produktet for.
• Udvikling af iOS-apps til iPhone – Jeg hjælper med at gøre din idé til en iPhone-app, der kan testes på en fysisk enhed. Vi vælger de vigtigste funktioner og afklarer data, adgang og udgivelse, før udviklingen begynder.

Skal du have udviklet første version?

Beskriv én bruger, én nødvendig handling og hvad du vil lære. Det giver os et grundlag for at beslutte, om en MVP, webapp eller blot en prototype er den rigtige start.

Direkte til mig: +45 20 71 02 89 · ow@oscarwinther.dk

Drøft din MVP · Se app-priser