In de meeste productteams is de backlog de plek waar urgentie sterft. Alles wat erin terechtkomt was urgent toen het werd toegevoegd — een klacht van een klant, een verzoek van sales, een feature van een concurrent, een intern idee. Zes maanden later staat alles er nog steeds, voelt alles nog steeds urgent en weet niemand precies wat er als volgende moet gebeuren.
Het probleem is niet een gebrek aan hulpmiddelen. Er zijn tientallen prioriteringsframeworks: RICE, MoSCoW, Kano, ICE, gewogen scoring. Het probleem is dat de meeste frameworks een soort schijnprecisie vragen — getallen toekennen aan onbekenden — waardoor ze degelijk aanvoelen terwijl je in feite alleen onderbuikgevoel door een spreadsheet witwast.
Wat echt werkt, is eenvoudiger: twee dimensies, eerlijk beoordeeld, en de discipline om naar de uitkomst te handelen.
Prioriteren komt neer op twee vragen. Ten eerste: hoeveel verbetert dit de uitkomst waar we om geven? (Impact.) Ten tweede: hoeveel kost het ons om het op te leveren? (Inspanning.) Al het andere is een verfijning van deze twee of een afleiding ervan.
Soms wordt zekerheid (confidence) als derde dimensie toegevoegd — "hoe zeker zijn we van de impact?" — en dat is het onthouden waard. Maar in de praktijk weten de meeste teams wel wanneer ze gokken. De discipline is om de gok eerlijk als zodanig te benoemen, en haar niet op een schaal van 1–5 te scoren en in een formule te stoppen.
Het moeilijke is niet de matrix begrijpen — het is eerlijk zijn bij het invullen. Elk team heeft features die het graag wil bouwen en die thuishoren bij "Tijdverspillers", maar die steeds worden herschikt naar "Big bets". Het framework werkt alleen als het team eerlijk kan zijn over impact.
Impact is de dimensie die teams het moeilijkst vinden om in te schatten, omdat je vaak de toekomst moet voorspellen. De verleiding is om er een cijfer aan te hangen en je wetenschappelijk te voelen. Een betere aanpak is kwalitatief maar gestructureerd.
Stel bij elke feature die je overweegt drie vragen:
Teams onderschatten inspanning stelselmatig. Dat is goed gedocumenteerd — het hangt samen met de planning fallacy en optimism bias — en komt vooral voor bij features die meerdere systemen raken, coördinatie tussen teams vereisen of mogelijkheden omvatten die het team nog niet eerder heeft gebouwd.
Twee werkwijzen helpen. Vraag ten eerste altijd eerst aan engineering voordat je de inspanning scoort, niet erna. PM's die de inspanning in hun eentje scoren, onderschatten bijna altijd. Gebruik ten tweede het concept van "unknown unknowns" als expliciete vermenigvuldiger voor inspanning. Elke feature die een nieuw deel van de codebase raakt, een API van een derde partij of een gebruikersflow die niet recent is getest, verdient een inspanningsscore die 1,5 keer hoger ligt dan het voor de hand liggende werk doet vermoeden.
Het merendeel van de urgentie in een productbacklog is geen echte urgentie — het is recency. Een klant klaagde vorige week, dus zijn verzoek voelt dringend. Een concurrent lanceerde vorige maand iets, dus het evenaren daarvan voelt kritiek. Maar recency is niet hetzelfde als belang, en reageren op recency is een van de betrouwbaarste manieren om echt belangrijk werk te laten liggen.
Een praktische test: vraag jezelf af of je dit nog steeds urgent zou vinden als je er zes maanden geleden over had gehoord in plaats van vorige week. Is het antwoord nee, dan is het recency bias aan het werk en geen strategische prioriteit. Leg het vast, beoordeel het rustig aan de hand van de matrix en weersta de neiging om het voorrang te geven alleen omdat het nieuw is.
De matrix levert niet altijd een eenduidig antwoord op. Twee items belanden in hetzelfde kwadrant met vergelijkbare scores en je moet toch kiezen. Dan zijn twee beslisregels handig: strategische aansluiting (welke brengt je dichter bij waar je over 18 maanden wilt zijn?) en omkeerbaarheid (welke is moeilijker terug te draaien als het fout blijkt?). Kies het item dat het best past bij je strategie en makkelijker terug te draaien is.