Å lage digitale produkter innenfor offentlig sektor handler, direkte eller indirekte, om å implementere politikk. At det tar tid, skal være en del av den politiske prosessen. Det skaper stabilitet, forankring og forutsigbarhet. Men det skaper også utfordringer for de som skal lage løsningene. Når vi driver med digitalisering, kommer den beste læringen om mulighetene, utfordringene og gevinstene når vi jobber med å faktisk lage ting.

Denne avstanden skaper noen utfordringer som gjør digital produktutvikling i offentlig sektor ekstra vanskelig. I denne artikkelen skal vi se på hva disse utfordringene er, hvor de kommer fra, og hva det krever av et team å håndtere dem.

Hvis du ser mange nok team drive med digital produktutvikling i små og store selskaper på tvers av bransjer, er det overraskende hvor gjenkjennbare problemer der står i. Likevel er det noen utfordringer som tar en litt egen form i offentlig sektor.

Her vi skal vi ta for oss fire av disse utfordringene, og si litt om hva et utviklingsteam kan gjøre for å løse dem.

M’en i Minimum Viable Product er svær

Å definere MVPer er vanskelig. Og det blir ikke noe lettere når bestillingen din er å implementere en reform eller et lovverk, som på ingen måte presiserer en del som er mer eller mindre viktig. Eller en del av loven som kan implementeres når kjernefunksjonaliteten bare er i produksjon.

Den spesielle utfordringen i offentlig sektor er at et produkt som ikke er komplett, fort kan være et produkt som er ulovlig. Å finne den vertikalen av produktet som kan lages og testes isolert, samtidig som den totale risikoen er håndtert, krever kreativitet og tett samarbeid mellom utviklere, designere, jurister, fageksperter og ledere.

Hvis teamet ikke klarer å finne en mindre MVP som både er brukbar og lovlig, kan de gjerne ende opp med implementasjonsløp som går over flere måneder og gjerne år før den kan tas i bruk i produksjon. Når løsningen da først går i produksjon, blir overgangen fra en lang produksjonsfase til å jobbe utforskende med eksperimenter, effekt og læring fort vanskelig. Å jobbe utforskende for å skape gode brukeropplevelse og effekt er en annen modus, som krever en annen kultur, prosess og dels kompetanse, enn å være i leveransemodus.

Å håndtere denne overgangen krever en stor grad av bevissthet både i og rundt teamet. Det aller viktigste er at teamet jobber hardt og bevisst med å finne ut hvordan de kan gjøre MVPen sin så liten som mulig, og hvordan de kan begynne å lære så tidlig som mulig. Videre må de ha et konstant fokus på hvordan de kan få noe i produksjon, og begynne å eksperimentere og lære. Det krever også en god dialog med omgivelsene rundt teamet for å håndtere risikoen med å gå i produksjon med noe som ikke dekker alle juridiske krav.

Stor avstand fra utforming av lovverk til produktutvikling

Tanken om det digitale produktutviklingsteamet kommer fra anerkjennelsen av mulighetsrommet ved digitalisering først blir kjent når man jobber i dybden med å implementere produktet. Det står i stor kontrast til en verden der mange sentrale beslutninger om det som skal lages blir tatt før det i det hele tatt er tenkt en tanke om teamet som skal lage det. Når produktutviklingsteamet først er satt og begynner å høste erfaringer, er veien tilbake til å utfordre forutsetningene lang. Det gjør at teamene ender opp med å måtte lage løsninger som er vanskeligere å bruke og bommer på intensjonen bak.



Som regel finnes det et handlingsrom gjennom gode ledere og jurister som støtter teamene i prosessen og dialogen ovenfor interne juridiske miljøer og bestillere i departementet. Dette er en prosess som burde vært bedre forstått og definert: hva kan utfordres, når kan de diskusjonene tas og hva er prosessen for å gjøre det?

Dette må starte med produktutviklingsteamene. Det er de som kjenner hvor skoen trykker, og hvor potensialet ligger. Det krever team som er bevisste på verdiskapning og målene sine. Når de finner muligheter må de vurdere i hvilken grad den er i tråd med intensjonen bak lovverket, og klare å formidle utfordringen og effekten det kan skape. Det forutsetter også at teamet har god støtte fra omgivelsene rundt seg, og klarer å navigere organisasjonen og finne fram til folkene som kan hjelpe dem med å ta vanskelige diskusjoner. For å lykkes med det, trenger de å jobbe godt på tvers av fagområder som teknologi, design og juss.

Vanskelig samarbeid på tvers av ulike fagområder og kulturer

Det begynner heldigvis å bli mer og mer vanlig at produktutviklingsteam settes sammen med bredden av fagområder som trengs for å levere. I offentlig sektor betyr det at teamene ikke bare består av tradisjonelle produktutviklere som designere og teknologer, men også jurister og representanter for faget, som for eksempel saksbehandlere.

