Når alle kan bygge alt, flytter flaskehalsen seg. Produktlederen må finne den

De fleste produktledere vi møter, har vokst opp med én sannhet: Det er alltid flere gode ideer enn det er utviklere til å lage dem. Kostnadene var høye, backloggen var lang, sprintene var fulle, og en stor del av jobben handlet om å sikre tilgang til knappe ressurser.

Den virkeligheten har endret seg. Et team med AI-agenter kan i dag lage en fungerende prototype på timer og teste nye tjenesteideer på dager. Oppgaver som tidligere krevde betydelig tid og utviklingskapasitet, kan nå løses langt raskere.

Det høres ut som gode nyheter. Det er det også. Men det skaper utfordringer mange organisasjoner ikke har tatt innover seg.

En gammel lov i ny drakt

I 1984 kom romanen «The Goal» av Eliyahu Goldratt og Jeff Cox, som gjorde det vi i dag kaller Theory of Constraints kjent for et stort publikum. Poenget er enkelt: Kapasiteten i et system begrenses av det svakeste leddet. Ethvert system har en flaskehals som bestemmer hvor mye systemet klarer å levere. Forbedrer du noe annet enn flaskehalsen, blir ikke systemet raskere. Det fører bare til at køen foran flaskehalsen vokser.

Når AI gjør det raskere og billigere å skrive kode, kan det være nettopp dette som skjer. Det amerikanske IT-selskapet Faros AI analyserte i 2025 data fra over 10 000 utviklere i 1 255 team. Utviklere i team med høy AI-bruk fullførte 21 prosent flere oppgaver og fikk flettet inn 98 prosent flere kodeendringer. Samtidig økte tiden det tok å gjennomgå endringene med 91 prosent, og på selskapsnivå fant de ingen sammenheng mellom AI-bruk og bedre resultater.

Googles årlige DORA-rapport fra 2025, med svar fra nesten 5 000 teknologer verden over, peker i samme retning. 90 prosent bruker AI i jobben, og over 80 prosent mener det har gjort dem mer produktive. Men rapportens hovedbudskap er at AI ikke retter opp svakheter i et team. Den forsterker det som allerede er der.

Med andre ord: Den enkelte koder raskere, men systemet rundt henger ikke med. Flaskehalsen har flyttet seg.

Forbedrer du noe annet enn flaskehalsen, blir ikke systemet raskere. Du får bare mer kø.

Verktøy: Tell køene

Før du gjør noe annet, forstå hvor arbeidet faktisk stopper opp. Det tar en halvtime og krever bare en tavle.

1. Tegn opp flyten fra idé til effekt: idé → beslutning → bygging → gjennomgang og test → lansering → i bruk → målbar effekt.
2. For hvert steg, skriv opp hvor mange saker som venter der akkurat nå, og omtrent hvor lenge den eldste har ventet.
3. Finn stegene der arbeid hoper seg opp eller blir liggende lenge. Undersøk hvorfor sakene ikke kommer videre.
4. Spør teamet: Hvis vi doblet farten i byggingen i morgen, hvor ville arbeidet hopet seg opp?

Hvis arbeidet ville hopet seg opp andre steder, er ikke mer AI i utviklingen nødvendigvis det som hjelper. Vår erfaring er at køen hos mange havner på to steder: foran beslutning, der saker venter på at noen skal si ja eller nei, og etter lansering, der ting er levert uten at noen vet om det har gitt riktig effekt.

Fra «kan vi bygge det?» til «bør vi bygge det?»

Når byggingen ikke lenger er det dyre eller vanskelige hinderet, havner presset hos dem som skal avgjøre hva som er verdt å bygge. Og der har vi aldri vært spesielt treffsikre. Da Microsoft gikk gjennom resultatene fra sine kontrollerte eksperimenter, var omtrent en tredjedel av ideene positive, en tredjedel hadde ingen effekt og en tredjedel gjorde det verre. I Bing var treffprosenten enda lavere. Produktanalyseselskapet Pendo fant noe lignende fra en annen kant da de i 2019 analyserte bruksdata fra 615 kundeabonnementer: 80 prosent av funksjonaliteten i et gjennomsnittlig programvareprodukt ble sjelden eller aldri brukt, og 12 prosent av funksjonene sto for 80 prosent av den daglige bruken.

Så lenge det var dyrt å bygge, fungerte kostnaden som et naturlig filter. Teamene måtte prioritere fordi de ikke hadde noe valg. Når den begrensningen er borte, forsvinner ikke de dårlige ideene. De blir bare satt i produksjon raskere, uten at noen har spurt om de bør bygges. Derfor er product discovery viktigere enn noen gang før: å finne ut om det vi planlegger å lage, faktisk vil skape verdi.

Dette ser vi allerede i norske virksomheter. I Team Agiles undersøkelse blant 385 produktledere, produkteiere og teamledere i januar 2025 svarte 46 prosent at teamene bygger det de har kapasitet til, uavhengig av om det skaper mest verdi. Bare 18 prosent hadde en strategi som faktisk styrte produktutviklingen. Les mer om undersøkelsen her. Gi de samme teamene ti ganger så mye kapasitet, og du får ikke ti ganger så mye verdi. Du får ti ganger så mye av det de allerede gjør.

