Sådan får AI produktchefer til at bevæge sig ud over deres rolle

Rejsen til produktledelse

Jeg har været produktchef i over 15 år nu. Tidligere i min karriere lavede jeg alt muligt andet, herunder design, salg, rådgivning, marketing og endda kodning tilbage i PHP-dagene — adr.

Jeg begyndte med produktledelse, fordi jeg virkelig nød at bevæge mig mellem forskellige emner og samarbejde med brugere, udviklere, ledere osv. Jeg havde også et ret godt øje for design og en god fornemmelse for produktkvalitet. Efter en masse research fandt jeg ud af, at der var en rolle, der passede rigtig godt til det — produktledelse. Så jeg søgte min første PM-stilling, og det er sådan, jeg kom hertil.

Jeg har arbejdet inden for alle mulige vertikaler: B2B, B2B2C, detailhandel og forbrugersoftware. Jeg begyndte at undervise i produktledelse hos General Assembly for over et årti siden, og derefter lancerede jeg mine egne kurser online på egen hånd med Udemy og senere LinkedIn Learning. I dag har jeg tilsammen over 1,6 millioner studerende på begge platforme. Og jeg har talt på en lang række konferencer om produkt- og projektledelse, blandt andet i samarbejde med Google, hvor jeg underviste i et produktkursus i Kyiv, Ukraine.

I øjeblikket arbejder jeg med Probably.dev, en deterministisk dataagent-app finansieret af a16z. Vi er et lille team, så jeg er ikke kun PM, men også ingeniør, salgsrepræsentant, designer osv.

Vores app er en indbygget desktopapp, der udfører deterministisk datavidenskab på ph.d.-niveau med understøttende visualiseringer for direkte at besvare enhver given forespørgsel på naturligt sprog, uden at følsomme data forlader din maskine. Du kan tænke på den som en "datapilot". Vi arbejder direkte oven på datavarehusenes skemaer (f.eks. BigQuery, Snowflake, Clickhouse osv.) samt med lokale filer som CSV, JSON og Parquet. Alle de svar, vores agent giver, kan spores og genskabes af et menneske, så typiske hallucinationer fra LLM'er er ikke et problem. Det er ikke bare endnu en SQL-generatoragent, og vi kan håndtere milliarder af rækker/kolonner og komplekse skemaer med titusindvis af tabeller.

You should also read

• Eisenhower-matricen: Sådan prioriterer du opgaver på en smart måde

• Tips til at opbygge din Slack-profil

• Sådan mestrer du ressourcestyring i projektledelse

Sådan hjælper AI teams med at nå mere pr. person

AI har haft stor indflydelse på mit arbejde. Jeg plejede at være "bare en PM". Det lyder fjollet, fordi PM'er laver så meget, men nu kan jeg også bidrage til alt muligt andet, såsom udvikling og salg. Og det hjælper teamet med at komme hurtigere frem. I takt med at AI forandrer projektledelse, bliver de traditionelle rolleafgrænsninger mere flydende.

Tidskrævende opgaver som research og analyse går meget hurtigere, og den sparede tid giver mulighed for langt mere direkte kontakt og kommunikation med interessenter. Det muliggør også hurtigere beslutningstagning.

En stor del af en PM's arbejde består i at sikre, at alle andre kan udføre deres arbejde effektivt, så når jeg selv kan gøre endnu mere, kan vi nå meget mere pr. person. Denne menneske-AI-hybridtilgang er ved at blive afgørende for moderne leveringsteams.

Hvorfor en dyb forståelse af AI gør det muligt for produktchefer at gøre næsten hvad som helst

Jo mere jeg går ind i det, desto mere indser jeg, hvor stejl læringskurven faktisk er for at bruge AI/LLM effektivt og produktivt, samt for at få det til at passe ind i de arbejdsgange, som folk omkring dig eller på dine teams foretrækker. Det styrker yderligere min overbevisning om, at alle i en virksomhed skal være fortrolige ikke kun med LLM'er generelt og de tilgængelige modeller, men også med de mange økosystemværktøjer omkring dem, såsom MCP'er, modaliteter som CLI og GUI og vigtigst af alt transformerarkitekturen. For dem, der ønsker at uddybe deres forståelse, kan det være værdifuldt at udforske bøger om AI-projektledelse for at få indsigt i, hvordan disse teknologier implementeres effektivt.

