Våren 2026 lanserte Digdir sin anbefaling for produktorganisering i offentlig sektor. Da hadde store offentlige etater allerede gått i gang med transformasjonen. Så hvordan ser produktorganisering egentlig ut? Og hva er det?

Hva er produktorganisering?

En virksomhet kan sies å være produktorganisert når den organiseres i team rundt sine produkter og tjenester. Slike produktteam bør – eller snarere skal – være tverrfaglige og autonome, med klare mandater for styring og ansvar. Produktorganisering dreier seg om organisasjonens struktur og governance.

I tillegg karakteriserer vi gjerne virksomheten som «produktorientert» hvis den strategi- og målstyrer mot verdiene som produktene og tjenestene skaper, og har kontinuerlig fokus på kundebehov og verdiskapning. Produktorientering dreier seg om organisasjonens strategi og kultur.

Det er fullt mulig å gå i gang med produktorientering uten nødvendigvis å være produktorganisert. Men i klassisk organisasjonsteori antar man ofte at struktur følger fra strategi. Litt forenklet kan vi si at

virksomheter produktorganiserer seg for å bli mer produktorienterte.

Med produktorganisering blir det tydeligere hvilken verdi- og kundeeffekt arbeidet har, og det blir enklere å ta produktansvar og prioritere effekter fremfor leveranser.

Om bruk av smidige metoder

Kundebehov og verdiskapning er som kjent sentralt i smidig også, så det å være produktorientert innebærer implisitt bruk av smidige metoder og tankesett. Likevel bør ikke det operative arbeidet begrenses til kun smidig.

Smidige metoder er velegnet når man står overfor problemstillinger i den såkalte kompliserte problemdimensjonen. Men i henhold til Cynefin finnes det i tillegg til Komplisert også andre problemdimensjoner som Klart, Komplekst og Kaotisk. I operativt arbeid bør produktteam bruke metoder og tankesett som er tilpasset problemdimensjonen. Først da blir virksomheten i stand til å håndtere alle typer problemer og utfordringer adekvat.

I problemdimensjonen Komplisert kan og bør operativt arbeid og fremdrift måles opp mot et verdidrevet og outcome-basert styringsunderlag. I problemdimensjonen Klart kan det være bedre å måle dette opp mot et plandrevet og output-basert styringsunderlag. Og i problemdimensjonen Komplekst må man kanskje over mot serendipitet og en mer posisjonsdrevet evaluering av progress og status. Jeg kommer ikke til å si mer om dette her, men henviser heller til min kronikk Syv kart over Cynefin, der jeg forklarer hva dette går ut på.

Uansett, når digitalisering mislykkes er grunnen ofte at man har evaluert arbeid og tiltak underveis opp mot et styringsunderlag som egentlig var uegnet for viktige deler av problemene og utfordringene som skulle løses.

Puristene i smidigmenigheten for ha meg unnskyldt,
men det er altså ikke slik at smidig ene og alene og alltid er det rette.

For det er ikke slik at alle til enhver tid jobber i Komplisert. Jada, den produktorienterte virksomheten strategi- og målstyre mot verdiskapning. Men det betyr ikke at et produktteam aldri trenger å levere eller måles mot output (i problemdimensjonen Klart) eller mot serendipitet (i problemdimensjonen Komplekst). God governance tar høyde for alt dette, og baserer seg på styringsprinsipper tilpasset problemene som skal løses.

Kort om matriseorganisasjoner

Modus operandi for større virksomheter er å produktorganisere seg i en eller annen form for matriseorganisasjon. Historisk har denne strukturen kombinert to prinsipper, som for eksempel funksjon og prosjekt, der hver ansatt rapporterer langs to akser, til en fagsjef og til en prosjektleder.

Matrisestrukturen har noen klare utfordringer ved motstridende prioriteringer og uklar beslutningsmyndighet mellom funksjon og prosjekt. For å tydeliggjøre mandat og myndighet, skiller man derfor mellom svake, balanserte og sterke matriser.

I en svak matrise vill den rødmarkerte prosjektlederen være en koordinator med liten egentlig makt og myndighet. I en balansert matrise vil prosjektlederen ha reell myndighet og innflytelse. De ansatte vil rapportere og lytte til både prosjektlederen og faglederen (linjelederen). I en sterk matrise ville prosjektaksen ha samme autoritet og myndighet som fag-aksen (linja), med en prosjektdirektør på tilsvarende nivå i organisasjonshierarkiet som fagdirektørene.