Å jobbe så bredt tverrfaglig krever en stor investering i kultur for samarbeid og å forstå hverandre sine perspektiver. Uten bevisst, hardt arbeid for å lykkes med samarbeidet på tvers, ender teamene fort opp med å være flerfaglige heller enn tverrfaglige. I flerfaglige team jobber folk fra ulike fagdisipliner i parallell med hverandre, uten at de i nevneverdig grad klarer å skape ekstra verdi med å jobbe sammen. I tverrfaglige team skjer et mest interessante i grensegangen mellom ulike fagområder, der teammedlemmene bruker perspektivene fra hvert sitt fagfelt til å skape en bedre og mer kreativ helhet enn de kunne gjort hver for seg.

Samarbeidet blir ekstra vanskelig når folk kommer fra veldig ulike bakgrunner. Tidligere betydde «tverrfaglig» typisk samarbeid mellom utviklere og designere, som stort sett kommer fra de samme skolene og har vokst opp med teamarbeid. Jurister og fagspesialister kommer ofte fra studiebakgrunner og miljøer der individuelt arbeid er vanlig, og organiseringen er mer hierarkisk. Da kan møtet med et flatt organisert, smidig og autonomt produktteam by på en kulturkræsj.

Å lykkes med dette samarbeidet krever at alle i teamet går inn med en bevissthet om verdien av å jobbe tverrfaglig, og er villige til å investere i å få teamet til å fungere. Det betyr å bruke tid og krefter på å forstå hverandre sine fagfelt, snakke om samarbeidet og hvorfor det er vanskelig, og å være forberedt på å endre måten man jobber på selv.

I brede tverrfaglige team er det også sannsynlig at man trenger en teamleder som kan olje maskineriet. 

En finansieringsform som ikke legger til rette for læring

Det er skrevet og sagt mye klokt om finansieringsmodellen for prosjekter i offentlig sektor. Og det er vel egentlig ingen som mener måten vi gjør det på i dag funker. Det vanligste er fortsatt prosjektfinansiering, der det settes av en stor pott penger, et sett gevinster som skal realiseres og en frist. Og så er det bare å sette i gang med å levere.

Dette er omtrent det motsatte av de forutsetningene du trenger for å drive god produktutvikling. Gode produkter oppstår når team eier et produkt over lang tid, og kan iterere gjennom å utfordre, teste hypoteser, måle effekt og lære.



For produktutviklingsteamene er dette først og fremst en rammebetingelse det er viktig å forstå og anerkjenne. Det er lov håpe, men samtidig er det nok lenge til statsbudsjettet legger til rette for smidig utvikling. Når det er virkeligheten, er det desto viktigere å alltid ha fokus på hvilket problem er det egentlig vi prøver å løse her, og hvorfor er det verdt å løse? Hva er den underliggende verdien vi prøver å levere til befolkningen?

Heldigvis er det mange ledere i offentlig sektor som er flinke til å jobbe kreativt med både driftsmidler og prosjektfinansiering. Hvis ledere klarer å snu forutsetningene rundt til å være best mulig, og teamene jobber bevisst med å skape verdi, så skal det fortsatt være fullt mulig til å jobbe ekte produktutvikling. Selv om den grunnleggende finanseringen er til hinder heller enn støtte.

Digital produktutvikling er et problem som er verdt å løse

Digital produktutvikling i offentlig sektor er vanskelig. Men det er det i privat sektor også! Selv om utfordringene jeg har beskrevet er ekstra store i offentlig sektor, så finner du du variasjoner samme problemene i de fleste team som driver med produktutvikling.

I moderne team drar vi ikke på jobb for å levere kode eller lage funksjonalitet. Vi drar på jobb for å skape verdi. Det handler om at vi må ta eierskap til problemene vi prøver å løse, og er villige til å jobbe med rammebetingelsene. Spesielt når rammebetingelsene er vanskelige. Noen forutsetninger er vanskelig å gjøre noe med, men det går aldri hvis du ikke prøver.

Offentlig sektor i Norge står ovenfor store effektiviseringsutfordringer i årene som kommer, og mye av løsningen ligger i vellykket digitalisering. For å få til det er vi avhengige av å lykkes med digital produktutvikling.

Så oppfordringen er: ikke gi opp å jobbe for å få det til bedre! Jobb for å få til en MVP som lar dere teste hypoteser og verifisere at løsningene deres virker. Jobb for å lage det riktige produktet innenfor lovverket, og jobb for å justere lovverket sånn at produktet blir riktig. Jobb for å få til det krevende, brede tverrfaglige samarbeidet. Og jobb for å levere på det underliggende målet selv om rammebetingelsene er utfordrende.

For lykkes vi med det, så lykkes vi med å skape bedre tjenester for oss alle, og en mer en mer bærekraftig offentlig sektor i fremtiden.

Fire utfordringer for digitale produktutviklingsteam i offentlig sektor

Designdrypp er en artikkelserie hvor forskjellige designere fra Bekk forteller om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips!





Hvem er jeg?

Navn: Beate Ingebretsen

Alder: 34 år 

Fra: Larvik

