Hoe AI productmanagers buiten hun rol laat treden

De weg naar productmanagement

Ik ben inmiddels al meer dan 15 jaar productmanager. Eerder in mijn carrière deed ik alles wat ik kon, waaronder ontwerp, verkoop, advies, marketing en zelfs programmeren in de PHP-dagen — bah.

Ik ben productmanagement ingegaan omdat ik het erg leuk vond om tussen verschillende onderwerpen te schakelen en contact te hebben met gebruikers, ontwikkelaars, leidinggevenden enzovoort. Ik had ook een goed oog voor ontwerp en een goed gevoel voor productkwaliteit. Na veel onderzoek ontdekte ik dat er een rol was die daar heel goed bij paste — productmanagement. Dus solliciteerde ik naar mijn eerste PM-functie en zo ben ik hier terechtgekomen.

Ik heb in allerlei sectoren gewerkt: B2B, B2B2C, retail en consumentensoftware. Ruim tien jaar geleden begon ik productmanagement te geven bij General Assembly, en daarna lanceerde ik zelfstandig mijn eigen online cursussen via Udemy en later LinkedIn Learning. Tegenwoordig heb ik op beide platforms samen meer dan 1,6 miljoen studenten. En ik heb op veel conferenties gesproken over product- en projectmanagement, waaronder mijn samenwerking met Google om een productcursus te geven in Kyiv, Oekraïne.

Momenteel werk ik bij Probably.dev, een deterministische data-agentapp die wordt gefinancierd door a16z. We zijn een klein team, dus ik ben niet alleen PM, maar ook ingenieur, verkoper, ontwerper enzovoort.

Onze app is een native desktopapplicatie die deterministische datawetenschap op PhD-niveau uitvoert, met ondersteunende visualisaties om elke gegeven query in natuurlijke taal rechtstreeks te beantwoorden zonder dat gevoelige gegevens je computer verlaten. Je kunt het zien als een "datacopiloot". We werken rechtstreeks boven op schema's van datawarehouses (bijvoorbeeld BigQuery, Snowflake, Clickhouse enzovoort), en met lokale bestanden zoals CSV, JSON en Parquet. Alle antwoorden die onze agent geeft, zijn door mensen traceerbaar en reproduceerbaar, dus typische hallucinaties van LLM's vormen geen probleem. Het is niet zomaar een andere SQL-generatoragent en we kunnen miljarden rijen/kolommen en complexe schema's met tienduizenden tabellen verwerken.

You should also read

• De Salesforce-PM die de manier herschrijft waarop bedrijfsteams AI inzetten bij projectoplevering

• Amy Mitchell van Dell over waarom AI de “bouwende productmanager” creëert

• Deze CEO van een AI-start-up verandert projectoplevering in een proactieve discipline met voorspellende intelligentiemodellen

Hoe AI teams helpt om per persoon meer gedaan te krijgen

AI heeft een grote impact gehad op mijn werk. Vroeger was ik "alleen maar een PM". Dat klinkt misschien onzinnig, omdat PM's zoveel doen, maar nu kan ik ook aan allerlei andere zaken bijdragen, zoals engineering en verkoop. En dat helpt het team sneller vooruit. Nu AI projectmanagement verandert, worden de traditionele rolgrenzen vloeiender.

Tijdrovende taken zoals onderzoek en analyse gaan veel sneller, en de tijdwinst maakt veel meer contact en communicatie met belanghebbenden mogelijk. Het zorgt ook voor snellere besluitvorming.

Een groot deel van het werk van een PM bestaat eruit ervoor te zorgen dat alle anderen hun werk effectief kunnen doen. Doordat ik zelf nog meer kan doen, kunnen we per persoon veel meer gedaan krijgen. Deze mens-AI-hybride aanpak wordt essentieel voor moderne leveringsteams.

Waarom een diepgaand begrip van AI productmanagers vrijwel alles laat doen

