Produktorientering er på agendaen, men hvordan komme i gang?
Mange virksomheter er nysgjerrige på produktorientering om dagen. Noen har allerede tatt de første stegene og ønsker hjelp til å skape mer…
Produktorientering er på agendaen, men hvordan komme i gang?
Mange virksomheter er nysgjerrige på produktorientering om dagen. Noen har allerede tatt de første stegene og ønsker hjelp til å skape mer effekt i større skala. Samtidig sitter mange og lurer på hvordan de i det hele tatt skal komme i gang. Hvor starter vi? Passer dette egentlig for oss? Og hvilke gevinster kan vi forvente?
I denne artikkelen løfter vi frem noen praktiske tips for virksomheter som ønsker å utforske produktorientering. Disse bygger både på våre egne erfaringer fra ulike kunder og inspirasjon fra blant andre Teresa Torres og Hope Gurion.
Forstå problemet og motivasjonen før dere begynner
Som med det meste innen organisasjonsutvikling finnes det ingen hellig fasit på hvordan starte med produktorientering. Det er mange veier til Rom, og minst like mange fallgruver. Men i de fleste tilfeller innebærer en vridning mot produkt at medarbeidere og ledere endrer måten de tenker rundt og jobber med læring og verdiskaping. Det betyr gjerne at noen grunnleggende antakelser må utfordres, både på individnivå og i organisasjonen. Slik endring krever både nysgjerrighet og motivasjon for å få ting til å skje.
Et naturlig sted å begynne er derfor å forstå hvorfor virksomheten vurderer produktorientering i utgangspunktet. Grunnleggende her ligger ofte opplevelsen av at dagens måte å utvikle digitale tjenester på ikke fungerer godt nok. Kanskje har dere kjent på smerten ved mange overleveringer, økende teknisk gjeld, lange ledetider eller den litt nagende følelsen av at «vi burde få til mer enn dette». For noen kommer signalene enda tydeligere: tap av markedsandeler, synkende kundetilfredshet eller en opplevelse at konkurrenter alltid er det lille kneppet foran.
Når slike symptomer blir synlige, både internt og i markedet, blir motivasjonen for endring som regel sterk. (Man skal aldri undervurdere effekten av en god, gammeldags burning platform). Når smertepunktene er reelle, blir det også lettere å samles rundt noe nytt, et felles mål. Og som alltid: jo høyere opp i organisasjonen disse utfordringene merkes på kroppen, jo sterkere blir drivkraften for endring. Men selv om problemet er tydelig, betyr ikke det automatisk at produktorientering er den riktige løsningen
Bygg erfaring gjennom pilot-team
Uansett hvor mye dagens situasjon smerter, og hvor høy motivasjonen er for å prøve noe nytt, vil det alltid være en naturlig skepsis når en organisasjon står overfor en større endring. Kommentarer som «Vi har ikke tid til dette — vi må levere på neste milepæl», «Mer frihet til teamene vil bare skape kaos», eller den klassiske «Disse produkt-greiene vil aldri fungere hos oss», dukker opp i de fleste virksomheter.
Informasjon og kursing kan være nyttig i en startfase, men praktiske grep og håndfaste resultater trumfer alltid teori. Og den mest høylytte skepsisen har en tendens til å stilne når man får se konkrete resultater.
En effektiv måte å vise hva produktorientering kan utgjøre er å starte med et utvalgte pilot-team som får teste en produktorientert arbeidsform i praksis over en periode. Det innebærer ofte større endringer i hvordan teamene ledes, hvordan de utforsker problemer og muligheter, og hvordan de utvikler og leverer tjenestene sine.
Disse større endringene er mye enklere og mer virkningsfulle å få til i en del av organisasjonen, snarere enn å lykkes med mindre virkningsfulle endringer for hele organisasjonen.
Ved å starte smått kan dere skape gode eksempler som andre team kan lære av, samtidig som dere får verdifull innsikt i hva som fungerer, og hvilke organisatoriske grep som må gjøres.