Hva med prosjektene?

Med produktteam som kontinuerlig tilpasser, utvikler og leverer produkter og tjenester, så mange med rette for seg et redusert behov for prosjekter, og kanskje da spesielt de (alt for) store og omfattende utviklingsprosjektene. Men når man fokuserer på det, blir det man er på vei mot ofte redusert til «det motsatte». Gårsdagens protagonist blir morgendagens antagonist så å si, og så også med prosjekt og produkt. Men

å destillere ned produktorganisering til
floskelen «fra prosjekt til produkt», er lite dekkende.

For man produktorganiserer ikke for å bli kvitt alt av prosjekter og ditto metodikk. Selv om mer leveres via produktteam, er det fortsatt fornuftig å bruke prosjekter som supplerende leveransemekanisme. Under gitte forutsetninger kan endog et prosjekt fortsatt være den foretrukne leveransemetoden.

Så hva er da poenget?

Poenget med produktorganisering er å syntetisere ulike prinsipper fra populære rammeverk og nye ideer om organisering, slik at man kan opprette og opprettholde en teamstruktur der produktteamene arbeider og samarbeider om å levere produkter og tjenester kontinuerlig, på måter som løpende ivaretar den produktorienterte virksomhetens mål og muligheter.

Mange av ideene fra de nye og populariserte rammeverkene har dreid seg om målstyring og arbeidsmetodikk i team. Det er temaer som hører inn under produktorienteringen. Men den største påvirkningen på selve produktorganiseringen har diskutabelt kommet fra Team topologies og Spotify-modellen:  

• Fra Team topologies kommer ideen om at produktteam kan deles inn i verdistrømteam, spesialiserte team, plattformteam og metodikk- og veiledningsteam, og om ulike grensesnitt og samarbeidsformer mellom team. Og ikke minst ideer om hvordan team kan struktureres og skaleres slik at virksomheten effektivt kan håndtere flere titalls og kanskje hundretalls team.
  
  
• Fra Spotify-modellen kommer foruten ideer om governance, ideer om hvordan faglig kompetanse kan ivaretas, brukes, stimuleres og videreutvikles i «kapitler» og «laug», som egne grupper, team og nettverk på tvers annen operativ tilhørighet for de ansatte. Slik kan både de ansattes og virksomhetens faglige kapabiliteter økes effektivt.

En strukturløs transformasjon?

Hvordan ser så organisasjonsstrukturene ut i produktorganiserte virksomheter? Det har vært populært å fremstille produktorganisering som en transformasjon fra et fast hierarki med funksjonsoppdelinger til et dynamisk og fleksibelt nettverk av team som oppretter forbindelser og samarbeid der det trengs. Men hvordan teamene skal få til dette har vært mer diffust beskrevet. Dynamikken man har forsøkt å illustrere, har mest av alt brakt tankene i retning av brownske bevegelser hos molekyler i en væske.

Den ser riktig så besnærende ut, men «molekylmodellen» over er ikke til særlig hjelp for å forstå hva slags organisasjonsstruktur man er på vei mot, eller hvordan governance skal fungere. For produktteam flyter ikke fritt omkring, ei heller i smidige virksomheter.

Faktum er at organisasjoner, uten unntak har, og må ha, strukturer og hierarkier. Og det er ingenting iboende galt med det. Hverken strukturer eller hierarkier er ensbetydende med byråkrati, anti-demokrati eller anti-smidige tilbøyeligheter. Noen strukturer og hierarkier er nødvendige. Andre kan være nyttige. Mens mange, og ikke minst «for mange», kan være til hinder.

De vertikale og horisontale strukturene

En organisasjons form eller struktur kan fremstilles i et organisasjonskart. En komplett struktur omhandler både den vertikale og horisontale fordelingen av posisjoner. Men ofte vises ikke eller iverksettes ikke begge disse aksene like tydelig og rigid.

Organisasjonskart og strukturer sier selvfølgelig lite om hvor godt virksomheten egentlig fungerer. Men en synliggjøring av de horisontale og vertikale strukturene kan hjelpe oss å forstå hvordan mandater, beslutningslinjer og myndighet bør fordeles og utøves langs sentrale akser av virksomheten. Og da trer også koordineringsbehovene og rolleavklaringene virksomheten faktisk trenger tydeligere frem.