At arbejde godt med AI i det enorme hav af AI-skrammel, der findes i disse dage, hvad enten det er indhold eller værktøjer, er en færdighed, du er nødt til at opøve, og det kan kun gøres gennem erfaring. Du skal kunne forstå, hvordan LLM'er fungerer, og hvad de er eller ikke er gode til, for at få det bedste ud af dem og præstere optimalt.

Mange "banebrydende" SaaS-produkter og -værktøjer derude virker som gode løsninger — for eksempel til at lave PRD'er — men jeg har fundet ud af, at 99 % af alt det, du har brug for at gøre, kan du selv gøre billigere, hurtigere, mere tilpasset og langt bedre. Altså så længe du har en forståelse af ovenstående begreber og færdighederne til at bruge LLM'er effektivt.

Det er ligesom i de der tv-reklamer, hvor en person gør noget simpelt, hvorefter de viser, hvor "svært" det er, og forsøger at sælge dig et helt apparat til at løse det lille problem. I stedet for at skære en banan i stykker med en kniv som et normalt menneske vil de for eksempel sælge dig en bananformet skærer, der skærer alle stykkerne i én bevægelse...

Kniven er en LLM, og bananskæreren er en ligegyldig nicheapp. Lær at bruge den forbandede kniv. Køb en af god kvalitet, brug den, lær den at kende, og hold op med at købe dumme ting, fordi tech-Twitter fortæller dig, at en tilfældig SaaS-app lige har »gjort designere overflødige« eller »dræbt kodning«.

Der er grundlæggende ikke noget, du ikke kan gøre med en LLM i en CLI, webbrowser og fra tid til anden et åbent, formålsuafhængigt automatiseringsværktøj som n8n.

Spar dine penge, og lær at bygge ting, der afspejler visdommen fra dine indlærte erfaringer, i stedet for at acceptere outputtet fra et SaaS-værktøj, der er dukket op fra den ene dag til den anden.

Det eneste tidspunkt, hvor dette ikke gælder, er ved værktøjer med ét formål, som specifikt fokuserer på at løse problemer, hvor transformer-LLM-arkitekturen i almindelige frontmodeller (dvs. ikke finjusterede modeller) grundlæggende har fejl. Det gælder for eksempel datavidenskab eller matematik i stor skala.

Sådan kommer du i gang med at lære om AI som produktchef

Det bedste ved LLM'er er, at du kan spørge dem, hvordan du lærer om dem. Hvis du er en visuel lærende som mig, er YouTube prikken over i'et, og der findes masser af gode ressourcer om AI og LLM'er.

Hvis jeg skulle begynde forfra, ville jeg gribe læringen sådan an: Fortæl en LLM, at du gerne vil lære om alt inden for AI/LLM-området, tilpasset dit tekniske forståelsesniveau. Du kan endda instruere den i at stille dig stadig mere tekniske spørgsmål for at forstå dit nuværende færdighedsniveau inden for alt i AI/LLM-området, begyndende med det grundlæggende. Og når du når til et punkt, hvor du er på dybt vand, kan du få den til at anbefale emner, du bør lære, lige fra det grundlæggende i transformerarkitekturen til, hvordan en app som ChatGPT fungerer.

Idéen er at få en liste over emner, du skal lære, og derefter søge efter hvert af dem på YouTube for at finde en video, der kan hjælpe dig med at forstå emnet.

Her er et eksempel på en prompt:

Fungér som min vurderer af mit »udgangspunkt« inden for AI/LLM.

Stil mig op til 12 spørgsmål (en blanding af lette og tekniske) for at vurdere:

• min generelle tekniske fortrolighed (kodning, data, API'er)
• min forståelse af, hvordan LLM'er fungerer (modelmodaliteter som CLI og grafiske brugergrænseflader samt tokens, kontekst, hallucinationer osv.)
• mit kendskab til moderne mønstre for LLM-apps (RAG/indlejringer, agenter/værktøjsbrug)
• min evne til at vurdere kvalitet (evalueringer, verificering)
• min bevidsthed om risici (privatliv, prompt-injektion osv.)
• min bevidsthed om AI's begrænsninger (gode kontra dårlige anvendelsesområder for LLM'er, nøjagtighed, den ukontrollable karakter af LLM-output osv.)

Når jeg har svaret, må du KUN vise:

• 5–10 YouTube-emner med størst effekt, som jeg bør lære derefter, sorteret efter prioritet. Hvert punkt skal være en YouTube-søgesætning (ikke en sætning) + 5–10 ord om »hvorfor det er vigtigt«.

Begynd med dine spørgsmål nu.

Hvilke AI-færdigheder produktchefer bør lære først

Efter min mening er det vigtigt at forstå, hvor og hvordan du kan bruge LLM'er. Med det mener jeg at forstå, at de kan være i en app, i din computerterminal eller i kode, der fungerer i en automatisering via MCP'er eller API'er.

Derudover skal du forstå, at de er:

1. Ikke-deterministiske, ukontrollable og fejlbehæftede
2. Aldrig til at stole på, når det gælder præcise oplysninger, især ikke ved kritiske beslutninger
3. Mulige at automatisere kreativt for at mindske virkningerne af de to foregående punkter, afhængigt af din anvendelse

Det klassiske eksempel, jeg bruger, er, at du aldrig skal bruge en LLM til at skrive en hel opgave for dig, men det er helt fint at bede den om at liste nogle idéer til retninger, du kan gå i, hvis du sidder fast i forhold til, hvad du skal skrive som det næste. Med andre ord er LLM'er gode supplementer til det menneskelige sind, men det er en mørk vej at begive sig ned ad, når du forsøger at få dem til at tænke alt i stedet for det menneskelige sind.

Det sidste, jeg vil nævne her, er, at mens du lærer ovenstående begreber, skal du selv afprøve dem. Hvis du for eksempel lærer, hvordan prompt engineering fungerer, bør du stille det samme spørgsmål til en LLM formuleret på to forskellige måder for at se forskellen i outputtet. Lær aldrig uden samtidig at øve dig på det, du lærer.

Hvorfor du ikke bør automatisere værdifulde kundeinteraktioner med AI

Når du har lært det, du har brug for at vide, kan du gøre stort set hvad som helst. Men det betyder ikke, at du bør.

For en virksomhed i den tidlige fase med et premiumprodukt ser kundeinteraktion og salg »ud til« at være de områder, der er mest oplagte til AI og automatisering. Men i praksis har jeg fundet ud af, at en menneskelig kontakt er helt nødvendig. Personligt synes jeg, at interaktionen med brugere eller potentielle kunder er en stor værdiskabelse for begge parter, og jeg har ikke engang lyst til at forsøge at automatisere den.

Som produktchef ville du gøre dig selv en bjørnetjeneste ved overhovedet at distancere dig fra at tale med brugerne. Jo mere du personligt taler med dem med din egen stemme, desto mere information får du, og desto mere tillid skaber du.

Hvorfor det er svært — men muligt — for produktchefer at bidrage til kode

Så jeg er forsigtig med, hvad jeg bruger AI til, men jeg bruger det meget.

For eksempel er der altid et intenst kapløb om at rette fejl lige før en udgivelse til produktion. Typisk ville udviklerne og QA-teamet i en større virksomhed stå for denne type sidste finpudsning. Den erfarne produktansvarlige ville naturligvis være orienteret, men ville også planlægge de næste skridt og strategier for overvågning af udgivelsen, indsamle brugerfeedback, forberede flere cyklusser frem eller indsamle målinger, når funktionen eller produktet var lanceret.

Da jeg i øjeblikket arbejder i en mindre virksomhed, har det været en afgørende fordel for mig at kunne hjælpe med at nedkæmpe fejl sammen med udviklerne, og det har jeg kun kunnet gøre ved hjælp af AI/LLMs.

Jeg har altid været involveret i QA af produkter og funktioner i løbet af min karriere, men jeg har sjældent haft mulighed for at gå helt ned i maskinrummet og rette en fejl, der involverer kodeændringer gennem hele stakken.

Erfarne teknikere vil forstå, at udviklere er meget omhyggelige med deres kodebaser og kodestandarder. Så selv hvis du teknisk set ved, hvordan du retter en bestemt fejl, skal du også kende konteksten omkring kodestandarderne og personlighederne på udviklingsteamet samt forstå de udviklere, der har arbejdet på hver del af koden. Derfor er det flere niveauer fra nemt at rette nogle fejl, selv hvis du ved hvordan, og de fleste udviklere ville afvise din pull-anmodning med rettelsen.

Takket være AI har jeg dog ikke kunnet bidrage til koden ved at skubbe direkte til main, men også afhjælpe de sekundære kulturelle faktorer, der er involveret.

