Det er fristende at bygge “hele løsningen” med det samme, men ruten til et robust produkt går gennem små, kontrollerede skridt. Valget mellem en prototype, et proof of concept og et minimum viable product påvirker både tid, budget og risiko. Her får du en praktisk måde at beslutte, hvad du skal bygge først.
Forskellen på prototype, PoC og MVP
En prototype er en hurtig model af brugeroplevelsen. Den kan være klikbar i et designværktøj eller en tynd frontend, der viser flow, men uden fuld backend. Et proof of concept (PoC) tester en central antagelse: Kan algoritmen skalere? Kan integrationen til ERP lykkes? Et minimum viable product (MVP) er den første smalle version i drift med logging, monitorering og basal support, så rigtige brugere kan skabe data, der validerer forretningen. Brug definitionerne aktivt, så teamet taler samme sprog.
Hvornår giver hver tilgang mening
Brug den mindst mulige artefakt, der besvarer det vigtigste spørgsmål:
- Usikkerhed om brugerbehov: Lav en prototype og indsamle kvalitative reaktioner.
- Usikker teknologi eller integration: Byg en PoC i et afskærmet testmiljø.
- Klart problem og behov for adfærdsdata: Leverér en smal MVP med sporbarhed og support.
- Regulatoriske krav eller sikkerhed: Start med PoC + arkitekturvurdering før MVP.
Afslut hver aktivitet med en beslutning: Hvad lærte vi, og hvilket næste skridt reducerer mest risiko?
Faldgruber og enkel beslutningsramme
Typiske faldgruber er, at prototyper sniger sig i drift, PoC’er bliver til permanent kode, og at scope vokser hurtigere end læringen. Sæt tydelige exit‑kriterier, mål på hypotesen og tidsboks arbejdet. Brug denne ramme: 1) Formulér kernespørgsmålet, 2) vælg den letteste metode, der kan falsificere det, 3) definér målepunkter og “go/no‑go”, 4) planlæg næste iteration, før du starter. Når beslutninger og kriterier er synlige, går du hurtigere uden at øge risikoen. Start småt, lær hurtigt og udrul kun det, der er bevist værdifuldt.
