Første version skal indeholde det, der skal til for at lære det, I mangler at vide, og intet andet. Prototype, proof of concept og MVP besvarer tre forskellige spørgsmål, og derfor er det første skridt at finde ud af, hvilket spørgsmål I står med. Derefter kan funktioner sorteres efter, om produktet virker uden dem. Skæringen er stifterens beslutning. Udviklere kan fortælle, hvad en funktion kræver, men hvad kunderne skal have først, er et forretningsvalg.
Tre ord, tre spørgsmål
- Prototype: vil brugerne forstå det? En prototype viser, hvordan produktet kan se ud og opføre sig. Den er ofte tegnet eller bygget hurtigt og er ikke beregnet til rigtige data.
- Proof of concept: kan det lade sig gøre? Et proof of concept er et lille teknisk forsøg, der afprøver det sværeste, fx om en integration virker, eller om en beregning er hurtig nok.
- MVP: vil nogen bruge og betale for det? MVP står for minimum viable product, den mindste version, der løser et rigtigt problem for rigtige kunder.
Rækkefølgen følger usikkerheden. Er I usikre på teknikken, starter I med et proof of concept. Er I usikre på, om brugerne forstår idéen, er prototypen først. Ved I begge dele, kan I gå direkte til MVP’en. Mange springer til MVP’en, fordi ordet er kendt, og bruger måneder på at bygge det, en prototype kunne have vist på en uge.
Begynd med det, I skal lære
Skriv de tre vigtigste ting ned, I ikke ved. Eksempler er: betaler kunderne, kan vi skaffe data, vil brugerne ændre arbejdsgang? Vælg derefter den ene, der vil vælte projektet, hvis svaret er nej.
Omfanget af første version er det, der skal til for at få svar på netop det spørgsmål. Alt andet er et ønske. Skriv svaret i en enkelt sætning: “Vi bygger det her for at finde ud af, om …”. Hvis sætningen ikke kan skrives, er I ikke klar til at bede om et tilbud.
Sortering af funktioner
Skriv alle funktioner på en liste, og sortér dem med tre spørgsmål:
- Kan kernen virke uden? Hvis ja, skal funktionen ud af første version.
- Kan den klares i hånden? En faktura kan laves manuelt, og en rapport kan sendes pr. mail. Så venter automatiseringen.
- Findes den færdig? Login, betaling og mails kan ofte købes som standardkomponent, så I ikke skal bygge dem, se bygge, købe eller integrere.
Tilbage står de få funktioner, der skal bygges. Læg dem i rækkefølge efter kerneflowet, altså det forløb, brugeren skal igennem for at få værdi. Ét forløb, der virker hele vejen, er bedre end fem halve.
Det, der skal med, selv om ingen kan se det
En lille version må gerne være lille. Den må ikke være uansvarlig, når rigtige kunder og rigtige data kommer ind. Disse punkter bør være med:
- Login og rettigheder, der er bygget ordentligt.
- Backup, som I har prøvet at genskabe.
- Adskillelse af kundernes data.
- Behandling af personoplysninger, der er tænkt igennem.
- Mulighed for at se fejl og rette dem hurtigt.
Prototyper er undtaget, så længe de ikke indeholder rigtige data og kundernes oplysninger.
Et tænkt eksempel
En stifter vil lave et system, der hjælper mindre byggefirmaer med tilbud. Listen rummer tegninger, materialepriser fra leverandører, tilbud som PDF, godkendelse hos kunden og bogføring. Det, stifteren ikke ved, er, om firmaerne vil skrive deres tilbud et nyt sted. Første version bliver derfor et enkelt tilbudsskema og en PDF. Materialepriser skrives ind i hånden, og bogføring venter. Fem firmaer bruger det i en måned, og først da besluttes det, hvad der skal bygges næste gang. Eksemplet er tænkt.
Hvem skærer?
Skæringen er stifterens. Den er svær, for hver funktion er en, nogen har bedt om. To vaner hjælper:
- Skriv “ikke nu”-listen. Det, der er skåret fra, får en plads, så det ikke forsvinder. Mange ting bliver aldrig savnet.
- Sæt en fast tidsramme. Beslut, hvornår første version skal bruges af kunder, og tilpas omfanget til datoen.
Udviklerne skal høres om, hvad der er dyrt, og om der er tekniske valg, der er svære at ændre. Enkelte valg skal træffes rigtigt allerede nu, se teknologivalg til MVP’en. Når første version er klar, står I over for en ny række opgaver, beskrevet i første version er leveret.
Det skal I lade være med
- At kalde alt for en MVP · vælg ordet efter spørgsmålet.
- At skære i det usynlige · sikkerhed og backup er ikke luksus.
- At lade udviklerne vælge omfanget alene · det er en forretningsbeslutning.
Det skal I kræve af den eksterne
- ☐ Hjælp til at formulere, hvad første version skal svare på.
- ☐ En ærlig liste over, hvad der kan skæres, og hvad der ikke kan.
- ☐ Et overblik over de valg, der er dyre at ændre senere.
- ☐ En kort plan for, hvad der skal ske, når I har fået svar.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Ikke-teknisk stifter: sådan kommer produktet i gang · Fra AI-bygget prototype til produkt
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
