Pilotfellen

Hvorfor vibe coding gjør gapet mellom demo og drift større, ikke mindre.

Kort oppsummering: Pilotfellen er gapet mellom en vellykket pilot (som ikke kommer i drift) og en løsning som faktisk kommer i drift. AI og vibe coding gjør det enklere å bygge demoer, men gapet til produksjon har blitt større. Selskaper som unngår fellen definerer en levedyktig versjon (VMP) i stedet for en minimumsversjon (MVP), bygger med ett team som eier helheten fra idé til drift, velger færre initiativer og gjør dem ferdig, og måler suksess på reell adopsjon, ikke på demo.

Vi har sett det skje mange ganger. Et selskap starter et digitalt initiativ. En pilot. En proof of concept. En demo. Resultatene blir gode nok til å vises frem internt, ledergruppen er fornøyd, og alle er enige om at dette er veien videre.

Så stopper det.

Piloten blir aldri et produkt. Plattformen blir aldri tatt i bruk i full skala. To år senere er teknologien utdatert, teamet oppløst, og selskapet starter et nytt initiativ med nytt navn og samme premiss.

Det er dette vi kaller pilotfellen.

Vi har bygget DAYTWO rundt det motsatte: å ta ideer fra idé til ferdig løsning. Det er derfor vi kjenner igjen mønstrene som stopper dem underveis.

Hva pilotfellen er

Pilotfellen er gapet mellom et vellykket pilotprosjekt og en løsning som faktisk kommer i drift og skaper verdi over tid. Selskapet klarer å bygge noe som fungerer i et kontrollert miljø, men ikke å gjøre det til noe som fungerer i hele organisasjonen.

Mønsteret er ikke nytt. Det vi ser nå er at det har blitt mer utbredt, ikke mindre.

Med AI-verktøy går det raskere enn noensinne å bygge noe som ser ferdig ut. En prototype med god UI, fungerende flyt, og en demo som imponerer i et møterom kan være laget på en ettermiddag. Mange snakker om "vibe coding": å klikke sammen en løsning ved hjelp av AI uten å tenke på arkitektur, data, integrasjoner eller drift. Det er moro å gjøre, og det blir gjerne pent å se på. Men gapet mellom demo og produksjon har blitt større, ikke mindre. Demoen ser bedre ut. Det som ligger under er enda lengre fra noe som faktisk kan kjøres i en organisasjon.

Hvorfor det skjer

Pilotfellen handler sjelden om teknologi. Teknologien fungerer som regel godt nok når piloten avsluttes. Det er det som kommer etterpå som svikter.

Vi ser fire grunner igjen og igjen.

1. Piloten ble bygget for å imponere, ikke for å skalere

Det vanligste mønsteret. Piloten gjøres så lett som mulig for å demonstrere effekt raskt. Den kobles til testdata, har en hardkodet brukergruppe, og kjører på infrastruktur som ikke tåler produksjon. Når selskapet skal sette den i drift, viser det seg at å gjøre piloten produksjonsklar krever langt mer arbeid enn å bygge den i utgangspunktet. Da er prosjektbudsjettet brukt opp og oppmerksomheten flyttet videre.

2. Det finnes ingen produkteier

En pilot drives gjerne av en innovasjonsavdeling, en intern entusiast eller en ekstern leverandør. Når piloten er ferdig, skal ansvaret over til en linjeorganisasjon som ikke var med på å definere løsningen. Linjen kjenner ikke koden, har ikke ressurser til å vedlikeholde den, og er heller ikke målt på om den lykkes. Resultatet er at ingen tar eierskap, og løsningen forfaller sakte.

3. Drift og integrasjoner ble lagt til på slutten

En løsning må fungere sammen med eksisterende systemer, sikkerhetsregimer, brukerstøtte, dokumentasjon og kompetansen til dem som faktisk skal bruke den. Hvis disse hensynene først kommer inn i bildet etter at piloten er ferdig, må store deler av løsningen bygges om. Da koster det mer å sette den i drift enn det kostet å bygge den.

4. Suksesskriteriene var feil

En pilot blir ofte målt på om demonstrasjonen gikk bra. Det er feil spørsmål. Det riktige spørsmålet er om den endrer hvordan folk faktisk jobber. En pilot som beviser at noe er mulig, men som ingen tar i bruk, har ikke skapt verdi. Den har bare bevist en hypotese.