Figur 1: Med pilot-team er det mulig å skape store endringer i et avgrenset område
Velg riktig antall pilot-team for å skape læring og redusere risiko
Premisset for å lykkes med denne tilnærmingen er naturligvis at pilot-teamene faktisk leverer verdi. Den gode nyheten er at dere kan øke sannsynligheten for dette gjennom hvilke team dere velger, hvordan de rigges, og hvordan de støttes underveis.
Avhengig av virksomhetens størrelse er det lurt å velge mellom 2–4 pilot-team. Risikoen ved å velge kun ett team er at eventuelle organisatoriske hindringer innen et spesifikt forretningsområde, vil stoppe det hele opp. Eksempler på slik hindringer er manglende tilgang til brukere, uklare prioriteringer, umoden teknisk plattform og avhengigheter. Velger dere for mange team er det risiko for å spre støtten og oppmerksomheten så tynt at ingen får de forutsetningene de trenger.
Gi pilot-teamene de riktige forutsetningene
Folkene i og rundt teamene er naturligvis helt avgjørende. Produktsuksess kommer ikke av at et team «jobber smidig», men at det har forutsetninger for å levere kontinuerlig verdi. Det handler om kompetanse på produktutvikling, tverrfaglig samarbeid, innsikt i brukernes behov, og evnen til å lære og tilpasse seg raskt.
Mange virksomheter har allerede personer med erfaring fra tverrfaglige team, produkteierroller eller smidige prosjekter. Det er et godt utgangspunkt, men produktsuksess krever noe mer. Et team må forstå verdikjeden de påvirker, kunne teste hypoteser, jobbe datadrevet og ta ansvar for helheten, ikke bare sine faglige leveranser.
Hvis kompetansen mangler internt, er det klokt å bygge den direkte inn i pilot-teamene. Det kan bety å leie inn eller ansette folk som faktisk har jobbet i moderne produktteam tidligere. Ikke for å «gjøre smidig», men for å hjelpe teamet å etablere gode produktpraksiser, lære raskere og bygge retning og eierskap.
En tredje løsning for å sikre kompetanse og støtte (utover å videreutvikle egne eller å ansette/leie inn) er å etablere en såkalt operativ enablement-kapasitet: et lite team som jobber tett på pilotene og lederne deres for å bygge ferdigheter, fjerne friksjon og hjelpe teamene å lykkes i praksis. Dette er ikke rådgivere som står på sidelinjen, men en integrert støtte som gjør teamene bedre over tid.
Utover å vurdere kompetansen i og rundt team er det viktig å velge riktig startpunkt teknologisk. Selv om teknisk kompetanse er viktig, handler dette først og fremst om hva som faktisk lar seg gjennomføre i praksis. Eksempelvis er det vanskelig å demonstrere effekten av produktutvikling hvis teamet starter med å «produktifisere» en monolittisk applikasjon som ikke lar seg endre løpende. Det er derfor smart å begynne der kontinuerlig verdiskaping faktisk er mulig, slik at teamet får bevist effekten raskt.
Et siste råd rundt utvelgelse av pilot-team: ikke undervurder relasjonene. Et team kan være faglig sterkt, men uten trygghet, åpenhet og et genuint ønske om å lære sammen, blir veien mot verdiskaping lang. Derfor er det klokt å velge pilotteam som allerede har gode relasjoner og ikke minst er motivert for å utvikle seg mot en annen måte å operere på.
Sett tydelige effektmål og skap delt eierskap
Pilot-team handler ikke om å “gjøre litt produkt” i et hjørne av organisasjonen. Det handler om å teste i praksis om virksomheten faktisk klarer å skape kontinuerlig verdi når team får riktig eierskap, støtte og rammer. Derfor må de styres etter effekter — ikke leveranser. Outcome viser om retningen er riktig. Output viser bare at folk har jobbet.
I de fleste etablerte organisasjoner mangler man både datagrunnlag, teknisk praksis og systemstøtten til å sette gode effektmål. Det gjør det ekstra viktig at ledergruppen involveres tidlig og får et delt eierskap. Ikke for å detaljstyre, men for å definere hva som faktisk betyr noe, dele kritisk forretningskontekst, fjerne hindringer og gi teamene rom til å lære.
Det er denne læringen som skal være selve motoren i endringen. Ingen pilot vil være perfekt. Det er heller ikke målet. Målet er å finne ut hva som fungerer i deres kontekst, hvilke strukturer som støtter kontinuerlig verdi, og hvilke mønstre som må endres før man i det hele tatt vurderer skalering.
Se figur 2 for oppsummering av hvilke hensyn dere bør ta for valg av pilot-team, og figur 3 for hvilke fordeler og fallgruver dere bør være oppmerksom på.

Figur 2: Grunnprinsipper og alternativer basert på kompetanse i virksomheten
Vær tålmodig, ikke skaler for tidlig
Hvis dere er i en situasjon hvor pilot-teamene begynner å få god fart, kommer et siste, men viktig råd på veien: Ikke skaler produktmodellen for tidlig! Når de første resultatene kommer, er det fristende å rulle ut i stor skala. Men nettopp her er det lett å snuble.
Dersom dere utvider før teamene har skapt reelle effekter, før praksisene sitter over tid, før støttestrukturene er på plass, og før lederlaget har funnet sin nye rolle, er risikoen stor for å skli tilbake til gamle arbeidsformer.
La derfor pilotene løpe litt lenger enn dere tror. Dette blir kanskje spesielt viktig for større organisasjoner hvor ulike forretningsenheter gjerne har sine egne prosesser, struktur og kultur. Det som fungerer i område X, vil ikke nødvendigvis fungere i område Y. Da blir ikke svaret å etablere flere team, men heller utvikle de strukturelle forutsetningene som for eksempel finansiering, styring, organisering og teknologi.
Tema om skalering vil dekkes i en senere artikkel i denne serien om produktorientering fra Sopra Steria.
Her er hovedpoengene som kan hjelpe dere å ta de første stegene mot produktorientering:
- Forstå problemet og motivasjonen før dere begynner
- Bygg erfaring gjennom pilot-team
- Velg riktig antall pilot-team for å skape læring og redusere risiko (2–4 stk)
- Sikre riktig kompetanse og støtte rundt teamene
- Sett tydelige effektmål og skap delt eierskap
- Vær tålmodig, ikke skaler for tidlig

Figur 3: Når velge hva basert på kompetansen og tilhørende forutsetninger, fordeler og fallgruver
메타데이터
- post_id
- 1c75abd678a2
- slug
- produktorientering-er-på-agendaen-men-hvordan-komme-i-gang-1c75abd678a2
- url
- https://medium.com/sopra-steria-norge/produktorientering-er-p%C3%A5-agendaen-men-hvordan-komme-i-gang-1c75abd678a2
- canonical_url
- https://medium.com/sopra-steria-norge/produktorientering-er-p%C3%A5-agendaen-men-hvordan-komme-i-gang-1c75abd678a2
- author_url
- https://medium.com/@preben.giving
- status
- ok
- fetched_at
- 2026-07-14 22:53:46