
I de flesta produktteam är eftersläpningen en plats där brådska går för att dö. Allt som kom in i det var brådskande när det lades till — ett kundklagomål, en försäljningsförfrågan, en konkurentfunktion, en intern idé. Sex månader senare är allt fortfarande där, och det känns fortfarande brådskande, och ingen vet riktigt vad de ska göra härnäst.
Problemet är inte bristande verktyg. Det finns dussintals prioriteringsramverk: RICE, MoSCoW, Kano, ICE, viktad poäng. Problemet är att de flesta ramverk kräver en slags falsk precision — tilldelning av siffror till okända — som gör dem kännas rigorösa medan de faktiskt bara tvättar magkänsla genom ett kalkylblad.
Det som faktiskt fungerar är enklare: två dimensioner, ärligt bedömda, och disciplinen att agera på resultatet.
Prioritering kollapsar till två frågor. Första: hur mycket förbättrar detta det resultat vi bryr oss om? (Påverkan.) Andra: hur mycket kommer det att kosta oss att leverera det? (Ansträngning.) Allt annat är antingen en förfining av dessa två eller en distrahering från dem.
Confidence läggs ibland till som en tredje dimension — "hur säkra är vi på påverkan?" — och det är värt att ha i åtanke. Men i praktiken vet de flesta team när de gissar. Disciplinen är att märka gissningen ärligt, inte att poängsätta den på en 1–5 skala och lägga till den i en formel.
Det svåra är inte att förstå griden — det är att vara ärlig när man fyller i den. Varje team har funktioner de vill bygga som hör hemma i "Tidssugare" men fortsätter att omklassificeras som "Stora satsningar." Ramverket fungerar bara om teamet kan vara ärligt om påverkan.
Påverkan är den dimension som team finner svårast att bedöma, eftersom den ofta kräver att förutsäga framtiden. Frestelsen är att poängsätta den numeriskt och känna vetenskaplig om det. En bättre metod är kvalitativ men strukturerad.
Ställ tre frågor för varje funktion under övervägande:
Team underskattade systematiskt ansträngning. Detta är väl dokumenterat — det är relaterat till planeringsfeilen och optimismfördom — och det är särskilt uttalat för funktioner som berör flera system, kräver samordning mellan team eller involverar kapaciteter som team inte har byggt tidigare.
Två metoder hjälper. Först, fråga alltid teknik innan du poängsätter ansträngning, inte efter. PM:er som poängsätter ansträngning ensidigt underskattade nästan alltid. Andra, använd begreppet "okända okända" som en explicit ansträngnings multiplikator. Vilken funktion som helst som berör ett nytt kodbasområde, ett tredjepartAPI eller ett användarflöde som inte har testats nyligen förtjänar ett ansträngningspoäng 1,5x högre än det uppenbara arbetet föreslår.
De flesta brådska i en produkteftersläpning är inte verklig brådska — det är nyhet. En kund klagade förra veckan, så deras förfrågan känns pressande. En konkurrent lanserade något förra månaden, så matching det känns kritisk. Men nyhet är inte detsamma som vikt, och att reagera på nyhet är ett av de mest pålitliga sätten att låta äkta viktigt arbete glida.
Ett praktiskt test: fråga dig själv om du skulle fortfarande överväga detta brådskande om du hade hört om det för sex månader sedan istället för förra veckan. Om svaret är nej, det är nyhetsbias i arbete, inte strategisk prioritet. Logga det, bedöm det lugnt mot griden och motstå dragningen att snabba på det bara för att det är färskt.
Griden producerar inte alltid ett rent svar. Två objekt landar i samma kvadrant med likartade poäng, och du måste fortfarande välja en. I dessa fall är två tiebreakers användbara: strategisk justering (vilken förflyttar dig närmare där du vill vara om 18 månader?) och reversibilitet (vilken är svårare att ångra om det är fel?). Föredra objektet som är mer strategiskt justerat och mer reversibelt.