Vi er på vei inn i en verden med uendelig mange løsninger og altfor få ekte problemer.

Forventningene til produktlederen øker

Flere tunge stemmer i bransjen trekker de samme konklusjonene. «Fordi vi nå kan bygge raskt, må en større andel av tiden brukes på å bestemme hva vi skal bygge», skrev Andrew Ng i nyhetsbrevet The Batch i april 2026. Han beskriver team som presser forholdstallet mellom utviklere og produktledere ned fra rundt 8:1 til helt ned mot 1:1.

LinkedIn har gått lenger. I desember 2025 fortalte produktsjef Tomer Cohen at selskapet erstatter traineeprogrammet for produktledere med et program for «associate product builders», der nyansatte lærer koding, design og produktledelse samtidig. Og Marty Cagan skrev i mai 2025 at produktlederjobben verken handler om å være prosjektleder eller å administrere en backlog, men om å skape produkter. Han venter at produktledere som ikke gjør det, vil bli hengende etter.

Retningen er tydelig: Produktlederen skal i mindre grad koordinere og i større grad skape retning og legge til rette for gode beslutninger. Basert på forskningen og egne erfaringer fra team vi jobber med, ser vi fire skifter som går igjen.

1. Fra backlog til dømmekraft

Når alt kan bygges, er den viktigste beslutningen hva dere lar være å bygge. Det krever en tydelig hypotese om hvilket problem dere løser, for hvem, hvorfor nå og hvordan dere måler verdi.

Et grep vi har sett fungere overraskende godt, er en eksplisitt stoppregel. Teamet slutter å bygge nye funksjoner til ett bestemt effektmål er nådd, og bruker all innsats på det som står i veien. Det føles unaturlig når det er så lett å lage noe nytt. Det er nettopp derfor det virker.

Prøv dette i morgen: Skriv stoppregelen deres på én linje og heng den opp der teamet ser den:

«Vi bygger ikke ny funksjonalitet før [metrikk] har gått fra [nå] til [mål] innen [dato]. Alt vi gjør frem til da, skal flytte denne metrikken.»

Klarer dere ikke fylle inn hullene, har dere funnet det første dere må jobbe med. Her viser vi hvordan dere setter produktmål med metrikk og måltall, steg for steg.

2. Fra taus kunnskap til nedskrevne prinsipper

AI-agenter er ikke bedre enn konteksten de får. Det så vi allerede da vi bygde en fullstack-app på 20 minutter, og senere oppdaget feil AI-en ikke hadde fanget opp selv. Når AI tar en større del av utviklingsarbeidet, blir det viktigere å gjøre teamets kunnskap, prioriteringer og kvalitetskrav tilgjengelige, fremfor å la dem bli værende i hodene på enkeltpersoner.

Her er det interessant forskning å hente. I studien «The Cybernetic Teammate», publisert i Organization Science i 2026, lot Fabrizio Dell'Acqua og kolleger 791 ansatte i Procter & Gamble jobbe med reelle produktutviklingsoppgaver. Enkeltpersoner med AI presterte like godt som team uten AI, og AI brøt ned siloene mellom fagområdene: Forslagene ble mer balanserte uansett om personen kom fra forskning og utvikling eller fra den kommersielle siden. Studien viser hvordan AI kan gjøre kompetanse på tvers av fagområder mer tilgjengelig. Den sier derimot ikke at AI erstatter behovet for gode team. For oss understreker dette verdien av å gjøre faglige vurderinger og prinsipper eksplisitte, slik at både mennesker og AI har et bedre grunnlag å jobbe ut fra.

Prøv dette i morgen: Lag en prinsippfil på én side som både mennesker og agenter kan bruke. Fem overskrifter holder:

• Hvem vi er til for, og hvem vi ikke er til for
• Problemet vi løser nå, formulert som et kundeproblem, ikke en løsning
• Hva god opplevelse betyr hos oss, med tre konkrete eksempler
• Hva vi aldri gjør, uansett hvor lett det er å bygge
• Når noe er ferdig: hvilken metrikk som skal ha flyttet seg

Legg gjerne til en rolle som har lov til å være ubehagelig. Vi bruker en instruks som denne: «Før du hjelper meg å bygge noe, spør hvilket problem det løser, hvilke data som støtter at problemet er reelt, og hva vi bør slutte med for å få tid til det.» Det er lett å bli forelsket i det dere bygger når det går så fort.

3. Fra leveranse til læringshastighet

Når det går raskt å bygge, går det også raskt å lære, forutsatt at dere faktisk måler. Den største gevinsten med AI for produktledere er ikke at dere får mer ut av utviklingen. Det er at dere kan teste flere hypoteser på kortere tid.

Men data vil ofte fortelle deg noe ubehagelig: at problemet ikke ligger i produktet i det hele tatt. Det kan ligge i hvem som finner frem til det, i hvor mange brukere som må være på plass før tjenesten blir nyttig, eller i måten organisasjonen rundt tar imot endringen. Den flaskehalsen fikser du ikke med mer kode.

