Agentische verschuiving: Agentische werkprocessen vervangen lineaire overdrachten door parallelle, crossfunctionele delivery, gebaseerd op gedeelde code en documentatie.
Menselijk inzicht: AI verzorgt coördinatie en eerste versies, terwijl leiders verantwoordelijk blijven voor kwaliteit, creativiteit, prioritering en vertrouwen.
Begin met auditen: Teams moeten wekelijks onderzoeken waar tijd verloren gaat voordat ze tools kiezen, zodat algemene adoptie en opvallende maar ineffectieve toolsets worden vermeden.
Rituelen zijn belangrijk: Snellere AI-delivery vereist nog steeds een duidelijke scope, afstemming met belanghebbenden, grondige validatie en gedisciplineerde checklists om de productkwaliteit te behouden.
Leiderschapsmodel: Succesvolle AI-adoptie combineert leiders die hun werkprocessen veranderen met teams die experimenteren en verbeteringen delen binnen de organisatie.
Anshumani Ruddra is productleider bij Google en werkt aan de levering binnen de betalingsproducten van het bedrijf. Hij is ook docent en heeft leidinggevende leveringsfuncties op C-niveau bekleed.
We spraken met Anshumani om te leren hoe AI de levering verandert bij bedrijven zoals Google. Dit is wat hij vertelde.
Producten bouwen bij Google
Ik ben Anshumani Ruddra. Ik heb meer dan 22 jaar besteed aan het bouwen van consumentenproducten op het snijvlak van technologie, verhalen vertellen, popcultuur en menselijk gedrag — eerst als auteur van kinderboeken, daarna als gameontwerper van wereldwijde sociale hits zoals Mafia Wars en Café World, en vervolgens door Hotstar uit te bouwen tot een van 's werelds grootste streamingplatforms tijdens de IPL-jaren.
De afgelopen vijf jaar bij Google heb ik het productmanagement geleid voor de uiterst succesvolle GPay-app in India, het volledige betalingsproductaanbod van Google voor APAC beheerd en AI-producten voor consumenten gebouwd. Momenteel leid ik een AI-productontwikkelingsinitiatief van begin tot eind om een volledig nieuw product te bouwen.
Daarnaast leer ik productleiders en leidinggevenden via mijn Maven-cursus Naar een super-IC in productmanagement hoe ze met AI kunnen bouwen. Ik vervul tegelijkertijd twee rollen — uitvoerder en docent — en beide bepalen mijn aanpak van productlevering: minder gericht op coördinatie en goedkeuringen, en meer op het ontwikkelen van inzicht tot een werkend prototype zonder op toestemming te wachten.
Hoe AI mensen in staat stelt meer te doen van waar ze het best in zijn

