I de flesta produktteam är backloggen en plats där brådska går för att dö. Allt som kommer in var brådskande när det lades till: ett kundklagomål, en säljförfrågan, en funktion hos en konkurrent, en intern idé. Sex månader senare ligger allt kvar, det känns fortfarande brådskande och ingen vet riktigt vad man ska ta tag i härnäst.
Problemet är inte brist på verktyg. Det finns dussintals ramverk för prioritering: RICE, MoSCoW, Kano, ICE, viktad poängsättning. Problemet är att de flesta ramverk kräver en sorts falsk precision, där man sätter siffror på det okända, vilket får dem att kännas stringenta men egentligen 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 kokar ner till två frågor. Den första: hur mycket förbättrar detta det resultat vi bryr oss om? (Effekt.) Den andra: hur mycket kostar det oss att leverera? (Insats.) Allt annat är antingen en förfining av dessa två eller en distraktion från dem.
Konfidens (confidence) läggs ibland till som en tredje dimension – ”hur säkra är vi på effekten?” – och det är värt att ha i åtanke. Men i praktiken vet de flesta team när de gissar. Disciplinen ligger i att märka gissningen ärligt, inte i att poängsätta den på en skala från 1 till 5 och lägga in den i en formel.
Det svåra är inte att förstå matrisen, utan att vara ärlig när man fyller i den. Varje team har funktioner de vill bygga som hör hemma under ”Tidstjuvar” men som hela tiden omklassificeras till ”Stora satsningar”. Ramverket fungerar bara om teamet kan vara ärligt om effekten.
Effekt är den dimension som team har svårast att bedöma, eftersom det ofta krävs att man förutspår framtiden. Frestelsen är att poängsätta den numeriskt och känna sig vetenskaplig. Ett bättre angreppssätt är kvalitativt men strukturerat.
Ställ tre frågor för varje funktion som övervägs:
Team underskattar systematiskt insatsen. Det är väldokumenterat – det hänger ihop med planeringsfelslutet och optimismbias – och är särskilt tydligt för funktioner som berör flera system, kräver samordning mellan team eller innebär förmågor som teamet inte har byggt tidigare.
Två arbetssätt hjälper. För det första: fråga alltid utvecklingsteamet innan du poängsätter insatsen, inte efteråt. Produktchefer som poängsätter insatsen på egen hand underskattar den nästan alltid. För det andra: använd begreppet ”okända okända” som en uttrycklig multiplikator på insatsen. Varje funktion som rör ett nytt område i kodbasen, ett tredjeparts-API eller ett användarflöde som inte har testats nyligen förtjänar en insatspoäng som är 1,5 gånger högre än vad det uppenbara arbetet antyder.
Det mesta av brådskan i en produktbacklog är inte verklig brådska, utan närhet i tid. En kund klagade förra veckan, så kundens önskemål känns pressande. En konkurrent lanserade något förra månaden, så att matcha det känns avgörande. Men det som är nytt är inte detsamma som det som är viktigt, och att reagera på det nya är ett av de mest pålitliga sätten att låta verkligt viktigt arbete glida undan.
Ett praktiskt test: fråga dig själv om du fortfarande skulle se detta som brådskande om du hade fått höra om det för sex månader sedan i stället för förra veckan. Om svaret är nej handlar det om att det nya väger för tungt, inte om strategisk prioritet. Logga det, bedöm det lugnt mot matrisen och stå emot lockelsen att köra om det i förtur bara för att det är färskt.
Matrisen ger inte alltid ett tydligt svar. Två punkter hamnar i samma kvadrant med liknande poäng, och du måste ändå välja en. I de fallen är två avgörande kriterier användbara: strategisk riktning (vilken tar dig närmare där du vill vara om 18 månader?) och reversibilitet (vilken är svårare att ångra om den visar sig vara fel?). Välj det alternativ som ligger mer i linje med strategin och som är lättare att backa från.