Hvordan KI flytter produktledere utover rollen sin

Veien til produktledelse

Jeg har vært produktleder i over 15 år nå. Tidligere i karrieren gjorde jeg alt annet jeg kunne, inkludert design, salg, rådgivning, markedsføring og til og med programmering i PHP-dagene — æsj.

Jeg begynte med produktledelse fordi jeg likte veldig godt å veksle mellom ulike temaer og kommunisere med brukere, utviklere, ledere og så videre. Jeg hadde også et ganske godt blikk for design og en god sans for produktkvalitet. Etter mye undersøkelser fant jeg ut at det fantes en rolle som passet veldig godt til dette — produktledelse. Så jeg søkte på min første PM-rolle, og det var slik jeg havnet her.

Jeg har jobbet innen alle mulige bransjer: B2B, B2B2C, detaljhandel og forbrukerprogramvare. Jeg begynte å undervise i produktledelse ved General Assembly for over ti år siden, og etter det lanserte jeg mine egne kurs på nett uavhengig av andre, med Udemy og senere LinkedIn Learning. I dag har jeg over 1,6 millioner studenter til sammen på begge plattformene. Og jeg har holdt innlegg på mange konferanser om produkt- og prosjektledelse, blant annet i samarbeid med Google, der jeg underviste i et produktkurs i Kyiv i Ukraina.

For tiden jobber jeg med Probably.dev, en deterministisk dataagent-app finansiert av a16z. Vi er et lite team, så jeg er ikke bare PM, men også ingeniør, selger, designer og så videre.

Appen vår er en innebygd skrivebordsapp som utfører deterministisk datavitenskap på doktorgradsnivå, med tilhørende visualiseringer, for å svare direkte på alle gitte spørsmål i naturlig språk uten at sensitive data forlater maskinen din. Du kan tenke på den som en «datakopilot». Vi arbeider direkte oppå skjemaer i datavarehus (f.eks. BigQuery, Snowflake, Clickhouse og så videre), samt med lokale filer som CSV, JSON og Parquet. Alle svarene agenten vår gir, kan spores og gjenskapes av et menneske, så typiske hallusinasjoner fra store språkmodeller er ikke et problem. Det er ikke bare enda en SQL-generatoragent, og vi kan håndtere milliarder av rader/kolonner og komplekse skjemaer med titusenvis av tabeller.

You should also read

• Eisenhower-matrisen: Slik prioriterer du oppgaver på en smart måte

• Tips for å bygge Slack-profilen din

• Slik mestrer du ressursstyring i prosjektledelse

Hvordan AI hjelper team med å få gjort mer per person

AI har hatt stor innvirkning på arbeidet mitt. Før var jeg «bare en PM». Det høres kanskje dumt ut, fordi PM-er gjør så mye, men nå kan jeg bidra med alt mulig annet også, som utvikling og salg. Og det gjør at teamet kommer raskere fremover. Når AI endrer prosjektledelse, blir de tradisjonelle rollegrensene mer flytende.

Tidkrevende oppgaver som research og analyse går mye raskere, og tidsbesparelsene gir rom for langt mer direkte kontakt og kommunikasjon med interessenter. Det legger også til rette for raskere beslutningstaking.

En stor del av jobben til en PM er å sørge for at alle andre kan gjøre jobbene sine effektivt, så når jeg selv kan gjøre enda mer, kan vi få gjort mye mer per person. Denne menneske–AI-hybridtilnærmingen blir stadig viktigere for moderne leveringsteam.

Hvorfor en dyp forståelse av AI lar produktledere gjøre nesten hva som helst

Jo mer jeg setter meg inn i dette, desto mer innser jeg hvor bratt læringskurven faktisk er for effektiv og produktivitetsfremmende bruk av AI/store språkmodeller, samt for ferdigheten med å tilpasse dette til arbeidsflytene som menneskene rundt deg eller i teamene dine foretrekker. Dette forsterker ytterligere overbevisningen min om at alle i et selskap må ha inngående kjennskap ikke bare til store språkmodeller generelt og modellene som er tilgjengelige, men også til de mange verktøyene i økosystemet rundt dem, som MCP-er, grensesnitt som CLI og GUI, og viktigst av alt transformerarkitekturen. For dem som ønsker å fordype forståelsen sin, kan det å utforske bøker om AI-prosjektledelse gi verdifull innsikt i hvordan disse teknologiene kan tas i bruk på en effektiv måte.