Om vektorer og sektorer

For snart tre år siden skrev jeg artikkelen Smidig transformasjon vs. smidig stagnasjon. Der beskrev jeg en smidig virksomhetsmodell og en organisasjonsstruktur basert på vertikale sektorer og horisontale vektorer:

Historisk sett ble de vertikale og hierarkiske organisasjonslinjene, også kalt «sektorer», bygget for ansvarliggjøring via Chain of Command og for effektivisering av produksjonen via stadig mindre bruk av innsatsfaktorer. De horisontale strukturene, «vektorene», ble bygget flatere for å være autonome og adaptive, for å skape verdi og effekt i markedet.

Det er derfor smidige organisasjoner flytter ansvar og roller over på vektorer for produkter, tjenester og verdikjeder. Ved å være tettere på kundene med flatere struktur, kan innovasjon og tilpasninger til markedet skje raskere.

Vektorene og sektorene i produktorganiserte virksomheter

La oss derfor se nærmere på hvordan en produktorganisert virksomhet kan illustreres horisontalt og vertikalt med vektorer og sektorer, og hvordan det hjelper oss å tydeliggjøre teamenes plassering, ansvar og myndighet.

Vi begynner med å overlagre molekylmodellen med sektorer og vektorer, og innplassere de ulike teamtypene og gruppene i sine respektive sektorer og vektorer gitt av fargekodene:

• Verdistrømteam jobber med produkter, tjenester og leveranser, og plasseres sammen med andre verdistrømteam i sin spesifikke vektor for den verdi- og leveransekjeden (produktlinjen) de leverer til.
  
  
• Spesialiserte team eier systemdeler som er så spesialiserte at det gir mening å eie dem i (en eller flere) sektorer på tvers av verdistrømmene, på grunn av knapphet på spesialiserte ressurser, ekspertkompetanse, osv.
  Typiske eksempler kan være team med spesialister på avanserte algoritmer som maskinlæring eller kvantealgoritmer, og der resultatet eksponeres via grensesnitt som skjuler kompleksiteten for andre team.
  
  
• Plattformteam tilbyr infrastruktur og plattformfunksjoner til andre team i (en eller flere) sektorer på tvers av verdistrømmene, gjerne via selvbetjening, slik at teamene som velger å ta dette i bruk kan gjøre det selv.
  Typisk infrastruktur som plattformteam tilbyr er Sky, Kubernetes, Kafka, Snowflake, samhandlingsløsninger, bank- og finanstransaksjoner m.m.
  
  
• Metodikk- og veiledningsteam støtter andre team i å tilegne seg kunnskap og kompetanse som de trenger når eller hvis behovet oppstår. Kapabiliteten tilbys fra (en eller flere) sektorer på tvers av verdistrømmene.
  Typiske eksempler kan være coaching i arbeidsprosesser, domenekunnskap, DevOps, Smidig, testautomatisering, bruk av syntetiske data, m.m.
  
  
• «Kapitlene» og «laugene» fra Spotify-modellen jobber på tvers av verdistrømmene, og hører også naturlig hjemme i (en eller flere) sektorer.
  Her kan de ansatte, som har sin primæroppgave i team tilhørende andre vektorer og sektorer, ha et «andre hjem» for den delen av tiden de bruker på faglige bidrag, egenutvikling og på å bygge opp egen og virksomhetens faglige kapabiliteter.
  
  
• De tradisjonelle linjefunksjonene kan selvfølgelig fortsatt bli liggende i egne sektorer. Men trenger de det? Hvis de ansatte har sin operative tilhørighet i vektoren eller sektoren de leverer sitt primærbidrag til, og sitt «andre hjem» i en sektor for faglig utvikling, trenger de da i tillegg «et tredje hjem»? Må for eksempel alt av personaloppfølging legges til egne HR-strukturer? Eller kunne noe like gjerne blitt fulgt opp i de mer operative vektorene, som uansett må forholde seg til den etablerte praksisen for området?

Hva så med prosjektene? Som nevnt tidligere, kan det være fornuftig å beholde denne kapabiliteten som en supplerende leveransemekanisme. Men hører prosjekter hjemme langs vektor- eller sektoraksen?