Hoe meer ik me erin verdiep, hoe meer ik besef hoe steil de leercurve voor effectief en efficiënt gebruik van AI/LLM's daadwerkelijk is, evenals de deelvaardigheid om AI te laten aansluiten op de werkstromen waaraan de mensen om je heen of in je teams de voorkeur geven. Dit versterkt mijn overtuiging dat iedereen binnen een bedrijf niet alleen grondige kennis moet hebben van LLM's in het algemeen en de beschikbare modellen, maar ook van de vele ecosysteemtools eromheen, zoals MCP's, modaliteiten zoals CLI en GUI, en bovenal de transformerarchitectuur. Voor wie zijn kennis wil verdiepen, kunnen boeken over AI-projectmanagement waardevolle inzichten bieden in het effectief implementeren van deze technologieën.

Goed samenwerken met AI in de enorme zee van AI-rommel van tegenwoordig, of het nu om inhoud of hulpmiddelen gaat, is een vaardigheid die je moet aanscherpen en die je alleen door ervaring kunt ontwikkelen. Je moet begrijpen hoe LLM's werken en wat ze wel en niet goed kunnen, om er het beste uit te halen en optimaal te presteren.

Veel "baanbrekende" SaaS-producten en hulpmiddelen die er zijn lijken goede oplossingen te zijn — bijvoorbeeld voor het maken van PRD's — maar ik heb ontdekt dat 99% van alles wat je moet doen zelf goedkoper, sneller, meer op maat en aanzienlijk beter kan worden gedaan. Tenminste, zolang je de bovenstaande concepten begrijpt en over de vaardigheden beschikt om LLM's effectief te gebruiken.

Het is net als bij die reclamefilmpjes waarin iemand iets eenvoudigs doet, waarna ze laten zien hoe "moeilijk" het is en je een heel apparaat proberen te verkopen om dat kleine probleem op te lossen. In plaats van bijvoorbeeld een banaan zoals een normaal mens met een mes in stukjes te snijden, willen ze je een banaanvormige snijder verkopen die alle stukjes in één beweging snijdt...

Het mes is een LLM en de bananensnijder is een nutteloze niche-app. Leer dat verdomde mes te gebruiken. Koop er een van goede kwaliteit, gebruik het, leer ermee werken en stop met het kopen van domme dingen omdat tech-Twitter je vertelt dat een willekeurige SaaS-app ontwerpers zojuist "overbodig heeft gemaakt" of "programmeren heeft gedood".

Er is eigenlijk niets wat je niet kunt doen met een LLM in een CLI, webbrowser en af en toe een open-ended, taakagnostische automatiseringstool zoals n8n.

Bespaar je geld en leer hoe je dingen bouwt die de wijsheid van je opgedane ervaringen weerspiegelen, in plaats van de uitvoer van een SaaS-tool die 's nachts is verschenen zomaar te accepteren.

De enige keer dat dit niet van toepassing zou zijn, is bij tools voor één specifiek doel die zich uitsluitend richten op het oplossen van problemen waarvoor de transformer-LLM-architectuur in standaard frontier-modellen (d.w.z. niet gefinetunede modellen) inherent tekortschiet. Denk bijvoorbeeld aan grootschalige datawetenschap of wiskunde.

Hoe je als productmanager kunt beginnen met leren over AI

Het beste aan LLM's is dat je ze kunt vragen hoe je erover kunt leren. Als je net als ik visueel leert, is YouTube de kers op de taart; daar vind je enorm veel goede bronnen over AI en LLM's.

Als ik opnieuw zou beginnen, zou ik het leren als volgt aanpakken: vertel een LLM dat je alles wilt leren over het AI/LLM-domein, aangepast aan jouw niveau van technisch inzicht. Je kunt het zelfs instrueren om je steeds technischere vragen te stellen om je huidige vaardigheidsniveau voor alles binnen het AI/LLM-domein te begrijpen, te beginnen bij de basis. En wanneer je op een punt komt waarop de stof je boven het hoofd groeit, kun je het onderwerpen laten aanbevelen om te leren, van de basis van de transformerarchitectuur tot en met hoe een app zoals ChatGPT werkt.