Å arbeide godt med AI i det enorme havet av AI-slurv som finnes i dag, enten det gjelder innhold eller verktøy, er en ferdighet du må utvikle, og det kan bare gjøres gjennom erfaring. Du må forstå hvordan store språkmodeller fungerer, og hva de er eller ikke er gode til, for å få best mulig utbytte av dem og prestere optimalt.

Mange «banebrytende» SaaS-produkter og verktøy der ute virker som gode løsninger — for eksempel til å lage PRD-er — men jeg har erfart at 99 % av alt du trenger å gjøre, kan gjøres selv, billigere, raskere, mer tilpasset og langt bedre. Det vil si så lenge du har forståelse for konseptene ovenfor og ferdighetene som trengs for å bruke store språkmodeller effektivt.

Det er som i de TV-reklamene der en person gjør noe enkelt, før de viser hvor «vanskelig» det er, og prøver å selge deg en hel innretning for å løse akkurat dette lille bruksområdet. I stedet for å skjære en banan i biter med en kniv som et normalt menneske, vil de for eksempel selge deg en bananformet skjærer som kutter alle bitene i én bevegelse …

Kniven er en LLM, og bananskiveren er en søppelapp for en snever nisje. Lær deg å bruke den forbannede kniven. Kjøp en av god kvalitet, bruk den, lær deg den, og slutt å kjøpe idiotiske ting fordi teknologifol på Twitter forteller deg at en eller annen tilfeldig SaaS-app nettopp «gjorde designere overflødige» eller «tok knekken på programmering».

Det finnes i praksis ingenting du ikke kan gjøre med en LLM i en CLI, nettleser og nå og da et åpent, formålsuavhengig automatiseringsverktøy som n8n.

Spar pengene dine og lær deg å bygge ting som gjenspeiler visdommen fra erfaringene du har opparbeidet deg, i stedet for å akseptere resultatet fra et SaaS-verktøy som dukket opp over natten.

Den eneste gangen dette ikke gjelder, er for verktøy med ett enkelt formål som spesifikt fokuserer på å løse problemer der transformer-LLM-arkitekturen i vanlige frontmodeller (altså modeller som ikke er finjustert) har iboende svakheter. For eksempel storskala datavitenskap eller matematikk.

Slik kommer du i gang med å lære om AI som produktleder

Det beste med LLM-er er at du kan spørre dem hvordan du skal lære om dem. Hvis du er en visuell type som meg, er YouTube prikken over i-en; det finnes masse gode ressurser om AI og LLM-er der.

Hvis jeg skulle begynt på nytt, ville jeg gått frem slik: Fortell en LLM at du ønsker å lære om alt innenfor AI/LLM-området, tilpasset ditt nivå av teknisk forståelse. Du kan til og med be den stille deg stadig mer tekniske spørsmål for å forstå ditt nåværende ferdighetsnivå innenfor AI/LLM-området, med utgangspunkt i det grunnleggende. Og når du kommer til et punkt der du er på dypt vann, kan du be den anbefale emner du bør lære, fra det grunnleggende i transformer-arkitekturen og helt til hvordan en app som ChatGPT fungerer.

Ideen er å få en liste over emner du bør lære, og deretter søke etter hvert av dem på YouTube for å finne en video som kan hjelpe deg å forstå emnet.

Her er et eksempel på en instruks:

Funger som min vurderer av utgangspunktet mitt innen AI/LLM.

Still meg opptil 12 spørsmål (en blanding av enkle og tekniske) for å kartlegge:

• min generelle tekniske trygghet (programmering, data, API-er)
• min forståelse av hvordan LLM-er fungerer (modellmodaliteter som CLI og GUI-er, samt token-er, kontekst, hallusinasjoner osv.)
• min kjennskap til moderne mønstre for LLM-apper (RAG/embeddings, agenter/verktøybruk)
• min evne til å vurdere kvalitet (evalueringer, verifisering)
• min bevissthet rundt risikoer (personvern, instruksjonsinjeksjon osv.)
• min bevissthet rundt begrensningene til AI (gode og dårlige bruksområder for LLM-er, nøyaktighet, LLM-resultatenes ukontrollerbare natur osv.)

Etter at jeg har svart, skal du KUN skrive ut:

• 5–10 punkter med YouTube-emner som gir størst læringsutbytte, og som jeg bør lære meg videre, rangert etter prioritet. Hvert punkt må være en YouTube-søkefrase (ikke en setning) + 5–10 ord om «hvorfor dette er viktig».