Ik probeer AI niet te zien als gewoon een ander, beter hulpmiddel. Die manier van kijken zorgt ervoor dat je denkt dat het alleen om efficiëntie draait. AI is een vermenigvuldigingsfactor — mogelijk een factor die maar één keer per eeuw voorkomt.
Daardoor besteed ik veel minder tijd aan het verbindende weefsel van levering: het samenvatten van vergaderingen, het opstellen van PRD's, status- en bijgewerkte informatie voor belanghebbenden, en onderzoek in een eerste ronde. Ik heb veel daarvan ondergebracht in een persoonlijk "agentisch besturingssysteem", waardoor het grotendeels zelfstandig kan draaien.
Dus besteed ik mijn tijd nu aan de 10% die moeilijk en menselijk is, niet aan de 90% coördinatie die vroeger de week opslokte. Ik richt me meer op het eigenlijke vakmanschap. Het denkwerk, afwegingen en prototypen.
Over prototypen gesproken: dat is op zichzelf al een enorme verandering. Ik kan een visie nu valideren door zelf een functioneel prototype te bouwen voordat ik iemand eraan toewijs. De drempel om iets te bouwen is verdwenen. Als ik iets kan bedenken, kan ik een eerste versie werkend krijgen.
Wanneer AI gebruiken en wanneer een mens nodig is
Het werk dat het meest te automatiseren is, bevindt zich in de samenvattings- en administratieve laag:
- Ruwe audio van vergaderingen omzetten in beslissingen en actiepunten
- Eerste versies van PRD's en onderzoek genereren
- Inkomende signalen sorteren
- Bijgewerkte informatie voor belanghebbenden afhandelen
Je implementeert dit met persoonlijke AI-assistenten die je invoer in de gaten houden, aangeven waarvoor een beslissing nodig is en de rest opstellen.
Klantinzichten worden hier ook sterk onderbenut: er bestaan nu hulpmiddelen die je vertellen welke functies je moet bouwen en de impact op ARR inschatten, maar de meeste teams verzamelen feedback uit Slack en ondersteuningstickets nog steeds handmatig.
Maar mensen moeten nog steeds bepalen wat “goed” betekent. Als leider is het definiëren van kwaliteit jouw taak en daarom vind ik evaluaties zo belangrijk.
Mensen moeten ook smaak en productinzicht inbrengen, oprecht creatieve sprongen van nul naar één maken, en het menselijke werk met veel vertrouwen uitvoeren dat nodig is om teams te coachen, door politieke situaties te navigeren en moeilijke prioriteringsbeslissingen te nemen.
AI geeft je meer kansen om de roos te raken; een mens moet nog steeds bepalen waar het doel staat.
Waarom technologie-ecosystemen met een controle moeten beginnen
AI-hulpmiddelen zijn precies als een geweldig videospel — gemakkelijk om te spelen, maar meedogenloos moeilijk om onder de knie te krijgen. Door de verleidelijke eerste ervaring denken mensen dat alles vanzelf gaat, waardoor ze geschokt zijn wanneer de complexiteit toeslaat. Velen geven het op. De echte vaardigheid zit niet in het schrijven van instructies, maar in de bereidheid om vol te houden en in je eigen tempo te leren, sneller dan comfortabel voelt.
Op het werk bestaat mijn technologie-ecosysteem voornamelijk uit de nieuwste Gemini-modellen, met Antigravity als centrale voor agents. De agentbeheerder van Antigravity wordt onderschat. Die is echt innovatief. Wat projectmanagement betreft gebruikt Google eigen aangepaste hulpmiddelen, die in de buitenwereld vergelijkbaar zijn met Jira en GitHub.
Voor mijn persoonlijke projecten en onderwijsactiviteiten bestaat mijn belangrijkste technologiestack uit:
- Claude Code voor programmeren. Dit springt eruit. Ik laat meerdere agents parallel werken. Het komt het dichtst in de buurt van een echte assistent, en is niet zomaar automatisch aanvullen.
- Replit voor prototyping. De aanpak waarbij je eerst een plan maakt en de parallelle agents onderscheiden het van de rest.
- NotebookLM plus Obsidian voor onderzoek en schrijven.
- Codex en Claude Cowork voeren veel geplande taken en automatiseringen uit, waarbij ze e-mail, agenda, cloudopslag en vergadernotities integreren.
- Granola en Wispr Flow maken de stack compleet. Ik ben een groot voorstander van spraak-naar-tekst en het gebruik van je stem als invoer.
In de afgelopen 6–12 maanden ontwikkelde de stack zich van "AI gebruiken om sneller concepten te maken" tot een echt persoonlijk agentisch besturingssysteem — minder gericht op eenmalige prompts en meer op permanente agents die terugkerende workflows van begin tot eind beheren.
Mijn advies voor het opbouwen van een stack: begin niet met de meest flitsende tool. Analyseer hoe je je week besteedt, zoek uit waar je de meeste tijd aan verliest en kies de specifieke tool die deze knelpunten wegneemt. Algemene adoptiestrategieën werken niet.
Hoe agentische workflows de oplevering van projecten stroomlijnen
We hebben ons bewust eerst gericht op de gedeelde basis die deze workflows mogelijk maakt, omdat alles daar samenkomt of juist uit elkaar valt.
Bijna al onze processen verlopen nu als agentische workflows, op het gebied van ontwerp, productmanagement en technische uitvoering. Agentische workflows beheren de strategie en het denkwerk achter wat er moet worden gebouwd, het ontwerp van componenten, schermen en lay-outs, en de manier waarop back-end- en front-endcode samenkomen. Dit is geen geïsoleerd experiment in een uithoek van het team; zo wordt het werk van begin tot eind uitgevoerd.
We hebben ons bewust eerst gericht op de gedeelde basis die deze workflows mogelijk maakt, omdat alles daar samenkomt of juist uit elkaar valt. Concreet betekent dit dat we gemeenschappelijke infrastructuur voor het hele team bouwen, een gemeenschappelijke set agentvaardigheden samenstellen en een gemeenschappelijk raamwerk bieden waarmee iedereen werkt. Het belangrijkste onderdeel is documentatie die niet alleen geschikt is voor mensen, maar ook voor agents. Als je documentatie alleen voor mensen begrijpelijk is, zullen je agents afdwalen. Daarom investeren we veel in schrijven voor beide doelgroepen tegelijk.
Concreet ziet dit eruit als duidelijk gemarkeerde kennisbestanden, PRD's en technische ontwerpdocumenten. We bewaren deze doorgaans in Markdown, houden ze zeer helder en schrijven ze zo dat ze begrijpelijk zijn voor zowel mensen als agents. Cruciaal is dat mensen al deze bestanden valideren voordat we iets gaan bouwen. Menselijke validatie van de invoer houdt de agentische workflow schoon, omdat agents slechts zo goed zijn als de documenten en vaardigheden waarnaar je ze verwijst.
We onderhouden ook zeer duidelijke checklists en zorgen ervoor dat agents deze doorlopen. Een agent markeert een stap pas als voltooid wanneer echt aan de checklist is voldaan; pas dan gaan we door naar de volgende stap. Deze discipline van duidelijke documentatie, door mensen gevalideerde invoer, gedeelde vaardigheden en stapsgewijze checklists verandert agentisch werken van een nieuwigheid in iets betrouwbaars.
De voordelen zijn reëel zodra de basis op zijn plaats is. Het moeilijke deel is de investering vooraf in gedeelde infrastructuur en documentatie die geschikt is voor agents. Teams die deze stap overslaan, krijgen een flitsende demo en zien die vervolgens uit elkaar vallen naarmate de complexiteit toeneemt. Teams die het werk wel doen, krijgen echt snelle, parallelle uitvoering op het gebied van ontwerp, product en techniek.
Hoe AI traditionele modellen voor projectmanagement verandert

