Een pleidooi voor de Enabling Engineer

Proloog

We gebruiken overal dezelfde woorden. Product. Product Manager. Agile. Engineer. En we doen alsof ze overal hetzelfde betekenen. Dat doen ze niet. En met AI erbij gaat dat ons nu geld kosten.

Dit is een pleidooi voor de Enabling Engineer, en voor de beweging waar hij bij hoort: forward-deployed engineering, vakmanschap naar de frontlinie, dicht op de klant en de business. Maar wíé je naar voren schuift, en met welke controlelaag, hangt af van één vraag die bijna niemand hardop stelt: wat is je echte product?

Onderweg stel ik er nog een paar. In welke wereld sta je? Bouw je het product, of iets wat het product mogelijk maakt? Waar zit je rem, nu bouwen zo goedkoop is geworden? En wie stuurt de engineer aan als de Product Owner geen mandaat heeft?

Op die laatste ga ik zelf aan. De Product Owner zonder mandaat was altijd al vooral een vertaler, en die vertaling los je op twee manieren op: je automatiseert haar, of je vangt haar af met opleiding. Ik ga met beide aan de slag; wat ik bouw, bouw ik transparant, want een controle die je niet kunt inspecteren, is geen controle.

Wat is eigenlijk jouw product?

"Wij willen een techbedrijf worden met een bankvergunning." Zo verwoordde ING zijn ambitie, jaren geleden. Een mooie zin. En toch fout.

ING is een bank. De technologie is alleen onmisbaar geworden, zo onmisbaar dat het voelt als de kern. Maar je klant betaalt niet voor de software. Hij betaalt voor een hypotheek, een betaalrekening, vertrouwen met zijn geld. De software maakt dat mogelijk. Op briliante wijze, misschien. Maar ze is het middel, niet het product.

Een techbedrijf met een bankvergunning? Nee. Een bank waarvan de IT alleen onmisbaar is geworden.

Klinkt als een woordspelletje. Is het niet. Dit verschil bepaalt letterlijk hoe je je organiseert, wie welke beslissing neemt, en straks hoe AI je rollen hertekent.

Neem Picnic. Een van de meest technologiegedreven bedrijven van het land: algoritmes, routeoptimalisatie, een strakke app. En tóch betaal je Picnic niet voor software. Je betaalt voor boodschappen, morgenvroeg voor je deur. De Product Manager daar werkt aan de app en de routing, en draagt daarmee bij aan één ding: die boodschappen, op tijd, bij jou. De software is onmisbaar. Ze is niet het product.

Zet die Product Manager naast een Product Manager bij een SaaS-bedrijf. Dezelfde functietitel. Dezelfde ceremonies. Dezelfde taal. En toch niet dezelfde rol. De een dient de boodschappen; de ander dient een product dat zichzelf ís. Zelfde woord, tegengestelde zwaartekracht.

• De lakmoesproef
• Waar betaalt je klant werkelijk voor? Voor het ding dat je bouwt, of voor iets anders dat jouw bouwsel alleen maar mogelijk maakt? Dat antwoord bepaalt in welke wereld je leeft. En het wordt bijna nooit hardop gegeven.

Dit is geen nieuw idee. Strategen kennen het als core versus context. Nieuw is wat AI ermee doet: het maakt het fout hebben van dit onderscheid plotseling duur. Want iedereen voelt het al. Een ervaren Product Manager weet donders goed dat Picnic iets anders is dan een softwarehuis, maar we hebben er geen ander woord aan gegeven. Dus plakken we het ene playbook op de andere wereld, en vragen ons af waarom het schuurt. Tijd om die scheiding een naam te geven.

De tweedeling

Uit die ene vraag vallen twee werelden. Van buiten zien ze er identiek uit: teams, sprints, backlogs. Maar ze dienen een ander doel. En dat verandert alles wat erop volgt.

Wereld één: IT ís het product. Een boekhoudpakket, Slack, een simpele site die je pdf naar Word omzet. Wat je bouwt is precies wat je verkoopt. Er zit niets tussen je code en de waarde voor de klant. De software is geen middel; ze is het einddoel.

Wereld twee: IT dient het primaire proces. Boodschappen, auto's, bankieren, verzekeren, logistiek. Hier is IT, hoe geavanceerd ook, dienend. Onmisbaar, vaak zelfs beslissend voor wie wint. Maar in dienst van een product dat buiten de IT ligt.

De grens is scherp, met één zeldzame uitzondering. Soms kantelt een dienend onderdeel en wordt het zélf een product. De bodemplaat van de Volkswagen Golf zit óók onder de Audi en de Škoda: wat een intern component was, is een herbruikbaar platform geworden, met een eigen roadmap en eigen afnemers. Maar let op: dat is de uitzondering, niet de regel. Picnic's software dient het primaire proces, boodschappen bij je deur, en blíjft enabling. Tot de dag dat Picnic zijn routing-engine aan Albert Heijn verkoopt. Dán, en pas dán, steekt ze over naar wereld één.