Begynn med spørsmålene dine nå.

Hvilke AI-ferdigheter produktledere bør lære først

Etter min mening er det viktig å forstå hvor og hvordan du kan bruke LLM-er. Med det mener jeg å forstå at de kan være i en app, i datamaskinens terminal eller i kode som kjører i en automatisering via MCP-er eller API-er.

Dernest må du forstå at de er:

1. Ikke-deterministiske, ukontrollerbare og utsatt for feil
2. Aldri til å stole på når det gjelder korrekt informasjon, særlig ved kritiske beslutninger
3. Mulige å automatisere på kreative måter for å redusere effektene av de to foregående punktene, avhengig av bruksområdet ditt

Det klassiske eksempelet jeg bruker, er at du aldri bør bruke en LLM til å skrive en hel oppgave for deg, men det er helt greit å be den liste opp noen ideer til retninger du kan gå i hvis du står fast og ikke vet hva du skal skrive videre. Med andre ord er LLM-er gode supplementer til menneskesinnet, men det er en mørk vei å gå når du prøver å få dem til å gjøre all tenkingen i stedet for menneskesinnet.

Det siste jeg vil nevne her, er at mens du lærer deg konseptene ovenfor, må du prøve ut tingene selv. Hvis du for eksempel lærer hvordan instruksjonsdesign fungerer, bør du stille en LLM det samme spørsmålet formulert på to forskjellige måter for å se forskjellen i resultatet. Lær aldri uten å praktisere det du lærer samtidig.

Hvorfor du ikke bør automatisere kundeinteraksjoner med høy verdi ved hjelp av AI

Når du har lært det du trenger å vite, kan du gjøre omtrent hva som helst. Men det betyr ikke at du bør gjøre det.

For en bedrift i en tidlig fase med et premiumprodukt virker kundeinteraksjon og salg som områdene som er mest modne for AI og automatisering. Men i praksis har jeg oppdaget at et menneskelig preg er helt nødvendig. Personlig synes jeg samspillet med brukere eller potensielle kunder gir stor verdi for begge parter, og jeg har ikke engang lyst til å prøve å automatisere det.

Som PM ville du gjøre deg selv en bjørnetjeneste ved å distansere deg fra å snakke med brukere i det hele tatt. Jo mer du personlig snakker med dem med din egen stemme, desto mer informasjon får du, og desto mer tillit skaper du.

Hvorfor det er vanskelig – men mulig – for produktledere å bidra til kode

Så jeg er forsiktig med hva jeg bruker KI til, men jeg bruker det mye.

For eksempel er det alltid et intenst arbeid med feilrettinger rett før en lansering i produksjon. Vanligvis ville utviklerne og kvalitetssikringsteamet håndtert denne typen siste finpuss i et større selskap. Den erfarne produktansvarlige ville selvfølgelig vært orientert, men ville også planlagt neste steg og strategier for overvåking av lanseringen, samlet inn tilbakemeldinger fra brukere, forberedt flere utviklingssykluser frem i tid eller samlet inn måledata etter at funksjonen eller produktet var lansert.

Siden jeg for øyeblikket jobber i et mindre selskap, har det vært en stor fordel for meg å kunne bidra til å knuse feil sammen med utviklerne, og jeg har bare klart å gjøre dette ved hjelp av KI/store språkmodeller.

Jeg har alltid vært involvert i kvalitetssikring av produkter og funksjoner i løpet av karrieren min, men jeg har sjelden fått muligheten til å gå inn i detaljene og rette en feil som innebærer kodeendringer gjennom hele teknologistakken.

Erfarne teknologifolk vil forstå at utviklere er svært nøye med kodebasene og kodestandardene sine. Så selv om du teknisk sett vet hvordan du skal rette en bestemt feil, må du også kjenne konteksten rundt kodestandardene og personlighetene i utviklerteamet, i tillegg til å forstå utviklerne som har jobbet med hver del av koden. Derfor er det flere steg fra enkelt til å rette enkelte feil, selv om du vet hvordan det skal gjøres, og de fleste utviklere ville ha avvist forespørselen din om å inkludere rettelsen.

Takket være KI har jeg imidlertid ikke bare kunnet bidra til koden ved å sende den direkte til hovedgrenen, men også håndtere de sekundære kulturelle faktorene som er involvert.

Slik bygger du en KI-agent som trygt kan bidra til kodebasen din