Het ouderwetse watervalmodel werkt simpelweg niet meer. Traditioneel projectmanagement was meedogenloos lineair: stap één leidde naar stap twee en vervolgens naar stap drie, met rigide overdrachten tussen disciplines. Product schreef de specificatie, ontwerp maakte de prototypes, engineering bouwde het en daarna beoordeelde ontwerp de afwerking — elke fase wachtte op de fase ervoor.
Die lineaire keten is doorbroken, en dat is geweldig. De stappen zijn nu uitwisselbaar en de grenzen tussen ontwerp, engineering en product zijn vervaagd. Ontwerpers hebben bijvoorbeeld het ontwerpsysteem al rechtstreeks in de codebase gebouwd — de juiste componenten, lay-outs en specifieke kleurentokens. Engineering kan vervolgens een volledige functiestroom bouwen en ontwerp kan alle problemen in de gebruikersinterface rechtstreeks in de code oplossen om de afwerking te voltooien. Niemand wacht op een overdracht vanuit Figma. Ontwerp werkt in hetzelfde medium als engineering.
Dezelfde vervaging vindt stroomopwaarts plaats. Het productteam kan veel meer PRD's parallel schrijven, waardoor de techniek wordt gedeblokkeerd. De techniek kan diepgaande, gedetailleerde technische ontwerpdocumenten genereren zonder dat het productteam elke stap hoeft goed te keuren, omdat AI elke discipline in staat stelt werk te produceren waarvoor eerder een specialist nodig was.
Verschillende teamleden kunnen nu verschillende onderdelen van het werk uitvoeren. In plaats van een lineaire estafette waarin bij elke overdracht het stokje valt, ontstaat er een klein team met veel eigen initiatief waarin iedereen zich naar aangrenzende gebieden kan begeven om werk te deblokkeren.
In de praktijk betekent dit lichte systemen in plaats van zware processen: minder statusvergaderingen en goedkeuringsmomenten, meer werkende prototypes. PRD's en technische ontwerpdocumenten worden snel gegenereerd en behandeld als levende artefacten in plaats van bevroren specificaties. Een gedeelde codebase — met het ontwerpsysteem ingebouwd — dient als de enige bron van waarheid waar product, ontwerp en techniek samenkomen.
Het resultaat is snelheid — teams valideren hun visie door te bouwen, niet door te coördineren, en leveren een afwerking die voorheen meerdere overdrachtsrondes kostte in een fractie van de tijd.
Waarom AI de noodzaak van projectrituelen niet kan wegnemen
Alle gebruikelijke rituelen bestaan nog steeds, en verschillende ervan worden met AI zelfs belangrijker, niet minder. Mensen gaan er ten onrechte van uit dat sneller bouwen een lossere discipline betekent. Het tegenovergestelde is waar.
Het afbakenen van de reikwijdte is nog altijd even cruciaal. Een team heeft nog steeds een glasheldere definitie nodig van wat het probeert te bouwen. Wat is veranderd, is wat er binnen die reikwijdte mogelijk wordt. Als een team efficiënt met AI bouwt, kunnen veel zaken die weinig prioriteit hadden of voor altijd in een achterstand bleven steken nu worden geprioriteerd en gelanceerd. Daardoor kun je een betekenisvoller en completer product bouwen dan voorheen. De ambitie van de reikwijdte kan groeien, maar de noodzaak om die duidelijk te definiëren blijft bestaan.
Teams hebben nog steeds volledige afstemming nodig. Belanghebbenden hebben nog steeds afstemming nodig. Wanneer je met meerdere teams samenwerkt, moet je nog steeds bewust zorgen voor afstemming binnen je team én tussen die teams. AI stemt mensen niet voor je op elkaar af.
Het valideren van werk is nog belangrijker. Wanneer je bij een groot bedrijf bouwt, bereiken je producten miljoenen mensen, niet slechts tientallen of honderden gebruikers. Producten moeten nog steeds uitstekend zijn, zeer goed werken en op die schaal presteren. Dat AI je helpt sneller te bouwen, verlaagt die lat niet. Validatie blijft dus niet-onderhandelbaar.
Wat is veranderd, is dat het proces niet langer zo moeilijk en traag is. De rituelen zelf — een duidelijke reikwijdte, echte afstemming en grondige validatie — blijven waar en worden zelfs belangrijker. We moeten de processen heroverwegen die traditioneel een snellere uitvoering belemmeren. AI stelt je in staat de ceremonie en wrijving rond deze rituelen terug te brengen, terwijl je de inhoud ervan beschermt.
Waarom beoordelingsvermogen nog belangrijker wordt in AI-gerichte organisaties
Op korte termijn zullen meer technologiebedrijven AI invoeren in productontwikkeling en -oplevering van begin tot eind. De gewaagdere voorspelling gaat echter over waar AI zich daarna verspreidt. Het blijft niet binnen de technologiesector. Het verspreidt zich naar grote ondernemingen, vervolgens naar niet-technologiebedrijven en uiteindelijk naar traditionele bedrijven.
Zodra deze voordelen zich verplaatsen van individuen naar kleine teams en naar hele organisaties, zal het vliegwieleffect teams en werkstromen ingrijpend veranderen. De structuur van opleveringsteams en de manier waarop werk door die teams stroomt, zal er heel anders uitzien dan vandaag.
Maar het belang van goede besluitvorming verdwijnt niet; het wordt juist belangrijker, omdat je nu veel vaker beslissingen neemt. Toen de algehele oplevering traag was, nam je slechts een paar belangrijke beslissingen, misschien eens in de paar weken of maanden. Nu moet je meerdere keren per dag, soms meerdere keren per uur, beslissingen van hoge kwaliteit nemen.
AI-gedreven ontwikkeling moet zowel van bovenaf als van onderaf worden ingevoerd.
Daarom moet de focus verschuiven naar menselijke besluitvorming. Elk expertisegebied moet een duidelijke reeks invalshoeken definiëren waarmee elke beslissing kan worden bekeken, zodat beslissingen scherper en sneller kunnen worden genomen. Net zo belangrijk is dat deze beslissingen worden vastgelegd, zodat agenten ze begrijpen en ernaar kunnen terugverwijzen.
Winnende teams zullen hoogwaardige, goed gedocumenteerde menselijke beoordeling als een schaars middel behandelen, omdat AI deze zowel frequenter als waardevoller maakt.
Waarom leidinggevenden op het gebied van oplevering AI moeten omarmen en experimenten moeten aanmoedigen