Die Product Manager bij Picnic is niet fout bezig. Hij dient terecht de boodschappen, tenzij Picnic de routing aan Albert Heijn verkoopt.

Tot nu toe deed de verwarring er niet zoveel toe. De twee werelden konden elkaars taal lenen zonder veel schade; je plakte "Product Manager" en "agile" overal op en het werkte redelijk. Waarom zou je dan nu wél scherp moeten zijn? Omdat AI op het punt staat te herdefiniëren wat elke wereld nodig heeft. En wie niet weet in welke wereld hij staat, kopieert straks het verkeerde playbook. Sneller dan ooit.

AI zet de grens tussen product en engineering onder druk

Rollen verbreden. Dat is het eerste wat AI met een organisatie doet: iemand kan ineens werk aan dat vroeger drie functietitels vroeg. Klinkt als winst. Is het ook. Maar het gebeurt in twee richtingen, en het gaat mis op één plek, in béíde.

De engineer wordt naar voren getrokken. Met AI naast zich overziet hij meer van de business, vertaalt hij sneller een klantvraag, werkt hij dichter op de frontlinie. Dit is de beweging die de industrie "forward-deployed" is gaan noemen.

En de Product Owner wordt naar het bouwen geduwd. Diezelfde AI laat hem ineens "zelf bouwen": een prototype, een script, een hele feature, uitgesproken tegen een agent. Het spiegelbeeld van de eerste beweging. Het bestaat al, en het voelt als magie.

‍

Neem het boekhoudpakket dat ik laatst met AI bouwde. Weken werk, en niet door de code; die was zo gebouwd. De tijd ging zitten in het écht snappen. Vraag een AI om "een balans" en je krijgt een balans. Maar het verschil tussen een saldibalans en een fiscale balans? Als je dat niet vertelt, bouwt hij de verkeerde: overtuigd, netjes, en fout. Niet de code was de bottleneck. Mijn domeinkennis was het.

Goedkoop betekent niet goed. "Made in China" stond ooit voor rommel; inmiddels komt er topkwaliteit vandaan, maar alleen als je er expliciet om vraagt, en weet wát je vraagt. Zo is het met AI-uitvoering ook. Ze is goedkoop en snel, en ze kan uitstekend zijn, mits je de juiste vraag stelt. En die vraag stellen is het werk. Dat is het vakmanschap.

Dat vakmanschap kent twee gedaanten, en hier gaat het vaak mis. Trek je een engineer naar voren, dan brengt hij technisch vakmanschap mee, maar hij moet leren wat de business waardevol maakt. Duw je een Product Owner naar het bouwen, dan kent hij de waarde, maar hij moet de architectuur leren. Béíde bewegingen zijn forward-deployment. Béíde zijn veilig zólang de ontbrekende controlelaag meekomt: via een framework, goede reviewcycli en tools die een expert heeft opgezet, of gewoon via opleiding. En béíde zijn gevaarlijk zonder.

Het gevaar is nooit de richting waarin je iemand naar voren schuift. Het gevaar is naar voren schuiven zónder de controle die de wereld vereist.

En daarmee is de echte vraag niet "engineer of Product Owner?", maar: wie bezit het oordeel over waarde, de rol zelf, of de business eromheen? Dat antwoord verschilt per wereld.

Skills, niet headcount

Vergeet even de functietitels. Kijk naar wat ze eigenlijk zijn: bundels skills die we voor het gemak in één persoon hebben gepropt.

Productmanager, engineer, UX-ontwerper, tester, business-analist, architect, SRE, data scientist. Stuk voor stuk verzamelingen vaardigheden. En had je meer vaardigheden nodig, dan had je vroeger precies één hefboom: meer mensen. Eén hoofd per skill. Schalen was aannemen.

AI draait die hefboom om. AI levert de uitvoering: het typt de code, schrijft de tests, vult de tabel, tekent de eerste versie. Handjes zijn niet langer schaars. Wie op de oude reflex leunt en mensen bijhuurt om sneller te gaan, koopt het verkeerde in.

Want, en dit is de hele grap, "AI levert de uitvoering" betekent ook "AI doet precies wat je zegt". Goedkoop, maar niet gratis, en zeker niet vanzelf goed. Je hebt iemand nodig die weet wat te vragen, en die ziet of het antwoord deugt. De schaarste verschuift van doen naar richten en oordelen: architectuur, vakmanschap, domeinkennis.

Je schaalt niet meer met mensen die het werk doen, maar met een enkeling die een zwerm agents aanstuurt, en ziet wanneer die zwerm de verkeerde kant op marcheert.

