POM bouwblok 2: governance, cadence en funding voor productgedreven werken.
Dit bouwblok is waar de meeste transformaties stuklopen, niet omdat mensen het niet willen, maar omdat systemen hardnekkig zijn. Je kunt productteams hebben, maar als funding start/stop is en besluitvorming versnipperd, dan blijft je operatie projectmatig.
Cadence: het ritme dat keuzes afdwingt
Productsturing vraagt om een vaste cadans waarin je keuzes maakt en bijstuurt. Niet alleen team-level (sprints), maar ook organisatie-level: kwartaal- of PI-ritme, roadmap reviews, capacity planning en value reviews. Zonder cadence wordt prioritering een ad-hoc competitie.
Een praktische regel: als je portfolio elke week verandert, kun je geen productorganisatie verwachten. Je runt dan een brandweerkazerne met roadmaps als decor.
Besluitvorming: wie mag waarover beslissen?
In projectorganisaties zit besluitvorming vaak verstopt in lagen: stuurgroepen, boards, escalatielijnen. Productorganisaties hebben nog steeds governance, maar expliciteren decision rights:
- Wat beslist het team zelf?
- Wat beslist product management?
- Wat is architectuur- of platformbeleid?
- Wanneer haak je risk/compliance aan?
- Wie kan “stop” zeggen?
Als je dit niet expliciet maakt, ontstaat “schaduwgovernance”: besluiten worden genomen via informele routes, en teams leren dat de formele route tijdverspilling is.
Funding: van start/stop naar continuïteit
Het gevoeligste onderwerp is funding. Veel organisaties hebben valide redenen om projecten te gebruiken: financiële verantwoording, procurement, auditability. Het doel is niet om die realiteit te ontkennen, maar om de operatie productgedreven te maken.
Een pragmatische tussenstap is hybride funding:
- Projecten blijven bestaan als “financiële container”
- Delivery gebeurt via stabiele teams (capaciteitsfinanciering)
- Initiatieven “kopen” capaciteit in plaats van mensen te verschuiven
Dit reduceert context-switching, verhoogt ownership en maakt continu verbeteren mogelijk. En ja: finance moet meebewegen. Niet door te “revolteren”, maar door transparantie te verhogen: duidelijke cost-to-serve, zicht op flow en waarde, en heldere keuzes.
Product governance zonder verstikking
Eigenlijk is hoe je de governance hebt geregeld niet een probleem; onduidelijke governance is dat wel.
Goede productgovernance zorgt voor de volgende zaken:
- borgt risico en compliance “shift left”
- maakt architectuurkeuzes uitvoerbaar
- voorkomt dat teams verzuipen in approvals
Een werkend patroon is “guardrails”: duidelijke normen waarbinnen teams vrij bewegen. Bijvoorbeeld: data-classificatie, security controls, observability, logging, privacy. Teams leveren sneller omdat ze niet voor elk detail toestemming hoeven vragen.
Portfolio naar product: outcomes, flow en kwaliteit
Projectsturing meet scope en planning. Productsturing meet outcomes en flow. Niet omdat planning onbelangrijk is, maar omdat planning zonder outcome een vorm van georganiseerde hoop is.
Een grote organisatie kan starten met drie simpele outcome-vragen:
- Welke klantwaarde is verbeterd?
- Welke risico’s zijn verlaagd?
- Welke kwaliteit is aantoonbaar verhoogd?
Combineer dit met flow-indicatoren: doorlooptijd, wachttijd, deploymentfrequentie, incidenten, rework, etc. Dat maakt gesprekken concreet en minder politiek.
Korte uitleg van de gebruikte afkortingen bij de indicatoren:
- Doorlooptijd (gemiddeld): De totale tijd van “start werk” tot “geleverd”, inclusief wachten en afstemming.
- Wachttijd (gemiddeld): Het deel van de doorlooptijd waarin werk stil ligt (in de rij, wachten op review, afhankelijkheid, akkoord, etc.).
- Flow-efficiëntie: Percentage van de doorlooptijd dat er écht actief aan gewerkt wordt. (Actieve tijd / totale doorlooptijd.)
- Throughput (items per week): Hoeveel werk-items je per week daadwerkelijk afrondt (bijv. stories, tickets, changes).
- WIP (werk in uitvoering): Hoeveel items tegelijk “open” staan in het systeem. Hoog WIP = vaak meer multitasken en langere doorlooptijden.
- Deploymentfrequentie: Hoe vaak je naar productie uitrolt. Een proxy voor leverritme en release-frictie.
- Change fail rate (%): Percentage deploys/changes dat leidt tot een incident, rollback of hotfix. Een kwaliteits- en stabiliteitsindicator.
- MTTR (gemiddeld): Mean Time To Restore/Recover; gemiddelde tijd om een incident te herstellen en de dienst weer stabiel te krijgen.
- Incidenten (per week): Aantal verstoringen per week (vaak productie-issues). Helpt trends en stabiliteit zichtbaar te maken.
- Rework (%): Percentage werk dat opnieuw moet (bugs, herstel, herbouw, heranalyse). Indirect signaal van kwaliteit, requirements-duidelijkheid en techniek.
Volgende post: hoe je teams en organisatievorm zó inricht dat je minder afhankelijkheden creëert en productgrenzen echt werken.
