In de meeste productteams is de backlog een plek waar urgentie gaat sterven. Alles wat erin terechtkomt was urgent toen het werd toegevoegd — een klantenklacht, een verkoopverzoek, een concurrentiekenmerk, een intern idee. Zes maanden later is alles nog steeds daar, voelt alles nog steeds urgent, en niemand weet precies wat te doen.
Het probleem is niet een gebrek aan tools. Er zijn tientallen prioriteringsraamwerken: RICE, MoSCoW, Kano, ICE, gewogen scoring. Het probleem is dat de meeste raamwerken een soort valse nauwkeurigheid vereisen — getallen toewijzen aan onbekenden — wat ze rigoureus doen voelen terwijl je eigenlijk gewoon gut feelings door een spreadsheet wast.
Wat echt werkt is eenvoudiger: twee dimensies, eerlijk beoordeeld, en de discipline om naar het resultaat te handelen.
Prioritering komt neer op twee vragen. Ten eerste: hoeveel verbetert dit het resultaat waar we om geven? (Impactafstand.) Ten tweede: hoeveel zal het ons kosten om het op te leveren? (Inspanning.) Al het andere is ofwel een verfijning van deze twee ofwel een afleiding ervan.
Vertrouwen wordt soms toegevoegd als derde dimensie — "hoe zeker zijn we over de impact?" — en het is nuttig om in gedachte te houden. Maar in de praktijk weten de meeste teams wanneer ze gokken. De discipline is om de gok eerlijk te labelen, niet om deze op een 1-5 schaal in te scoren en aan een formule toe te voegen.
Het moeilijkste deel is niet het begrijpen van het grid — het is eerlijk zijn bij het invullen. Elk team heeft functies die ze willen bouwen die in "Tijdverspillers" thuishoren maar steeds reclassificeren als "Grote inzetten." Het raamwerk werkt alleen als het team eerlijk kan zijn over impact.
Impact is de dimensie die teams het moeilijkst vinden om in te schatten, omdat het vaak het voorspellen van de toekomst vereist. De verleiding is het numeriek in te scoren en je wetenschappelijk te voelen. Een betere aanpak is kwalitatief maar gestructureerd.
Stel drie vragen voor elke functie onder overweging:
Teams schatten inspanning systematisch onder. Dit is goed gedocumenteerd — het hangt samen met de planningsvalkuil en optimismebias — en het is vooral uitgesproken voor functies die meerdere systemen aanraken, coördinatie tussen teams vereisen, of mogelijkheden betreffen die het team nog niet heeft gebouwd.
Twee praktijken helpen. Ten eerste, vraag altijd engineering voordat je inspanning scoreert, niet daarna. PMs die inspanning eenzijdig scoren onderschatten bijna altijd. Ten tweede, gebruik het concept van "onbekende onbekenden" als een expliciete inspanningsvermenigvuldiger. Elke functie die een nieuw codebasegebied aanraakt, een API van derde partij, of een gebruikersstroom die onlangs niet is getest, verdient een inspanningsscore 1,5 keer hoger dan wat het voor de hand liggende werk suggereert.
De meeste urgentie in een productbacklog is niet echte urgentie — het is actualiteit. Een klant klaagde vorige week, dus hun verzoek voelt dringend. Een concurrent lanceerde vorige maand iets, dus het aanpassen voelt kritiek. Maar actualiteit is niet hetzelfde als belang, en reageren op actualiteit is een van de meest betrouwbare manieren om echt belangrijk werk te laten slippen.
Een praktische test: vraag jezelf af of je dit nog steeds urgent zou vinden als je er zes maanden geleden in plaats van vorige week over had gehoord. Als het antwoord nee is, is het actualiteitbias aan het werk, geen strategische prioriteit. Log het, evalueer het kalm tegen het grid, en weersta de neiging om het snel door te zetten alleen omdat het vers is.
Het grid levert niet altijd een schoon antwoord op. Twee items landen in hetzelfde quadrant met vergelijkbare scores, en je moet toch één kiezen. In deze gevallen zijn twee tiebreakers nuttig: strategische afstemming (welke brengt je dichter naar waar je over 18 maanden wilt zijn?) en reversibiliteit (welke is moeilijker ongedaan te maken als het fout is?). Kies het item dat meer strategisch is afgestemd en beter reversibel is.