Zo bedoel ik die zwerm: één mens houdt het oordeel, de agents doen de uitvoering. Dat is de nieuwe eenheid van productiviteit. En het geldt in béíde werelden: hetzelfde geld dat vroeger naar tien paar handen ging, gaat nu naar een handvol mensen mét oordeel plus de agents die zij aansturen. De vraag aan de bestuurstafel verschuift daarmee. Niet langer "hoeveel mensen per skill?", maar "welk oordeel zit waar, en wat stuurt het aan?" En dat oordeel woont in de twee werelden op een andere plek.

Use case 1: de product organisatie

In de wereld waar IT het product ís, gebeurt iets tegen-intuïtiefs. De oude angst, "straks zit product onder engineering", draait om. Product komt niet onder engineering. Engineering komt ín product.

Logisch ook. Als de uitvoering door agents gebeurt, is "engineer" geen aparte afdeling meer om werk aan over te dragen. Het is een vaardigheid die de productmensen zelf in handen krijgen. Product Management verdwijnt hier niet; het blíjft de kern. Alleen krijgt het er een been bij, en verdeelt het zich langs een simpele as: tijd.

De Product Manager wórdt de Product Engineer, en bouwt morgen. Hierin versmelten strategisch én technisch productmanagement met engineering. Deze rol ontdekt en bouwt wat er nog niet is: het volgende product, de volgende doorbraak. Kansen en architectuur in één hoofd.

Operations draait vandaag. Hierin versmelten productmarketing, operatie en engineering: maak én run. Niet omdat die dingen hetzelfde zijn, maar omdat één mens met agents ze nu kan overzien. Deze rol houdt het bestaande product gezond voor bestaande klanten: verbeteren, bijsturen, laten draaien, laten groeien.

Hier bezit de rol het oordeel over waarde: er is immers geen business die dat voor je doet; het product ís de business. En precies daarom is deze wereld symmetrisch veeleisend. Kom je van product, dan moet je echte engineering-skills bouwen, of een framework en guardrails meekrijgen die dat opvangen. Kom je van engineering, dan moet je het hele product-management-repertoire leren.

Dat repertoire is geen mysterie. Er bestaat een bekende plaat die alle taken van productmanagement in blokjes uittekent, langs één as: van strategie links naar executie rechts. Het is een slimme weergave, en een prima ontleedmes. Aan de strategiekant de blokjes die over morgen gaan: marktproblemen, win/loss-analyse, marktdefinitie, positionering, de product-roadmap, buyer- en user-persona's. Aan de executiekant die over vandaag gaan: requirements, launchplan, sales-proces, collateral, readiness, support. Leg die plaat naast de twee rollen en je ziet grofweg welk blokje waarheen stroomt: de strategische, marktgerichte kant naar de Product Engineer; de executie- en run-kant naar Operations.

De duizendpoot-druk is hier dus reëel, maar hanteerbaar. Het worden twee brede rollen, geen enkele onmogelijke. En het doel is nooit "iedereen doet alles". Het doel is oordeel plus vakmanschap, gedragen door agents, met het ontbrekende been er expliciet bij gebouwd.

Use case 2: de enabling organisatie

De enabling-wereld draait dat om. Het oordeel over waarde ligt hier niet in de rol maar in de business. Ik bouw software vóór een boodschappendienst of een financieel product; het is niet mijn product. Het probleem komt daar vandaan: "de koekjes moeten kleiner, sneller, goedkoper. Los op."

De uitvoerende rol is de Enabling Engineer. En let op die naam, want de industrie beweegt naar een andere term, "Forward-Deployed Engineer", en die slaat de plank mis. "Forward-deployed" beschrijft waar iemand staat: naar voren, dicht op de frontlinie. Maar de Product Engineer uit het vorige deel staat óók naar voren. Positie onderscheidt de twee dus niet. Wat hen scheidt is hun doel: de een levert product, de ander enabelt. Noem hem dan ook naar wat hij doet.

"Forward-deployed" benoemt de logistiek, niet het doel. De een staat naar voren om product te leveren; de ander om te enabelen.

En ja, dit pleidooi draagt precies dát woord. Geen slordigheid. Als functietitel voor één rol deugt "forward-deployed" niet; als naam voor de beweging, vakmanschap naar voren in beide werelden, deugt hij juist wél. Ik kom er in het slot op terug.

Door AI is die Enabling Engineer razendsnel geworden, en hij spreekt steeds meer de taal van de business. Precies daar ontstaat een nieuw probleem. Als IT niet langer de rem is, waar zit de rem dan wél?

