Et målbilde for den produktorienterte modellen

En kollega tok nylig tak i meg, og spurte:

Det er et svært godt spørsmål, og det korte svaret er nei, strengt tatt ikke. Det er mer en mental modell for å tenke på de forskjellige aspektene ved det å jobbe produktorientert. Egentlig kan man se på dem som allmenngyldige spørsmål, som helt fint kan svares ut i en leveransestyrt modell også.

I boka Transformed skriver Marty Cagan at han verdsetter prinsipper over prosess, og at det er prinsippene man må ivareta når man skal implementere den produktorienterte modellen. Problemet med å kun tenke prinsipper er at det kan være krevende å forstå helheten, spesielt når man er fersk.

En konkretisering av hvordan modellen kan se ut, gir oss et bedre grunnlag for å forstå hvordan den er ment å fungere. Merk at det ikke finnes én fasit som fungerer for alle, modellen må tilpasses hver enkelt virksomhet. Vi skal se på hvert av de tre spørsmålene i den produktorienterte modellen, med konkrete forslag til hvordan de kan svares ut.

Hensikten med denne artikkelen er at du skal kunne bruke den som et referansepunkt, og forstå helheten i den produktorienterte modellen. Du kan for eksempel sammenligne målbildet som beskrives her med din egen virksomhet, og vurdere hvilken utvikling dere trenger.

Hvordan prioriterer man hvilke problemer som skal løses?

Dette spørsmålet handler hovedsakelig om å sette og tydeliggjøre retning for de involverte produktteamene. For å gjøre dette må vi sørge for fleksible, strategiske rammer som lar både virksomheten og teamene dreie kurs mot der det er mest verdi. Å sette retning innebærer en visjon og strategi for produktet, samt mål for teamene. Rammebetingelsene vi må ha på plass omhandler finansiering og organisering. Dersom disse rammebetingelsene ikke er på plass, vil det være vanskelig å hente ut potensialet som finnes i teamene, selv om retningen er satt tydelig. Hvor viktig finansiering og organisering er for prioritering — hvordan disse rammebetingelsene implisitt representerer prioritering i stor grad — er noe jeg opplever at ofte glemmes.

Sette retning

I den produktorienterte modellen søker vi å få myndiggjorte team. Dette er selve essensen av hvorfor denne måten å jobbe på gir grunnlag for bedre innovasjon og mer verdi enn leveransestyrte team. Myndiggjorte team har frihet under ansvar. En annen måte å se det på er at autonomi + retning = myndiggjøring.

Med andre ord er retning kritisk: Uten retning får vi hjemme-alene-fest. Marty Cagan omtaler et hierarki i Transformed, hvor man har en produktsjef (eng: product leader) over produktlederne (eng: product manager). Min erfaring er at vi i Norge typisk bekler produktsjefrollen med produktområdeledere. Det er denne produktsjefrollen som er ansvarlig for å sette retning. Poenget med dette er ikke å innføre mer byråkrati og IT governance-strukturer, men heller gi teamene en god forståelse for hvilke problemer de skal løse, samt hvorfor. Vi kan bryte det ned i fire deler:

1. Produktvisjonen beskriver den langsiktige, ønskede situasjonen. Når man har lykkes med å løse de problemene som er prioritert, får man en tilstand som er beskrevet i produktvisjonen. Produktvisjonen fungerer dermed som et målbilde, og har typisk en lang tidshorisont (gjerne flere år). Her er fokuset på hvordan produktet fungerer, og hvilken effekt det har for brukerne, ikke på hva man har laget. Hovedformålet til en produktvisjon er å skape en felles forståelse for hvorforman gjør det man gjør. Velformulerte målbilder av denne typen er også svært effektive for å kommunisere hensikt og ambisjoner til resten av virksomheten.

2. Produktstrategien konkretiserer hvilke steg vi må ta for å bevege oss mot produktvisjonen. Der produktvisjonen beskriver hvordan verden ser ut i en ønsket fremtidssituasjon, går produktstrategien mer i detalj på hvordanman skal komme seg dit. Følgelig er beskrivelsene mer konkrete, og omhandler gjerne hvilke brukergrupper man prioriterer, hvilken posisjon produktet skal ta, og hvilke måltall man skal oppnå (for å nevne noe). Tidshorisonten er gjerne kortere enn den er for produktvisjonen, men fortsatt av størrelsordenen tertialer til et par år. Det finnes mange rammeverk for å beskrive en produktstrategi. Et godt eksempel finner du her.