Het idee is om een lijst met onderwerpen om te leren te krijgen en vervolgens elk onderwerp op YouTube op te zoeken om een video te vinden waarmee je het onderwerp kunt begrijpen.

Hier is een voorbeeldprompt:

Handel als mijn beoordelaar van mijn "startpunt" op het gebied van AI/LLM's.

Stel me maximaal 12 vragen (een mix van eenvoudige en technische vragen) om het volgende in kaart te brengen:

• mijn algemene technische vaardigheid (programmeren, data, API's)
• mijn begrip van hoe LLM's werken (modelmodaliteiten zoals CLI's en GUI's, evenals tokens, context, hallucinaties enzovoort)
• mijn bekendheid met moderne patronen voor LLM-apps (RAG/embeddings, agents/toolgebruik)
• mijn vermogen om kwaliteit te beoordelen (evaluaties, verificatie)
• mijn bewustzijn van risico's (privacy, promptinjectie enzovoort)
• mijn bewustzijn van de beperkingen van AI (goede versus slechte gebruiksscenario's voor LLM's, nauwkeurigheid, de oncontroleerbare aard van LLM-uitvoer enzovoort)

Geef na mijn antwoorden ALLEEN het volgende:

• 5–10 YouTube-onderwerpen met de hoogste impact die ik vervolgens moet leren, gerangschikt op prioriteit. Elke bullet moet bestaan uit een YouTube-zoekterm (geen zin) + een uitleg van 5–10 woorden over waarom dit belangrijk is.

Begin nu met je vragen.

Welke AI-vaardigheden productmanagers als eerste moeten leren

Naar mijn mening is het belangrijk om te begrijpen waar en hoe je LLM's kunt gebruiken. Daarmee bedoel ik begrijpen dat ze zich in een app kunnen bevinden, in de terminal van je computer, of in code die in een automatisering via MCP's of API's werkt.

Daarnaast moet je begrijpen dat ze:

1. Niet-deterministisch en oncontroleerbaar zijn en vatbaar zijn voor fouten
2. Nooit mogen worden gebruikt als betrouwbare bron voor nauwkeurige informatie, vooral niet bij kritieke beslissingen
3. Op creatieve wijze kunnen worden geautomatiseerd om, afhankelijk van je gebruiksscenario, de gevolgen van de vorige twee punten te beperken

Het klassieke voorbeeld dat ik geef, is dat je nooit een LLM een essay volledig voor je moet laten schrijven, maar dat het prima is om het te vragen een aantal ideeën te geven over richtingen die je op kunt gaan als je vastzit met wat je vervolgens moet schrijven. Met andere woorden: LLM's zijn geweldige aanvullingen op het menselijk denkvermogen, maar het is een duistere weg om in te slaan wanneer je ze al het denkwerk wilt laten doen in plaats van het menselijk denkvermogen.

Het laatste wat ik hier wil noemen, is dat je, terwijl je de bovenstaande concepten leert, die dingen zelf moet proberen. Als je bijvoorbeeld leert hoe prompt engineering werkt, moet je dezelfde vraag op twee verschillende manieren aan een LLM stellen om het verschil in de uitvoer te zien. Leer nooit zonder het geleerde tegelijkertijd in de praktijk te brengen.

Waarom je waardevolle klantinteracties niet met AI moet automatiseren

Zodra je hebt geleerd wat je moet weten, kun je vrijwel alles doen. Maar dat betekent niet dat je het ook moet doen.

Bij een bedrijf in een vroege fase met een premiumproduct lijken klantinteractie en verkoop "het meest geschikt" voor AI en automatisering. In de praktijk heb ik echter gemerkt dat een menselijke benadering absoluut noodzakelijk is. Persoonlijk vind ik de interactie met gebruikers of potentiële klanten aan beide kanten een belangrijke meerwaarde bieden, en ik wil die niet eens proberen te automatiseren.

Als PM zou je jezelf tekortdoen als je je ook maar enigszins zou distantiëren van gesprekken met gebruikers. Hoe meer je persoonlijk met hen praat met je eigen stem, hoe meer informatie je verkrijgt en hoe meer vertrouwen je opbouwt.

Waarom het moeilijk — maar mogelijk — is voor productmanagers om bij te dragen aan code

Ik ben dus voorzichtig met waar ik AI voor gebruik, maar ik gebruik het veel.

Vlak voor een release naar productie is er bijvoorbeeld altijd een bugfixstorm. Bij een groter bedrijf zouden de ontwikkelaars en het QA-team zich doorgaans met dit soort laatste aanpassingen bezighouden. Natuurlijk zou de senior productverantwoordelijke op de hoogte zijn, maar die zou ook de volgende stappen en strategieën voor het monitoren van die release plannen, gebruikersfeedback verzamelen, meerdere cycli vooruit plannen of statistieken verzamelen zodra de functie of het product is gelanceerd.

Omdat ik momenteel bij een kleiner bedrijf werk, is het voor mij een enorme verandering geweest dat ik samen met de ontwikkelaars kan helpen om bugs op te lossen. Dat heb ik alleen kunnen bereiken door AI/LLM's te gebruiken.

In mijn loopbaan ben ik altijd betrokken geweest bij QA voor producten en functies, maar zelden heb ik de mogelijkheid gehad om echt de diepte in te gaan en een bug op te lossen waarbij codewijzigingen door de volledige stack nodig waren.

Ervaren techprofessionals begrijpen dat ontwikkelaars heel nauwgezet zijn als het gaat om hun codebases en coderingsstandaarden. Dus zelfs als je technisch gezien weet hoe je een bepaalde bug moet oplossen, moet je ook de context van de coderingsstandaarden en de persoonlijkheden binnen het engineeringteam kennen. Daarnaast moet je begrijpen welke ontwikkelaars aan elk deel van de code hebben gewerkt. Sommige bugs oplossen is daardoor meerdere stappen verwijderd van eenvoudig, zelfs als je weet hoe het moet, en de meeste ontwikkelaars zouden je pullrequest voor de oplossing met hoongelach ontvangen.

Dankzij AI heb ik echter niet alleen kunnen bijdragen aan de code door rechtstreeks naar main te pushen, maar heb ik ook de secundaire culturele factoren kunnen aanpakken.

Een AI-agent bouwen die veilig aan je codebasis kan bijdragen

Mijn eerste aanpak was om een Markdown-document met coderingsstandaarden op te stellen. Daarvoor liet ik een agentzwerm in Claude Code de volledige repository van de afgelopen zes maanden verkennen en de codeerstijl, het Claude.md-bestand van de repository en — het allerbelangrijkst — alle opmerkingen op GitHub-diffs, oplossingen voor conflicten, commits en bewerkingen aan pullrequests opnemen.

Daaruit had ik een behoorlijk solide document met coderingsstandaarden, dat ik verder uitbreidde door het om te zetten in een reeks vaardigheden en opdrachten in Claude Code. Die konden alle code die ik voor een bugfix genereerde, aanpassen aan de coderingsstandaarden die het team al in de codebasis had geïmplementeerd. Vervolgens maakte ik nog een subagent die hooks met GitHub zou gebruiken. Die kon ik ook handmatig activeren om te kijken naar de code die ik had geschreven, evenals naar de opmerkingen of oplossingen, en dat alles vervolgens verwerken in een aanvulling op het document met coderingsstandaarden.

Uiteindelijk kon de code die ik voor een bepaalde oplossing genereerde, al na slechts enkele pullrequests heel eenvoudig worden vertaald naar het soort code dat we graag in de codebasis zien. Dat gebeurde via een eenvoudig Markdown-document dat in feite een voortdurend verbeterende en zelflerende stijlgids voor code was, aangestuurd door meerdere cron-taken en automatiseringen met Claude Code.

De agent is nu zo goed dat ik rechtstreeks naar main kan mergen.

Hoe kleine productteams hun wendbaarheid kunnen vergroten

Dat is een goed voorbeeld van hoe ik verder ga dan de traditionele PM-rol. Maar verder gaan dan traditionele rollen vereist goede processen.

We hebben een goed bijgehouden en getagde backlog in Linear en we houden op maandag-, woensdag- en vrijdagochtend verplichte vergaderingen. Op dagen zonder synchronisatievergadering houden we elkaar op de hoogte met een korte statusupdate via Slack. Alle andere prioritering en discussie vindt in realtime plaats via Slack.

Dit is misschien niet de beste oplossing voor grotere bedrijven, maar je zou ervan versteld staan hoe goed het voor deze toepassing werkt en hoe wendbaar het ons houdt. Vroeger gebruikte ik Google Drive, spreadsheets, documenten, presentaties en nog een miljoen andere apps. Nu kunnen we als klein team volstaan met GSuite, Slack, Linear en GitHub.

Lichtgewicht PM-methoden zijn belangrijk in deze voortdurend veranderende AI/LLM-omgeving. Er kan elke dag van de week iets gebeuren met gebruikersfeedback of releases van potentiële concurrenten waar we snel bovenop moeten zitten en waar we onze prioriteiten omheen moeten bepalen.

Hoe AI productteams dwingt om rituelen opnieuw te doordenken

Als het om rituelen gaat, is de belangrijkste heroverweging dat het nu echt een zich herhalend, nooit eindigend ritueel is, in plaats van iets met stagnerende documenten die je voortdurend moet maken en raadplegen.

De reikwijdte begint als een beknopt Linear-ticket met een wisselende mate van detail. Vervolgens gebruik ik AI om het te testen op dubbelzinnigheid, randgevallen en opties voor de volgorde. Ik blijf het aanscherpen totdat het in de kleinst mogelijke vorm klaar is om te worden uitgebracht.

Voor ons in een klein team op afstand verloopt de afstemming grotendeels asynchroon — een kort Slack-gesprek dat eindigt met een duidelijke beslissing en de volgende acties, waarbij lichtgewicht stand-ups door Geekbot worden afgehandeld. Toch heeft het nog steeds enorme waarde om drie of vier teamvergaderingen per week te houden om samen ideeën uit te wisselen en het moreel te versterken.

Bij validatie ben ik strenger geworden, niet minder streng. LLM's genereren doorgaans overtuigende onzin als je niet weet hoe je ze correct moet gebruiken. Daarom krijgt elke functiewijziging of wijziging aan een app een kleine evaluatieopstelling — realistische invoer, verwachte uitvoer en vijandige gevallen — die AI kan helpen opstellen, maar die ik zelf samenstel en test.

De uitvoering bestaat vervolgens gewoon uit Linear + Claude Code + zelfgehoste Posthog-analyses. Lanceren, observeren, aanpassen en de cyclus snel houden, omdat de technologiemarkt tegenwoordig in een tempo verandert dat wel elk uur lijkt te zijn.

Waarom een minimalistische, AI-gerichte toolstack het beste is

Dit is dus mijn basisstack voor productmanagement:

• GSuite
• Slack
• De Geekbot Slack-bot (voor dagelijkse overleggen)
• Linear
• VSCode
• Op de CLI gebaseerde LLM (in ons geval Claude Code)

Waarom Linear? Het bevat alleen de essentie. Het is krachtig genoeg om aan vrijwel alle behoeften van een projectteam te voldoen, maar eenvoudig genoeg om toegankelijk te zijn. Het is het tegenovergestelde van JIRA. En het belangrijkste is dat het eenvoudig te integreren is met GitHub en Slack, de omgevingen waarin ingenieurs toch al werken. Het is eenvoudig, lichtgewicht en zorgt voor minimale extra frictie voor ingenieurs om taken bij te houden of bij te werken. Het is ook uiterst uitbreidbaar, zodat je leuke dingen kunt doen, zoals je LLM in je CLI automatisch laten proberen een fout op te lossen wanneer die in een concept-PR wordt gemeld — nog voordat een mens ernaar begint te kijken.

Meer is er niet nodig. Al het werk dat daarbuiten nodig is, kan worden gedaan met opensourcetools in de terminal.

Coles favoriete AI-tool voor persoonlijke productiviteit

Op persoonlijk niveau, dus buiten teamverband, ben ik absoluut geobsedeerd door Raycast voor productiviteit. Het is de ultieme snelle, volledig aanpasbare, ultralichtgewicht app die de vreselijke app "Spotlight" voor Mac of de "Windows"-toets in Windows vervangt. Voor de meeste dingen zul je je muis 75% minder gebruiken. Je kunt vrijwel elke app integreren via de bestaande integraties of eenvoudig je eigen aangepaste integraties maken — vraag Claude Code gewoon om een extensie voor je te maken!

Als ik de tekst van een afbeelding die ik zie op mijn klembord wil krijgen, druk ik op de sneltoetsen van Raycast, typ ik "OCR" en druk ik op Enter. Daarmee activeer ik de OCR-screenshottool van CleanShot X en heb ik binnen vijf seconden de tekst van elke afbeelding. Op dezelfde manier kan ik op de sneltoets drukken, "Ask Spotify" typen en vervolgens een zin in natuurlijke taal invoeren, zoals "geef me wat goede codemuziek met veel energie", waarna mijn zin via een LLM wordt geïnterpreteerd, muziektags en eigenschappen in de Spotify API worden doorzocht en er direct in Spotify een afspeellijst wordt gestart met het soort muziek waar ik om vroeg.

De toepassingsmogelijkheden zijn eindeloos. Download het gewoon, activeer AI via je eigen API-sleutels of hun abonnement en bekijk de populairste extensies op hun website om dingen te vinden die voor jou nuttig lijken. Een echte doorbraak.

Waarom productmanagement en softwareontwikkeling steeds meer overlappen

Binnenkort zullen de meeste ingenieurs die aan functies werken gedwongen worden om te gaan denken en beslissingen te nemen als productmanagers, en zullen productmanagers genoeg moeten leren over machinaal leren, neurale netwerken, LLM's en verschillende architecturen om zo dicht mogelijk in de buurt te komen van een ingenieur die LLM's gebruikt, zonder er daadwerkelijk een te zijn. Deze transformatie weerspiegelt gedurfde benaderingen van AI-integratie die traditionele rollen opnieuw vormgeven.

Uiteraard zijn er veel uitzonderingen en gebieden waarop dit niet van toepassing zal zijn, maar over het algemeen zal het Venn-diagram van alle eerdere rollen binnen een bedrijf, van verkoop en marketing tot product en softwareontwikkeling, onvermijdelijk steeds meer overlappen, en zullen maar weinig vaardigheden exclusief zijn voor één specifieke rol.

Hoe je de onvermijdelijke existentiële crisis voorkomt terwijl AI productwerk opnieuw vormgeeft

Dit is mijn advies: probeer de onvermijdelijke existentiële crisis te vermijden waartoe je geneigd zult zijn naarmate dit tijdperk van technologie zich verder ontwikkelt.

Richt je in plaats daarvan op de vaardigheden die je geest bezit en die je door ervaring hebt ontwikkeld. LLM's kunnen inhoud genereren, maar ze zijn echt slecht in het hebben van een goede smaak.

Antwoorden zijn tegenwoordig niet bijzonder schaars meer, dus het stellen van unieke, ervaringsspecifieke vragen aan AI is nu een vaardigheid. Bovendien is het ontdekken van de juiste vraag om in je eigen hoofd te stellen het echte intellectuele werk.

Volg hem

Je kunt Cole volgen op X en zijn persoonlijke website, terwijl hij blijft uitdagen wat er mogelijk is voor PM's. Bekijk ook Probably.dev!

Er komen nog meer interviews met deskundigen op The Digital Project Manager!