De PM-rol in het tijdperk van AI-agents

In 2026 draait productmanagement niet meer alleen om begrijpen wat mensen doen in je product. Het draait ook om begrijpen wat AI-agents doen. Die twee gedragspatronen lopen uiteen op bijna elk denkbaar vlak: snelheid, intentie, foutgevoeligheid en verwachting. Wie dat niet scherp heeft, bouwt aan een product dat voor de helft van zijn gebruikers niet goed werkt, en weet dat niet eens.

Het moment waarop ik het doorhad

Het drong bij mij door toen ik keek naar de API-logs van een product waaraan ik meewerkte. Er was een piek in gebruik, maar de gebruikersaantallen in onze standaard analytics bewogen nauwelijks. Iemand vroeg: "Wie doet dit dan?" Het antwoord bleek een extern geautomatiseerd proces te zijn dat via onze API data ophaalde, verwerkte en doorstuurde. Geen mens aan het stuur. Gewoon een agent die zijn werk deed.

Dat klinkt misschien technisch en ver van het bed. Maar het raakte direct aan onze roadmap. We hadden maanden geprioriteerd op basis van wat onze menselijke gebruikers nodig hadden. Navigatie, foutmeldingen, laadtijden, onboarding. Intussen was er een groeiende groep "gebruikers" die dat allemaal niet interesseerde. Die wilde betrouwbare endpoints, consistente datastructuren en duidelijke foutcodes. En die groep groeit alleen maar.

Wat is een AI-agent eigenlijk als gebruiker?

Een AI-agent is een softwaresysteem dat zelfstandig taken uitvoert, beslissingen neemt en daarvoor externe tools of diensten aanroept, waaronder jouw product. Dat kan een LLM-gebaseerde assistent zijn die namens een gebruiker data ophaalt, een geautomatiseerde workflow die elke nacht rapporten genereert, of een orkestratielaag die meerdere producten aanstuurt om een taak te voltooien.

Het cruciale verschil met een menselijke gebruiker: een agent heeft geen geduld, geen context buiten zijn taakopdracht, en geen tolerantie voor ambiguïteit. Als een mens een onduidelijke foutmelding ziet, denkt die na. Een agent retryget tot een limiet is bereikt of faalt stilzwijgend. Dat is een fundamenteel ander gebruikersgedrag.

Voor een bredere context over hoe AI de vindbaarheid van je product beïnvloedt, is het ook de moeite waard om te lezen over AI Overviews en je online vindbaarheid: wat nu?. De verschuiving in wie of wat je product "vindt" en gebruikt, loopt parallel aan wat er intern met agents gebeurt.

Hoe prioriteer je anders als je twee gebruikers hebt?

Prioriteren wordt ingewikkelder zodra je twee gedragspatronen moet bedienen. De klassieke aanpak, meest pijn voor de meeste gebruikers oplossen, werkt niet meer zonder context over welke gebruiker je bedoelt. Een bug die voor mensen nauwelijks zichtbaar is, kan voor agents catastrofaal zijn. En andersom: een onboarding-flow die menselijke gebruikers enorm helpt, is voor een agent volledig irrelevant.

Wat ik nu doe in de praktijk: bij elk prioriteringsgesprek stel ik twee vragen. Welk probleem lost dit op voor menselijke gebruikers? En welk probleem lost dit op voor geautomatiseerde gebruikers? Als het antwoord op de tweede vraag "geen" is, is dat prima, maar het moet een bewuste keuze zijn, geen blinde vlek.

Dit raakt ook direct aan hoe je je backlog indeelt. Ik ben begonnen met een apart label voor "agent-facing" work. Niet als aparte silo, maar als signaal in de prioriteringsdiscussie. Zo gaan verbeteringen aan API-stabiliteit, documentatie voor geautomatiseerde integraties en foutcodestructuur niet meer structureel onderaan de stapel liggen omdat ze "technisch" zijn en geen directe gebruikerswaarde hebben. Ze hebben wel gebruikerswaarde, alleen voor een gebruiker die eruitziet als code.

Als je meer wilt weten over hoe de rol van de product manager zich verhoudt tot bredere AI-adoptievraagstukken, vind je op mijn pagina over productmanagement en product ownership meer context over hoe ik daarnaar kijk.

Hoe ontwerp je voor twee totaal verschillende gedragspatronen?

Hier wordt het ook voor UX-designers en -onderzoekers interessant. Het vakgebied heeft altijd mensen als eindgebruiker gehad. Gebruikersonderzoek, persona's, usability-tests: allemaal mensgericht. Maar als een significant deel van je interacties geautomatiseerd is, heb je een ander soort "design" nodig voor dat deel.

Voor agents ontwerp je niet op scherm, maar op contract. Denk aan: duidelijke en stabiele API-structuren, voorspelbare foutcodes die door een agent geïnterpreteerd kunnen worden, goede documentatie die ook door een LLM begrepen wordt, en versioneringsdiscipline zodat een bestaande agent niet breekt bij een update.

Dat zijn geen traditionele UX-taken, maar ze zijn wel het domein van de product manager om te bewaken. Want als de engineering-backlog geen ruimte maakt voor agent-facing kwaliteit, en de designer alleen nadenkt over menselijke flows, dan valt het tussen de kieren. De PM is de enige die het geheel ziet.

Tegelijkertijd verandert er ook iets aan hoe je over de klantreis nadenkt. Als een agent namens een klant je product gebruikt, is de klant twee stappen verwijderd van de interactie. Dat heeft gevolgen voor hoe je feedback verzamelt, hoe je churn herkent en hoe je waarde aantoonbaar maakt. Ik schreef eerder over hoe nieuwe AI-kanalen de klantreis hertekenen, in het stuk over ChatGPT Ads: wat betekent dit voor jouw klantreis?. Dezelfde logica geldt hier: de klantreis loopt niet meer alleen door menselijke handen.

Tot slot: dit is geen reden tot paniek of hype. De meeste producten hebben vandaag nog voornamelijk menselijke gebruikers. Maar de trend is onmiskenbaar. Het aandeel geautomatiseerde interacties groeit. Als PM is het verstandig om nu alvast de infrastructuur te leggen, qua analytics, qua prioritering, qua ontwerpdiscipline, om dat dubbele gebruikersperspectief structureel te borgen. Niet omdat het hip is, maar omdat je anders over twee jaar een product hebt dat voor een groeiende gebruikersgroep slecht werkt, terwijl je dashboard je vertelt dat alles prima is.