3. Mål for teamet (team objectives) tydeliggjør hva teamet skal oppnå på kort sikt. Jeg har lang erfaring fra en rigg som hadde en produktstrategi, men hvor utarbeidelse av de konkrete målene for teamet lå hos teamet selv. Dette kan være svært krevende, fordi mulighetsrommet som defineres av produktstrategien som regel er veldig stort. Å ta gode valg for teamets mål krever en inngående forståelse for både produktvisjonen, produktstrategien og det kortsiktige perspektivet. Dette er noe teamet i min erfaring sjeldent er best posisjonert for å gjøre.

I riggen jeg befant meg i, hadde vi allerede begynt å eksperimentere med at produktsjefen (heller enn produktlederen og teamet selv) satte teamets mål da Transformed kom ut. I den boka skriver Marty Cagan at team objectives bør settes av produktsjefen, som en naturlig forlengelse av produktstrategien. Våre erfaringer med dette er utelukkende positive, og det er noe jeg vil anbefale alle på det sterkeste å utforske. I lys av den produktorienterte modellens tre spørsmål gir det også mening, for meg i alle fall, at målene settes fra utsiden: De representerer hvilke problemer vi skal løse, ikke hvordan vi skal løse problemer.

Det er verdt å merke seg at en produktsjef må ha inngående kunnskap om teamets kapabiliteter for å gjøre disse vurderingene, men det er jeg overbevist om at man uansett er tjent med: En produktsjef som ikke har denne innsikten i teamene vil neppe være i stand til å produsere en god og realistisk produktstrategi. Et annet argument for at målene bør settes av noen utenfor teamet er at teamet er innrettet for å løse problemer, mens dette handler om å prioritere hvilke problemer som er verdt å løse.

4. Læring fra teamet er essensielt for å prioritere de rette problemene. Et team som jobber produktorientert vil bidra med svært relevant innsikt og data om produktet. Denne læringen må veves inn i vurderingene og beslutningene som tas rundt hvilke problemer vi skal løse. Dette kan være konkrete muligheter og problemer som teamet har løftet, det kan være endrede antakelser om kundebehov og/eller markedssituasjonen, eller det kan være ny innsikt om hvordan produktet brukes, for å nevne noe.

Hvis vi bruker en startup som en analogi, så bidrar læringen fra teamet til å gjøre en pivot, persevere, perish vurdering. I ledelsesvurderingene av hvilke problemer som er verdt å løse, er læringen fra teamet uvurderlig. Jeg vil påstå at et tilstrekkelig modent team kommer med sine egne anbefalinger, sammen med læringen de sitter på. Å bygge denne feedback-sløyfen er dessverre noe som ofte nedprioriteres, i min erfaring.

Å sette retning handler om å tydeliggjøre hvorfor teamet jobber med de problemene de gjør, samt hvordan de skal tilnærme seg et langsiktig målbilde. Dekomponeringen er essensiell, og kanskje spesielt det å utfordre produktsjefer på å sette mål for teamene under seg. Dersom dette ikke gjøres, vil teamet ofte ha svært vanskelig for å forstå hvordan deres innsats best mulig leverer på en overordnet strategi.

Enhetlig finansiering

Finansieringen skal være i tråd med der vi tror det er størst verdi å hente. Når vi snakker om finansiering tenker man sjeldent på at dette er prioritering. Vi tenker gjerne på det som en rammebetingelse, hvor vi gjør påfølgende prioriteringsarbeid innenfor disse rammene. Paradoksalt nok representerer finansiering den største prioriteringen av hvilke problemer man skal løse av dem alle: Har du ingen finansiering så får du ikke adressert noen problemer i det hele tatt! Det samme gjelder dersom man har finansiering og denne skaleres opp eller ned: En oppskalering gir deg muligheter til å adressere flere problemer, mens en nedskalering gjør at du får adressert færre problemer. Dette forklarer hvorfor finansiering er en essensiell del av å prioritere hvilke problemer man skal løse. Vi skal se nærmere på tre aspekter ved enhetlig finansiering, som understøtter den produktorienterte modellen:

1. Én strøm for finansiering er det første du må sikre. På tvers av enheter, på tvers av nyutvikling, forvaltning og videreutvikling. Om det er snakk om et team, en portefølje eller et produktområde som skal finansieres er irrelevant: Denne enheten trenger én finansieringsstrøm. Hvorfor? Jo, fordi vi ønsker ett utgangspunkt for prioritering. Dersom man har flere finansieringsstrømmer, så er det flere som de facto prioriterer. Typisk har disse forskjellige mål de ønsker å nå, og forskjellige ting de er opptatt av. Da blir resultatet ofte et kompromiss, som i praksis gjør at teamene er låst til å ikke bare løse spesifikke problemer, men ofte på en spesifikk måte.