Het cruciale overkoepelende punt is dat AI-gestuurde ontwikkeling zowel van bovenaf als van onderaf moet worden omarmd. Het kan niet het een of het ander zijn.
Het top-downgedeelte vereist draagvlak van de leiding. Als de hogere leiding niet meegaat, niet experimenteert en niet probeert haar eigen werkprocessen en opleveringssystemen te veranderen, zal de organisatie AI zeer moeilijk op een betekenisvolle manier kunnen omarmen. Je kunt geen transformatie opleggen die je zelf niet doorleeft. Leidinggevenden die AI delegeren aan een taskforce terwijl ze hun eigen manier van werken ongewijzigd laten, geven een duidelijk signaal af dat dit optioneel is, en de organisatie interpreteert dat signaal correct. Mijn eerste advies aan collega-leidinggevenden op het gebied van oplevering is daarom om eerst je eigen werkprocessen te veranderen, voordat je iemand anders vraagt die van hen te veranderen.
Het bottom-upgedeelte is net zo belangrijk. Junior medewerkers en individuele teams moeten de vrijheid krijgen om te experimenteren, conventies ter discussie te stellen en bestaande werkprocessen uit te dagen. Ze hebben ruimte nodig om dingen uit te proberen, vragen te stellen bij de manier waarop oplevering altijd is aangepakt en vervolgens hun inzichten onder de aandacht van de leiding te brengen. Als dat kanaal niet bestaat, als mensen die vrijheid missen en hun bevindingen nooit naar boven komen, valt het geheel net zo zeker uiteen als wanneer de leiding ontbreekt.
Het nuttigste wat een leidinggevende op het gebied van oplevering nu kan doen, is beide uiteinden tegelijk vasthouden. Geef het goede voorbeeld door zichtbaar je eigen opleveringssystemen opnieuw te doordenken en creëer tegelijkertijd de voorwaarden waaronder je teams vrij kunnen experimenteren en wat werkt weer bij jou kunnen aandragen. Het moet zowel van bovenaf als van onderaf gebeuren.
Wanneer slechts één kant betrokken is, stagneert de invoering. Wanneer beide kanten betrokken zijn, krijgt de verandering voet aan de grond.
Volg hem
Je kunt het werk van Anshumani Ruddra volgen op LinkedIn. Bekijk ook zijn blog en zijn cursussen.
Er volgen meer interviews met experts op The Digital Project Manager!
