Produkttransformasjon
Det er ikke et endringsprogram, og ender for ofte i en ‘feature factory’
Digitaliseringen har skutt fart de siste årene og blitt forsterket av pandemien. Det er blitt enda viktigere for virksomheter å være i stand til å raskt kunne tilpasse seg nye forhold, skifte retning, endre organisasjonen, finne nye måter å arbeide på og utvikle nye produkter og tjenester. Behovet har kommet til alle typer virksomheter etter hvert som forventningene fra digitaliseringen har bredt om seg. Og som kjent — digitalisering går ikke over!
Utviklingen sammenfaller med at flere har sett ulempene med prosjektmodellen, eller man er en tradisjonell virksomhet som benytter smidige metoder, og ønsker å adoptere en produkttankegang til utviklingen. Virksomhetene ønsker å kopiere kulturen, organiseringen og arbeidsmåtene som kjennetegner de store teknologiselskapene. De ønsker å arbeide i tverrfaglige autonome team for å håndtere kompleksiteten i utvikling og i omgivelsene. Utvikling er komplisert men blir ofte komplekst pga. alle aktørene man må forholde seg til, design, prioriteringer, utforskning, samhandling, sikkerhet og mye, mye mer. Slike autonome team har vist seg bedre enn andre tilnærminger for å håndtere kompleksiteten, og gir større endringsevne enn tradisjonelle organisasjonsformer.
Mange virksomheter har erkjent at det er vanskelig å planlegge for fremtiden blir sjelden slik man tror, og ønsker å bygge en mer tilpasningsdyktig og dynamisk organisasjon som kan håndtere endringene bedre. De ønsker å bli mer innovative, dynamisk, skape mer verdi, vinne konkurransene, eller posisjonere seg i økosystemer med plattformer. Man ønsker å bli mer brukerdrevet, eller som Amazon sier — besatt av kunden.
Når arbeidet er komplekst så må man prøve, måle og lære. Av denne erkjennelsen kommer nyere metoder, og kompleksiteten håndteres ved å lære og få tilbakemeldinger i en desentralisert struktur. Skaper verdi og mer fart og flyt gjennom hele verdikjeden til hvert enkelt team.
Prosessen med å endre utviklingen til en produkttankegang kan man kalle en produkttransformasjon, eller kanskje man heller burde kalle det en evolusjon? For noen er det et paradigmeskifte.
Produktutvikling
Digital produktutvikling kan ses på som en videreutvikling av produktutvikling og smidig systemutvikling. Det har vært utviklet produkter i lang tid og i forrige århundre ble produktdesign viktigere. Design Thinking kom i begynnelsen av dette århundre. Sammen med konsepter fra Lean og Customer Development, er det grunnlaget for digital produktutvikling med metoder som Lean Startup, Lean UX og Sense and Respond.
Systemutvikling er et fagfelt fra femtitallet. Rett før årtusenskiftet kom en mer smidig tankegang med XP, Scrum og etter hvert Kanban. De er også påvirket av Lean. Det smidige manifestet ble skrevet i 2001. Deretter kom DevOps som sammen med mikrotjenester og skytjenester, er grunnlaget for mange av dagens digitale produkter.
Dette har smeltet sammen til en kontinuerlig produktutvikling. Først med boken «Inspired». Der M. Cagan tar smidig som gitt og er fokusert på hva man skal lage, hvorfor man skal lage det og til hvem. Utviklingen har fortsatt med «Escaping the Build Trap» M. Perri og «Continuous Discovery Habits» T. Torres, med fokus på å utvikle riktig produkt, på utforskning av hva og hvorfor, og å skape verdi.
Denne digitale produktutviklingen handler om å bygge det riktige produktet, mens smidig har tradisjonelt vært mest opptatt av å bygge produktet på riktig måte.
Den største endringen i den senere tid er at teamene nå også tar ansvar for utforskning av å velge hvilke muligheter som gir størst verdi å utvikle.
I mange virksomheter eksisterer utviklingsteamene for å levere til forretningen. Ofte, selv om det ikke er eksplisitt uttalt, ender forretningen med å drive det som faktisk blir implementert i utviklingsteamene.
I en produktorganisasjon er produktteamene til for å levere til en virksomhetens brukere eller kunder på måter som understøtter virksomhetens behov.
Produktteamene identifiserer eller får bruker-, kundebehov eller problemer å løse, har myndighet til å utforske og utvikle en løsning på disse, og er ansvarlige for resultatene.
Det kan se ut som en ubetydelig nyanse, men medfører en stor endring i hvordan utviklingen fungerer ved å gi en slik autonomi og ansvar til teamene. Det er ikke lengre en annen avdeling, ledelsen, eller noen andre som utelukkende prioriterer og beslutter. Dette er for mange en stor forskjell. Den påvirker nesten alt om hvordan teamene fungerer, og forskjellen resulterer i høyere motivasjon og moral. Det er veldig motiverende å kunne se hele verdikjeden og kunne påvirke resultatet. Og kanskje viktigst av alt, det gir resultater i form av verdi for brukerne, kundene og virksomheten.
«Det er kunsten å lære hva man skal lage, mens man lager det.» — Anders Skifte
Denne tilnærmingen kjennetegnes av et menneskelig ønske om sosial og erfaringsbasert læring. Mange foretrekker å løse problemer sammen i team, og ‘learning by doing’ gir en bedre og dypere læring enn å bli fortalt hva man skal gjøre. For ledelse medfører det mer fokus på nye digitale lederteknikker, andre måter å organisere utviklingsarbeidet på og mer desentraliserte beslutninger. De må skape en visjon og strategi sammen med teamene, bygge en digital kultur og ledertankegang. Eller som noen kaller det — gi slipp ledelse. Det hjelper neppe å si at man skal jobbe produktorientert og beholde samme bestiller — leverandør modell eller ‘feature factory’ oppsett. Ei heller beholde de tradisjonelle lederpraksisene.
Nøkkelkompetansen som er nødvendig blir ofte beskrevet som en produkttrio. Den har overordnet tre typer kompetanse og er et samspill mellom produktleder, tech lead og design lead:
Produktutvikling utvider tradisjonell smidig med mer fokus på utforskning og det er veldig viktig at teamet starter sammen for å unngå overleveringer og kunnskapstap med de utfordringene det bringer med seg. Slikt teamarbeid er vanskelig, rotete og medfører at man stadig må gå tilbake for å skape en felles forståelse av problemstilling. Det kan virke veldig ineffektivt på noen, siden alle teammedlemmene ikke er like opptatte og effektive hele tiden som man er vant til i en ‘feature factory’. Det å starte sammen kan være konter intuitivt for mange. I sine natur handler det om å utforske og utvikle et produkt samtidig. Hvis hele teamet er ansvarlig for produktets suksess, ikke bare å utvikle ting, så forstår og bidrar hele teamet til både utforskning og utvikling.
Denne samskapingen må gjøres av et team, sammen, på samme plass og til samme tid.
Slike myndiggjorte tverrfaglige produktteam eier suksessen til produktet, og akselererer tilbakemelding og eierskap. Det ansvarliggjør teamet og skaper engasjement og motivasjon. Tiden da IT-teamet eller forretningsteamet eide et digitalt produkt er nok over. DevOps fjernet overleveringene mellom utvikling, test og drift. Nå er det overleveringer mellom ideer, konsepter, spesifikasjoner — utforskning, og utvikling man ønsker å fjerne.
Transformasjon
En produkttransformasjon er å gå fra en modell der utviklingsteamene er til for å levere til forretningen eller utføre oppgaver i prosjekter, til en hvor de leverer verdi til brukerne eller kundene som understøtter virksomheten. Det betyr å gå fra en bestiller — leverandør tankegang der utviklingsteamene er underordnet forretningen, til en samarbeidsmodell.
NB! En slik transformasjon er ikke et endringsprogram.
Hovedpoenget er ikke å endre noe fra en tilstand til en annen. Det er en utvikling i bransjen som kan kalles en produkttransformasjon. Den bygger på det vi har lært om produkt- og systemutvikling over de siste 20 årene — og utviklingen vil faktisk fortsette! Transformasjonen man ønsker å få til:
Det er viktig at toppledelsen har digital kompetanse. Det er vanskelig å lykkes hvis man ikke har støtte fra ledelsen og en forståelse for digital produkt- og tjenesteutvikling. Da vil ofte flere deler av virksomheten fortsette å arbeide på tradisjonelt vis. En produkttransformasjon vil også ha konsekvenser for andre deler av virksomheten som f.eks. marked, salg, økonomi og ikke minst styringsenheter.
Dersom ledelsen ikke ordentlig har forstått hva produktutvikling innebærer og hva deres rolle er, kan veien være lang. Ledelsen må være ambassadører og selv etterleve prinsippene og utøve nye lederteknikker. Ledelsen må få tid til og erfaring med å gi tillit og beslutningsmyndighet. Hvis toppledelsen mangler digital kompetanse kan det være vanskelig å løfte blikket og fokusere på en digital transformasjon og strategi.
Toppledelsen må sette digital kompetansebygging i system og arbeide med problemstillingene over tid.
Ledelse må også forstå rollen som design og teknologi har i produktutviklingen som muliggjører for transformasjon og som en viktig rolle i virksomhetens strategi. Tiden da IT eller digitalisering var en støtteprosess, eller et kostnadssenter, er vel egentlig over?
Lær av andre. Det er mange som har gjennomført tilsvarende transformasjoner, har digitale produktorganisasjoner, eller er digitale. Se til dem som er omtrent like store. Alle mekanismene som store virksomheter har, kan ofte være overkill for mindre virksomheter. Start så enkelt som mulig.
Med lærdommen fra smidige transformasjoner bør man starte transformasjonen med — en smidig tilnærming. Start med et team, piloter, skaler ut horisontalt, eksperimenter og lære. Skaler ut og opp med støtte fra toppledelsen.
Man må ikke starte transformasjonen med en “big bang” hvor hele eller deler av virksomheten kastes opp i luften og tas ned i en ny form i løpet av kort tid. Det vil skape mye usikkerhet og tvil. Kunnskapsarbeidere har som kjent to ben å gå på — og bruker dem. Det er også motsatt av lærdommen fra mange som har kommet lang i sin produkttransformasjon eller har gjennomført en smidig transformasjon.
Forstå og kommuniser utgangspunktet. Hvor er man og hva ønsker man å oppnå. Utarbeid en visjon for transformasjonen, evangeliser og overkommuniser denne. Skap suksesshistoriene, kommunisere hele tiden ved historiefortelling, for å skape et ønske om å arbeide produktorientert.
Begynn med innovatørene og foregangs brukerne. Ikke kast bort tid på etternølerne i starten.
Bygg opp design og innsiktsarbeid. Etabler målinger og skap produktstrategien ut fra denne kunnskapen.
Bygg opp gode og tydelige produktledere som kan lede produktteamene og som kjenner til, eller kan lære seg hvordan produktutviklingsorganisasjoner ser ut og opererer. For andre typer team er gode teamledere også viktige. Produktutvikling krever mer og bedre ledelse. Og husk! Produktledelse er ikke det samme som prosjektledelse eller produkteierskap.
Myndiggjør utviklerne ved å hjelpe de ut av backloggen og inn i sentrum av produktteamene for å utforske og utvikle løsninger på behovene og problemene.
Arbeid kontinuerlig med å fjerne avhengigheter og flaskehalser for å skape mer autonomi.
Opplæring har en sentral rolle både for teamene og ledelsen. Skap en delingskultur. Uten en forståelse for produktutvikling og aksept av en annen tilnærming, risikerer man at man fortsetter som før med nye navn på prosesser og organisasjonsenheter.
Reetabler samarbeidet med forretningen. Bygg relasjoner, gjennomfør opplæring, vær transparent, utarbeid mål og kommuniser hyppig. Utfordringen er at de vil føle at de mister kontroll, og man må redefinere forholdet mellom produktorganisasjon og andre deler av virksomheter. Grunnen til at dette er vanskelig og viktig er fordi det synliggjør politikk og silotankegang. En produkttransformasjon representerer en reell endring for mange sentrale interessenter.
Endre måten man finansierer arbeidet. En årlig finansiering, eller på prosjektbasis er det motsatte av teamenes iterative og utforskende arbeid — en kollisjon mellom nye måter å arbeide på og tradisjonelle finansieringsmodeller.
Det er en lagsport og det er gøy!
For noen og kanskje spesielt endringsledere kan målet bli transformasjonen. Da kan det bli en fare at man mister fokus på den egentlige hensikten — utvikle gode digitale opplevelser for virksomhetens brukere og kunder. Produktet kan ende som et biprodukt.
«Jeg får et tydelig inntrykk av at skiftet fra prosjekt til produkt i mange store virksomheter er mer et skifte fra prosjektfabrikk til ‘feature factory’.» — John Cutler
Smidige transformasjoner
Vi kan også høste erfaringer fra smidige transformasjoner de siste 15 årene. En større undersøkelse viste at lederstøtte inkludert opplæring av ledelsen, og å tilpasse organisasjonen var de viktigste suksessfaktorene. Valg av og tilpasning av smidig tilnærming, et felles tankesett og verdier, ble ofte identifisert som suksessfaktorer. Virksomhetene benyttet ofte smidig faggrupper, sosiale arrangement og coacher for å spre kunnskap og knytte kontakter.
Mens de viktigste utfordringene var endringsmotstand, skepsis til nye måter å arbeide på, oppfatning om at det er vanskelig å arbeide smidig, misforståelse av konsepter og metoder, hierarkisk ledelse og organisasjonsgrenser. Flere peker på utfordringer med koordinering — autonome teammodellen er utfordrende. Flere av disse vil også gjelder for en produkttransformasjon.
Referanser
Cagan M. (2017). Inspired How to Create Tech Products Customers Love.
Cagan M. (2021). Silicon Valley Product Group (svpg.com/articles).
Cutler J. (2019). The (Messy) Shift to Starting Together. Amplitude. blog.prototypr.io.
Denning S. (2021). Forbes. Why ‘Big Bang’ Agile Transformations Are A Bad Idea. Twelve Leadership Keys To Embracing Digital At Volvo Car.
Dikert K. & al (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review.
Patton J. (2017). Dual Track Development is not Duel Track.