Hva som faktisk fungerer

De selskapene som kommer forbi piloten gjør noen ting annerledes fra start.

De definerer hva en levedyktig versjon av løsningen krever, ikke hva en minimumsversjon kan vise. Det betyr å starte med integrasjoner, drift, sikkerhet og brukeradopsjon i designet. Ikke som etterarbeid, men som premiss.

De bygger med ett team som tar ansvar fra idé til drift. Strategi, design, teknologi og produktledelse i samme rom. Når et team eier helheten, forsvinner overleveringene som ellers fører til at løsninger faller mellom stoler.

De velger færre prosjekter og gjør dem dypere. Et selskap som starter tre piloter samtidig får ofte tre piloter som aldri kommer videre. Et selskap som starter ett initiativ og forplikter seg til å ta det helt frem, får et produkt.

De aksepterer at det første som skal stå alene må fungere fra første dag. Ikke perfekt, men ekte. Brukere som faktisk bruker det. Data som faktisk er produksjonsdata. Eieren som faktisk har ansvaret videre.

Vi har et eget begrep for det. Vi snakker om viable minimum product, ikke minimum viable product. Det er rekkefølgen som gjør forskjellen. MVP starter med minimumet og håper det blir levedyktig. VMP starter med levedyktigheten, det som faktisk må fungere i bruk, og gjør det så lite som mulig innenfor den rammen.

Fem spørsmål vi tar opp tidlig

Disse fem spørsmålene jobber vi oss gjennom sammen med kunden tidlig i prosjektet. Svarene er ikke gitt fra start. Å finne dem er en del av jobben.

1. Hvem er produkteier i organisasjonen, og hva er deres ansvar etter at piloten er ferdig?

    

2. Hvilke eksisterende systemer må løsningen fungere sammen med fra dag én?
    
3. Hva må endres i hvordan folk jobber, for at løsningen skal skape verdi?
    
4. Hva er det minste som må være på plass for at noen kan bruke dette i ekte arbeid, ikke i en demo?
    
5. Hvem har ansvar for løsningen om to år, og hvordan finansieres videreutviklingen?

Spørsmålene er ikke et filter for å avlyse prosjekter. De er det som gjør at gode ideer faktisk når frem.

Hva vi ser nå

AI har gjort det enklere enn noensinne å starte. Det har ikke gjort det enklere å lande. Mange selskaper sitter nå med imponerende prototyper som ingen klarer å sette i produksjon, fordi det aldri var planlagt for det.

Prinsippene er de samme som før. Bygg for drift, ikke for demo. Eie helheten i ett team. Velg færre initiativer og gjør dem ferdig. Mål på adopsjon, ikke på teknisk leveranse.

Slik gjør vi det i DAYTWO. Og vi tror flere selskaper bør gjøre det på samme måte.

Slik går vi frem i DAYTWO
 

1. Vi går inn i ideen sammen med kunden. Vi bruker tid på å forstå hva den skal gjøre, hvem den er for, og hvilken vinkel som faktisk skaper verdi. Samtidig avklarer vi hvem som skal eie løsningen videre. Idé og forutsetninger utvikles parallelt, ikke sekvensielt.
    
2. Vi definerer en levedyktig versjon, ikke en minimumsversjon. Vi spør: hva må være på plass for at noen kan bruke dette i ekte arbeid fra dag én? Det blir målet, ikke "hva er det letteste å bygge først".
    
3. Vi setter sammen ett team som tar ansvar fra idé til drift. Strategi, design, teknologi og produktledelse jobber parallelt i samme rom. Ingen overleveringer, ingen briefer som blir tolket feil.
    
4. Vi bygger med integrasjoner og drift som premiss. Eksisterende systemer, sikkerhet, dokumentasjon og brukerstøtte er en del av designet, ikke noe som legges på til slutt.
    
5. Vi måler på adopsjon. Vi følger med på om folk faktisk begynner å bruke løsningen og justerer underveis. En lansering er ikke et sluttpunkt. Det er starten på den fasen hvor det er viktigst å være til stede.
    

Ingen av punktene er nye, men vi tror det gjøres en helhet og ikke i ulike team eller ulike sprinter.