Studerte på: Idefagskolen, Høyskolen Kristiania, Kunsthøyskolen og Westerdals Oslo school of arts

Jobbet som designer i 9 år


Hvorfor ble du designer? 

Allerede fra tidlig alder ble jeg dratt mot det visuelle og estetiske. Å forme, male og skape ble mine måter å uttrykke meg på, til tross for mammas stadige bekymringer for hjemmets overlevelse. Mine eksperimenter var ikke begrenset til små ark med saks, teip og penselstrøk. De tok ofte form på store flater rundt i huset på nattestid, til min mors store frustrasjon.


Fra jeg var 9 til 14 år var jeg så heldig at jeg fikk være med på oljemalingskurs for voksne, og lærte der om kunsten å manipulere lys og skygge for å gi form, dybde og perspektiv på bilder. Like viktig var leksjonen om å bygge opp et bilde; en prosess som involverer prøving og feiling, samt å omfavne feilene som en nødvendig del av den kreative prosessen.

Litt senere i tenårene kapret en grafisk designer hjertet til storesøsteren min, og jeg fikk da min første intro til dette spennende yrket. Min svoger var en god match for min søster, og en utdanning og karriere innen grafisk design var en god match for meg. 

Jeg sydde sammen min egen utdanning fra Westerdals, Kunsthøyskolen, Kristiania og Idefagskolen. På kunsthøyskolen, som jeg virkelig elsket å være en del av, fikk vi som elever rom til å utforske, dele og lære av hverandre. Vi var en gruppe på 13 elever, med hver sin helt unike stil.

Dette ga meg ikke bare muligheten til å dypdykke i design, men også til å forstå designets rolle i samfunnet. Vi ble oppfordret til å se nåtiden samtidig som vi lærte av historien og de som kom før oss. Det handlet om å forstå sammenhenger mellom samfunnet, kunsten, møblene og klesindustrien.



Hva eller hvem inspirerer deg?
På fritiden er jeg glad i å spille tennis. Tennis er en morsom, men også tidvis frustrerende sport. I likhet med design og maling er det nemlig ikke bare helt umulig å unngå å gjøre feil, det er en nødvendig del av veien til et godt resultat. Profesjonelle tennisspillere er svært inspirerende for meg. Ikke bare lærer de av sine feil på trening hver dag. De står i frustrasjonen av feil daglig i en konkurransesituasjon foran TV-kameraer og fullsatte tribuner. De havner konstant i situasjoner der de må vinne poeng, og en feil kan drastisk redusere mulighetene til å vinne kampen. At spillerne likevel klarer å beholde fokus på sine arbeidsoppgaver, uten å la frykten for å gjøre feil ta helt over, er utrolig imponerende. Her tror jeg vi har mye å lære.





Hvilket tips ville jeg gitt meg selv i starten av oppdraget/karrieren?
Den som intet våger intet vinner! Er man nybegynner i tennis kan det være en god strategi å sikte midt i banen for å minimere antall feil. For å lykkes på et litt høyere nivå må man imidlertid risikere litt høyere feilprosent ved å prøve på ting man ikke alltid er sikker på at vil gå bra. 

Nøkkelen er å lære av sine feil, samt å finne den riktige balansen mellom feil og trygghet. Slik er det for designere også. Du må tørre å gjøre feil for å utvikle deg over tid, men også for å oppnå resultater på kort sikt. For at et team skal kunne oppnå stor suksess må man skape et miljø der det er trygt å feile for enkeltpersoner.

Designdrypp med: Beate Ingebretsen

Vi snakker mye om digital produktutvikling, og hvordan det er en lagsport – at det krever mye av et kollektivt «vi»: man må ha sterke team og fremoverlente selskap. Og det er riktig. Seriøs digital produktutvikling krever et godt “vi” - det er så vanskelig at ingen kan gjøre det alene, og det krever større grupper folk. Og therein lies the rub. 

Fordi det er et krevende arbeid, som krever innsatsen til mange, med ulike nivåer av personlig tilknytning til arbeidet, krever det også en sterk leder, som får gruppen til å lykkes som gruppe, som dermed lykkes med arbeidet. Å være en leder er per definisjon ikke et “vi”, men et “jeg” - så dette skal handle om det helt personlige i å være en leder, og alt det krever av deg som individ. Er du klar?



Hvorfor legger jeg så vekt på ledelse?



La meg si litt om utkikkspunktet mitt for betraktningene jeg deler med dere i denne artikkelen. 

Jeg er avdelingsleder i et relativt stort konsulentselskap, med sånn ca. 600 håndverkere som hver dag sitter i sine produktteam - gjerne i flere år av gangen - og driver digital produktutvikling. Jeg er også oppdragsleder hos en av kundene våre, hvor vi har en liten håndfull av disse 600 spredt på et utvalg team som gjør det samme. De er utviklere og designere og produktfolk, og det de aller helst vil, er å lage skikkelig bra produkter - ting som funker og gir effekt. En stor del av ansvaret mitt i disse rollene, er å hjelpe folka våre å lykkes med det de gjør - slik at kundene våre lykkes med det de vil gjøre, og folka våre trives i jobben sin hos oss og hos dem.