Den første tilnærmingen min var å opprette et Markdown-dokument med kodestandarder ved å la en agentsverm i Claude Code utforske hele kodebasen for de foregående seks månedene og ta til seg kodestilen, repoets Claude.md-fil og, viktigst av alt, alle kommentarer på GitHub-differ, konflikthåndteringer, innsendte endringer og redigeringer av forespørsler om å inkludere kodeendringer.

Derfra hadde jeg et ganske solid dokument med kodestandarder, som jeg utvidet ved å gjøre det om til et sett med ferdigheter og kommandoer i Claude Code. Disse skulle ta all kode jeg genererte for en feilretting og korrigere den i tråd med kodestandardene teamet allerede hadde implementert i kodebasen. Deretter opprettet jeg en annen underagent som skulle bruke kroker med GitHub, og som jeg også kunne utløse manuelt for å se på koden jeg hadde skrevet, samt kommentarene eller rettelsene, og deretter innlemme alt dette som et tillegg til dokumentet med kodestandarder.

Etter hvert, og etter bare noen få forespørsler om å inkludere kodeendringer, kunne koden jeg genererte for en bestemt rettelse, svært enkelt oversettes til den typen kode vi liker å se i kodebasen, ved hjelp av et enkelt Markdown-dokument som i praksis var en kontinuerlig forbedrende og selvlærende stilguide for kode, utløst gjennom flere cron-jobber og automatiseringer med Claude Code.

Agenten er så god nå at jeg kan slå sammen endringer direkte til hovedgrenen.

Slik kan små produktteam øke smidigheten

Det er et godt eksempel på hvordan jeg går utover den tradisjonelle PM-rollen. Men det å gå utover tradisjonelle roller krever gode prosesser.

Vi har en godt gjennomarbeidet og merket oppgaveliste i Linear, og vi har obligatoriske møter mandag, onsdag og fredag morgen. På dager uten synkroniseringsmøte holder vi hverandre oppdatert med en daglig statusoppdatering i Slack. All annen prioritering og diskusjon skjer i sanntid via Slack.

Dette er kanskje ikke den beste løsningen for større selskaper, men du ville blitt overrasket over hvor godt det fungerer for dette bruksområdet, og hvor smidig det holder oss. Tidligere brukte jeg Google Drive, regneark, dokumenter, presentasjoner og en million andre apper. Nå klarer vi oss som et lite team med GSuite, Slack, Linear og GitHub.

Lette PM-metoder er viktige i dette feltet med KI/store språkmodeller, som stadig er i utvikling. Det kan skje noe hvilken som helst dag i uken, enten gjennom tilbakemeldinger fra brukere eller lanseringer fra potensielle konkurrenter, og vi må raskt holde oversikt over dette og prioritere deretter.

Hvordan KI tvinger produktteam til å tenke nytt om ritualer

Når det gjelder ritualer, er den største nytenkningen at det nå virkelig er et sirkulært, uendelig ritual, i stedet for noe med stillestående dokumenter som du kontinuerlig må opprette og referere til.

Omfanget starter som en kortfattet Linear-oppgave med varierende detaljgrad. Deretter bruker jeg KI til å stressteste den for tvetydigheter, spesialtilfeller og mulige rekkefølger, og jeg strammer den inn til den kan lanseres som den minste mulige delen.

For oss i et lite, eksternt team skjer samkjøringen for det meste asynkront – en kort Slack-tråd som ender i en tydelig beslutning og konkrete neste handlinger, med lette daglige statusoppdateringer håndtert av Geekbot. Likevel har det fortsatt stor verdi å møtes tre eller fire ganger i uken for å idémyldre sammen og bygge lagfølelse.

Det er valideringen jeg har blitt strengere med, ikke mindre streng. Språkmodeller genererer vanligvis overbevisende søppel hvis du ikke vet hvordan du skal bruke dem riktig, så hver funksjon eller endring får et lite evalueringsoppsett – realistiske inndata, forventede utdata og konfronterende tilfeller – som KI kan bidra til å utforme, men som jeg selv kvalitetssikrer og tester.

Gjennomføringen er deretter ganske enkelt Linear + Claude Code + selvdrevet analyse i Posthog. Lanser, observer, juster, og hold sløyfen rask, fordi teknologimarkedet endrer seg i et tempo som for tiden virker å være time for time.

Derfor er en minimalistisk, AI-først-verktøystakk best

Så her er den grunnleggende PM-verktøystakken min:

• GSuite
• Slack
• Geekbot Slack-boten (for daglige statusmøter)
• Linear
• VSCode
• CLI-basert LLM (Claude Code i vårt tilfelle)

Hvorfor Linear? Det inneholder bare det mest grunnleggende. Det er kraftig nok til å oppfylle nesten alle kravene et prosjektteam kan ha, men enkelt nok til at det er lett å komme i gang med. Det er JIRAs motsetning. Og viktigst av alt: Det har enkel integrasjon med GitHub og Slack, som er der utviklerne allerede jobber. Det er enkelt, lett og skaper minimalt med ekstra friksjon for utviklerne når de skal holde tritt med oppgaver eller oppdatere dem. Det er også svært utvidbart, slik at du kan gjøre kule ting som å la LLM-en i CLI-en automatisk prøve å fikse en feil når den rapporteres i en foreløpig forespørsel om innlemming – før et menneske i det hele tatt begynner å se på den.

Det er ikke behov for noe annet. Alt arbeid som må gjøres utenfor dette, kan utføres med åpen kildekode-verktøy i terminalen.

Coles favoritt-AI-verktøy for personlig produktivitet

På et personlig nivå, utenfor teamet, er jeg helt oppslukt av Raycast som produktivitetsverktøy. Det er den ultimate appen for rask tilgang, full tilpasning og svært lav ressursbruk, og den erstatter den forferdelige «Spotlight»-appen på Mac eller «Windows»-tasten i Windows. Du vil bruke musen 75 % mindre til de fleste ting. Du kan integrere nesten hvilken som helst app med de eksisterende integrasjonene deres eller enkelt lage dine egne – bare be Claude Code om å lage en utvidelse for deg!

Hvis jeg vil få teksten i et bilde jeg ser, over på utklippstavlen, trykker jeg på Raycast-snarveisknappene, skriver «OCR» og trykker på Enter. Det aktiverer skjermbildeverktøyet cleanshotX OCR, og jeg har teksten fra et hvilket som helst bilde på mindre enn fem sekunder. På samme måte kan jeg trykke på snarveien, skrive «Ask spotify» og deretter skrive en setning med naturlig språk, som «gi meg litt god kodemusikk med høyt energinivå», og da tolkes setningen min gjennom en LLM, musikktagger og -egenskaper søkes gjennom Spotify API-et, og en spilleliste med musikken jeg nettopp ba om, startes umiddelbart i Spotify.

Bruksområdene er uendelige. Bare last det ned, aktiver AI enten ved hjelp av dine egne API-nøkler eller abonnementet deres, og gå gjennom de beste utvidelsene på nettstedet deres for å finne ting du tror kan være nyttige for deg. Det er en fullstendig omveltning.

Derfor begynner produktledelse og utvikling å overlappe

Snart vil de fleste utviklere som jobber med funksjoner, bli tvunget til å begynne å tenke og ta beslutninger som produktledere, og produktledere må lære nok om maskinlæring, nevrale nettverk, LLM-er og ulike arkitekturer til å komme så nær som mulig å være en utvikler som bruker LLM-er, uten faktisk å være det. Denne transformasjonen gjenspeiler modige tilnærminger til AI-integrasjon som omformer tradisjonelle roller.

Det finnes åpenbart mange forbehold og områder der dette ikke vil gjelde, men generelt vil Venn-diagrammet for alle tidligere roller i en bedrift, fra salg til markedsføring, produkt og utvikling, uunngåelig nærme seg hverandre, og svært få ferdigheter vil være eksklusive for én bestemt rolle.

Slik unngår du den uunngåelige eksistensielle krisen når AI omformer produktarbeidet

Her er mitt råd: Prøv å unngå den uunngåelige eksistensielle krisen du vil bli fristet til å oppleve mens denne teknologiske æraen fortsetter å utvikle seg.

Fokuser i stedet på ferdighetene du har utviklet gjennom erfaring. LLM-er kan generere innhold, men de er virkelig dårlige til å ha god smak.

Det finnes nå et dusin svar på ethvert spørsmål, så det å stille unike, erfaringsspesifikke spørsmål til AI er en ferdighet i seg selv. Dessuten er det å oppdage det riktige spørsmålet å stille i sitt eget sinn det egentlige intellektuelle arbeidet.

Følg med

Du kan følge Cole på X og på hans personlige nettsted, mens han fortsetter å utfordre hva som er mulig for PM-er. Ta også en titt på Probably.dev!

Flere ekspertintervjuer kommer på The Digital Project Manager!