Penger er makt, og ved å samle makten sørger vi for at helheten vurderes i stort, og at teamene har tilstrekkelig handlingsrom innenfor den retningen som er satt. Et underfinansiert team vil som regel være villig til å sikre seg ytterligere finansiering ved å forplikte seg til en konkret leveranse, rett og slett for å sørge for at de har nok kapasitet til å fungere som et godt team. Dette undergraver måten vi ønsker å jobbe på i den produktorienterte modellen.

2. Koble mot eiere: Sørg for at beslutningstakerne som setter retning, også eier finansieringen. Penger er som sagt makt, og faktum er at dersom de som skal sette retningen ikke eier finansieringen, så kan de overkjøres. Dette skjer ofte. Vi er derfor tjent med å sammenstille disse funksjonene. Det er her stillinger som eksempelvis Chief Product Officer (CPO) kan spille en sentral rolle, hvor man har ansvaret både for finansieringen, og å sette en retning som sørger for å skape verdi. En CPO kan ha produktsjefer under seg, som videre bestemmer finansiering og retning (innenfor rammene de har blitt gitt) for sine enheter, eksempelvis produktområder. I en større virksomhet kan det være nødvendig med flere nivåer. Melissa Perri skrev nylig en kort og oversiktlig post på LinkedIn om hvordan dette kan se ut, som du kan lese her.

3. Drives av verdi: Det skal investeres først der vi tror det er mest verdi. Videre finansiering påvirkes av læring fra produktutviklingen. Tilsvarende skal vi kutte finansiering der vi sliter med å se at det er ytterligere verdi å hente. Med moderne produktutvikling vil man raskt se hvorvidt noe skaper verdi, og få stadig bedre kvantifisert data på hvilken verdi produktene skaper. Dette muliggjør en feedback-sløyfe fra teamet (som vi så på tidligere), som absolutt bør påvirke finansieringen. Ansvarlig finansiering innebærer å ha en klar tanke om hvordan allokerte midler skal skape verdi — gjerne formulert som konkrete hypoteser. I min erfaring skjer allokering for ofte på bakgrunn av historikk: Evnen og viljen til å snu seg etter hvor verdipotensialet befinner seg er ikke tilstrekkelig. Det er ingen skam å nedbemanne eller avvikle et team som har levert bra, dersom man ikke ser potensialet for verdiskapning videre.

Enhetlig finansiering handler om å erkjenne at penger er makt, og at allokering av disse midlene i praksis er å gjøre prioriteringer. Vi må innrette finansieringen slik at vi kan jobbe i tråd med den produktorienterte modellen: med myndiggjorte team og retningsgivende ledelse.

Effektiv organisering

Organiseringen skal understøtte virksomhetens mål og verdiskapningen på en effektiv måte. Hvordan gjør vi dette? Vi kan begynne å skille mellom team og digitale løsninger. Hvor mange er, eller har vært, i et team som har det samme navnet som den digitale løsningen de lager? Som regel er ikke den beste arkitekturen over tid at et team bygger alt inn i én løsning, men når vi implisitt knytter teamets identitet opp mot løsningen gjennom navnet, så blir det ofte slik likevel. Ved å definere teamets rolle, innrette retningen mot hvordan teamet leverer verdi i, og tydeliggjøre hvordan ansvarsdelingen mellom team er, får vi en organisering som effektivt understøtter produktutvikling. La oss ta en nærmere titt!

1. Team Topologies gir oss et solid rammeverk for å definere et teams rolle. Boka er godt skrevet: Den er konkret på hvordan team bør bygges, og selve essensen er et forlokkende enkelt rammeverk som definerer fire teamtyper. Vi skal ikke gå i dybden på rammeverket her (du kan heller lese en god oppsummering i denne bloggposten), men det er viktig å påpeke at teamtypen har mye å si for hvordan man innretter teamet. Et godt eksempel er at et plattformteam i langt større grad må ha en proaktiv holdning til andre team enn et verdistrømteam, fordi plattformteamet leverer verdi gjennom andre team. Dette stiller andre krav til hvordan roller som produktleder og teamleder agerer i hverdagen, samt hvilke møteserier og lignende man setter opp.

2. Inverse Conway Maneuver lar oss definere teamene på en måte som gir en robust arkitektur over tid. Conways lov forteller oss at arkitekturen som vokser frem, vil gjenspeile kommunikasjonsstrukturen til enhetene som lager den. Dette temaet er alt for stort til å detaljere i denne artikkelen, men essensen er at ved å bruke vår kunnskap om Conways lov, kan vi proaktivt sette sammen team på en måte som over tid vil gi oss den ønskede arkitekturen. Her er man tjent med å basere øvelsen på hvordan teamene leverer verdi. Et stort obs er at man etter en slik øvelse må investere i teknisk omstilling for å unngå to parallelle arkitekturparadigmer.

