Lösningsfällan i prioritering

Organisationer lider sällan brist på idéer. Ledningen ser möjligheter, problem och sådant som skulle kunna förbättras; nya funktioner, integrationer, automatiseringar, förmågor och systemförändringar. När idéerna är fler än vi har kapacitet att genomföra behöver vi prioritera.

Frågan är vad vi prioriterar.

I komplexitet kan effekten av det vi levererar bero på många saker: hur människor agerar, hur tekniken fungerar, organisatoriska beroenden, konkurrerande behov eller hur ett större system reagerar. Därför kan vi inte veta på förhand vilken lösning som kommer att skapa den effekt vi vill uppnå. Vi kan ha data, erfarenhet och goda skäl att tro att en idé kommer att fungera, men tills vi ser vad som faktiskt händer är den fortfarande en hypotes.

Ändå är det förvånansvärt vanligt att vi prioriterar som om vi redan visste. Krav, behov och lösningsidéer hamnar i backloggen. Vi kanske till och med börjar kalla dem Epics. Sedan förfinar vi dem, jämför dem och prioriterar dem mot varandra. Formen har förändrats, men frågan vi försöker besvara är fortfarande densamma: Vilken lösning ska vi bygga först?

Det är en rimlig fråga när vi vet vad som behöver byggas. I komplexitet behöver en annan fråga komma först: Vilken förändring är viktigast för oss att åstadkomma nu?

I övergången från projektomfattning till produktbacklogg finns en risk att vi börjar prioritera lösningar istället för de effekter vi vill uppnå.

Det kan verka som en liten skillnad, men den förändrar vad vi skapar riktning kring. En prioriterad backlog med lösningar talar om i vilken ordning vi ska bygga saker. Ett effektmål talar om vilken förändring vi vill åstadkomma.

Det betyder inte att ledningen ska sluta ha idéer om lösningar. De kan vara både värdefulla och välgrundade. Skillnaden är att en idé inte automatiskt behöver bli framtida arbete, utan kan få förbli ett möjligt sätt att uppnå en önskad effekt. Då finns det fortfarande utrymme för teamet att hitta en annan lösning, en enklare lösning eller kanske något betydligt mindre som skapar samma effekt.

Det påverkar också hur vi ser på backloggen. Om varje lösningsidé blir något vi planerar att bygga växer den lätt till en lista över arbete månader eller till och med år framåt. Det som från början var idéer och möjligheter börjar då likna en plan för framtiden.

Men det vi lär oss av dagens bygge bör påverka vad vi väljer att bygga imorgon. Ju mer av framtiden vi redan har fyllt med sådant vi har bestämt oss för att bygga, desto mindre utrymme finns kvar för det vi ännu inte har lärt oss.

Att tänka långt framåt är alltså inte problemet. Tvärtom behöver vi ha en långsiktig bild av vart vi vill och vilka förändringar vi vill åstadkomma. Det vi inte behöver bestämma långt i förväg är exakt vad vi ska bygga för att komma dit. En backlog kan bevara idéer om framtiden. Den behöver inte bestämma framtiden.

Om vi istället väntar med vissa beslut tills vi har hunnit lära oss mer kan vi också upptäcka att betydligt mindre behöver byggas än vi först trodde. Om tre Stories skapar tillräckligt av den önskade effekten finns det kanske ingen anledning att bygga Story fyra till tio. Det är inte ogjort arbete utan sådant vi upptäckte att vi inte behövde bygga.

Och det har betydelse. Varje funktion, integration och förmåga vi lägger till ska sedan underhållas, supporteras, testas, säkras och förändras över tid. Det vi bygger i onödan kostar två gånger: först att bygga, sedan att äga.

Det är lösningsfällan i prioritering: vi tror att vi prioriterar, men det viktigaste valet är redan gjort. Vi har redan bestämt vad vi ska bygga innan vi vet vilken förändring som är viktigast att åstadkomma.

Att prioritera lösningar är inte samma sak som att skapa riktning. Vi behöver vara tydliga med vilka effekter som är viktigast – och vänta med beslutet om vad vi ska bygga tills vi vet tillräckligt för att fatta det.

Se helheten

Lösningsfällan i prioritering är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.

Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.