Rammen om hele whitepaperet. Hvem skriver det, hvem er det til, og hvad det er, og hvad det ikke er.
AI er ikke endnu et værktøj vi propper ind i modellen. Det er en kraft der ændrer hvad produktledelse er. Hvilke beslutninger vi træffer. Hvordan teams bygges. Hvad der adskiller en god produktorganisation fra en dårlig.
Den her playbook er en ramme for det skifte. Fem lag fra kultur til værktøjer. Hvert med et princip, og noget jeg stadig er i tvivl om.
Skrevet til produktledere, designere, engineering managers og produktchefer. Læs fra ende til anden, eller hop direkte til det lag der presser dig mest.
Produktledere, designledere og engineering managers der har ansvar for hvordan deres team faktisk arbejder. Ikke folk der vil lære at prompte bedre. Folk der spekulerer på om hele rammen omkring deres team holder.
Det henvender sig også til CTO’er, VP’er og foundere der skal gentænke struktur, roller og processer fra grunden, fordi den gamle model er holdt op med at give mening.
Hvis du leder efter en checkliste til “AI-transformation”, er det her ikke for dig. Hvis du leder efter en ærlig samtale om hvad der faktisk skal flyttes på, og i hvilken rækkefølge, så læs med.
Min tese er at de fleste AI-transformationer starter i bunden, med værktøjer. “Vi rullede Copilot ud.” “Vi har fået Cursor-licenser.” “Vi bruger ChatGPT Enterprise.”
Det er den hurtigste vej til en fejlslagen transformation.
Når værktøjer møder en kultur der ikke har flyttet sig, en organisation der stadig er bygget om koordinering af eksekvering, og roller defineret af hvad folk producerer, så forstærkes alt det knirkende.
Kultur øverst, værktøjer nederst. Hvert lag styrer det nedenunder. Hvis kulturen ikke er på plads, hjælper det ikke at organisere sig om. Hvis organiseringen ikke er på plads, hjælper det ikke at lære nye kompetencer. Og så videre.
Fem lag:
Den hjælper med at sortere tænkningen og finde ud af hvor noget reelt skal flyttes på.
Min egen praksis. Jeg shipper produkter med AI hver dag: Stilnote, Vibetjek, Knud, Dynamo, Super Yes. Det her er ikke teori. Det er reflektioner fra et arbejdsbord hvor Claude Code kører hele dagen.
Konsulentarbejde. Jeg har set hvordan organisationer som Norlys, Energinet, LEGO, Jyske Bank prøver at navigere produkttransformationen. Hvor det virker, og hvor det går galt.
Produktledelseslitteraturen. Cagan, Perri, Cutler, Skelton/Pais, Microsoft Research og andre. Jeg prøver at koble til de stemmer der allerede har sagt noget rigtigt om feltet, frem for at lade som om alting er nyt.
Egen historie. Jeg har skrevet om produktroller og UX siden 2022.
Ingen “top 10 AI tools.” Ingen one-size-fits-all process.
I stedet:
Fem lag, hver på omkring 1000 ord. Kan læses som samlet whitepaper eller som enkeltartikler. Hver del afsluttes med et princip, noget der kan stå alene.
Identiteten flytter sig fra eksekvering til dømmekraft.
For fire år siden skrev jeg om en frustration jeg så hver dag: UX’ere reduceret til wireframe-tegnere. Product Owners reduceret til backlog-pushere. Folk med dyb faglighed der brugte en brøkdel af den, fordi systemet ikke krævede mere af dem. Deadlinen skulle nås. Featuren skulle ud. Glimmer kunne drysses ovenpå til sidst.
Den frustration har ligget der siden. Nu er der noget der ændrer den.
AI flytter ikke mursten i en produktorganisation. Den flytter spørgsmål. Det vigtigste spørgsmål var i mange år om vi kunne nå det inden release. Det burde nu være om vi overhovedet skal bygge det.
Når prototyper kan bygges på en weekend, bliver det faktisk sværere at stille spørgsmålet — direktøren er allerede forelsket i sin egen demo, og PM’en der beder om tid til at undersøge står med dårligere kort end før. AI gør ikke build trap nemmere at slippe ud af. Den gør den dybere. Det er den egentlige opgave det her lag handler om: at gennemføre et skifte i hvilket spørgsmål der vægter, mod en organisation der gør det modsatte.
Når det skifte gennemføres, bliver hele identiteten i et produktteam vendt på hovedet.
Hvem du er som produktleder har historisk fulgt hvad du laver. PM’en skriver krav. Designeren laver mockups. Udvikleren bygger. Tre roller, tre arbejdsstrømme, en arbejdsdeling.
Den arbejdsdeling holder ikke længere. Når en designer kan bygge en fungerende prototype med Claude Code, og en PM kan kode et MVP på en eftermiddag, kollapser opdelingen på eksekveringsniveau. Rollerne lever videre, men grænsen mellem dem er ikke længere bestemt af hvem der kan finde tasterne.
Det er den nemme del af pointen. Den svære del kommer nu.
Hvis din identitet som produktleder er bygget på at du skriver krav, er du i problemer. AI skriver bedre krav end de fleste PMs.
Hvis din identitet som designer er bygget på at du laver wireframes, er du i problemer. AI laver wireframes hurtigere end du kan beskrive dem.
PM’en og designeren bliver ikke overflødige af den grund. Men deres identitet kan ikke længere ligge i outputtet. Den skal flytte sig: fra jeg er den der laver X til jeg er den der står inde for at X er det rigtige.
Marty Cagans fire produktrisici er et brugbart sted at lægge den nye identitet. Risikoområderne kollapser ikke selvom eksekveringen flader ud. De skifter karakter:
Fire ansvarsområder et produktteam skal dække, fordelt bevidst mellem mennesker der kan røre alt.
Melissa Perri skrev Escaping the Build Trap i en tid hvor det var dyrt at bygge. Hvor det krævede måneder, ressourcer, business cases. Selv da var build trappen et reelt problem, virksomheder byggede ting fordi de kunne, ikke fordi de skulle.
Tag den verden. Gør byggeomkostningerne marginale. Fjern den naturlige bremse som det tager seks måneder at lave det her var. Build trappen bliver dybere. Mere subtil. Sværere at slippe ud af.
Det er den kontraintuitive pointe ved AI-acceleration. Den løser ikke problemet med at bygge for meget af det forkerte. Den forværrer det. Og den gør den vigtigste del af produktledelse, at sige nej, at vente, at undersøge, sværere at forsvare i en organisation hvor alle andre kan bygge med det samme.
Princippet jeg ville skrive på væggen i et nyt team er kort:
Kundens problem før vores løsning.
Et identitetsudsagn. Vores opgave er at vælge skarpere, ikke at producere mere.
John Cutler skelner mellem decision quality og execution quality. AI accelererer execution. Decision quality er ikke fulgt med, og kan ikke følge med, fordi den kommer fra et andet sted. Den kommer fra kontekst, dømmekraft, brugerforståelse, forretningsforståelse, modet til at sige nej.
Det er det nye flaskehals. Og det er hvor produktteamet skal lægge sin identitet.
Hvad består dømmekraft så af, når man fjerner ordet og kigger på arbejdet? Fire ting jeg ser igen og igen hos folk der træffer skarpe produktbeslutninger:
Resten af playbooken handler om hvordan de fire ting bygges op.
En nyere undersøgelse fra Microsoft Research bekræfter mønsteret. 885 produktledere har svaret på hvordan AI ændrer deres arbejde, suppleret med telemetri og dybdeinterviews (Ulloa et al., 2025). En sætning skiller sig ud: accountability must not be delegated to non-human actors.
Det er kulturlagets fundament. AI kan generere. Den kan eksekvere. Den kan foreslå. Men den kan ikke bære ansvaret når noget går galt, og hvis ansvaret for en beslutning ikke ligger hos et menneske, ligger det ingen steder.
Produktlederens nye identitet: dommeren der bærer ansvaret når AI’en er forkert.
Der ligger en pointe gemt i det her som er nemmere at se end at gennemføre. UX’ere og PO’er får i princippet lov til at flytte sig fra eksekveringspres til faglighed. I praksis reagerer mange ikke med taknemmelighed. De reagerer med modstand mod den AI der har nedlagt deres synlige bidrag. Den modstand er rationel — deres karriere er bygget på det artefakt der nu kan genereres.
Når en udvikler kan generere et UI på fem minutter, kan ingen længere holde en UX’er i hjørnet med ordene vi mangler bare lige nogle skitser. Når AI kan tømme en backlog hurtigere end et team kan refine, kan en PO ikke længere skjule sig bag tickets. Eksekveringspresset, som var undskyldningen for at folk ikke fik lov til at bruge deres faglighed, falder bort.
En befrielse, hvis man kan finde sin nye identitet i den.
Befrielsen er ikke gratis. Den kræver at ledelsen aktivt ombygger belønningssystemet væk fra synligt output. Det arbejde er ingen organisationer jeg har set, færdige med.
Tre principper et team kan teste sig selv på:
Den kulturelle ramme alt andet skal hænge på. Hvis den ikke står klart, kommer organisationsstruktur, kompetencer, processer og værktøjer til at trække i hver sin retning.
Derfor står kultur øverst i pyramiden.
Hvad et produktteam organiseres efter, når koden er en commodity.
Tech Lead, Design Lead, Product Manager. Den klassiske produkttrio. Bygget på en præmis der ikke længere holder: at koden er den dyre del.
Kode er ved at blive en commodity. Når en designer kan prompte sig til en fungerende prototype, og en PM kan kode et MVP på en eftermiddag, skal teamet ikke længere organiseres efter hvem der eksekverer på hvad.
Spørgsmålet er hvad det så skal organiseres efter.
Den nemme reaktion er at tegne tre nye roller. Generalisten, Arkitekten, Compliance-ankeret. Det er fristende fordi roller er nemme at tale om, nemme at hyre på, nemme at sætte i et organisationsdiagram.
Det er den samme fejl produktorganisationer altid har lavet: at tro at struktur følger titler. Den fejl er værd at lade være med at gentage.
En ærlig modposition: formelle titler er ikke værdiløse. De tvinger en artikulation af ansvar der ellers forsvinder ind i det uformelle (Pollok et al., 2019), og de er ét af fire indbyrdes afhængige ben — struktur, processer, belønning, mennesker — i en velfungerende organisation (Galbraith, 1982). Pointen er ikke at titler skal afskaffes. Pointen er at de er sekundære til kompetencerne, og at de fleste organisationer har den rækkefølge omvendt.
Tre kompetenceområder skal altid være dækket i et produktteam. Hvor mange mennesker der dækker dem, og om de samme mennesker dækker flere, afhænger af konteksten.
Generalist-evne. Forståelse for bruger, forretning og produkt på én gang. Evnen til at shippe selv uden at vente på nogen. For et år siden ville du have kaldt det en urealistisk profil. I dag er det bare en person med et AI-abonnement og en god produktsans.
Arkitektur-overblik. Ikke for at skrive koden, men for at validere den. Når alle prompter sig til features i hver deres retning, skal nogen sikre at det hænger sammen. At databasen ikke ligner en losseplads. At sikkerhedsmodellen ikke er bygget på håb. Det kræver det eneste AI endnu ikke kan erstatte: overblik.
Compliance-bevidsthed. Sikkerhed, GDPR, regulering. Når kode skrives hurtigere end nogensinde, og halvdelen af teamet ikke kan forklare hvad deres egen kode gør, bliver den kedelige person i rummet pludselig den vigtigste.
Brug listen som et tjek på om teamet er i balance. Mangler ét af de tre, er du i problemer, uanset hvor mange mennesker du har.
Det her er ikke en undskyldning for at glemme kundeværdien. Marty Cagans fire risici står stadig: kan vi bygge det, vil nogen bruge det, bliver det betalt for, virker det i forretningen.
Det der ændrer sig er ikke om risiciene skal dækkes. Det er hvem der dækker dem.
Trio-modellen, PM, designer, lead engineer, holdt sammen på en præmis: at hver rolle var den eneste der kunne lave sit eget arbejde. PM’en kunne ikke kode. Engineers lavede ikke design-research. Designere tog ikke produktbeslutninger. Samarbejdet var en nødvendighed, ikke et valg.
Den præmis er væk. Enhver af de tre roller kan nu lave et udkast til de andres arbejde.
Det betyder ikke at Cagan tager fejl om at trio-modellen er værdifuld. Han har ret i at god produktudvikling kræver at de tre fagligheder mødes om beslutninger. Men begrundelsen har skiftet fundament. Det der før hang sammen på arbejdsdeling, hænger nu sammen på beslutningsdeling: på hvem der ved hvad der skal gøres.
En undersøgelse af 38 udviklere og 102 surveyrespondenter fandt at folk der tildelte AI flere fluide roller havde højere adoption og brug end folk der låste sig fast på én rolle (Zakharov et al., 2025). Pointen handler om AI, men den rækker bredere: organisering der lever af fluiditet slår organisering der lever af titler.
Det er også der diskussionen står lige nu. Cagan forsvarer trio-modellen som elevated faglighed. Andre stemmer som Benioff, Tsemirava og versatilist-tænkningen argumenterer for at rollerne flyder ud i generalister med dybde i ét område.
Min position ligger tættere på den anden lejr. Roller er nyttige som retning, ikke som mure.
Team Topologies-tænkningen fra Skelton og Pais starter med en simpel observation: afhængigheder mellem teams er det største skaleringsproblem i moderne software.
Indsigten er ikke ny. Brooks’ law er fra 1975: adding manpower to a late software project makes it later. Et empirisk studie af 58 open source-projekter med 580.000+ commits og 30.000+ udviklere bekræftede det kvantitativt: koordineringsbehov skalerer ikke-lineært med teamstørrelse, og produktiviteten falder (Scholtes et al., 2015).
Vi har vidst det i 50 år. Alligevel har danske enterprise-projekter konsekvent løst forsinkelser ved at sætte flere folk på. Deadline gled, en konsulent blev ringet ind, et nyt scrum-team blev formeret, og forsinkelsen blev værre.
Hvorfor? Fordi alternativet, at sige vi har ikke kapacitet, vi udskyder eller skærer i scope, har været organisatorisk umuligt. Output blev målt på “har vi nok mennesker på opgaven”. Så ansatte man flere.
AI fjerner undskyldningen.
Hvis tre personer kan levere det fem kunne før, og fem kan levere det ti kunne før, kan man endelig organisere sig efter den regel der altid har været rigtig: hold teams så små som muligt og afhængighederne ude.
Idéen er gammel. Forskellen er at den for første gang er praktisk realiserbar i en dansk enterprise-kontekst.
Når teams bliver små og selvkørende, hvad styrer så produktorganisationen?
Ikke at fordele opgaver. Ikke at tracke output. Ikke at koordinere release-noter. Ikke at lave kapacitetsplaner.
Produktorganisationen styres af outcomes: hvilke effekter der tæller, og hvilke trade-offs der er acceptable. Output bliver måleløst i AI-volumen, fordi alle kan producere mere. Den eneste meningsfulde måling tilbage er om noget faktisk gjorde en forskel.
En strukturpointe, før det er en personalepointe. Hvis output stadig er det der bestemmer beslutninger om budget, prioritering og retning, falder hele resten af pyramiden sammen. Outcomes er forudsætningen for alt det andet.
Tværgående koordinering forsvinder ikke. Den minimeres, men er stadig til stede.
I en AI-tid tror jeg at koordineringen flytter sig fra rolle til værdistrøm. Du organiserer dig efter den vej en kundes problem rejser fra start til løsning, og lader teams følge værdistrømmen frem for at tildele dem komponenter. Roller skal stadig findes, men de er sekundære til hvad strukturen betjener.
Forskningen er enig om at moderate koordineringsniveauer slår både minimal og maksimal koordinering (Hahn et al., 2025). I store organisationer findes der 27 forskellige mekanismer der kan bære den koordinering (Berntzen et al., 2023).
Jeg er stadig i tvivl her. Det her er ikke færdigt-tænkt. Min foreløbige holdning: følg værdistrømmen, hold koordineringen så minimal som muligt, og acceptér at noget fortsat skal koordineres på tværs.
Princippet er kort:
Færrest mulige mennesker. Færrest mulige afhængigheder.
Det er den ramme alt andet hænger på. Færre mennesker bliver kun til virkelighed hvis de få der er, har den rette kombination af kompetencer — som er emnet for næste lag.
Færre kompetencer end før. Dybere end før.
Når kulturen og strukturen er flyttet, hvad skal det enkelte menneske så være godt til? Det er det her lag handler om, ikke roller, ikke processer, men håndværket. Hvad er det folk skal kunne, og hvad er det der ikke længere differentierer?
Færre kompetencer end før. Dybere end før. Det er den korte version.
Min tese er at hovedparten af det vi kalder digital fagkundskab i dag, bliver commodity inden for få år. Ikke fordi der ikke er kvalitetsforskel mellem en god og dårlig udførelse, men fordi forskellen ikke længere er den der differentierer en virksomhed eller en karriere.
Frontend-udvikling. UI-design. Backlog-styring. Test-skrivning. Stort set al CRUD-kode og standard-integrationer. Det er ikke et spørgsmål om hvis, det er et spørgsmål om hvor hurtigt.
Benchmarks giver et nuanceret billede af hvor langt vi er. AI-agenter kan i dag løse 91% af isolerede coding-opgaver i HumanEval (Tufano et al., 2024). Men i en simuleret enterprise-kontekst med rigtige workflows, mails og kollegaer kan den bedste agent kun løse 30% af opgaverne autonomt (Xu et al., 2024). Forskellen er kontekst og kompleksitet, og den lukkes hurtigt.
Min vurdering: i dansk enterprise-virkelighed er meget af det der bygges, commodity-kompleksitet. Standardflows, integrationer, dashboards, formularer. AI klarer det allerede eller gør det inden for få år. Det betyder ikke at de tekniske roller forsvinder, det betyder at de tekniske roller koncentreres om det faktisk komplekse.
Nogle kompetencer hæver sig samtidig:
Fire mere som er værd at tilføje:
Det er ikke ti nye kompetencer. Det er måske syv-otte i alt. Men de er svære. De tager årevis at bygge op.
En udvikler kan lave et UI med AI under armen. Det er ikke det samme som at vide hvad der virker for brugeren. En PM kan kode et MVP på en eftermiddag. Det er ikke det samme som at have tålmodighed til vedligehold bagefter. En designer kan generere en strategi i Claude. Det er ikke det samme som at have greb om forretningstal.
AI fjerner kapacitetsbarrieren mellem domænerne. Den fjerner ikke smagen, instinktet eller den dømmekraft der kommer af ti års arbejde i et felt. Det er nemt at overse. Når AI kan udfylde det man ikke selv har, opstår fristelsen til at lade være med at differentiere — alle kan jo bare gå rundt i hinandens domæner. Den frihed eksisterer. Den fører til middelmådige resultater i alle tre domæner.
Hver person bør have et primært område, der hvor dømmekraften er dyb og skarp. Og en bevidst sekundær kapacitet, der hvor de kan bidrage uden at vente på andre. Det er forskellen på en T-form og en kam-form. T’et havde sin tid. Komben er bedre tilpasset en organisation hvor alle kan røre alt.
Komben gælder for alle i teamet. Produktlederens trekant er smallere. Tre kompetencer, og det er overlappet mellem dem der afgør om en produktleder er stærk i en AI-augmenteret kontekst.
Det første er domæneviden. Den specifikke forståelse af interiørdesignere, hospitalsapotekere, pensionsrådgivere. Niche-viden der ikke kan tilegnes via en LLM. Det er også derfor de startups der vinder, ofte er vertikale — de bygger for et domæne hvor viden er svær at tilegne sig udefra.
Men domæneviden alene er en faldgrube. Domæneeksperter der ikke forstår discovery, bliver de farligste personer i organisationen. De spytter features ud som ingen bruger, fordi deres egen erfaring er deres eneste prøvebænk.
Discovery-disciplin er det andet svar. Heller ikke nok alene. Du kan undersøge til evig tid uden at tage beslutninger. Build trap forværres af AI: når byggeomkostningerne falder mod nul, bliver presset for at producere endnu større. Den eneste modgift er at turde sige nej.
Trekanten:
Forskningen peger samme vej. En undersøgelse fra 2026 af 174 produktledere konkluderer at AI literacy, evaluation discipline og decision support design bliver core competencies for produktledere fremadrettet (Oladeji, 2026), netop fordi cognitive overload og decision fatigue er den primære risiko når informationsmængden stiger. Marty Cagan har i årevis argumenteret for at evnen til at sige nej er kerne i god produktledelse. Melissa Perri kalder build trap den største systemiske risiko i moderne produktudvikling. John Cutler peger eksplicit på decision quality som det nye flaskehals i AI-augmented teams.
Den nye produktleder bor i sweet spot. Hverken i prompt-evner, Figma-skills eller backlog-styring.
Når du hyrer ind, er det sweet spot du leder efter — ikke en certificering eller en titel.
Og hvad laver en AI product manager så egentlig? De jobopslag er begyndt at dukke op. Min vurdering: titlen er ny, håndværket er det her. Trekanten er svaret, ikke en separat rolle.
Der er en udbredt antagelse om at prompting snart bliver det samme som almindelig tekst, at man bare beskriver hvad man vil have, og så gør AI’en resten. Forskningen siger noget andet.
I et meget citeret studie kaldet “Why Johnny Can’t Prompt” testede forskerne 14 ikke-eksperter i at designe prompts til en LLM-baseret chatbot (Zamfirescu-Pereira et al., 2023). De fejlede systematisk, ikke fordi prompting er svært teknisk, men fordi de overgeneraliserede fra hvordan man taler til mennesker. De troede AI’en ville udfylde det de mente, men ikke skrev. Et større studie senere bekræftede at højere prompt-engineering-skills direkte forudsiger output-kvalitet (Knoth et al., 2024).
Min vurdering: prompting bliver mere naturligt over tid, modellerne bliver bedre til at gætte intent. Men det vil stadig adskille folk. Det er nærmere som skriftlig kommunikation: alle kan skrive, men nogle skriver så meget bedre at det giver dem en strukturel fordel. Det er også derfor skriftlighed står på listen ovenfor, det er den samme kompetence, bare anvendt på en ny modtager.
Når commodity-laget er stort nok, splittes feltet i to.
I bunden: en stor gruppe af mennesker der alle kan prompte og deltage i bygning. Ikke fordi de er udviklere i klassisk forstand, men fordi grænsen mellem at prompte kode og at skrive den, kollapser. Det er den brede befolkning af AI-kompetente medarbejdere.
På toppen: en lille gruppe af mennesker der kan det rigtigt svære. Designe nye AI-systemer, bygge teknisk kompleksitet der ligger ud over commodity-niveau, løse problemer der ikke er løst før. Den gruppe bliver smallere, ikke bredere.
Tilbage er en gammel mellemkategori, den klassiske udvikler der byggede CRUD og standardflows i årevis, der ikke længere har en plads. Det er der den hardeste personlige udfordring ligger.
Nogle vil kalde det A-hold og B-hold. Det handler ikke om hvem der er klogest, det handler om hvem der har et growth mindset, og hvem der har et fixed mindset.
Nuancen er vigtig. Fixed mindset er ikke karakter, det er kontekst. Folk med 15 års erfaring har ofte været belønnet for at være eksperten. Det er rationelt at klamre sig til den identitet, når den har været nyttig hele karrieren. Pointen er ikke at fixed mindset er en personlighedsfejl. Pointen er at den belønningsstruktur der skabte det, er ved at forsvinde.
Det betyder at folk der har siddet i en rolle i 15 år, kan have et stort potentiale for at flytte sig, hvis de har growth mindset. Men det kræver en forandringsvilje der gør ondt i identiteten først.
Vanens kraft er svær at ændre på, og den varierer fra rolle til rolle. Tre mønstre går dog igen på tværs:
At gemme sig bag artefakter. PRD, ticket, mockup, story point. Det at have produceret noget har været nok til at retfærdiggøre lønnen. Når AI kan producere alle artefakter, er det ikke nok længere.
At tro at man “ejer” en faglighed. Designerens “det er mit område”. Udviklerens “kun jeg forstår koden”. Når alle kan røre alt, falder territorium-tænkningen sammen.
At måle sig selv på travlhed. Folk der har levet på “jeg har 17 møder i dag og en backlog jeg skal nå”, får en eksistentiel udfordring når AI overtager både møder og backlog.
Det er identitet bundet til artefakt, territorium og ritual. Det er den hardeste at give slip på, og det vigtigste skifte for at komme videre.
Princippet er kort:
Andre færdigheder. Dybere dømmekraft.
Det er ikke alt. Men det er det der gentages dagligt, det der ikke kan automatiseres, og det der differentierer. Resten kan AI hjælpe med.
Når byggeri er gratis, bliver beslutninger flaskehalsen.
Når kulturen er flyttet, organisationen er omstruktureret og kompetencerne er pejlet om, hvordan flyder arbejdet så i hverdagen? Hvilke processer overlever, hvilke dør, og hvilke nye opstår?
Min tese: meget af det vi kalder agile praksis i dag, er bygget om at løse et koordineringsproblem der er ved at forsvinde. Mens et nyt problem, beslutningskvalitet under accelereret produktion, vokser i samme tempo. De fleste organisationer løser stadig den gamle udfordring og overser den nye.
John Cutler har skrevet skarpt om det her: AI accelererer eksisterende mønstre. Hvis dine processer var sunde, bliver de bedre. Hvis de var brækkede, bliver de værre. Hans eksempel er et team der ovenpå et i forvejen knækket stage-gate-system bolter en “Governance Agent” og AI-genererede PRD’er. Hver knækket mental model, nu med AI.
Jeg har endnu ikke set det gå galt i en dansk virksomhed, men jeg tror det kommer.
Et tidligt symptom er stillingsopslagene. Pludselig søger alle en “AI Product Manager”. Hvad er det egentlig for en rolle? En produktleder der kan noget med AI? Det er ikke svaret. At skrive AI foran rollebeskrivelserne løser ingenting — det skjuler bare at organisationen ikke har tænkt over hvad der reelt skal ændres.
De fleste organisationer der påbegynder “AI-transformation” lige nu, automatiserer deres knirkende processer i stedet for at undersøge om processerne stadig løser et reelt problem. Fælden er stillet og indbydelser er sendt ud.
Det er den åbne front for hele dette lag.
Den første konkrete fare ligger i discovery. Når prototyping er gratis, og du kan bygge en fungerende løsning på en weekend, opstår en kraftig fristelse: spring discovery over. Steve Blank har advaret mod det i årevis under titlen “fall in love with the problem, not the solution”. Den fare bliver større nu, ikke mindre.
For når en CEO eller mellemleder kan diktere en prototype og se den køre samme aften, bliver vedkommende forelsket i sin løsning. Ikke på grund af den research der underbygger den, men på grund af hastigheden hvormed den blev til. Det er en helt ny form for organisationspolitik. PM’en der argumenterer for at vente og undersøge står pludselig over for en prototype direktøren har bygget i weekenden og er forelsket i.
Der er en ekstra rynke. Når det er hurtigt at bygge, opstår også fristelsen til bare at spørge kunden hvad de vil have. “Vi spørger jo bare, og så bygger vi det.” Det lyder fornuftigt. Det er det ikke. Henry Ford sagde det for over hundrede år siden: havde han spurgt folk hvad de ville have, havde de sagt hurtigere heste. Forskellen i 2026 er at du faktisk kan bygge de hurtigere heste, på en uge, med onboarding-flow oveni.
Rob Fitzpatrick beskriver i The Mom Test hvordan gode discovery-spørgsmål handler om kundens liv og adfærd, ikke om din idé. Hvad gjorde du sidste gang slår ville du købe det her. Den disciplin bliver ikke mindre vigtig af AI. Den bliver den vigtigste.
Den dyreste feature er ikke den der tager lang tid at bygge. Det er den der aldrig skulle have været bygget.
Den anden faldgrube er mere subtil. AI gør det fristende at skrive lange spec-dokumenter og overlade resten til en agent. Du kan indtale specifikationen på en eftermiddag, give den til Claude eller Cursor, og se en hel feature blive bygget i en lang strøm.
Det ligner agile på overfladen, “vi shipper hurtigt”. Det er det modsatte. Det er vandfald i ny indpakning. Den iterative løkke, hvor vi bygger lidt, tester på brugere, lærer noget, og bygger igen, står over for sin største prøvelse i tyve år. Fordi den løkke kræver disciplin, og disciplinen er sværere når alternativet (en stor specifikation der bare bygges) er så nemt.
Det kræver hardere processer end før, ikke blødere. Korte cykler. Hyppige reviews. Eksplicit læring mellem hver iteration. Det modsatte af det man kommer til, hvis man bare lader AI’en køre med specen.
Karri Saarinen fra Linear har skrevet om en bevægelse han kalder “the disappearing middle of software work”. Pointen er at midten af softwareudvikling, at oversætte intent til implementation, har været kerne-håndværket i årevis. Det er hvor de fleste timer er blevet brugt.
Den midte bliver tyndere. AI-agenter producerer fungerende kode fra mål, kontekst og opgaver. IDE’en bliver mere af en kode-viewer end et kode-skrivende værktøj. Det betyder at presset flytter sig til de to ender:
Processerne skal designes om de to ender, ikke om midten.
For at forstå hvor hurtigt det her flytter sig, kig på hvad Scrums ceremonier faktisk gør. Daily standup er informationsrouting. Sprint planning er oversættelse fra forretningsbehov til opgaver. Refinement er kollektiv gætteleg om størrelse. Retro er et af de få møder der ikke handler om koordinering, og det er også et af de møder de fleste teams springer over.
Scrum løser et reelt problem: hvordan holder vi styr på hvem der laver hvad, og hvordan sikrer vi at information fløj mellem mennesker der ellers ikke ville snakke sammen.
Det problem er ved at forsvinde. AI er exceptionelt god til koordinering. Et system der ved hvad alle arbejder på, kan erstatte standups. Et system der forstår kapacitet og afhængigheder, kan erstatte sprint planning. MCP-servere, browser-agenter og voksende kontekstvinduer er byggestenene. Orkestreringen mangler. Den kommer.
Når den kommer, sidder Scrum med et problem: frameworket er designet til at løse et problem som et system snart løser bedre. Spørgsmålet er ikke hvordan bruger vi AI i Scrum? Det er hvad laver vi, som ikke er koordinering?
Når koordineringen automatiseres, og produktionen accelererer, bliver beslutningskvalitet det der adskiller. Forskningen er på vej til at forstå det. Et nyt studie påpeger eksplicit at speed-quality trade-off i AI-drevne beslutninger er fundamental, og at quality-first design er nødvendigt for at håndtere det (Majumdar, 2025).
Jeg taler med danske udviklere lige nu der bekræfter mønsteret i hverdagen. Et eksempel fra en bank: udvikleren sagde til mig at de bare sad og ventede på at en beslutning blev truffet, så de kunne rykke videre. De havde styr på hvad de skulle bygge. Det var beslutningen der haltede.
Det er det nye mønster. Eksekveringen er hurtigere end beslutningerne. Møder bliver til venteværelser hvor folk venter på at en leder afgiver en retning. Sprintet bliver kortere end beslutningscyklussen. Alt det der ligner produktivitet, viser sig at være kø.
Løsningen er ikke flere møder. Løsningen er bedre møder, og fundamentalt anderledes møder. Møder hvor vi specifikt træffer en beslutning, ikke hvor vi koordinerer.
En personlig observation: Scrum Master-rollen er for ofte endt som mødeindkalder. Hentet kaffe og kage, tidsstyret ståemmøder, tracket impedimenter i et spreadsheet ingen læste. Det er ikke rollen der har svigtet — det er udførelsen. De Scrum Masters jeg har arbejdet tæt med, har sjældent taget ansvar for outcome og transformation. Så fyldte de tiden ud med koordineringsritualer.
Den superkraft der kommer tilbage er beslutningsfacilitering. Håndtere konflikter, samle uenighed til beslutning, presse en gruppe til at vælge i stedet for at snøre. Den evne har altid været værdifuld, altid undervurderet. Den bliver kritisk nu.
Det er coaching, mediation og beslutningskunst i én person. Det er ikke en ny rolle — det er Scrum Master-rollen forsvarligt udført. Den der vil fortsætte i rollen efter koordineringen er automatiseret, skal mestre det. Det er forskellen på at blive overflødig og at blive uundværlig.
Jeg er forsigtig med at være for kategorisk her. Mønsteret går ud over Scrum: enhver proces der primært er koordinering, er truet. Enhver proces der lever af refleksion eller beslutning, bliver vigtigere. Min nuværende vurdering:
Decision quality handler ikke kun om hvor godt du beslutter. Det handler om hvornår.
Et MIT Sloan-studie fra 2025 fulgte 579 teams gennem en intern innovationskonkurrence i en Fortune Global 500-virksomhed (Cromwell & Harvey, 2025). Forskerne forventede at teams der definerede problemet tidligt og klart, ville implementere flest løsninger. Det modsatte viste sig.
Teams der startede med høj problemklarhed havde 50% implementation rate. Teams der startede uklart og opdagede problemet over tid, ramte 80%+. Mekanismen er to-foldet: bredere idé-eksploration og dybere team-commitment, fordi folk er mere committed til ideer de selv har formet.
Men — og det er pointen — kaos er ikke svaret. Teams der ikke konvergerede inden 50%-mærket, faldt til 25% implementation rate. Samme studie. Lederens job er at skifte gear: divergent ledelse i første halvleg, konvergent i anden.
Det matcher godt det jeg ser i praksis. De værste produktbeslutninger jeg har været med til, faldt i to grøfter: enten besluttede vi for tidligt (vi havde ikke forstået problemet) eller for sent (vi diskuterede stadig retning da vi skulle eksekvere). AI gør begge grøfter dybere. Når byggeomkostningerne falder, bliver det fristende at låse for tidligt — fordi vi kan bygge. Og det bliver fristende at udskyde — fordi vi kan generere endnu en variant.
Den nye dømmekraft er ikke bare hvad du beslutter. Det er hvornår. Førsthalvleg: hold problemet åbent længere end du synes er rart. Andenhalvleg: luk det ned hårdere end du synes er rart.
Princippet er kort:
Tid til læring. Tid til levering. I rigtig rækkefølge.
Det er den modsatte instinkt af det de fleste agile-implementeringer er bygget på. De er bygget om hastighed til levering. Det var den rigtige optimisering da byggeri var dyrt. Det er den forkerte optimisering nu.
Forskningen peger samme vej. Et fem-årigt multi-site studie af large-scale agile i en multinational telecom-virksomhed identificerer seks pitfalls hvor agile-praksis aktivt skader individuel læring, ideation og exploitation (Annosi et al., 2020). Rita McGrath formulerer det skarpere endnu i Journal of Management: i den digitale økonomi vinder den der lærer hurtigst (McGrath, 2023).
Når byggeri er gratis, er den eneste meningsfulde måling hvor hurtigt I lærer noget. Med ét forbehold: hurtig læring kan ende som mange små eksperimenter på det lette at observere. Felin et al. (2020) advarer mod præcis dén faldgrube — at læringscyklen bliver så hurtig at hypoteserne aldrig bliver dristige. Det skift fra hastighed til levering til hastighed til læring er ikke et frikort til kun at lære småt. Det er et krav om at lære om det der faktisk afgør produktet.
Alt det andet — sprints, ceremonier, ritualer — skal designes om det.
Det mindst interessante lag, og det de fleste organisationer starter med.
De fleste AI-transformationer starter her. “Vi rullede Copilot ud.” “Vi har Cursor-licenser til alle.” “Vi bruger ChatGPT Enterprise.”
Det er den hurtigste vej til en fejlslagen transformation.
Værktøjer er det nemmeste at tale om, det nemmeste at indkøbe, og det nemmeste at retfærdiggøre på et budget. Og de er det mindst betydningsfulde af de fem lag. Hvis de fire ovenfor, kultur, organisation, kompetencer, processer, ikke er flyttet, så er værktøjer ligegyldige. Du får bare hurtigere dårlige outputs.
Det er derfor laget kommer sidst. Og det er derfor det her afsnit bevidst er kortere end de andre.
Det er værd at sige højt: forskellene mellem de store AI-modeller er marginale i en produktkontekst. Claude, GPT, Gemini: de leverer alle 90% af det de fleste teams skal bruge. Forskellene betyder mest når man løser de sidste 10%.
Det samme gælder coding-værktøjer. Claude Code, Cursor, Copilot, Windsurf: de gør grundlæggende det samme. De adskiller sig på UX, integration og pris. Ikke på om de virker.
Det betyder at valget af værktøj er nemt. Det er ikke der differentieringen ligger.
Hvor differentieringen ligger:
Det er de tre ting der adskiller en organisation der får meget ud af AI fra en der får lidt. Ikke om de valgte Cursor eller Claude Code.
For en produktorganisation der vil arbejde AI-først, ser et fungerende grundsetup nogenlunde sådan ud:
Det er ikke en udtømmende liste. Men det er det minimum der skal være på plads, før du kan tale om at være AI-først.
Den fejl der gentages i hver enterprise-AI-transformation jeg har set, er denne: at vælge et værktøj og kalde det transformation.
“Vi har rullet Copilot ud til 500 udviklere” er ikke en transformation. Det er en licensaftale. Hvad gør de 500 udviklere anderledes nu? Hvilke beslutninger tages anderledes? Hvilke processer er ændret? Hvilke kompetencer er styrket?
Hvis svaret er vi måler velocity og det stiger lidt, så er det ikke transformation. Det er produktivitetsboost på en eksisterende model.
Real transformation kræver at de fire lag ovenover er i bevægelse. Værktøjet er bare det redskab der gør de andre lag mulige. Ikke det der driver dem.
Fordi feltet bevæger sig så hurtigt, er det vigtigste princip ved værktøjsvalg ikke hvilket værktøj er bedst nu, men hvor nemt er det at skifte.
Det betyder:
Det er de samme principper man har brugt i softwarearkitektur i 30 år: undgå tight coupling, byg på interfaces, hold dine data fri. AI ændrer ikke på det. Det forstærker behovet.
For at gøre det konkret: mit eget setup pr. dato er Claude Code som primær kode-assistent, Cursor som backup, MCP til kontekst-integration mod Notion og andre datakilder, Loops til email-automatisering, og Cowork som browser-agent til de opgaver der kræver klikker rundt på websites.
Det er ikke en anbefaling. Det er en øjebliksrapport. Om seks måneder er halvdelen af det formentlig skiftet ud. Pointen er præcis at det skal kunne ske uden at hele setuppet bryder sammen.
Princippet er kort:
Vælg principper. Skift værktøjer.
Principperne, hvad I beslutter at automatisere, hvilke kontekst I deler med AI, hvordan I evaluerer outputs, hvordan I håndterer compliance, er det der varer. Værktøjerne er det der skiftes ud hver sjette måned.
Hvis du har det rigtige princip, kan du bruge ethvert værktøj. Hvis du ikke har det, gør det ingen forskel hvilket værktøj du valgte.
Hvis nogle af begreberne i dette lag er nye for dig, har jeg samlet en kort ordliste her: /playbook/ordbog.
Research-arbejdet bag denne playbook er understøttet af consensus.app — en AI-drevet søgemaskine til evidensbaserede svar i videnskabelige artikler. Alle citater og findings er verificeret mod kildernes originaltekst før brug.