3. Domenevertikaler og prinsippene for domenedrevet design gir en tydelig ansvarsdeling for teamene. Verdistrømteam (stream aligned team) i Team Topologies jobber med en helhetlig verdistrøm for et forretningsområde. På samme måte kan vi tenke at en avgrenset del av et domene kan regnes som en domenevertikal. Ved å kartlegge de delene av et produkt som brukerne interagerer med, får vi en rekke domenevertikaler.

Disse vertikalene kan grupperes etter prinsippene i domenedrevet design, og da spesielt mantraet low coupling, high cohesion. Dette gir et godt grunnlag for å dele inn og tydeliggjøre teamenes ansvar, og spiller på lag med en Inverse Conway Maneuver. De resulterende teamene defineres ut fra hvilke tjenester man leverer, og har tydelig avgrensede ansvarsområder. Ettersom teamet utvikler seg over tid, oppdaterer man løpende hvilke domenevertikaler teamet har ansvaret for.

De samme teknikkene som jeg har beskrevet for team her, fungerer godt på enheter av andre størrelsesordener også, eksempelvis produktområder. Et produktområde kan vel så gjerne være et plattformområde som et verdistrømområde. På samme måte som for et team, legger dette føringer for hvordan vi bør innrette prosesser, rutiner og rolleforståelse.

Hvordan løser man de problemene som er prioritert?

En av hovedforskjellene med produktteam i forhold til leveranseteam, er at med produktteam legger vi et vesentlig større ansvar på selve teamet for å finne de gode løsningene. For et leveranseteam ligger dette ansvaret på utsiden. Hele rasjonalet for å legge dette ansvaret til teamet, er fordi dette muliggjør bedre innovasjon. Vi får potensialet for løsninger som gir større verdi, fordi teamet er i den beste posisjonen til å se det fulle mulighetsrommet, og velge den beste fremgangsmåten. Dette kommer ikke av seg selv, dóg: Selv om forutsetningene er der, gjenstår det hardt og målrettet arbeid. Dersom teamet får frihet og mandat, involverer interessenter på en god måte og får til produktutforsking, er vi godt på vei til å lykkes.

Myndiggjorte team

En periode var begrepet autonome team mye brukt. Jeg har aldri likt dette begrepet, fordi full frihet ikke sikrer ensretting med de målene man har satt. Sagt på en annen måte, så bør frihet balanseres med en forståelse for retning og formål. Lykkes man med det, så får man myndiggjorte team.

Bemanning, finansiering, organisering, teamidentitet og retningen som er satt gir den tilstrekkelige konteksten for å gi teamet både retning og autonomi. Med den oppnådde myndiggjøringen er teamet ansvarlig for at de løsningene de lager oppnår verdi for virksomheten. De kan ikke lenger peke på eksterne ledere, eller beslutninger de ikke rår over, dersom de ikke lykkes. Teamet må svare for sine resultater, og eie effektene deres løsninger oppnår.

1. Ansvarsforståelse for teamet er viktig når man får vesentlig økt myndighet. Et faktum det kanskje snakkes litt for lite om, er at mange team ikke er modne og klare for å forvalte det ansvaret som følger av å jobbe som et myndiggjort team. Selv om vi balanserer autonomien til teamet med retning, så er det betydelig økt frihet sammenlignet med et leveransestyrt team. Med denne friheten følger ansvar.

I praksis handler dette typisk om forståelse for og eierskap til problemene vi skal løse. Det kan være utviklere som kun ønsker å kode, eller en produktleder som ikke forstår hvordan man skal rigge gode nok målinger. Det kan være designere som tenker for konseptuelt og langsiktig, eller en tech lead som ikke involverer seg i produktutforskingen. I et myndiggjort produktteam, så skal alle teammedlemmene til en hver tid fokusere sin innsats på de oppgavene som tar oss nærmere å løse problemet på best mulig måte. Dette krever en helt annen innstilling og kompetanse, enn å komme på jobb og plukke den neste oppgaven som ligger klar. Det krever at teammedlemmene bryr seg, og er nysgjerrige på hvordan de best mulig kan utnytte den fulle bredden av sine ferdigheter. Marty Cagan beskriver dette godt:

Det hviler et betydelig ansvar på lederne i og utenfor teamet: De må jobbe med denne ansvarsforståelsen. Dette er enda et eksempel på at myndiggjorte team krever bedre, ikke mindre, ledelse.

