I de fleste produktteam er backloggen et sted hvor hastighet går for å dø. Alt som kom inn i det var haster da det ble lagt til — en kundeklage, en salgsforespørsel, en konkurrentfunksjon, en intern idé. Seks måneder senere er det alt fortsatt der, og det føles hele tiden haster, og ingen vet helt hvilket som skal gjøres neste.
Problemet er ikke mangel på verktøy. Det er dusinvis av prioriteringsrammeverk: RISE, MoSCoW, Kano, IS, vektet scoring. Problemet er at de fleste rammeverk krever en slags falsk presisjon — å tilordne tall til ukjente — som gjør dem føles grundige mens de faktisk bare låner magefølelse gjennom et regneark.
Det som faktisk fungerer er enklere: to dimensjoner, ærlig bedømt, og disiplinen til å handle på resultatet.
Prioritering kollapser til to spørsmål. Først: hvor mye forbedrer dette resultatet vi bryr oss om? (Påvirkning.) Sekund: hvor mye vil det koste oss å levere det? (Innsats.) Alt annet er enten en raffinement av disse to eller en distrahering fra dem.
Tillit blir noen ganger lagt til som en tredje dimensjon — "hvor sikker er vi på påvirkning?" — og det er verdt å ha i bakhodet. Men i praksis vet de fleste teamene når de gjetter. Disiplinen er å merke gjettet ærlig, ikke å score det på en 1–5 skala og legge det til en formel.
Den vanskelige delen er ikke å forstå nettet — det er å være ærlig når du fyller det inn. Hvert team har funksjoner de vil bygge som hører hjemme i "Tidsinkter" men fortsetter å bli omklassifisert som "Store innsatser." Rammeverket fungerer bare hvis teamet kan være ærlig om påvirkning.
Påvirkning er dimensjonen teamene finner vanskeligst å bedømme, fordi det ofte krever å forutsi fremtiden. Fristelsen er å score det numerisk og føle vitenskapelig om det. En bedre tilnærming er kvalitativ men strukturert.
Spør tre spørsmål for hver funksjon under vurdering:
Team underestimerer systematisk innsats. Dette er godt dokumentert — det er relatert til planleggingsfeilen og optimismeforskjellen — og det er særlig uttalt for funksjoner som berører flere systemer, krever koordinering på tvers av team, eller involverer evner teamet ikke har bygd før.
To praksiser hjelper. Først spør alltid ingeniørfag før du scorer innsats, ikke etterpå. PMs som scorer innsats ensidigt undervurderer nesten alltid. Sekund, bruk konseptet "ukjente ukjente" som en eksplisitt insatssmultiplikator. Enhver funksjon som berører et nytt kodebasisområde, en tredjepartsAPI, eller en brukerflyt som ikke har blitt testet nylig fortjener en innsatsscore 1,5x høyere enn det opplagte arbeidet foreslår.
De fleste av hastigheten i en produktbacklog er ikke reell hastighet — det er nyhet. En kunde klaget forrige uke, så deres forespørsel føles presserende. En konkurrent lanserte noe forrige måned, så tilsvarende det føles kritisk. Men nyhed er ikke det samme som viktighet, og reaksjon på nyhed er en av de mest pålitelige måtene å la virkelig viktig arbeid gli.
En praktisk test: spør deg selv om du ville fortsatt vurdert dette haster hvis du hadde hørt om det for seks måneder siden i stedet for forrige uke. Hvis svaret er nei, er det nyhetsbias på arbeid, ikke strategisk prioritet. Logg det, vurdert det rolig mot nettet, og motstå trekk til å spole det bare fordi det er fersk.
Nettet gir alltid en ren svarer. To gjenstander lander i samme kvadrant med lignende score, og du må fortsatt velge en. I disse tilfellene er to brekslutninger nyttige: strategisk justering (hvilken flytter deg nærmere hvor du vil være om 18 måneder?) og reversibilitet (hvilken er vanskeligere å angre hvis det er feil?). Foretrekk gjenstanden som er mer strategisk justert og mer reversibel.