Det gir meg en ganske bra interesse for folks hverdag i teamene de er i.

Og er det én frustrasjon jeg får høre fortere enn noe annet, så er det når de savner reell ledelse i teamene de er i.

Min tredje rolle er å selv være både i og mellom team som fagperson og håndverker - og jeg deler denne frustrasjonen så fort jeg merker fraværet av reell ledelse i teamet. Og jeg ser det også så altfor ofte. Team kan slite med mange ting, og likevel mestre mye, om de har en god leder! Men uten en effektiv leder, kan forutsetningene nesten være så gode de vil, og ting vil likevel oppleves som vanskelige.



Hvorfor trenger vi å snakke mer om ledelse når det kommer til produktteam?



Jeg synes det er blitt underkommunisert for lenge

Når vi snakker om ledelse av teams arbeid, har vi som oftest snakket om prosjektledelse; å holde orden har vært det grunnleggende - administrere tid, kost og oppgaver slik at tidsfrister blir nådd innenfor et gitt budsjett. Det holder ikke lenger, når vi er over i kontinuerlige leveranser av digitale produkter og tjenester, hvor team som bygger dem også skal drive dem, og ta ansvar for effekten av dem. Likevel opplever jeg at vi fremdeles ikke er kommet oss videre til å snakke om *ledelse* på teamnivå. Og i en tight-loose-tight-styring er det det som trengs.

Vi tilnærmer oss det ofte for teknisk

Vi løser ofte ledelse gjennom å sette inn ulike roller, og beskrive ansvaret til hver av disse. Vi regner med at når vi har pekt på noen og gitt dem en hatt som sier «lead», så er det løst. «Jamen, vi har jo en teamlead, det er jo hens jobb». Men å lede er ikke å sjekke av en oppgaveliste, og det å gi noen ledertittelen er ikke det samme som å sikre et team reell ledelse.

Produktutvikling er lagsport - ikke demokrati

Vi er avhengige av sterke team for å få til bra produktutvikling. Team blir sterke når de har gode ledere. Det holder ikke at man har flinke enkeltindivider som sitter på pulter ved siden av hverandre, eller er tildelt samme oppgave. Alle må bidra til et felles arbeid. Og vi kan ikke stemme oss frem til hver eneste beslutning. 



Team der ingen leder, opplever fort



1. Passivitet 

Uenighet i gruppa fører til stillstand – ingen tar beslutninger, så lite kan bli gjort dersom det ikke er helt klart for alle hva som skal gjøres og hvordan hver og en av dem trenger å gjøre det.

2. Falsk harmoni eller høyt konfliktnivå

Ingen tar tak i utfordringer med prosess, gruppedynamikk eller manglende retning fordi det er ubehagelig å peke på indre problemer i et team du selv sitter i - det er jo dine egne kolleger og deg selv du må peke på. Eller du kan ha situasjonen der uenighet har boblet opp, fordi folk er blitt for frustrert med hvordan noe er - og ingen griper inn og løser det ut. Uenighetene blir enten liggende og ulme, eller ende opp med å eksplodere.

3. Lavere prestasjon

Når ingen setter retning, vet ikke teamet hva det skal jobbe etter. Hvert enkelt individ følger sine egne innskytelser, eller teamet ender med å forvalte bestillinger utenifra, og produktet de skal ha ansvar for ender opp som et konglomerat av alle de ulike tingene som gjøres, med lite påvirkning på effekten som egentlig ønskes av selskapet og brukere.



Hva mener jeg egentlig med ledelse?



Du kan ha en teamlead, techlead, produktleder, ux lead, scrum master i teamet – og likevel mangle noen som leder.

Det er hva du gjør i rollen som betyr noe – ikke hva du kan peke på at du er.

Å lede er et verb, og du gjør det først når folk faktisk følger deg.

Utviklingen jeg ønsker meg hos mange folk med tittelen “leder”, er at de går fra å gjøre ting på bestilling eller ut ifra en stillingsbeskrivelse – å være en ren administrator eller prosjektleder - til å begynne å finne frem til hva de selv ønsker å oppnå med produktet og teamet, tenke utenfor stillingsbeskrivelsesboksen, og si om seg selv: jeg kan jo lede! Og så: at de tar makten som ligger i det å lede. Får folk til å følge seg.

«Makt» er et litt skummelt ord, er det ikke? Du tenker fort at dersom du skal ta makten noe sted, så betyr det at du er en diktator. Veldig mange kvier seg for det. Får litt berøringsangst for det. Jeg skjønner det.

Naturlige ledere



Men makt finnes i former som trenger å være diktatoriske. Vi trives når vi har trygge ledere rundt oss. Uformell makt handler om å være matriarken i flokken – bestemorelefanten som de andre stoler på og følger. Matriarken har masse makt! Hun bestemmer hvor flokken skal gå – ikke gjennom pisk og diktatur, men fordi flokken stoler på henne og at hun kan lede dem trygt over savannen til neste vannhull.