2. Målstyring handler om å konkretisere hva teamet skal oppnå, samt innrette styringsmekanismene deretter. For å lykkes hele veien med myndiggjorte team, så må effektene som teamet oppnår evalueres og vurderes. I den produktorienterte modellen er dette produktsjefens ansvar, altså den samme rollen som er ansvarlig for å prioritere hvilke problemer vi skal løse. Dette gir et kretsløp, hvor tydeliggjøringen av problemet (med tilhørende strategisk kontekst og rammebetingelser) gjøres av den samme rollen som forventer verdi fra teamet.

Dette kretsløpet er delikat: Samtlige “piler” i figuren over må fungere. Dersom én eller flere av dem ikke fungerer, jobber ikke teamet målstyrt. Som jeg detaljerte i en artikkel for en stund tilbake, så er gjerne gode målinger dessverre det siste som kommer på plass i modningsreisen mot målstyrte team. Det hviler et felles ansvar på både produktsjefen og teamet for å lykkes med dette: Produktsjefen må tydeliggjøre hvilke metrikker og effekter det er ønskelig å måle, teamet må utforske og kommunisere hva de er i stand til å måle. Ofte er gapet her betydelig, og det er krevende å forsere.

Myndiggjøring er et resultat av autonomi og en tydelig retning. I tillegg må vi sørge for en god ansvarsforståelse i teamet, samt lykkes med målstyring for å komme i mål med denne måten å jobbe på.

Interessentinvolvering

Interessenthåndtering er ikke nytt i seg selv, men det er ekstra viktig i den produktorienterte modellen, fordi vi tar bort mange av de strukturene som interessenter er vant til å forholde seg til (eksempelvis et PMO i et prosjekt). Det som gjelder når man jobber produktorientert, er at man aktivt må involvere interessentene. Dersom man ikke lykkes med dette, er sannsynligheten stor for at teamet ikke vil få den støtten og hjelpen det trenger fra virksomheten. Vi skal se på hvordan kartlegging av interessenter, proaktiv dialog og evangelisme gir oss tilstrekkelig interessentinvolvering.

1. Kartlegging av interessenter avdekker hvem vi må følge opp tett. I en virksomhet er det en mengde relevante interessenter for et gitt produkt. Noen av disse har formell makt, mens andre har uformell makt. Fellesnevneren er at de har innflytelse på det du lager. Dette kan være alt fra kunnskap du trenger, til en alliert som kan hjelpe deg å realisere produktet. Ved å sette sammen en oversikt over disse personene, har man et verktøy som muliggjør strukturert oppfølging. På denne måten ivaretar man deres interesser, som gagner både teamet og produktet. Merk igjen at dette er ekstra viktig når vi jobber produktorientert, fordi det ikke er noen andre entiteter som interessentene kan forholde seg til.

2. Proaktiv dialog med nøkkelinteressenter sikrer god involvering. I fravær av andre entiteter som nøkkelinteressentene kan forholde seg til, kan det fort oppstå et vakuum. I praksis er dette inversion of control, sammenlignet med for eksempel et prosjekt: I prosjektet kunne interessentene henvende seg til prosjekteieren, eller prosjektkontoret. Når de enhetene bortfaller, må teamet selv sørge for å proaktivt gå ut og inkludere interessentene. Fra teamets perspektiv kan dette kanskje virke rart, men dette er enda et eksempel på at myndiggjorte team krever bedre ledelse. Det vil rett og slett ikke føles naturlig for mange interessenter å trenge seg på teamet. Kanskje vet man ikke en gang at man har en interesse i produktet som teamet lager.

3. Evangelisme sprer budskapet vårt til hele virksomheten. På mange måter er et team i den produktorienterte modellen litt isolert. Litt alene. Vi har sett på interessentkartlegging, men hva med resten av virksomheten? Prosjekter er av natur store og viktige, og noe mange som regel får med seg, uten at man helt vet hvordan. Produktteam derimot, de går fort under radaren. På samme måten som det er teamets ansvar å involvere interessenter, er det teamets ansvar å sørge for sin egen synlighet. Teamet er sin egen lykkes smed, og må spre det glade budskap. Dette sikrer innsikt og bygger tillit. Husk at innsikten i teamet og produktet, som all innsikt, er ferskvare. Dette betyr at du må repetere, repetere, repetere: Det er en kontinuerlig aktivitet. Bruk forskjellige kanaler, og variér innholdet og budskapet for å holde det spennende. Åpne delingssesjoner, workshops, innspillinger, podcasts, deling på intranett: Formatene som kan fungere begrenses kun av fantasien.