Sådan bygger du en AI-agent, der sikkert kan bidrage til din kodebase

Min første tilgang var at etablere et Markdown-dokument med kodestandarder ved at få en agentsværm i Claude Code til at udforske hele repositoriet for de foregående seks måneder og tilegne sig kodestilen, repoets Claude.md-fil og, vigtigst af alt, alle kommentarer på GitHub-diffs, konfliktløsninger, commits og redigeringer af PR'er.

Derfra havde jeg et ret solidt dokument med kodestandarder, som jeg udbyggede ved at omdanne det til et sæt færdigheder og kommandoer i Claude Code, der tog al kode, jeg genererede til en fejlrettelse, og tilpassede den til de kodestandarder, teamet allerede havde implementeret i kodebasen. Derefter oprettede jeg en anden underagent, som brugte hook-mekanismer sammen med GitHub, og som jeg også manuelt kunne udløse for at gennemgå den kode, jeg havde skrevet, samt kommentarerne eller rettelserne, og derefter indarbejde alt dette som en tilføjelse til dokumentet med kodestandarder.

Efterhånden kunne den kode, jeg genererede til en given rettelse, efter blot nogle få PR'er meget nemt oversættes til den type kode, vi gerne vil se i kodebasen, via et simpelt Markdown-dokument, der i praksis var en løbende forbedret og selvlærende vejledning i kodestil, udløst gennem flere cron-job og automatiseringer med Claude Code.

Agenten er så god nu, at jeg kan flette direkte til main.

Sådan kan små produktteams øge deres agilitet

Det er et godt eksempel på, hvordan jeg går ud over den traditionelle produktchefrolle. Men det kræver gode processer at gå ud over traditionelle roller.

Vi har en velbearbejdet og tagget backlog i Linear, og vi holder obligatoriske møder mandag, onsdag og fredag morgen. På dage uden et synkroniseringsmøde holder vi os ajour med en daglig statusopdatering i Slack. Al anden prioritering og diskussion foregår i realtid via Slack.

Det er måske ikke den bedste løsning for større virksomheder, men du ville blive overrasket over, hvor godt det fungerer til dette formål, og hvor agilt det holder os. Jeg plejede at bruge Google Drive, regneark, dokumenter, præsentationer og en million andre apps. Nu kan vi som et lille team klare os med GSuite, Slack, Linear og GitHub.

Enkle produktstyringsmetoder er vigtige i dette rum, der konstant udvikler sig med AI/LLM. Der kan ske noget alle ugens dage med brugerfeedback eller udgivelser fra potentielle konkurrenter, som vi hurtigt skal holde øje med og prioritere i forhold til.

Sådan tvinger AI produktteams til at gentænke ritualer

Når det kommer til ritualer, er den største gentænkning, at det nu virkelig er et cirkulært, uendeligt ritual i stedet for noget med stagnerende dokumenter, som du hele tiden skal oprette og referere til.

Omfanget begynder som en præcis Linear-ticket med varierende detaljeringsgrad, hvorefter jeg bruger AI til at stressteste den for tvetydighed, kanttilfælde og mulige rækkefølger, og jeg strammer den op, indtil den kan leveres i den mindst mulige del.

For os på et lille distribueret team foregår koordineringen hovedsageligt asynkront — en kort Slack-tråd, der afsluttes med en klar beslutning og de næste handlinger, mens enkle daglige statusmøder håndteres af Geekbot. Der er dog stadig stor værdi i tre eller fire teammøder om ugen, hvor vi kan udvikle ideer sammen og styrke moralen.

Det er ved valideringen, at jeg er blevet mere stringent, ikke mindre. LLM'er genererer typisk overbevisende nonsens, hvis man ikke ved, hvordan man bruger dem korrekt, så hver funktions- eller appændring får en lille evalueringsramme — realistiske input, forventede resultater og fjendtlige testtilfælde — som AI kan hjælpe med at udarbejde, men som jeg selv vil kuratere og teste.

Udførelsen er derefter blot Linear + Claude Code + selvhostet Posthog-analyse. Udgiv, observer, juster, og hold processen hurtig, fordi teknologimarkedet i disse dage ændrer sig i et tempo, der næsten virker time for time.

Hvorfor en minimalistisk, AI-først-værktøjsstak er bedst

Så her er min grundlæggende PM-værktøjsstak:

• GSuite
• Slack
• Geekbot-Slackbotten (til daglige statusmøder)
• Linear
• VSCode
• CLI-baseret LLM (Claude Code i vores tilfælde)

Hvorfor Linear? Det indeholder det mest nødvendige. Det er kraftfuldt nok til at imødekomme næsten alle de krav, et projektteam kan have, men enkelt nok til at være tilgængeligt. Det er anti-JIRA. Og vigtigst af alt har det nem integration med GitHub og Slack, som er der, hvor ingeniører arbejder til at begynde med. Det er enkelt, letvægtigt og tilfører minimal ekstra friktion for ingeniører, når de skal holde styr på opgaver eller opdatere dem. Det kan også udvides ekstremt meget, så du kan gøre smarte ting som at få din LLM i din CLI til automatisk at forsøge at rette en fejl, når den rapporteres i en kladde-PR — før et menneske overhovedet begynder at se på den.

Der er ikke brug for andet. Alt slags arbejde, der er nødvendigt uden for dette, kan udføres med open source-værktøjer i terminalen.

Coles foretrukne AI-værktøj til personlig produktivitet

På et personligt niveau uden for teamet er jeg fuldstændig besat af Raycast til produktivitet. Det er den ultimative hurtige adgang til en fuldt tilpasningsapp, en ultralet app, der erstatter den forfærdelige "Spotlight"-app på Mac eller "Windows"-tasten i Windows. Du vil reducere din brug af musen med 75 % til de fleste ting. Du kan integrere næsten enhver app med deres eksisterende integrationer eller nemt oprette dine egne — du skal bare bede Claude Code om at lave en udvidelse til dig!

Hvis jeg vil have teksten fra et billede, jeg ser, over på mit udklipsholder, trykker jeg på Raycast-genvejstasterne, skriver "OCR" og trykker på Enter. Det aktiverer skærmbilledværktøjet cleanshotX OCR, og så har jeg teksten fra ethvert billede på under fem sekunder. På samme måde kan jeg trykke på genvejen, skrive "Ask spotify" og derefter skrive en sætning på naturligt sprog som "giv mig noget god kodningsmusik med høj energi", hvorefter min sætning fortolkes gennem en LLM, musikmærker og -egenskaber søges i Spotify API, og en playliste med den type musik, jeg netop bad om, startes øjeblikkeligt i Spotify.

Anvendelsesmulighederne er uendelige. Du skal bare downloade det, aktivere AI via enten dine egne API-nøgler eller deres abonnement og gennemgå de bedste udvidelser på deres websted for at finde ting, du tror vil være nyttige for dig. En fuldstændig omvæltning.

Hvorfor produktledelse og ingeniørarbejde begynder at overlappe

Snart vil de fleste ingeniører, der arbejder med funktioner, blive tvunget til at begynde at tænke og træffe beslutninger som produktchefer, og produktchefer bliver nødt til at lære nok om maskinlæring, neurale netværk, LLM'er og forskellige arkitekturer til at komme så tæt som muligt på at være en ingeniør, der bruger LLM'er, uden faktisk at være det. Denne transformation afspejler modige tilgange til AI-integration, som omformer traditionelle roller.

Der er naturligvis mange forbehold og områder, hvor dette ikke vil gælde, men generelt vil Venn-diagrammet for alle tidligere roller i en virksomhed, fra salg til marketing, produkt og ingeniørarbejde, uundgåeligt nærme sig hinanden, og meget få færdigheder vil være eksklusive for én bestemt rolle.

Sådan undgår du den uundgåelige eksistentielle krise, når AI omformer produktarbejdet

Her er mit råd: Prøv at undgå den uundgåelige eksistentielle krise, som du vil blive fristet til at gennemgå, mens denne teknologiske æra fortsætter med at udvikle sig.

Fokuser i stedet på de færdigheder, dit sind har, og som du har udviklet gennem erfaring. LLM'er kan generere indhold, men de er virkelig dårlige til at udvise god dømmekraft.

Svar er massevarer nu, så det er en færdighed at stille AI unikke, erfaringsspecifikke spørgsmål. Desuden er det egentlige intellektuelle arbejde at opdage det rigtige spørgsmål at stille i sit eget sind.

Følg med

Du kan følge Cole på X og på hans personlige websted, mens han fortsætter med at udfordre, hvad der er muligt for PM'er. Og tjek Probably.dev ud!

Der kommer flere ekspertinterviews på The Digital Project Manager!