Sånn er det også med oss. Vi lener oss mot de naturlige lederne:

De vi ønsker å lære av

I et produktteam er de kompetente kjennetegnet av forståelse for digital produktutvikling. De som vet hvordan det er å jobbe i team, som enten selv har vært teknolog, designer eller annen fagperson i et digitalt produktutviklingsteam. og som ser ut til å ha et godt grep om hvilken retning vi burde bevege oss i for å lykkes.

De som håndterer «juksere» 

Fordi vi er et samarbeidende vesen, er vi sårbare og sensitive for å bli utnyttet - å gi noe til en gruppe av sine egne ressurser, kan være et sjansespill. «Juksere» er både folk som ikke gjør sin del av teamarbeidet – det kan være rene unnasluntrere, men også de som vil jobbe på en måte som ikke er hensiktsmessig, blir for kontrære, stjeler andres arbeid, eller ikke er gode til å samarbeide. Fordi det å korrigere andre er så ubehagelig for folk, blir de som tar på seg å gjøre det – som tar den byrden – fort noen de andre lener seg på.

De som yter mest

Fordi det vi gjør er så vanskelig, krever det alles superinnsats. En produkteier som ikke jobber med teamet, og gjør «sin skjerv» vil ikke bli sett på som leder. Flokken din vil anerkjenne tittelen, men de vil bli frustrert over at du ikke er der og gjør jobben med dem. Produktledere som ikke er til stede er det per definisjon heller ikke mulig å jobbe sammen med dem. Teamet får ikke noe inntrykk av innsats, og kan derfor heller ikke vurdere personen som leder.

De som definerer «oss» 

I denne sammenhengen er tosidig: både å skape en opplevelse av at teamet faktisk er en gruppe, et «vi» som hører sammen, og å posisjonere teamet tydelig opp mot andre team og hva disse gjør.



Så hva ligger i å faktisk lede et produktteam?



Det er noen helt egne krav til det. Fordi gode produkter krever helt klare mål, riktig prosess, og sterke team. Dermed krever det også at noen i teamet tar ansvar for:

å definere hva vi egentlig gjør her, og hvorfor. Sette retning for arbeidet vårt, som gir oss som team noe å følge – sammen.

at vi fungerer som gruppe. Både at vi får levert, og opplever selv at vi leverer godt. Det betyr å ta ansvar for både indre prosess – og ytre omstendigheter som påvirker leveranseevnen vår.

at vi er en god gruppe å være i. Sosialt og faglig. Det betyr ikke bare hygge – det betyr trygghet når vi er uenige, og at vi faktisk får til å være uenige og diskutere! For å levere på et nivå som faktisk digitaliserer, er vi nødt til å utfordre hverandre – uten å gå i oppløsning som team.

Og dette savner vi ofte fra produktlederne våre.

Høres det mye ut? Husk at å ta ansvar ikke betyr det samme som å utføre. DU trenger ikke være den som fikser prosessen. Men du må kunne skjønne nok til å se om noe er gærent, og kunne sette i gang de riktige folka til å fikse det. Så du må ha nok kompetanse på digital produktutvikling til å kunne være en naturlig leder i det.

På sett og vis er det det samme, egentlig, om det er produktlederen for teamet eller noen andre som tar dette ansvaret - så lenge noen gjør det. Det som ofte likevel blir problematisk, er når den formelle beslutningsmyndigheten for disse tingene ikke ligger hos samme person som tar mest ansvar for det. Da vil teamet fort havne i en spagat, hvor de ser til den de oppfatter som sin naturlige leder - men blir ventende på den formelle lederen. Som produktleder har du gjerne den formelle beslutningsmyndigheten i teamet - om du ikke også tar den uformelle makten og blir den faktiske lederen, hindrer du fort teamet i å gjøre jobben. 



Hvordan utøver vi ledelse?



Gary Yukl har gjennom analyser av forskning på ledelse, funnet at der folk opplever at de blir ledet på en god måte, og der team presterer bra, utøver lederen deres adferd innen følgende 4 kategorier:

Oppgaveorientert adferd, relasjonsorientert, endringsorientert og adferd knyttet til ekstern orientering.

Adferd er hva jeg sier og gjør, og det er forskjellig fra hva jeg tenker og ønsker, altså intensjonene mine. Der ledelse har effekt, er det fordi lederen får til å utøve disse adferdene, ikke bare kjenne til dem.

Hos oss i Bekk har vi snakket en hel del om hvordan personlighet påvirker lederutøvelsen. For det gjør det helt klart. Men personlighet dikterer ikke om du får til å lede eller ikke. Det påvirker nok hvilke av disse adferdene du gjør mer naturlig enn andre adferder. Og dét er nyttig å ha selvinnsikt på, for det kan hjelpe deg å utvikle deg selv som leder langs de aksene du ikke er så sterk. Som leder påvirker min personlighet adferden min på den måten at jeg helt naturlig lener meg inn i oppgaveorientert og endringsorientert adferd. Relasjonsorientert adferd krever mer av meg, jeg trenger oftere påminnelser om å gjøre det, og jeg må øve mer på det for å gjøre det godt. Mange ledere jeg ser rundt meg er motsatt av meg: gode på å se folk, men dårligere på å tydeliggjøre mål og hjelpe team med å se hva vi kan få til.