Hele virksomheten er essensielt dine interessenter. Sørg for å ivareta dem på en god måte, og husk at dette krever vesentlig proaktivitet fra teamets side.

Produktutforsking

I den produktorienterte modellen snakker vi mye om hvordan teamet skal myndiggjøres, og at de er i den beste posisjonen for å finne de løsningene som gir mest verdi. Dette kommer derimot ikke av seg selv: Forutsetningene er på plass, men det må fortsatt knallhardt arbeid til for å utnytte dette potensialet. Produktutforsking er svaret på hvordan vi skal gjøre dette. Selve essensen med produktorientering handler om å lykkes med produktutforsking, og at alt annet er nødvendige endringer og rammebetingelser for å få til dette. Teamet bør helhetlig jobbe med produktutforsking, med produkttrioen (eng: product trio) i front som ansvarlige. Dette arbeidet gjøres kontinuerlig, parallelt med at man produserer produktet.

Min gode kollega Sonja kom med en veldig god beskrivelse i sin artikkel om hva produktutforsking er:

Det er en forfriskende enkel og jordnær fremstilling, og det vitner om Sonjas kunnskap og innsikt i temaet når hun evner å beskrive det så lettfattelig. Å lykkes med produktutforsking derimot, er svært vanskelig. Jeg vil kort gå gjennom essensen i de fire produktrisikoene som Marty Cagan definerer, men jeg vil anbefale deg på det sterkeste å lese Sonjas artikkel for å bedre forstå produktutforsking.

1. Gjennomførbarhet handler om at vi rent teknisk skal klare å lage produktet. Dette er hovedgrunnen til at vi trenger en tech lead i produkttrioen: Vi må vurdere om den skisserte løsningen er mulig å bygge. I praksis handler dette som regel om å gjøre en kostnadsvurdering. Det aller meste er mulig å lage, men kosten kan være uoverkommelig stor. Drømmescenariet vårt er at tech lead tar et vesentlig større ansvar enn å bare bidra med disse vurderingene, og det kan du lese mer om i denne utmerkede artikkelen.

2. Brukervennlighet handler om at produktet skal fungere godt for brukeren i den konteksten det er tiltenkt. Summen av hva et produkt leverer for brukeren er ofte større enn man tenker over i det daglige. Følgelig er også brukervennlighet langt mer enn å tilfredsstille krav til universell utforming og lage pene brukergrensesnitt. Et berømt eksempel på god brukervennlighet er den aller første iPhonen til Apple, som tok verden med storm. Det var ikke utforming av appene som gjorde dette produktet til en suksess: det var helheten. Å lage produkter som gir god brukervennlighet er svært krevende, og en kritisk faktor for å lykkes med verdiskaping.

3. Attraktivitet handler om at produktet skal gi verdi for virksomheten vår. Det er ikke nok at produktet skal fungere for brukerne, vi må sørge for at det skaper verdi for virksomheten vår. For å ta noen enkle eksempler: I det private kan dette være økt inntjening eller økt kundetilfredshet, i det offentlige kan det være enklere brukeropplevelser til mer effektive måter å jobbe på. Utfordringen er typisk at i praksis er avstanden mellom effektene vi oppnår med produktene våre ikke lar seg måle så direkte som vi skulle ønske. Å klare å knytte endringer i produktet til måling av verdi er svært krevende, og en kritisk faktor i god produktledelse.

4. Forretningsrisiko handler om å avdekke andre momenter som hindrer produktet, eksempelvis etiske og juridiske. Produktene våre må forholde seg til slike “store rammebetingelser”. Her må man være påpasselig med alt fra merkevare eller posisjon i markedet, til de mer harde begrensningene som eksempelvis lovverk. Kort fortalt må produktet kunne eksistere som en del av virksomheten. Dersom dette ikke er tilfellet, må man revurdere produktet (eller i alle fall de delene av det som medfører en uakseptabel forretningskonsekvens).

Produktutforsking er kritisk for å lykkes med å lage gode produkter, men vanskelig. Invester i det, og ikke gi opp før det er noe du mestrer!

Hvordan bygger man løsningene på problemene?

Fagfeltet digital produktutvikling er forholdsvis ungt, og mange av konseptene er ferske, og gjerne ukjente for mange. Når det gjelder å bygge løsninger derimot, har vi en håndfast og solid fasit for hvordan vi bør gjøre det. Som jeg har skrevet tidligere mener jeg at Accelerate er den beste fagboka som er skrevet for vår bransje (og en god oppsummering kan du lese her): Den gir deg en grundig forståelse for både hvorfor og hvordan smidig metodikk bør utøves av et utviklingsteam. Dette er rett og slett beste praksis for utviklingsarbeidet, uavhengig av styringsmekanismene som gjelder.

