ProduktutviklingHafsteinn Runarsson · AI Konsulent05 Oct 2026 · 9 min
Proof of concept: slik tester du en idé før full utvikling
En proof of concept (PoC) er en avgrenset test som skal vise om en idé lar seg gjennomføre før du investerer i full utvikling. En god PoC undersøker én tydelig usikkerhet, bruker målbare suksesskriterier og ender i en beslutning: gå videre, juster eller stopp.
Det viktigste er derfor ikke å bygge mye. Det er å skaffe nok bevis til å ta neste beslutning med mindre usikkerhet.
Hva er en proof of concept?
En proof of concept er en liten undersøkelse eller demonstrasjon som tester om et konsept kan fungere i praksis. Den lages tidlig, før teamet binder mye tid, penger eller kapasitet til løsningen. Både Atlassian og Lucid beskriver PoC som en måte å undersøke gjennomførbarhet før full utvikling.
En PoC skal svare på et avgrenset spørsmål, for eksempel:
- Kan en modell hente riktig informasjon fra de aktuelle datakildene?
- Kan et nytt system integreres med infrastrukturen som allerede finnes?
- Kan løsningen håndtere den viktigste arbeidsflyten uten uakseptabel ventetid?
- Kan vi redusere en bestemt teknisk risiko før vi planlegger resten av produktet?
Resultatet trenger ikke være pent eller klart for kunder. Det må være tydelig nok til at beslutningstakerne forstår hva som ble testet, hva teamet lærte og hvilke usikkerheter som gjenstår.
Når bør du bruke en PoC?
En PoC passer når en kritisk antakelse kan velte hele initiativet. Test den antakelsen først, i stedet for å skjule den inne i et stort utviklingsprosjekt.
Bruk en proof of concept når:
- teknologien er ny for teamet
- en integrasjon eller datakilde kan være en flaskehals
- kvalitet, sikkerhet, kapasitet eller kostnad er usikker
- flere tekniske tilnærminger må sammenlignes
- ledelsen trenger dokumentasjon før den godkjenner videre investering
En PoC er mindre egnet når hovedspørsmålet er om brukerne forstår grensesnittet eller vil betale for løsningen. Da gir brukerintervjuer, en klikkbar prototype eller en markedstest ofte bedre svar. Velg metode etter usikkerheten du faktisk trenger å redusere.
Proof of concept, prototype, MVP eller pilot?
Begrepene beskriver ulike trinn og bør ikke brukes om hverandre. En praktisk huskeregel er at en PoC tester om noe kan fungere, mens de neste trinnene undersøker hvordan det bør fungere i bruk.
- Proof of concept: Tester en kritisk antakelse eller teknisk mulighet. Resultatet er kunnskap og en beslutning, ikke et ferdig produkt.
- Prototype: Viser hvordan løsningen kan se ut eller oppleves. Den brukes ofte for å utforske flyt, funksjoner og brukergrensesnitt.
- Minimum viable product (MVP): Er en begrenset, brukbar produktversjon som kan gi læring fra reelle brukere.
- Pilot: Prøver en løsning i et avgrenset, virkelig miljø før bred utrulling.
Lucids sammenligning av PoC, prototype og MVP bruker samme skille: PoC-en undersøker om konseptet kan virke, prototypen viser hvordan det kan virke, og MVP-en lar brukere utføre reelle oppgaver.
Slik gjennomfører du en proof of concept
En nyttig PoC starter med beslutningen som skal tas og jobber bakover derfra. Disse sju trinnene holder testen liten nok til å gi et tydelig svar.
1. Formuler beslutningen
Skriv hva resultatet skal brukes til. Skal dere velge teknologi, godkjenne en investering, redusere en sikkerhetsrisiko eller avgjøre om prosjektet bør stoppes?
En presis formulering kan være: "Vi skal finne ut om den valgte tilnærmingen kan løse kjerneoppgaven med akseptabel kvalitet og innenfor våre krav til datahåndtering."
2. Velg én kritisk antakelse
Avgrens PoC-en til det dere vet minst om, og som har størst konsekvens hvis antakelsen er feil. En test som prøver å bevise alt på én gang, gir ofte uklare resultater.
Skriv antakelsen som en påstand som kan avkreftes. Da blir det vanskeligere å flytte målstolpene etter at testen er ferdig.
3. Definer suksesskriteriene på forhånd
Bestem hva som teller som godt nok før arbeidet begynner. Kriteriene bør være observerbare og knyttet til beslutningen.
For en teknisk PoC kan kriteriene gjelde:
- kvaliteten på resultatet
- svartid eller kapasitet
- tilgangskontroll og databehandling
- robusthet ved feil og mangelfulle data
- forventet kostnad per oppgave
- hvor mye manuelt arbeid løsningen krever
Bruk terskler som passer virksomheten og risikoen. Poenget er ikke å kopiere andres tall, men å gjøre vurderingen etterprøvbar.
4. Avgrens data, brukere og funksjoner
Ta bare med det som trengs for å teste antakelsen. Beskriv hvilke data, systemer, brukergrupper og scenarioer som er innenfor og utenfor testen.
For AI-prosjekter bør testgrunnlaget ligne virkeligheten. Ta med vanskelige, tvetydige og mangelfulle eksempler, ikke bare ryddige demonstrasjonsdata.
5. Bygg den minste testen som kan gi svar
Lag akkurat nok til å måle kriteriene. Det kan være et skript, en enkel integrasjon, en teknisk demonstrasjon eller en manuell arbeidsflyt med én automatisert del.
Kode fra en PoC er ikke automatisk produksjonskode. Snarveier kan være forsvarlige i testen, men de må dokumenteres slik at ingen tolker demonstrasjonen som en ferdig løsning.
6. Test, loggfør og undersøk avvik
Kjør representative scenarioer og registrer både gode og dårlige resultater. Noter hvilke forutsetninger som måtte være på plass, hvor løsningen feilet, og om feilene kan håndteres uten å endre hele konseptet.
Ikke fjern ubehagelige testtilfeller for å få en pen demo. Avvikene er ofte den mest verdifulle delen av en proof of concept.
7. Ta en tydelig beslutning
Avslutt med ett av tre utfall:
- Gå videre: Antakelsen holder godt nok til neste trinn.
- Juster og test på nytt: Konseptet virker lovende, men en konkret usikkerhet må undersøkes.
- Stopp: Resultatet oppfyller ikke kriteriene, eller videre arbeid kan ikke forsvares.
Et stoppet prosjekt kan være et godt PoC-resultat. Teamet har da unngått å bygge videre på en antakelse som ikke holdt.
Hva bør leveransen inneholde?
Leveransen bør gjøre beslutningen forståelig for personer som ikke deltok i testen. En kort rapport er ofte mer nyttig enn en polert demonstrasjon uten sporbarhet.
Ta med:
- problemet og beslutningen PoC-en skulle støtte
- hypotesen og suksesskriteriene
- omfang, avgrensninger og antakelser
- data, metode og testscenarioer
- resultater opp mot hvert kriterium
- kjente feil, risikoer og teknisk gjeld
- anbefalingen og neste steg
Skill mellom det testen faktisk viste og det teamet antar. Det gjør det lettere å vurdere om bevisene er sterke nok.
Eksempel: proof of concept for en AI-assistent
En AI-PoC bør teste hele risikokjeden rundt én konkret oppgave, ikke bare om modellen kan skrive et overbevisende svar.
Tenk deg at en virksomhet vurderer en intern assistent for spørsmål om rutiner. Den kritiske antakelsen er at assistenten kan finne riktig informasjon, vise hvilket grunnlag svaret bygger på og sende usikre saker til et menneske.
En avgrenset test kan bestå av:
- et representativt utvalg godkjente dokumenter
- et testsett med vanlige, vanskelige og tvetydige spørsmål
- en enkel søke- og svarflyt
- kontroll av tilganger og datalagring
- manuell vurdering mot avtalte kvalitetskriterier
- registrering av feil, kostnad og behandlingstid
PoC-en skal ikke konkludere med at løsningen er klar for produksjon. Den skal vise om den valgte tilnærmingen fortjener neste investering, og hvilke krav som må løses før en pilot.
Vanlige feil som svekker en PoC
De fleste svake PoC-er feiler på avgrensning og beslutningsgrunnlag, ikke på selve demonstrasjonen.
- For stort omfang: Teamet bygger mange funksjoner og mister spørsmålet testen skulle besvare.
- Uklare kriterier: Resultatet vurderes etter magefølelse fordi ingen definerte "godt nok" på forhånd.
- For enkle data: Testen fungerer bare på ryddige eksempler som ikke ligner hverdagen.
- Demo blir likestilt med verdi: En imponerende presentasjon sier lite om brukernes behov, drift eller økonomi.
- Ingen eier beslutningen: Prosjektet fortsetter av vane selv om resultatet er uklart.
- Sikkerhet og personvern kommer for sent: Data brukes før tilgang, lagring og ansvar er avklart.
- PoC-kode settes rett i produksjon: Midlertidige snarveier blir permanent risiko.
Hva skjer etter en vellykket PoC?
En vellykket PoC reduserer én type usikkerhet, men den erstatter ikke produktutvikling. Neste steg kan være en prototype for brukeropplevelse, en MVP for læring i markedet eller en pilot i et kontrollert driftsmiljø. Atlassian peker også på MVP som et mulig neste trinn, avhengig av hva PoC-en har bevist.
Før produksjon bør teamet lage en ny plan for blant annet arkitektur, sikkerhet, overvåking, datakvalitet, drift, kostnader og ansvar. Vurder PoC-koden som dokumentasjon på læring, ikke som et løfte om at løsningen er ferdig.
Mal for en kort PoC-plan
En god plan kan være kort hvis hvert punkt er konkret. Bruk denne strukturen før arbeidet starter:
- Beslutning: Hvilken beslutning skal testen støtte?
- Antakelse: Hva tror vi er mulig, og hva kan avkrefte det?
- Omfang: Hva er med, og hva er uttrykkelig ikke med?
- Suksesskriterier: Hvilke observerbare resultater kreves?
- Testgrunnlag: Hvilke data og scenarioer representerer virkeligheten?
- Ansvar: Hvem gjennomfører testen, og hvem tar beslutningen?
- Resultat: Hvilke funn støtter eller svekker antakelsen?
- Neste steg: Gå videre, juster eller stopp?
Hvor lang tid bør en proof of concept ta?
En PoC bør være så kort som mulig, men lang nok til å teste den kritiske antakelsen på en troverdig måte. Varigheten styres av tilgangen til data, integrasjoner, fagpersoner og nødvendige godkjenninger. Hvis testen krever et helt produktløp, er omfanget sannsynligvis for stort.
Hva koster en PoC?
Kostnaden avhenger av teknisk usikkerhet, datatilgang, integrasjoner og krav til sikkerhet. Lag et eget budsjett for testen og avtal en stoppregel. Da unngår dere at en avgrenset undersøkelse glir over i et åpent utviklingsprosjekt.
Må en PoC inneholde kode?
Nei. En proof of concept kan være et eksperiment, en manuell prosess, en teknisk skisse eller en enkel demonstrasjon. Den trenger bare å produsere troverdig bevis for antakelsen som testes.
Kan en mislykket PoC være nyttig?
Ja. Hvis testen viser at ideen ikke møter kriteriene, har den spart virksomheten for en større feilinvestering. Dokumenter hvorfor den feilet, hvilke antakelser som ble avkreftet, og om en annen tilnærming bør prøves.
Er en PoC det samme som en pilot?
Nei. En PoC tester om et konsept kan fungere. En pilot prøver en mer moden løsning i et begrenset, virkelig miljø for å se hvordan den fungerer med faktiske brukere, prosesser og driftskrav.
En proof of concept har gjort jobben sin når den gir et ærlig beslutningsgrunnlag. Hold testen liten, gjør kriteriene tydelige og vær like villig til å stoppe som til å gå videre.