Hva savner folk i digitale produktteam aller mest av sine produktledere i dag?



Noen som tar beslutninger - ikke bare spør utenfor teamet om hva som skal gjøres

En tydelig retning for teamets arbeid – en kobling mellom hva teamet jobber med og hvorfor det er viktig for virksomheten

Gode rammer for hvordan teamet jobber; en leder som får til å påvirke omstendighetene teamet jobber innenfor

Noen som stiller krav til teamets leveranser; ja, folk vil ha det hyggelig – men flinke folk vil også levere og kjenne at de strekker seg

En som sikrer teamets – og teammedlemmenes – autonomi



Dette er en stor pakke å be om, jeg vet.

Men så er det vanskelig å være en god produktleder, og! Det er ikke bare noe du hopper inn i. Det er noe du må vokse inn i. Å lede er vanskelig. Men jeg har tro på at folk kan klare det.

De må bare begynne å tenke det om seg selv – at de skal lede.



Så hva gjør du nå?

Å lede er en veldig personlig sak. Vi gjør det gjennom oss selv - det finnes egentlig ingen andre verktøy du kan bruke for å få det til annet enn din egen adferd. Alt annet kan maks bli ganske ustabile støttehjul. Det betyr at veien frem til å bli bedre på det går via selvinnsikt og selvrefleksjon.

Disse 15 adferdene: ta dem med hjem, og tenk over hvordan du utøver dem. Hvilke av dem gjør du naturlig, hvilke av dem gjør du ikke så mye av? Hva må til for å gjøre mer av det?

Og be om hjelp. Det er VANSKELIG å lede. Be om at noen setter av tid til at dere kan reflektere sammen over det, at dere kan diskutere det som lederkolleger og hjelpe hverandre med det. Huk tak i meg! Jeg kommer mer enn gjerne bort og snakker med dere om det! Dette er for viktig til at vi kan la det være godt nok å fikse på egenhånd, hver og en av oss.

Og i mellomtiden: husk at titler ikke betyr noe. Ikke vent på at noen skal gjøre det for deg, eller at noen skal gi deg et mandat. Ta makta. Bli en matriark. En bestemor-elefant. Led teamet ditt.

Produktlederen som L E D E R

During my time as a React developer, I have experienced that you never should mutate your state, as it leads to weird bugs when rendering your components. This article will show you some tricks on how to make your state immutable, achieving a more bug-free UI.

Your state and values should be immutable, always. This means that you should not modify the state, but rather make a copy of it and then add or remove data. This is because React depends on knowing if some state or props have changed to be able to decide if the component needs to re-render. React compares the previous value with the potentially updated value. If previous value is mutated, it will not re-render properly because React may not detect the changes.

Take a look at the different ways to avoid mutating your values.

Immutable variables

Historically, JavaScript developers commonly used let or var when creating variables. When ES6 came, it introduced the const keyword which was a new way to create a variable. By using const you cannot change the value of the variable after it has been created. Consistently using const enforces you to make a copy of the variable when creating a new value.

Immutable arrays

Updating arrays is common to do in React, and if you are experienced with JavaScript it may familiar to use the .push array function. By using the .push method you are mutating your list, which is unfortunate. Make a copy instead and add the desired value:

If you want to modify, filter or remove values in your array, you can use the .map, .filter or .reduce array functions. These functions loop through the array and creates a new list, and they don't mutate the original list. Take a look at an example with .map.

Immutable objects

It is also not recommended to mutate objects as well. You should always make a copy by spreading the values from the object and then modify the values as you want.

Please don't use lodash

While Lodash provides various methods for handling lists or objects, such as sorting, grouping, or checking for equality, it's not the most optimal solution. Lodash consumes a significant amount of space and, more importantly, it mutates your data. Some lovely developers have created this great Github project named You might not need lodash, giving you an overview of how to make similar functions you can add directly to your code without downloading a third-party library. This is great since they give you functions that are immutable, and you are getting a deeper understanding of how the code actually works.

(They also created an eslint-rule you can add to your project if you are using lodash, giving you a warning where you use functions from lodash that can be replaced).

___

Hope you learned something about immutability!

Immutable state

Norway is known for its fjords, glaciers and cold winters. The latter is suboptimal for cyclists, which is why we ended up creating dundring.com; a free and open source in-browser training application created to control and track your training with a smart bike trainer ⚡️

This article will go through the magical story of how our hobby project dundring.com was made 🎅

Norwegian weather and cycling during the winter

Cycling during the winter in subzero temperatures and snow is something only a fraction of the Norwegian cyclists endure. Most of us take our cycling sessions indoors with a bike trainer, which can be thought of as a treadmill for bikes. However, working out indoors on a bike trainer can be monotonous and feels harder than riding outdoors, which may tempt you to join the ranks of the tough winter cyclists. 