Teste tidlig og billig

Dette handler om å være trygg på at man har funnet en god løsning, før man bygger noe som er dyrt. Å utvikle en skreddersydd løsning og lansere denne i produksjon, er noe av det dyreste et team gjør. Følgelig ønsker vi, på billigst mulig måte, å få validert at idéene våre har livets rett. Vi kan belage oss på hypoteser og eksperimenter, for å få en validering så tidlig og så billig som mulig.

1. Hypoteser får oss til å artikulere hva vi tror kommer til å skje. Produktutforskingen gir oss en mengde idéer som vi tror er gode. For disse idéene kan vi utarbeide hypoteser om hvordan de vil skape verdi. Husk at ferdigstilling av funksjonalitet ikke skaper verdi i seg selv: Verdien kommer fra endret adferd. Denne kan vi måle, og hypotesene sier hvordan vi tror at denne adferden vil se ut.

Å jobbe frem disse hypotesene får oss til å fokusere på verdien vi ønsker å oppnå, fremfor å låse oss til løsning. Sagt på en annen måte, så prøver vi å være bevisst våre antakelser om hvordan funksjonaliteten vil tas i bruk. Med hypotesene etablert, kan vi diskutere og resonnere om det gir verdi. Noen ganger kan dette i seg selv bekrefte eller avkrefte at noe er verdt å lage, men som regel må vi gjøre noe mer for å bedre forstå hvordan hypotesene våre treffer den virkelige verden. Det er her eksperimenter kommer inn i bildet.

2. Eksperimenter hjelper oss å validere hypoteser. Når det foreligger én eller flere hypoteser, finnes det en mengde måter vi kan validere denne på. Alt fra enkle spørreundersøkelser til sofistikerte prototyper kan fungere godt. For å gjennomføre slike eksperimenter, må man dra ut i felten for å møte brukerne og kundene. Dette kan være alt fra å ta på seg vernestøvler og hjelm for å gå inn i en fabrikk, til å sette seg ned med saksbehandlere.

Poenget er å se hvordan produktet ditt brukes, og hvordan det bistår de som anvender det. Vi ønsker å se forbi selve oppgaven, og fokusere på det underliggende behovet. Som et eksempel er det ingen som har behov for en drill, man har behov for et hull i veggen. Det er selve behovet og påvirkningen produktet vårt har på det vi er interessert i. Eksperimentet bør utformes deretter, og her er det utallige muligheter.

Å teste tidlig og billig høres ut som en selvinnlysende og god idé, men det glemmes ofte i hverdagen. Vev det inn i teamets rutiner, så vil det skje naturlig over tid.

Kontinuerlig leveranse

Kontinuerlig leveranse handler om å få ut endringer av alle typer til brukerne på en enklest, raskest og tryggest mulig måte. Ved å gjøre dette kontinuerlig og automatisere så mye som mulig, innarbeider vi rutiner som tar ned risikoen. Så fort vi har verdi klar, går den ut til brukerne. Det er skrevet veldig mye bra om dette tidligere, så jeg skal holde denne delen kort og fokusere på hovedpoengene.

1. Hyppige deploys tar ned risikoen for feil, og sørger for at verdien kommer raskt ut til brukerne. Hvis noe er vanskelig, bør det gjøres ofte. Gjør det til en vane! Får man innarbeidet en rutine, reduseres sannsynligheten for at noe går galt. Ved å ha rutiner for å deploye hyppig får vi kortere nedetid ved feil i produksjon: En feilretting kan legges ut så raskt feilen er identifisert og utbedret, heller enn å vente på neste planlagte deploy. Å identifisere feilen er forholdsvis enkelt, fordi endringsraten fra deploy til deploy er lav (som følge av at vi deployer hele tiden). I sum tar hyppige deploys ned risikoen betydelig, gir oss mindre nedetid i produksjon, og bringer teamet nærmere brukerne.

2. Bærekraftig fart er essensielt for å opprettholde produktivitet og kvalitet over tid. Et ordtak jeg liker godt, og som jeg ofte kommer på når jeg tenker på bærekraftig fart (eng: sustainable pace): “A line without beginning, a line without end”. Vi må finne balansen mellom vedlikeholdsarbeid og innovasjonsarbeid, slik at teamet kan opprettholde farten over tid. Målet er å ha kontroll på teknisk gjeld, og gjøre nødvendige, proaktive grep for å holde kodebasen endringsdyktig. Å lykkes med dette vil være viktig for å forhindre utbrenthet, noe blant annet Accelerate peker på.