Prøv dette i morgen: Finn det ene stedet i brukerreisen der flest faller fra, og ta det med på neste møte med teamet med disse spørsmålene:

• Hvilket problem tror brukerne dette produktet løser for dem?
• Hva skjer rett før brukerne forsvinner?
• Er dette et produktproblem, eller er det noe utenfor produktet?
• Hva er det minste vi kan gjøre denne uka for å finne ut av det?

Vil du gjøre dette til en fast vane, kan du lese her om hvordan dere får målene til å styre uka.

4. Fra funksjoner til tillit

Når alle kan lage innhold og tjenester med AI, blir oppmerksomhet og tillit knappere ressurser. Mesut Cicek og hans kolleger ved Washington State University fant i 2024, gjennom eksperimenter med over 1 000 amerikanere, at produkter som ble beskrevet med «kunstig intelligens», var mindre populære enn identiske produkter uten. Forklaringen var lavere emosjonell tillit. Effekten var sterkest for produkter folk opplever som risikable, som dyr elektronikk, medisinsk utstyr og finansielle tjenester.

For produktlederen betyr det at nærhet til brukerne blir viktigere, ikke mindre viktig. Det er ikke nok å forstå problemet. Du må også forstå hvor brukerne er, hva de stoler på, og hvordan du når dem. I en strøm av ansiktsløst innhold er en ekte person med en ekte historie et konkurransefortrinn. Som vi har skrevet før: AI er en hygienefaktor, ikke et konkurransefortrinn.

Prøv dette i morgen: Ta kontakt med tre sluttbrukere av tjenesten eller produktet ditt, uten å vise dem noe dere har laget. Spør: «Hvordan fant du ut om oss, og hva fikk deg til å prøve?» Skriv ned ordene de bruker. Det er ofte de beste ordene du har til neste lansering. Her får du tre tips som gjør samtalen mer verdifull.

Men er det så enkelt?

Det finnes gode grunner til å være forsiktig med å slå fast at flaskehalsen nå sitter hos produktlederen.

For det første er det ikke opplagt at AI alltid gjør utviklingen raskere. I et randomisert forsøk fra forskningsinstitusjonen METR tidlig i 2025 brukte 16 erfarne utviklere 19 prosent lengre tid på 246 reelle oppgaver når de fikk bruke AI. Før forsøket trodde de at AI ville gjøre dem 24 prosent raskere, og etterpå mente de fortsatt at de hadde jobbet 20 prosent raskere. METR har selv senere skrevet at resultatene er utdaterte fordi verktøyene har blitt bedre. Likevel er studien en god påminnelse om at følelsen av fart ikke er det samme som fart.

For det andre viser både Faros og DORA at mye av køen i dag oppstår i gjennomgang, testing og kvalitetssikring, ikke bare i prioriteringen. Flaskehalsen kan like gjerne sitte i et svakt utviklingsmiljø eller i uklare arbeidsflyter. I studien «Navigating the Jagged Technological Frontier» fikk 758 konsulenter i Boston Consulting Group løse oppgaver med og uten AI. På oppgaver AI mestret, leverte de mer, raskere og med bedre kvalitet. Men på en oppgave som lå utenfor det AI mestret, falt andelen riktige svar fra 84 prosent uten AI til 60–70 prosent med. Mer AI gir altså ikke automatisk bedre beslutninger.

For det tredje bør vi være varsomme med å tolke dette som at produktlederen skal bli et enmannsorkester. Procter & Gamble-studien fant at løsningene som havnet blant de 10 prosent beste, var omtrent tre ganger så sannsynlig å komme fra team som brukte AI som fra enkeltpersoner uten AI. Og Andrew Ng peker på at de raskeste teamene han ser, har utviklere som selv kan gjøre en del produktarbeid. Rollene glir inn i hverandre, de forsvinner ikke.

Vårt syn er derfor dette: Flaskehalsen sitter der systemet er svakest, og det er ikke alltid hos produktlederen. Men det er produktlederens jobb å finne den. Og når det er blitt så billig å bygge, er den største risikoen at den nye kapasiteten brukes på feil ting.

Flaskehalsen sitter der systemet er svakest. Men det er produktlederens jobb å finne den.

Et enmannsorkester trenger et publikum

AI har gjort det enklere enn noen gang å lage noe. Det har ikke gjort det enklere å lage noe noen vil ha. Arbeidsmengden er ikke nødvendigvis blitt mindre, den har bare flyttet seg: fra å skrive kode til å forstå problemer, ta valg, lære raskt og nå frem til mennesker.

Du trenger ikke snu opp ned på alt. Start i morgen med å telle køene. Velg så det av de fire skiftene som treffer der køen er lengst.

Et enmannsorkester kan spille en vakker symfoni. Men den er ikke verdt mye uten noen som lytter.

Artikkelen bygger på et foredrag Anders Erlandsen holdt på NDC. Ta kontakt hvis du vil utforske hvordan produktlederne og teamene deres kan lykkes med produktutvikling når AI flytter flaskehalsen.