Fortunately, there are applications that strive to make this experience as bearable as possible, such as Zwift, the leading bike trainer software.

Zwift is a massively multiplayer online cycling and running physical training program that enables users to interact, train, and compete in a virtual world. - Wikipedia

Zwift has many great features, and it's really fun to see a 3D version of yourself cycling in the virtual world, especially when you are able to overtake lots of other virtual cyclists. 

As we were using Zwift, we realized that we did not really use the killer features of Zwift; the massive living world, group rides and races. We were mostly using Zwift to control the pedaling resistance over time, and were not really looking at anything else than the real time numbers such as Watt, heart rate and elapsed time. 

This sparked a question; why can't we create our own bike trainer app using Web Bluetooth?

Creating a minimum viable product

After experimenting with Web Bluetooth for reading heart rate data, the next step was being able to control the bike trainer. One thing was reading the power data, but actually being able to send commands to the device was not straight forward for someone new to Web Bluetooth. 

Combining data from a heart rate monitor with power data from a bike trainer with some nice graphs, and some power controls, resulted in our first minimum viable product of dundring.com.

Workouts don't create themselves

The ability to create custom workouts is a fundamental feature of any cycling trainer app.

Every workout in dundring.com is built around ERG mode, a setting on smart trainers that automatically adjusts resistance to match your cadence, essentially turning the bike trainer into a "cycling treadmill".

The workout editor on dundring.com allows you to predefine the resistance for different stages of a workout. This feature is ideal for creating interval sessions with varying power intensity and for easier rides with consistent and low intensity.

As shown in the current interface of the workout editor, a workout is a sequence of time intervals, each with a targeted power output, measured in watts and percentages.

But what do these percentages represent?

They are calculated as a percentage of your Functional Threshold Power (FTP). FTP is essentially the average power you can sustain for one hour. In the cycling community, it's common to base power targets on this metric. Using percentages of FTP, rather than fixed numbers, makes the workouts adaptable and applicable to every cyclist. The workouts automatically adjust to the rider's current level by scaling based on their FTP. This is handy when sharing workouts with your friends, which dundring.com allows you to do.

In addition to the workout editor, dundring.com also offers a library of workouts you can use out of the box, or use as template for your own custom workouts.

You didn't workout if it isn't on Strava

In the cycling community, there's a popular saying: "If it's not on Strava, it didn't happen". Recognizing this, we've made it possible for users to upload their rides from dundring.com to Strava. Our current approach allows users to export and download their session data, which includes data about laps, heart rate, power, cadence and simulated gps points based on estimated speed and distance.

The speed and distance are estimated based on the rider's current power output, using approximations for factors like gravity, rolling resistance, and aerodynamic drag. For those interested in the specifics, the full formula is available here: Cycling Wattage Calculator.

Group sessions

One of the primary reasons people ride bikes is to enjoy group rides with friends in the sun. Even though the weather might not be on our side during the winter, it might still be nice to be able to ride together. This led us to implement a group session feature, allowing users to create a live group for others to join. Everyone in the group are able to see each other's live data. 

Tech stack

For the nerds, dundring.com is written in TypeScript. The frontend is React using Chakra UI components, the backend is Node using Express and also Prisma as an ORM connected to a Postgres database. The project is structured as a monorepo using Yarn Workspaces with Turborepo 🤓

Where is dundring.com headed?

Our goal with dundring.com is to have an easy to use and lightweight application with all the necessary features needed to make the indoor cycling season alright. It also serves as a playground where we can explore new ways of indoor training, potentially making the winter a bit less unbearable for cyclists in colder parts of the world. ☃️



Try the app at dundring.com or check out the source code on GitHub! 🤠

If you want to contribute or have any questions, head over to the dundring.com Slack workspace 🤓

Surviving the Norwegian winter as a cyclist with dundring.com

Gjennom kvalitativt innsiktsarbeid utforsker vi hva vi skal lage og hvorfor. Når en person i et brukerintervju forteller sin historie, så skaper det empati. Det gir en mulighet til å sette seg inn i og forstå en annen persons perspektiv. Perspektiv på verden. Perspektiv på organisasjonen du jobber i. På tjenesten teamet leverer.

Hvilke intervjuer med brukere har du fått mest ut av, og hvilke har du sterkest i minnet?

Det jeg husker best fra innsiktsarbeid er når folk forteller sin historie. Ikke om hvordan det var å trykke rundt i en app, men hele grunnen til hvorfor man brukte tjenesten - og hvilken situasjon en da var i.

Gjennom å jobbe som designer i NAV har jeg fått innblikk i flere vanskelige livssituasjoner. Å miste jobben. Bli permittert under pandemien. Å prøve å komme tilbake til hverdagen med jobb etter flere år med sykdom. Det å savne å ha kollegaer. Å møte NAV-veiledere som beskriver hvordan det er å jobbe med folk som har det vanskelig.

