PoC eller MVP?

PoC og MVP høres ut som samme type tidlige eksperiment, men de svarer på helt forskjellige spørsmål. En proof of concept beviser at noe kan bygges teknisk. En minimum viable product beviser at noen vil bruke og betale for det. Den ene tar brodden av den tekniske risikoen, den andre av markedsrisikoen, og å vite hvilken du står overfor, avgjør hvor du bør begynne. Spørsmålet er særlig vanlig i AI- og integrasjonsprosjekter, der teknologien oftere er et åpent spørsmål.

Kan det bygges, eller vil noen bruke det?

En PoC stiller spørsmålet kan dette i det hele tatt bygges? Tåler API-et belastningen? Når AI-modellen høy nok treffsikkerhet? Er det mulig å integrere mot det gamle ERP-systemet? En PoC er derfor ofte smal og teknisk, bygget for å svare på ett eneste slikt spørsmål, og den mangler vanligvis et ferdig grensesnitt fordi den ikke er laget for brukere, men for å bevise noe for teamet.

En MVP stiller i stedet spørsmålet vil noen faktisk bruke dette? Den er et fungerende, forenklet produkt som møter virkelige brukere i drift, og det den måler, er atferd: Kommer folk tilbake, fullfører de flyten, betaler de?

Kjernen: PoC-en tar for seg teknisk risiko, MVP-en markedsrisiko. Bruker du feil verktøy, svarer du garantert på feil spørsmål.

Typiske rekkefølger: Hvor ligger risikoen?

Hvilken rekkefølge som er riktig, avgjøres av hvor den største usikkerheten ligger.

• Prosjekter med teknisk risiko: PoC først, så MVP. Når det store spørsmålet er om løsningen i det hele tatt kan bygges (en ny algoritme, en uprøvd integrasjon, et strengt ytelseskrav), bør du starte med en PoC. Faller den, har du spart en hel produktinvestering. Holder den, bygger du MVP-en på innsikten og tester forretningen.
• Prosjekter med markedsrisiko: rett på MVP. Når teknologien er velprøvd, men det er usikkert om noen vil ha produktet, er en PoC bortkastet tid. Gå rett på en MVP og legg kreftene i å teste etterspørselen.
• Begge deler: PoC på den kritiske tekniske delen, så MVP rundt den. Noen ganger finnes det både en teknisk nøtt som må knekkes, og et markedsspørsmål. Da avgrenses PoC-en til akkurat den usikre teknologien, og når den er løst, bygges MVP-en som tester helheten.

De fleste prosjekter havner i én av disse. Å sette ord på hvilken risiko som veier tyngst, er ofte den mest verdifulle beslutningen i hele oppstarten.

Den vanlige feilen: PoC-en som sniker seg inn i produksjon

Her snubler mange. En PoC bygges raskt for å bevise et poeng, den fungerer, og noen sier: «Den fungerer jo allerede, kan vi ikke bare bygge videre på den?» Slik glir provisoriet umerkelig inn i produksjon.

Problemet er at en PoC bevisst hopper over det som gjør et produkt holdbart: feilhåndtering, sikkerhet, tester, struktur. Den var bygget for å svare på et spørsmål, ikke for å leve i drift. Når den likevel settes i produksjon, bygges teknisk gjeld inn i selve fundamentet, og regningen kommer senere i form av feil, sikkerhetshull og en kodebase som er vanskelig å bygge videre på.

Botemiddelet er en beslutning på forhånd: PoC-en skal kastes. Det er lærdommen som tas videre, ikke koden. MVP-en bygges deretter på riktig grunnlag, med kunnskapen om at teknologien holder.

Et konkret scenario

Et selskap ønsket å bygge en tjeneste som automatisk tolker innskannede fakturaer med AI. Den store usikkerheten var teknisk: Blir treffsikkerheten god nok til at tjenesten er brukbar? De bygget en PoC på et par uker, kjørte den mot hundrevis av virkelige fakturaer og konstaterte at den nådde et brukbart nivå, med tydelige unntak for håndskrevne felt.

I stedet for å sette PoC-en i drift brukte de den som beslutningsgrunnlag og kastet den. MVP-en ble deretter bygget skikkelig, med feilhåndtering og en flyt for tilfellene der AI-en var usikker og et menneske måtte ta over. PoC-en besvarte kan det bygges; MVP-en gikk videre til vil noen bruke det, i riktig rekkefølge og uten at provisoriet ble grunnlaget for produktet.

Slik velger du riktig startpunkt

Spør deg selv hvilken risiko som kan senke satsingen: at det ikke lar seg bygge, eller at ingen vil ha det? Ligger den tunge usikkerheten i teknologien, bør du starte med en PoC. Ligger den i markedet, gå rett på en MVP. Vi i Weapp avklarer ofte nettopp det spørsmålet først i AI- og integrasjonsprosjekter, som en del av tjenestene våre.

Usikker på hvor den tyngste risikoen din ligger? Ta kontakt, så hjelper vi deg med å finne den og velge riktig første steg.