Vi må snakke om prioritering
Vel, det snakkes selvsagt en hel del om prioritering allerede – alle skjønner at vi må forsøke å bruke det vi har av kapasitet der hvor det betyr mest. Der det gir mest verdi. Men hva mener vi egentlig med ordet “verdi”? Og hvem er “vi”? Dette kan høres ut som halvinteressante filosofiske spørsmål, men jeg tror det er mye mer potent enn som så. Det er slike spørsmål som kan ruste oss til å gjøre riktige prioriteringer og ikke minst skape alignment – en felles sterk forståelse av hva som er viktig for suksess. Ingen sak egentlig, å prioritere noe opp. Det som er vanskelig (og som egentlig er prioritering) er å bestemme oss for hva vi skal prioritere ned.
Det er hovedsakelig to grunner til at det er viktig å beherske prioriteringens kunst:
1) Å kanalisere energien i selskapet i en bestemt strategisk retning og
2) Unngå overbelastning.
Strategisk retning
Det snakkes mye om felles fokus og samkjøring (alignment) av organisasjonen, men det virker som få får det til i praksis. Jeg tror det er mange årsaker til dette. En ganske åpenbar forklaring er at prioritering er ubehagelig – siden det innebærer å gi tommel ned. Det vil være noen som ikke får det de mener de har rett på. Det kan være mange ulike interessenter rundt et produkt som hver og en mener de har en solid case som fortjener fokus. Å si nei til disse betyr at de blir skuffet, kanskje til og med sinte. Tydelig, klar prioritering vil aldri oppleves rettferdig for alle. Det er mye mer behagelig å tilfredsstille alle littegrann, enn å fokusere på bare én på bekostning av alle de andre.
Overbelastning
Det virker som mange produktorganisasjoner er i en konstant tilstand av overbelastning, der man hele tiden febrilsk forsøker å ta igjen det tapte. Arbeidsdagene blir dominert av heseblesende multitasking – noe som vi mennesker stadig innbiller oss at vi behersker godt. I neste omgang blir vi tvunget til å jobbe fokusert med den ene tingen som brenner aller mest. Dette gir et dårlig klima både for innovasjon, forbedringsarbeid og kompetansedeling. Vi trenger faktisk å ha en grad av overskudd og ledig kapasitet for å sikre at vi hele tiden evner å utvikle oss som organisasjon, og å ta vare på det vi oppdager underveis.
Innen produktutvikling er det vanskelig å ta igjen det tapte ved å bemanne opp (Brooks). Den reelle kapasiteten øker saktere enn vi håper, og den er sjelden lineær. Nei, det beste man kan gjøre for å komme ut av en slik tilstand er å begynne å prioritere ting ned – på strategisk nivå; være klare og tydelige på hva vi skal unngå å bruke kapasitet på.
Typiske dilemmaer og potensielle kandidater til nedprioritering
Jeg har samlet en del erfaring som konsulent innen Scrum og smidig og her kommer en (ikke uttømmende) liste over typiske områder som kan lede til overbelastning og manglende fokus hvis de ikke håndteres strategisk, tydelig og gjennomført. Man må bestemme seg – hva skal veie tyngst?
Valg av kundesegment
Vi kan ikke tilfredsstille alle. I hvert fall ikke med en gang. Her er det gylne anledninger til å prioritere så det monner. Det kan være at visjonen (4-5 år) er “verdensherredømme” i et bestemt marked – men vi må begynne smalt og vinne erfaring og bevise at vi er på rett vei i et snevert kundesegment.
Det er også vanlig at man etter noen suksessrike år har “pådratt seg” en rekke små og ulønnsomme kunder. Det kan virke brutalt, men allikevel nødvendig å sanere kundeporteføljen fra tid til annen.
En “nordstjerne”?
Finnes det én egenskap som trumfer alt annet? I så fall kan dette være en ekstremt kraftfull mekanisme for prioritering. Edgeir Aksnes i Tibber hevdet for et par år siden (og gjør det muligens ennå) at de trenger vekst mer enn alle andre ting. Vekst trumfer alt. Det mangler ikke på initiativer og ønsker, men hvis man ikke kan sannsynliggjøre at det vil føre til vekst går det i søppelbøtta.
Mange tror Vipps driver finans, men Rune Garborg vil hevde at nei, det Vipps driver med er én og bare én ting: forenkling. Hvis en produktidé ikke kan vise til at det vil føre til forenkling for brukerne, får det ikke prioritet.
Kortsiktig vs langsiktig
Hvis vi utvikler et produkt eller en tjeneste må vi ganske raskt bestemme oss for om dette skal være robust og bærekraftig på lang sikt, eller om vi må pøse på med nye features (MVP-er) for å lære sammen med kundene. I det siste tilfellet kan vi leve med mangler og litt rufsete kvalitet rett og slett fordi vi er i en læringsfase. Her må vi være sikre på at vi ikke gjør dette til modus operandi slik at det hoper seg opp med teknisk gjeld vi ikke kommer oss ut av igjen.
Det er dessverre altfor vanlig å neglisjere dette dilemmaet og hvis det er uklart vinner nesten alltid de kortsiktige hensynene. Man jager milepæler, tar seg ikke tid til å jobbe med forbedring og ender opp med teknisk gjeld.
Hvem sin gevinst skal være styrende?
Det er ikke nødvendigvis sånn at sluttbrukerne, andre interessenter og egen organisasjon har sammenfallende interesser. Amazon har i flere tiår hatt customer obsession som mantra – og dette prinsippet gjennomsyrer prioriteringene helt fra Jeff Bezos og ned til alle deres “two pizza teams”. Tanken er at hvis tilstrekkelig mange kunder er tilstrekkelig fornøyde, vil de selv gå med overskudd. Ingen tvil om at dette har vært en vellykket strategi for Amazon. Ikke dermed sagt at dette er riktig strategi for alle, men uansett en stor fordel å være tydelig på slike strategiske prioriteringer.
Feilretting eller nyutvikling?
Dette er kanskje det vanligste dilemmaet mange er i nærmest på daglig basis. Man har målsetninger og strategier som innebærer mye nyutvikling, men så kommer disse evinnelige feilrapportene og supportsakene i veien. Ikke lett å si noe generelt om hvordan slikt bør prioriteres, men i hvert fall viktig å legge stor vekt på at ikke feilrettingen tar for mye energi og kapasitet. Har man pådratt seg mer teknisk gjeld enn man kan leve med, kan det være helt avgjørende å prioritere “gjeldssanering” for å komme seg ut av dette uføret.
Smått trumfer stort
Vi slipper ikke unna estimering – uansett hvor lite populært dette måtte være. De som skal gjøre jobben må kunne si noe grovt om arbeidsmengden for at det skal være mulig å gjøre gode prioriteringer. Det som gir best kost/nytte er åpenbart små saker som gir høy antatt nytteverdi for kundene (innenfor den retningen man har satt).
Operativ prioritering
Det er naturlig å begynne på toppen – hva er visjonen for dette nye produktet – eller tjenesten?
VISJON
Denne skal være overordnet og langsiktig. Gjerne så ambisiøst at den kan virke uoppnåelig.
Hvordan ser suksess ut om 3-5 år? Går vi for “verdensherredømme” eller nøyer vi oss med en nisje? Hvor viktig kommer vekst og skalerbarhet til å bli for suksess? Skal vi inn i et marked med strenge regulatoriske krav? Kan liv og helse stå på spill med dette produktet? Skal vi konkurrere på brukervennlighet?
Deretter er det naturlig å sette mål for “mellomlang sikt” (i Scrum: Produktmål). Disse har typisk varighet på ¼ til 1 år. For å oppnå visjonen må vi altså nå en serie med produktmål – men bare det nærmeste målet er operativt.
SERIE MED PRODUKTMÅL
En Product Owner eller Produktsjef vil gjerne bruke produktmålene som som en grov Road Map for produktet. Det er viktig at også disse målene må være effektmål og si en del om hva vi ønsker å oppnå på vegne av kundene, men i liten grad være spesifikke på akkurat hva vi skal lage og hvordan.
Produktmålene tror jeg er nøkkelen til tydelig og god prioritering. Hvilket kundesegment skal vi ha fokus på? Hvilke kunder eller produktområder er vi IKKE skal jobbe med her? Har vi en Nordstjerne? Skal vi gønne på med MVP-er eller skal vi ta det rolig og skape robusthet? Slike ting.
For å oppnå det neste Produktmålet lager vi gjerne en Product Backlog. Denne vil hele tiden være “i arbeid” og altså ikke være “forpliktet”. På den måten vil det være enkelt å omprioritere løpende basert på det vi lærer når vi leverer produktinkrementer til brukerne.
PRODUCT BACKLOG
Bruker man Scrum vil elementene i Product Backlog være input til Sprintene med varighet på 1-4 uker. Hver av disse Sprintene skal ha Sprintmål.
SPRINTMÅL
Unngå Sprintmål av “hummer og kanari”-typen som forsøker å fikse på en usammenhengende liste problemer. Sprintmålene bør også være formulert som effektmål: I denne sprinten skal vi løse dette spesifikke problemet for disse kundene. Det bør være tydelig at Sprintmålet representerer et tydelig skritt i retning av det neste produktmålet.
PRODUKTSJEF/PRODUKTEIER
Operativ prioritering må gjøres raskt, løpende og ofte uten nok informasjon tilgjengelig. Dette dreier seg om handlekraft. Derfor vil mange ta til orde for at dette ivaretas av én person – altså ikke en komité. Med Scrum vil dette åpenbart være Product Owner rollen. Her trenger vi altså en person som er komfortabel med å prioritere andre ned, selv om de åpenbart blir skuffet. En som har en klar visjon, tydelige mål og som står stødig selv når det stormer som verst.
In: Lean, produkteier, Scrum · Tagged with: Prioritering