Når vi intervjuer brukere graver vi gjerne i konkrete problemstillinger knyttet til det produktet vi lager, men jeg tror vi oftere trenger å samle historier. En barriere for å gjøre intervjuer kan være at teamet ikke helt har landet på hva en ønsker å finne ut av. Dere trenger ikke egentlig vite det. Vær nysgjerrig på brukerens historie, for det vil gi et mye bredere kunnskapsgrunnlag. Gjennom historiebaserte intervjuer vil teamet forstå hvem vi lager produktene til, hvilken situasjon brukerne er i og hvordan situasjonen føles.

Historier er ikke ferskvare

Vi i bransjen sier gjerne at innsikt er ferskvare, men jeg er egentlig ikke helt enig i det. Hvis du opplever et innsiktsøyeblikk som treffer deg midt i hjerterota så er ikke det ferskvare, det er noe du har med deg resten av karrieren. Når noen forteller om sin situasjon og hvordan de opplevde møtet med tjenesten, så kan det være aktuelt for produktutviklingen i årevis. Detaljene i et digitalt produkt endres, og innsikten om opplevelsen av selve brukergrensesnittet er ofte ferskvare. Men historien om folk og hvilke situasjoner de er i når de trenger å bruke tjenesten som teamet lager, det endrer seg ikke nødvendigvis drastisk over tid. For eksempel i NAV så vil det alltid være aktuelt å høre om hvordan det oppleves å miste jobben.

Hva gjør historier med oss?

Alle som tar valg for produktet, og dermed påvirker brukerens opplevelse, bør ha en forståelse for situasjonen til de folka vi lager dette til. Å høre folks historier gir alle i teamet bakkekontakt. Vi får empati og bedre forståelse. Det påvirker hva vi prioriterer å jobbe med, og hvordan vi løser det. Og det skaper fantastisk god stemning i teamet når vi sammen forstår at det vi lager faktisk kan hjelpe folk. Det er jo det alt arbeidet vårt handler om!

Alle i teamet bør være med å høre historier til folk – uansett hvilken rolle en har i teamet. Hele teamet kan ikke være med på alle intervjuer, det er overveldende for personen som blir intervjuet. Vær maks tre per intervju, og bytt på hvem som er med.

Fokus på historiene til sluttbrukerne

Hvis du designer et fagsystem, er det interessant å høre historiene til de som er brukerne av akkurat det systemet. Men fagsystemet finnes av en grunn - hva behandler fagsystemet? Hvem er sluttbrukerne i tjenesten dere leverer? Det er historiene om sluttbrukerne som er de viktigste historiene å få innblikk i. Designet av fagsystemet påvirker sluttbrukerens opplevelse. En kan for eksempel gjennom fagsystemet nudge til økt brukerinvolvering eller legge opp til at sluttbruker får bedre innsyn i saksbehandlingen. For å kunne vite hva som er riktig å lage, så trenger en å forstå sluttbrukerens situasjon og behov.

Let frem historier fra ulike kilder

Oppsøk historier fra andre kanaler, for eksempel dybdejournalistikk eller forskning. Finnes det artikler i media som er relevant for det du jobber med? Det er kanskje spesielt relevant for de som jobber i offentlig sektor. Journalister er eksperter på å fortelle historien til folk. I NAV har blant annet historien om Ingrid (På innsiden av NAV) og Emilie (Alt det jeg er) gjort dype inntrykk og har påvirket mange valg vi i teamet har gjort opp gjennom årene.

Aldri nok historier

Dette innsiktsarbeidet blir du aldri ferdig med. Har du hørt historien til tre forskjellige folk, så er det historien til disse tre folkene. Da kan en ikke generalisere og bare regne med at slik er det nok for folk flest. Og det kan være fristende å tenke at vi trenger mer innsikt – hele tiden. Jo mer vi lærer, jo mer finner vi ut at vi ikke kan. Når vi lager og forbedrer produkter, så kan det være så fristende å bare undersøke litt til, bare grave litt til, og enda litt til. Da kan det være lett å falle dypt ned i det Ida Aalen beskriver som analysefella. Vi må rett og slett akseptere at vi ikke kan finne ut av alt. Vi kan ikke få alle brukerne sine historier. Og det er helt ok. Se på innsikten som det det er: historien til ett menneske. Historien er så utrolig viktig for å skape mer forståelse og mer empati med brukerne.

Vær nysgjerrig. Gi brukerne muligheten til å fortelle sin historie. I den travle, smidige hverdagen må vi jobbe for å øke antallet av disse innsiktsøyeblikkene. Hig etter å forstå folks opplevelse av produktet dere lager, av tjenesten i en helhet og av situasjonen folk er i når de møter det dere lager.

18-Dec

Today's posts

Fire utfordringer for digitale produktutviklingsteam i offentlig sektor

Designdrypp med: Beate Ingebretsen

Produktlederen som L E D E R

Immutable state

Surviving the Norwegian winter as a cyclist with dundring.com

Kraften i historiebaserte intervjuer