Waarom productmanagers zelf hun features bouwen

Op Lenny's Podcast liet Meta-productmanager Zevi Arnovitz zien dat het niet langer de ontwikkelaar is die bepaalt hoe snel een product verandert. Zonder technische achtergrond bouwt Arnovitz zelf features in Cursor en Claude Code. Wat voorheen weken wachten op een engineer kostte, heeft hij in een middag op zijn scherm staan. Zijn eigen engineeringteam vraagt hem intussen om uitleg. De verschuiving die hij belichaamt is niet kosmetisch, ze raakt de kernvraag wie in een organisatie eigenaar is van uitvoering.

Van coördinator naar full-stack bouwer

Arnovitz gebruikt AI op drie manieren tegelijk. Hij laat Claude de bouwplannen opstellen voor wat hij wil, Cursor de code schrijven, en een tweede model de uitkomst controleren via een door hem bedachte peer review-stap. Het zijn geen grote systeemwijzigingen, maar kleine UI-aanpassingen, A/B-tests en interne tools waar hij voorheen een ticket voor moest openen. Die kleine veranderingen stapelen op. In het bestek van een kwartaal leveren ze vaak meer gebruikerswaarde dan een grote release.

De bredere beweging die hier zichtbaar wordt, heeft een naam gekregen. In de industrie wordt dit vibe coding genoemd: software bouwen door intentie uit te spreken, niet door regels te typen. Het verschil met klassiek coderen is niet dat de vaardigheid verdwijnt, maar dat ze verschuift. Wie een helder proces kan denken en een goed oordeel heeft over output, is nu bouwer.

Wat verdwijnt en wat verschijnt

De klassieke rol van productmanager is een coördinerende rol: vertalen tussen klant, design, engineering en commercie. Die vertaalslag kostte tijd en was precies het soort werk waar veel waarde verloren ging aan misverstanden. Als een PM zelf het eerste werkende prototype kan neerzetten, verdwijnt een deel van die vertaalstap.

Dat betekent niet dat ontwikkelaars overbodig zijn. Arnovitz bouwt geen kritische backend-systemen en pretendeert dat ook niet. Wat verandert is de rolverdeling: de PM levert een werkend voorbeeld, engineers pakken dat op en bouwen het stevig genoeg voor productie. De discussie gaat niet meer over "wat bedoel je eigenlijk", maar over "hoe maken we dit robuust".

Hetzelfde patroon zie je buiten productontwikkeling. Marketeers die eigen landingspagina's bouwen, HR-medewerkers die hun onboardingflow opzetten, juridische afdelingen die prototypes maken van contractgenerators. Effectief werken met AI is in essentie goed leren managen: duidelijke opdracht, zicht op kwaliteit, bereidheid om te sturen op uitkomst.

Wat dit betekent voor Nederlandse organisaties

Twee patronen vragen bestuurlijke aandacht. Het eerste is de rolverdeling in je eigen teams. Functieprofielen die strikt onderscheid maken tussen bouwen en bedenken worden ongemakkelijk. Wie alleen op coördinatie is ingehuurd, voegt minder toe als coördinatie niet meer het zeldzame goed is. Wie alleen op uitvoering is ingehuurd, raakt in de verdrukking. Teams die daar nu niet actief over praten, krijgen de discussie later alsnog op tafel, aangereikt door medewerkers die met een alternatief aanbod elders naar binnen stappen.

Het tweede is de verhouding tussen experimenteren en opschalen. Wat een PM of marketeer in een middag bouwt, is een werkend prototype, geen productierijp systeem. Organisaties die die twee verwarren, stapelen kleine features op in het hoofdsysteem en raken het overzicht kwijt. De gezonde werkwijze is om de lichtheid van AI-bouwen te benutten voor snel leren, en duidelijke afspraken te maken over wanneer engineering het stokje overneemt.

Waar Dubbel.ai mee kan helpen

De verschuiving naar een werkvloer waar meer mensen zelf bouwen vraagt om afspraken: over wat iedereen zelf mag, waar het stokje wordt overgedragen, en hoe je voorkomt dat shadow AI uitmondt in shadow software. Wij helpen organisaties om die spelregels te maken zonder de nieuwsgierigheid van medewerkers te smoren. Wil je weten hoe zo'n aanpak voor jouw team eruitziet? Plan een kennismaking in, we denken graag mee.