De rem verschuift naar de business zelf. De mensen die boodschappen bezorgen of geld beleggen kunnen niet zo snel beslissen en verwoorden als engineering nu kan bouwen. De frictie zit niet meer tussen wens en techniek. Ze zit tussen de business en haar eigen vermogen om te zeggen, en te besluiten, wat ze wil.

‍

Let op wat hier níét gebeurt: Product Management verdwijnt niet. Integendeel: het blijft de kernrol op de naad tussen business en engineering. Wat verdwijnt is de mandaatloze tussenpersoon, de proxy Product Owner. En dat is geen nieuw "ongemak". Scrum.org beschrijft de proxy Product Owner al jaren als anti-patroon: "a bottleneck … as they do not have any decision making authority." SAFe plaatst de Product Owner in het team, als onderdeel van een grotere Product Management-functie, dus het mandaat zit hoger. En juist in gereguleerde sectoren, bank en verzekering, ligt de beslissing sowieso elders: bij risk, compliance, de business. In een survey onder 26 transformerende organisaties (Wolpers, 2026) veranderde er bovendien precies één fundamenteel hóé werd besloten wát er gebouwd wordt; het beslissysteem bleef waar het zat. Nieuw is dus niet het probleem. Nieuw is dat je er nu iets aan kunt doen.

De Product Manager blíjft, met mandaat, op de naad, en stuurt de Enabling Engineer nu aan via een specify-laag: deels tooling (denk aan het specificeer-gedeelte van moderne agent-frameworks), deels opleiding, die business-intentie in een spec vangt waar de engineer mee bouwt. De mandaatloze doorgeefrol ertussenuit; de vertaling geautomatiseerd of aangeleerd.

De business bezit en beslist, de Product Manager weegt en prioriteert, de specify-laag vertaalt naar de engineer. Niemand die eigenaarschap veinst dat hij niet heeft. Precies wat de proxy Product Owner altijd wél deed.

Naar voren

Dit is het pleidooi, in één zin: schuif vakmanschap naar de frontlinie, maar weet eerst wat je echte product is, want dat bepaalt wélke controlelaag meemoet.

Doe dat, en de rest volgt. In de productwereld wordt de Product Manager de Product Engineer, en vouwt engineering zich ín product en ops, verdeeld over morgen en vandaag. In de enabling-wereld blíjft de Product Manager, op de naad met de business, en stuurt hij de Enabling Engineer aan via een specify-laag of via opleiding. Product Management verdwijnt in geen van beide; het verandert alleen van gedaante.

Béíde rollen zijn forward-deployed. Dat is de kern van dit pleidooi: niet één nieuwe functietitel, maar een beweging. Vakmanschap naar voren, met de controlelaag die elke wereld vereist. Fake die breedte niet. Een Product Owner die via AI bouwt zonder de architectuur te snappen, voelt productief en stapelt schuld. Een engineer die naar voren komt zonder de business te leren, bouwt onberispelijk het verkeerde. Geen romantiek over handwerk, gewoon hoe je grip houdt als de uitvoering goedkoop wordt.

Snelheid was nooit het punt. Grip is het punt. De rem is niet langer de techniek; het is de business die moet bijhouden hoe goedkoop bouwen geworden is.

De eerlijke vervolgvraag. En dan? Ik ga je geen keurig stappenplan voor maandagochtend verkopen; dat heb ik zelf namelijk nog niet. Wat ik wél heb, zijn de vragen die volgens mij op tafel horen:

1. In welke wereld sta je? Per productlijn, niet per bedrijf. Is dít het product, of iets wat het product mogelijk maakt?
2. Waar zit je nieuwe rem? Als IT niet langer remt, wie dan wel? En durf je toe te geven dat het de business zelf is?
3. Trek je vakmanschap naar voren, of fake je breedte? Bouw je het ontbrekende been erbij, via een framework, tools, of opleiding, of hoop je dat het vanzelf goed komt?
4. Wie overbrugt de kloof naar de business, en doe je dat met tooling, met opleiding, of allebei?

Die laatste houdt me het meest bezig. De vertaling die de mandaatloze proxy altijd al was, valt te automatiseren én op te leiden, en aan allebei ga ik werken. Wat ik bouw, bouw ik in de open lucht. Een controlelaag die je niet kunt inspecteren is geen controle, maar een nieuwe zwarte doos. Precies wat je bij AI wilt vermijden. Een open, gedeelde specify-laag is een betere weg dan een dichtgetimmerd product. Daar gaat een vervolg over.

_{This is a case and a stance, meant to test whether the distinction resonates and whether the pain is recognized. Companies and products named serve as illustration, not as case study or recommendation. The Product Owner's limited mandate is broadly documented (among others Scrum.org and SAFe; data from Wolpers' 2026 survey).}

_{Connects to the adoption model From Handwork to Agents: that model is deliberately abstract; this piece makes it concrete with the question of your real product.}

‍

‍

‍

‍