3. Eierskap til produksjonsmiljøet sikrer at teamet har fokus på hva brukerne forholder seg til. Sitatet “you build it, you run it!” har blitt ganske så vanlig i DevOps-miljøer, og med god grunn. Det er ikke koden lokalt på en utviklermaskin som gir verdi, det er koden som kjører i produksjon og som brukerne forholder seg til. Å skape eierskap til produksjonsmiljøet bringer teamet tettere på brukerne. De vil dermed føle på et større ansvar hvis noe faller ned, og generelt føle på at arbeidet deres har et formål.

En anerkjent måte å måle de mest sentrale faktorene for kontinuerlig leveranse er DORA-metrikkene. Disse gir teamet innsikt i utviklingen over tid, og er et godt grunnlag for å diskutere hvordan man bli bedre på kontinuerlig leveranse.

Måle bruk og effekt

På samme måte som at vi ønsker at teamet skal ha eierskap til produksjonsmiljøet, ønsker vi kvantitative data på både bruk av systemet, og verdien vi leverer. Dette må bygges inn i løsningene, og er helt essensielt for å lykkes med den produktorienterte modellen. Uten måling av effekt er det umulig å vurdere om vi lykkes med å skape verdi.

1. Instrumentering handler om å rigge løsningen for å måle bruk og effekt. Både helsemetrikker for løsningen din, og forretningsverdien vi skaper, er noe vi ønsker å måle. Her må vi bygge dette inn fra bunnen av, og tenke over hvilke rammeverk og teknologier vi trenger for å klare å fange opp de nødvendige dataene. Analyseverktøy som Google Analytics er svært populære av en grunn. Når man påbegynner utvikling av ny funksjonalitet, bør man ha klart for seg hvordan man skal klare å måle bruk av denne funksjonaliteten.

2. Mål verdidrivere for å følge med på verdiskapingen. Husk at verdi = adferdsendring. Denne adferdsendringen bør vi ha hypoteser om hvordan kommer til å skje, før vi begynner utviklingen av ny funksjonalitet. Ofte er ønskene våre ganske overordnede, eksempelvis at vi vil gi brukerne bedre informasjon. Verdidrivere handler om å dekomponere disse store, svevende målene til noe mer håndfast. En annen måte å se på dette på er at det er operasjonalisering av en strategi. Bedre informasjon kan eksempelvis brytes ned til blant annet mer relevant informasjon, som kommer til rett tid.

For å klare å koble sammen verdidrivere og målinger, må man ofte tilnærme seg en ønsket måling fra begge sider samtidig: Hva er mulig å måle i løsningene våre, og hva ønsker vi optimalt sett å måle. Dessverre er ofte det strategiske arbeidet her frakoblet realiteten av hva vi faktisk klarer å måle, ergo hviler det et stort ansvar på teamet for å tenke kreativt rundt hvordan vi kan få til gode målinger i løsningene for å treffe verdidriverne. Det beste er at teamet jobber tett med de som utarbeider strategien og dekomponerer dette til verdidrivere for å finne koblingene.

Å måle bruk og effekt er som sagt helt essensielt for å lykkes med den produktorienterte modellen. Denne delen av artikkelen er likevel ganske kort, og det er fordi konseptene er forholdsvis enkle. I praksis er dette noe av det absolutt vanskeligste ved å jobbe produktorientert, og jeg skal se nærmere på konkrete problemstillinger, fremgangsmåter og eksempler for dette i en fremtidig artikkel.

Hensikten med den produktorienterte modellen er å sikre innovasjonskraft og verdiskaping

Denne artikkelen er et forsøk på å vise frem en konkret helhet for den produktorienterte modellen. Det er ikke en fasit, men et gjennomtenkt utkast. Det er mange veier til mål, og forhåpentligvis har jeg fått deg til å tenke over hvordan din virksomhet fungerer, og kanskje hvordan du ønsker at målbildet deres bør se ut.

Gapsanalyser og modenhetsvurderinger er gode verktøy for å synliggjøre hvor vi er, og hvor vi skal. Bruk gjerne denne artikkelen som sammenligningsgrunnlag!

La meg repetere bittelitt helt på tampen: Hele poenget med den produktorienterte modellen er å sikre innovasjonskraft. Vi gjør dette ved å få myndiggjorte team, som utøver produktutforsking basert på en tydelig definert og forstått retning. Løsningene bygges etter smidige prinsipper, med gode målinger som lar oss følge verdiskapingen. I sum gir dette økt verdi for virksomheten. Ha dette forrest i pannebrasken når du jobber med transformasjonen til den produktorienterte modellen!