• Hvis prosjektet for eksempel skal utvikle og igangsette en ny produktlinje, er det fornuftig å kjøre det langs vektoraksen, slik at man kan dra nytte av erfaringer og know-how om ledelse og governance fra de andre vektorene. Og så blir det selvfølgelig ditto argumentasjon for å kjøre et «sektorprosjekt», hvis prosjektet skal levere for eksempel et nytt samhandlingssystem. Eventuelle prosjekter bør kort og godt ledes og kjøres langs den vektoraksen eller sektoraksen det leveres til.

Et organisasjonskart for den produktorganiserte virksomheten

Hvis vi nå kort beskriver hovedleveransene fra de respektive vektorene og sektorene, legger på et ledelsesnivå og gir sektorene passende navn, ender vi opp med noe som begynner å ligne på et organisasjonskart med tydelige vertikaler og horisontaler.

• Her er sektorene for «Plattform og infrastruktur» og «Komplisert teknologi» blitt samlet under en teknologileder.
  
  
• Sektorene for «Arbeidsprosesser» og «Fag og kompetanse» er blitt samlet under en utviklingsleder.
  
  
• Og de ulike vektorene (produktlinjene) er blitt samlet under en leder med ansvar for det som leveres av produkter og tjenester.

Om disse lederne er på C-nivå (COO, CTO, CFO, osv.) eller D-nivå (direktør-nivå) er ikke et vesentlig poeng i figuren, det kommer an på skaleringen av organisasjonen.

Og heller ikke selve skaleringen er et vesentlig poeng her. I store organisasjoner må strukturen splittes ytterligere opp, og kanskje og suppleres med mer domenespesifikke strukturer. I mindre organisasjoner kan strukturen innskrenkes ytterligere.

Det som imidlertid er et poeng, er at jeg har plassert de tradisjonelle linjefunksjonene i stab. En stab kan være stor og omfattende, men den gir kun råd, støtte og service til ledelsen, og bestemmer ikke selv over andre i organisasjonen. Dermed reduseres antallet hierarkier, strukturer og rolleavklaringer som trengs, samt det medfølgende behovet for koordinering. Poenget er altså ikke om «tradisjonelle linjefunksjoner bør ligge i sektorer», men at

virksomheter bør redusere organisasjonskompleksitet der de kan.

For eksempel kan det være nødvendig å organisere «Plattform og infrastruktur» i flere mindre sektorer. Men dette vil samtidig kunne øke organisasjonskompleksiteten for vektorene, som da må forholde seg til prosedyrer og regler fra flere sektorer. Mens færre sektorer betyr klarere mandater og beslutningsveier, og en potensielt mer smidig og mindre «stiv» organisasjon for vektorene å måtte forholde seg til.

Karakteristisk struktur

Men slik figuren over illustrerer, ser altså den generiske og karakteristiske delen av organisasjonens struktur og governance ut, mer eller mindre, i den produktorganiserte virksomheten. Eller det ser slik ut lenger nede i virksomheten, i de underliggende enhetene, hvis det er de som utgjør den produktorganiserte delen av organisasjonen.

Prouktorganisering er altså en matrise som kombinerer flere prinsipper.
Men er matrisen svak, balansert eller sterk?

Rent historisk, i svake eller balanserte matriser, var det sektorene som var sterkest. Maktforholdet ble først utjevnet når matrisen ble gjort sterk. Men i produktorganiserte og samtidig produktorienterte virksomheter, strategi- og målstyres det mot verdiene som leveres av vektorene. Og da vil mange med god grunn forvente at nettopp vektorene bør være sterkere enn sektorene i de aktuelle delene av virksomheten.

Men er det slik produktorganiserte virksomheter faktisk blir rigget, med sterke horisontaler for verdistrømmene? Mange virksomheter har for eksempel en Chief Technology Officer (CTO), som er C-nivået for den vertikale teknologilederen i organisasjonskartet over. Men hvor ofte ser vi noen på tilsvarende nivå for produkter, en Chief Product Officer (CPO)? Det er rett og slett litt pussig, men

ansvaret for verdistrømmene i produktorganiserte virksomheter er ofte ikke plassert like høyt i ledelseshierarkiet som ansvaret for sektorene.

Er tanken at alt av tverrfaglighet, autonomi og mandater for styring og ansvar, kun er et ansvar på lavere ledernivåer? Men i så fall er jo produktteamenes forståelse av seg selv som autonome og selvstendige med et klart ansvar og mandat, kun er en slags organisatorisk illusjon, uten tydelig forankring oppover i ledelseshierarkiet.

