Häromveckan gjorde jag en lista över alla förbättringar jag skulle vilja bygga in i vår inhouse-mjukvara. Mjukvaran är byggd från scratch sedan ett par år tillbaka, och dess utveckling går hand i hand med företagets utveckling.

Listan med önskade förbättringar blev 49 punkter lång. Alltifrån små enkla UI-grejer, till stora nya funktioner som lär kosta en del. Med nuvarande budget/tempo skulle dessa 49 punkter ta minst två år att realisera. Kanske mer, eftersom det brukar dyka upp nya önskemål under tiden, som gör att vägen mot målet är längre än man trodde.

Vilken av de 49 punkterna ska vi börja jobba med? Och vilka kan vänta? Hur är det möjligt att göra en vettig prioriteringsordning på alla dessa olika förbättringar?

Tre kategorier av uppgifter

Hittills, under de år som gått, har jag mest gått på magkänsla. Plockat den ”lågt hängande frukten”, som klyschan säger: de enkla grejerna, som har stor effekt, och som inte kostar så mycket. Men nu är det ett nytt år och nytt tänk. Jag ville hitta ett mer systematiskt sätt att prioritera listan.

Jag frågade mig: Vilken typ av problem ska mjukvaran lösa?
Insåg att det finns tre huvudkategorier:

1. Pains
2. Risks
3. Opportunities

”Pains” är sådant som helt enkelt är jobbigt. Det kan vara småsaker som är krångliga, som därför dränerar en på energi (fast de hade kunnat vara enkla och friktionsfria). Och det kan vara större saker som gör ont.

”Risks” är sånt som kan ge allvarliga följdfel om de inte fångas upp. I min värld, med kökssnickerier, kan ett litet fel på en ritning bli dyrt att fixa till i verkligheten.

”Opportunities” är de roliga grejerna. Sådant som jag har massor av idéer för. Det är till exempel frön till nya affärsmöjligheter, och metoder för att öka ”konverteringen”. I fallet med mjukvaran handlar det till exempel om hur vi kunna ska hålla koll på alla leads, och hur vi ska underhålla dessa.

Defensivt vs offensivt

De två första kategorierna är defensiva. Att undvika Pains och Risks.
Den tredje är offensiv: Att skapa något nytt.
Det behövs en balans emellan dem för att det ska bli bra, men jag tror att man först bör ta hand om Pains och Risks, innan man satsar på anfall.

Så. När jag hade tagit fram dessa tre kategorier, gjorde jag ett Google Sheet med de 49 punkterna, med tre kolumner till höger, en för varje kategori. I varje ruta satte jag en siffra, 1-5, för hur stor ”pain”, ”risk” och ”opportunity” respektive punkt var. Jag viktade ”pain” högre än ”risk”, och ”risk” högre än ”opportunity”.
Först en bra defensiv, sedan ett effektivt anfall.

Och voilà, nu fick jag fram ett värde på varje punkt. Jag satte en koefficient på värdet och fick fram en summa, i kronor, på vad funktionen faktiskt värd.

Jag la också till en kolumn med kostnaden på vad varje punkt. Det är förstås grova uppskattningar, men nu hade jag alltså värden på vad varje punkt är värd, och vad den kostar. Låg kostnad, högt värde = Lågt hängande frukt. Och vice versa.

Därefter sorterade jag listan på detta värde, och därmed hade prioriteringsordningen satt sig automatiskt.

PRIO

Så, vad skulle jag kalla detta upplägg?
Tja, varför inte göra en akronym.

För att snygga till det, tweakade jag namnet på tredje kategorin till ”Innovation & Opportunities”.

Då landar man här:
Pains.
Risks
Innovations
Opportunity
PRIO.

Så blir det.
Nästa gång jag frågar mig själv hur jag ska prioritera mellan olika saker att göra, kommer jag utgå från PRIO-regeln.
Först ta hand om pains,
sedan eliminera risker,
och till sist utnyttja möjligheterna och skapa nytt.

—
Nästa vecka ska jag berätta mer om framtidsplanerna för Kulladal: Nya produkter och kanske en finansieringsrunda?

Prenumerera på bloggen

[utm_campaign_i][/utm_campaign_i]
[utm_source_i][/utm_source_i]
[utm_medium_i][/utm_medium_i]
[utm_term_i][/utm_term_i]
[utm_content_i][/utm_content_i]
[gclid_i][/gclid_i]