Hvis man ikke forankrer produktteamenes mandat høyt nok i ledelseshierarkiet, og kanskje heller ikke til ledere med den reelle makten og myndigheten i organisasjonen, er det ikke da de facto vektorene som blir «svakest», jmf. svake, balanserte eller sterke matriser? Og legger ikke dette forholdene til rette for mindre produktorientering, og ikke mer? For over tid vil svake vektorer som forankres lavere eller dårligere i ledelseshierarkiet enn sektorene, uunngåelig svekke produktteamenes autonomi, beslutningsmyndighet og evne til styring.

Arbeidsmodellen for produktteam

Djevelen ligger som kjent i detaljene, og få steder er det like tydelig som når virksomheten egentlig mangler en arbeidsmodell for hvordan de tverrfaglige produktteamene bør jobbe. Den kan baseres på for eksempel prinsipper og praksiser fra «The Product Operating Model», ref. Transformed: Moving to the Product Operating Model, 2024, Marty Cagan. Arbeidsmodellen er ikke en rigid prosess eller metode, men snarere en prinsipp- og praksisbasert modell for hvordan autonome produktteam kan jobbe og prioritere, og som er konsistent med virksomhetens struktur, kultur og governance. I utgangspunktet vil en slik arbeidsmodell være tilstrekkelig for en virksomhet som lager IT-baserte produkter for det åpne markedet.

Men hvis man for eksempel lager saksbehandlingssystemer som også er underlagt helt andre premisser, som etterlevelse av kompliserte lovverk, regler og fortolkninger, så er det kanskje ikke nok å simpelthen «bare» øke tverrfagligheten i teamet. Da må man kanskje og vurdere selve arbeidsmodellen og bestemme seg for hvilke prinsipper og praksiser som skal gjelde ved motstrid mellom for eksempel smidig utviklingsmetodikk og metoder som skal sikre etterlevelse av lover og regler.

For det er altså ikke slik at en smidig prinsipp- og praksisbasert arbeidsmodell kan fungere på ethvert problem som teamet er forventet å løse. Ei heller er det slik at teamet selv alltid vil være i stand til å tilpasse eller endre arbeidsmodellen når de blir underlagt nye premisser.

Kanskje ligger det et dilemma her? Produktteam skal være autonome, og det kan de ikke være uten også å være tilstrekkelig tverrfaglige. Men tverrfaglighet har også en kostnad i form av flere premisser som det må tas hensyn til, så

jo mer tverrfaglig et produktteam er,
jo viktigere er det å sjekke at den operative arbeidsmodellen faktisk fungerer.

Hvis og når dette blir vanskelig, er det i høyeste grad et ledelsesansvar å komme med retningslinjer, avklaringer og tiltak for å sikre konsistens med hvordan virksomheten faktisk er ment å operere.

I verste fall kan det til og med være slik at man bør vurdere om virksomheten er bedre tjent med en produksjonslinje som er mer oppsplittet mellom «fagene». Var det noen som sa «siloer»?

Organisering eller orientering?

Bør man så produktorganisere seg, eller bare produktorientere seg? En virksomhet kan ta mange grep mot produktorientering. Strategi, målstyring og kultur med fokus på kundebehov og verdiskapning kan oppnås selv om man ikke er produktorganisert. Det blir imidlertid enklere å sikre kontinuerlig fokus på kundebehovene og prioritere effekter fremfor leveranser hvis virksomheten også er produktorganisert.

Men produktorganisering er ikke enkelt. Det innebærer en full organisatorisk transformasjon som endrer måten virksomheten får gjort ting på. Og det er snublesteiner på veien. Jeg har nevnt noen som for eksempel en tydelig og sterk vektorrstruktur i organisasjonen, et begrenset antall sektorstrukturer og en arbeidsmodell for produktteamene som er tverrfaglig konsistent. Kanskje er den viktigste denne: Å forankre produktaksen høyt nok i virksomhetens ledelseshierarki. Følgende fyndord kan i så måte tjene som en påminnelse for de som skal gå i gang med å produktorganisere seg:

Half-measures only preserve the old while pretending to build the new.

---

Denne artikkelen er skrevet av Stefano Angelo Donati. Han jobber i PROMIS.